Mount root filesystem from initramfs

59,888

Solution 1

exec switch_root /mnt/root /sbin/init

https://wiki.gentoo.org/wiki/Custom_Initramfs#Init

Solution 2

It depends on the kind of problem, if the problem was borking the initramfs image itself then you'll need to actually regenerate it (run update-initramfs) to fix things. Remember the initramfs file system is a RAM filesystem, so to fix anything you need to fix the compressed initramfs image and/or fix the root filesystem.

I've used the following procedure on an LUKS encrptyed Ubuntu system in order to resume a boot broken by a bad crypttab.

First, I decrypted the partition

cryptsetup luksOpen /dev/nvme0n1p3 nvme0n1p3_crypt

Note the device_crypt isn't random. It needs to match the name that's normally used when your system mounts (partition + _crypt seems to be standard).

Next, you need to activate the Volume Groups on that now-decrpyted partition.

vgchange -ay

Now, you can try mounting the file systems, /, /boot, proc, swap, etc, and getting things running that way.

Though in my case all I had to do was type exit and initramfs saw the logical volumes sitting there and happily resumed the boot. At that point it was easy to fix the damange and run update-initramfs -u

Solution 3

Simply run fsck command without options from initramfs then reboot

eg: the root partition is sda3

fsck /dev/sda3

Solution 4

If the root= parameter is correct and the issue is just that the necessary device isn't available (for example because the initramfs failed to assemble an md RAID), then it's enough to make the device available manually, for example:

mdadm --assemble ...

Then check that the device is there and if everything looks good, hit ctrl + d or type exit to quit the initramfs shell. The initramfs will then mount the root filesystem and continue to boot as usual. After the system has booted, you should then repair the underlying issue, for example by running update-initramfs -u.

I haven't yet found a way to tell the initramfs to boot a different device than what /proc/cmdline says. Maybe someone else has an idea?

Solution 5

normal procedure is

  1. mount /dev/sdX /mnt
  2. fix problem on /mnt
  3. reboot

You might want to

  1. mount /dev/sdX /mnt
  2. fix /mnt
  3. umount /mnt
  4. mount /dev/sdX /
  5. finish boot manualy

This is not recommended, you'll have to do it on every boot. In a production environment, you can't be sure manual boot follow same steps as automatic one.

However in a emergency with critical data, step 5 usualy boil down to:

  • 5.1 set up network
  • 5.2 copy important file to safe place
Share:
59,888

Related videos on Youtube

MathematicalOrchid
Author by

MathematicalOrchid

Updated on September 18, 2022

Comments

  • MathematicalOrchid
    MathematicalOrchid over 1 year

    It's a common scenario. For whatever reason, the initramfs (OpenSUSE, in case it matters) has failed to find the root filesystem, so it drops you into a rescue shell. I know perfectly well what device needs to be mounted though. My question:

    What is the correct procedure to mount the root filesystem and continue the boot sequence?

    Presumably that's the whole point of the rescue console. And yet, nobody seems to have documented how you actually do this.

    Obviously I can mount the root filesystem somewhere. But how do I make that the root of the filesystem tree? And now do I continue the normal boot process after that? (I thought just exiting the shell would do it... but it doesn't.) What exactly do you need to get mounted before you continue, and how do you continue?

    • Eric Renouf
      Eric Renouf almost 8 years
      I could be wrong, but I think once you're in a rescue shell you can't continue the current boot, you fix things so the next boot will succeed
    • Martin von Wittich
      Martin von Wittich almost 8 years
      @EricRenouf manually booting the full system may very well be the easiest way to fix such an issue. I had problems in the past where the initramfs failed to open my cryptsetup-luks encrypted root partition, and the easiest fix was to manually boot it and then run update-initramfs -u. I absolutely couldn't get it working when I just chrooted into the root filesystem from a rescue system; the resulting initramfs was always broken.
    • Gilles 'SO- stop being evil'
      Gilles 'SO- stop being evil' almost 8 years
      Is it actually an initrd, or an initramfs? (Just because the file is called initrd doesn't mean that it's one: most distributions have switched to initramfs but keep calling the file initrd.) What distribution are you using (as what the initrd/initramfs does depends on what the distribution put there)?
    • MathematicalOrchid
      MathematicalOrchid almost 8 years
      @Gilles I'm pretty sure it's actually initramfs. Not sure if it actually makes a difference though; either way, I've got a mini filesystem and I need to mount the real filesystem. (OpenSUSE, in case it matters.)
  • user2121874
    user2121874 over 6 years
    I believe the "actual" question of the original poster was "How exactly do you do '5. finish boot manualy'?"
  • jaam
    jaam about 5 years
    The reboot just dropped me to grub shell instead of initramfs shell. Now I'll do everything over again to get to initramfs shell
  • janh
    janh almost 4 years
    This worked for me. reboot didn't do anything, but simply running exit after completing the checks continued the booting process, now with a good file system.
  • Vishal K
    Vishal K almost 3 years
    I had a similar problem running fsck give clean. But I still won't able to boot normally.