"An unexpected error has occured" during Chromebook recovery (fix)

Some time ago I bought a Samsung Chromebook Plus V2 (with LTE connectivity, codename nautilus). Despite not being a huge fan of Samsung, I have to admit they make beautiful screens, and their stylus feel great to use. I end up loving the odd aspect ratio (3:2), and the keyboard, although I’ve used better, is quite usable. I bought it with the goal of keeping my work/personal life a bit more divided. In the end I didn’t use it as much as I would’ve liked.

After some time of getting a bit annoyed by the small eMMC (32G) I went and installed a full UEFI ROM. I had some audio issues but I was able to sort them out (*cof cof* open source is awesome).

Some time went by without actually using it for anything productive besides sporadically trying out different distros, I wanted to use it to study the scriptures we use in the church I go to so I needed to go back to stock ChromeOS.

I used the same script to go back to the stock firmware (of course I made a backup), and then I ran Chrome’s recovery utility to reinstall the OS, and to my surprise (and panic) it threw a beautiful “An error has occurred” message. After some googling I found this reddit post that mentions the nautilus recovery images are broken, so I went and downloaded an old image (thanks to archive.org). The download was taking a long time and I wanted to see what was going on with the recovery, so as I waited I started trying to find how to access the logs.

In the end, chrome is linux, so pressing CTRL+F2 or CTRL+F3 (in this device F2 is the next button and F3 is reload) take you to a different virtual terminal. In VT2 there are some logs and in VT3 there is the full recovery script debug output. I saw something about it not being able to mount /dev/sda1 and some logging errors, so I assumed the logs went to this partition (I’m actually not sure about this, but this was my thinking at the time). I took the disk out and tried to mount it in my notebook and well, the partition was a bit broken:

$ sudo file -s /dev/sdb1
/dev/sdb1: Linux rev 1.0 ext2 filesystem data, UUID=8ac56793-38e6-417e-ad8c-07120b3c159d (large files)

$ sudo mount /dev/sdb1 /home/fermino/recovery
mount: /home/fermino/recovery: fsconfig system call failed: Structure needs cleaning.
       dmesg(1) may have more information after failed mount system call.

So of course I fsck’d it, and after some SEVERE DATA LOSS warnings it was done.

$ sudo fsck -a /dev/sdb1
fsck from util-linux 2.40.1
e2fsck 1.47.1 (20-May-2024)
ext2fs_check_desc: Corrupt group descriptor: bad block for block bitmap
...

At this point it kind of clicked that maybe the errors in the recovery were just because this partitions was broken, and as I found no logs in the partitions and I would lose nothing trying it again (besides 5 minutes maybe), I just went for it. (As as side note, I think I might’ve deleted some stuff from that partition when I executed fsck on it, but who knows).

In the end, that was effectively the issue. The recovery started and finished with no errors, and it’s kind of cool that you can see the script dd‘ing the partitions if you go to VT3.

Anyway, the old recovery images probably work too, but they’re a bit annoying to find, and I found it easier to just fix the image I had in hand instead of downloading and flashing an old one. I don’t know why google/samsung doesn’t fix this, but as chromebooks are a bit “disposable”, it doesn’t feel that odd. Not that I agree with it but well…

In a different topic, I’m seriously thinking about replacing the eMMC it has and upgrading it to 64 or 128G. It shouldn’t be too painful because well, it’s just linux, right? And it’s x86, so not dealing with any uBoot configs here. In theory replacing it and migrating the data to a new one should be sufficient, but that’s for another day :)