Fsck fails at boot: I/O error

Hello, I managed to get myself in a stupidly disasterous and disasterously stupid accident.

While a dom0 update was in progress I put my system to sleep as I was suddenly called away. After turning the computer back on it was unresponsive after which I manually rebooted it and no domain could be spawned.

After another reboot the startup began to fail at the fsck of /dev/mapper/qubes_dom0-root stage with the error code 4. I manually fsck-ed it with -yc (another dumb mistake) and it couldn’t proceed due to Input/Output failure.

I made an image of /dev/mapper/qubes_dom0-root with testdisk. The plan is to fsck it and then overwrite the original partition with the fixed version. Is this the right approach?

I would truly appreciate some assistance in preventing this string of stupid decisions turning into an even longer string of stupid decisions. Thank you.

Gut instinct reply:

I/O error generally makes me look for a spare hard disk to make a full image of the entire device, using a livecd or rescue disk/key.

It might just be paranoia from the days of spinning hdd, but I always feel reassured with at least that stored away…

Not sure how best to fix the filesystem problem :frowning:

Oh it’s even worse: I’ve got an ssd. Don’t really have a hard disk either but I backed up all of the crucial crucial stuff.

It worked! But now I have another problem…
I keep receiving

Failed to mount boot-efi.mount - /boot/efi
Dependency failed for local-fs.target - Local File System.

I guess I’ll run fsck on the boot partition…

EDIT: can’t do that. All the posts online suggest it’s some kind of vFAT issue, but I have no idea how to deal with this. Oh well…

That error may be from something related to the most recent kernel installation, which did not complete. Do you have an option to try an older kernel when you get to Grub?

If that does not get you to a point where you can redo the update, then maybe it will be necessary to boot another linux, and chroot to Dom0. There may be instructions somewhere here or in the docs … Let us know if you are not sure.

That is the first thing I did, doesn’t really change much.

I have considered the chroot option but couldn’t figure it out, so a guide would be very much appreciated.

I reckon the links in this post from @MellowPoison might do it:

I have not tested it, but up until you mount the /proc and other filesystems and get a prompt it looks reasonable. I haven’t tested it though. You might need to adapt it a bit.

If possible, avoid connecting to the network in your live or rescue distribution - QubesOS developers work hard to keep Dom0 isolated. Keep wired network unplugged before starting, and skip giving wireless to it. If you get desperate, networking can be tried later.

If your current blockage is at the “root password or ctrl-D” prompt, then setting the root password might be useful later, if you have to do a lot of fixing.

For fixing the failed update, maybe only dnf -C update will be enough: the -C option should use cached data inly, and will avoid taking Dom0 online.