Fun with fsck on Fedora – avoiding mounted partitions and handling LUKS encrypted ones
I run Fedora on a few of my machines, and inevitably over the course of time the filesystem will need to be repaired because of orphaned inodes, wrong free byte counts, etc.
Typically when EXT4 errors are detected during boot, Fedora will detect this and offer to drop you into “Emergency mode” or continue.
example:
|
Welcome to emergency mode! After logging in, type "journalctl -xb" to view system logs, "systemctl reboot" to reboot, "systemctl default" to try again to boot into default mode. Give root password for maintenance (or type Control-D to continue): |
That’s all well and grand, however at this point of the boot sequence, some of the file systems are typically already mounted, making a forced fsck very dangerous (and highly not recommended).
If your rootfs became corrupted in a way that fsck refused to fix it in non-interactive mode, you will have to run fsck manually.
The easiest way I’ve found to do this is using the built-in ‘rd.break’ functionality before grub boots the kernel.
Simply reboot the system and modify the kernel’s cmdline, using grub edit command…
- Start your system and wait for the GRUB menu to show (if you don’t see a GRUB menu, press and hold the left Shift key right after starting the system).
- Now highlight the kernel you want to use, and press the e key. You should be able to see and edit the commands associated with the highlighted kernel.
- Go down to the line starting with
linux and add your parameter rd.break=pre-mount to its end.
- Then press Ctrl + x to boot.
|
The boot process will break just before mounting any filesystem. This means that you can now manually run fsck on any of your filesystems since they have not been mounted yet.
If this worked successfully, you can now reboot the system and go on with your life…
But what if my filesystem(s) are encrypted with LUKS?
First, congratulations on your above-average security consciousness. There is not a laptop or workstation I own in existence that has a single byte of my data left unencrypted. While the piece of mind and added security is nice, it adds another layer of complexity around performing fscks…
The exact method for fsck’ing an encrypted filesystem depends on how you have setup LUKS, and if you have LVM on top of LUKS or if you just have a filesystem within the LUKS volume.
If you don’t have LVM in addition to LUKS then you would probably do something like this…
|
cryptsetup luksOpen /dev/rawdevice somename fsck /dev/mapper/somename |
OR
|
cryptsetup luksOpen /dev/sda2 _dev_sda2 fsck /dev/mapper/_dev_sda2 |
If you used the LVM on LUKS option providied by the OS installer, then you’ll need to start up LVM. So vgchange -aly after opening the encrypted volume, then run fsck against the /dev/mapper/lvname .
|
Protip:
Like the rd.break solution? Dracut has couple other breakpoints you can use. To check full list, run:
grep -E 'rd.?break' /usr/lib/dracut/modules.d/99base/init.sh
Share on Facebook
Erik
Thursday, July 13, 2017
linux administration - tips, notes and projects
No Comment