- SurgicalOntologist
- Jun 17, 2004
-
|
OK, this is quite the journey, but bear with me...
I borked my ChromeOS Crostini VM (LXD container) during an upgrade. This is not unexpected as it's a beta feature and I would usually just start my container over, as I don't keep anything important on it and I have a backup in my office. However, my office is closed and in another city. And I just realized that without getting those private SSH keys I have a couple of servers I will not be able to access without traveling during COVID. (I used to have 2 regular use machines, now with only one I didn't anticipate this problem).
I followed these instructions to get a disk image. It might be worth noting for later this output from ChromeOS:
code:crosh> vmc list
termina (225341743104 bytes, min shrinkable size 267399462912 bytes, raw, sparse)
Total Size (bytes): 225341743104
crosh> vmc export termina termina.tar.gz
Export in progress: 963b5756-b9fa-4ef2-bb59-7e7f864122fd
Operation completed successfully
code:$ ls -s dGVybWluYQ==.img
220049612 'dGVybWluYQ==.img'
$ ls -l dGVybWluYQ==.img
-rw------- 1 user user 418591202918 Dec 29 20:24 'dGVybWluYQ==.img'
$ stat dGVybWluYQ==.img
File: dGVybWluYQ==.img
Size: 418591202918 Blocks: 440099224 IO Block: 4096 regular file
Device: 810h/2064d Inode: 13 Links: 1
$ file dGVybWluYQ==.img
dGVybWluYQ==.img: BTRFS Filesystem sectorsize 4096, nodesize 16384, leafsize 16384, UUID=728e3472-7c47-481e-a4cd-9475250187b7, 216445390848/418591199232 bytes used, 1 devices
$ sudo fdisk -l dGVybWluYQ==.img
Disk dGVybWluYQ==.img: 389.86 GiB, 418591202816 bytes, 817560943 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
code:$ sudo mount -v -o rootflags=usebackuproot,clear_cache -t btrfs dGVybWluYQ==.img /mnt/recovery
mount: /mnt/recovery: wrong fs type, bad option, bad superblock on /dev/loop7, missing codepage or helper program, or other error.
Edit: in case anyone is curious about the LXD side of things, here's what happens when I try to start it:
code:crosh> vmc start termina
Error: routine at frontends/vmc.rs:238 `vm_start(vm_name,&user_id_hash,features,user_disks)` failed: failed to start lxd: `FAILED`: Starting LXD failed: Failed to lxd import container: Error importing container. Stdout/err: . Error: exit status 1
SurgicalOntologist fucked around with this message at 11:32 on Dec 30, 2020
|
#
?
Dec 30, 2020 11:26
|
|
- Adbot
-
ADBOT LOVES YOU
|
|
|
#
?
May 4, 2024 14:49
|
|
- SurgicalOntologist
- Jun 17, 2004
-
|
No luck
code:$ sudo btrfs restore dGVybWluYQ==.img /mnt/disks/tmpdisk2
checksum verify failed on 47481929728 found 000000B6 wanted 00000000
checksum verify failed on 47481929728 found 000000B6 wanted 00000000
checksum verify failed on 47481929728 found 000000B6 wanted 00000000
bad tree block 47481929728, bytenr mismatch, want=47481929728, have=0
Couldn't read tree root
Could not open root, trying backup super
checksum verify failed on 47481929728 found 000000B6 wanted 00000000
checksum verify failed on 47481929728 found 000000B6 wanted 00000000
checksum verify failed on 47481929728 found 000000B6 wanted 00000000
bad tree block 47481929728, bytenr mismatch, want=47481929728, have=0
Couldn't read tree root
Could not open root, trying backup super
checksum verify failed on 99355459584 found 000000B6 wanted 00000000
checksum verify failed on 99355459584 found 000000B6 wanted 00000000
checksum verify failed on 99355459584 found 000000B6 wanted 00000000
bad tree block 99355459584, bytenr mismatch, want=99355459584, have=0
Couldn't read tree root
Could not open root, trying backup super
|
|
#
?
Dec 30, 2020 11:41
|
|
- MarxCarl
- Jul 18, 2003
-
|
I can't mount it... tried all different btrfs options.
code:$ sudo mount -v -o rootflags=usebackuproot,clear_cache -t btrfs dGVybWluYQ==.img /mnt/recovery
mount: /mnt/recovery: wrong fs type, bad option, bad superblock on /dev/loop7, missing codepage or helper program, or other error.
from the "wrong fs type, bad option, bad superblock", I'd say the dumped image is bad, or the VM image is corrupt to begin with. Seems it doesn't know it's filesystem.
Things I'd try:
1. can you dump the VM with out compression? I've had compression screw images up.
2. sneaker net the image to the other machine, my work laptop will screw up images during network transfers so I rely on USB sticks, course I'm only dealing with a max 8GB image.
3. can you mount that VM drive in another VM and work on it that way?
Unfortunately that's all I got. I usually just flatten and reinstall at this point.
|
|
#
?
Dec 30, 2020 19:38
|
|
- SurgicalOntologist
- Jun 17, 2004
-
|
Thanks for taking a look. I already flattened and started setting everything up again, so those kinds of things are off the table. I transferred the image by upload to Google Cloud Storage.
I went a little deeper into btrfs recovery but never had any luck so I think I'm giving up.
I think the only fallout from this is the RPi in my parents basement (that I use for VPN since I'm in another country) and I guess I'll have to coach them to setup a monitor and keyboard and enable password authentication for a moment...
|
|
#
?
Dec 30, 2020 20:00
|
|
#
?
Dec 30, 2020 11:26
