Grub update fails because root FS appearing as diferent /dev/sdX on each boot

  • The problem I see about this is that when I reboot OMV the boot disk is relocated on another device and the previous one is not retained.

    This causes that the next grub update it will fail forcing me to fix it by hand with 'dpkg --configure -a' again.

    This has happened twice in about 10 o 15 days with the two recent grub updates.

    Take a look at this 8.8.2. GRUB 2 Configuration. Apparently is a bug on Debian Bullseye.

    After each reboot the device order of the drives changes and the next grub update will fail.

    May be there is some way to retain the boot drive association to /dev/sda. I don't know how to do it yet.


    Thank you

  • macom

    Hat das Thema freigeschaltet.
  • I've never seen this. Maybe because I have this in my fstab?


    /dev/disk/by-label/ssd-omv-6 / ext4 noatime,nodiratime,errors=remount-ro 0 1


    It mounts by label, not by device. You could mount by UUID also.

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

    • Offizieller Beitrag

    I've never seen this. Maybe because I have this in my fstab?


    /dev/disk/by-label/ssd-omv-6 / ext4 noatime,nodiratime,errors=remount-ro 0 1


    It mounts by label, not by device. You could mount by UUID also.

    I'm pretty sure it does anyway.. (granted, I installed Debian then OMV on top of it, but I don't think that matters)...


    Code
    # / was on /dev/sda2 during installation
    UUID=b5f88bb5-2b0a-4d3c-a6cc-c70efc134425 /               ext4    errors=remount-ro 0       1
    # /boot/efi was on /dev/sda1 during installation
    UUID=2C4D-050D  /boot/efi       vfat    umask=0077      0       1
    # swap was on /dev/sda3 during installation
    UUID=4fe8fe31-f73a-4edf-aa46-3e01521e3203 none            swap    sw              0       0

    My experience however, has always been that once I start adding drives, my OS drive changes.. but it never has been an issue given it's mounted by UUID (as you can see in my fstab, it was sda during install.. the webUI and blkid shows it's sde now.


    Code
    root@openmediavault:~# blkid | grep /dev/sde
    /dev/sde1: UUID="2C4D-050D" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="16b671b4-bd9b-4066-a4d3-50f22290a3c2"
    /dev/sde2: UUID="b5f88bb5-2b0a-4d3c-a6cc-c70efc134425" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="2640ac6b-2733-4873-a21d-fce9951db884"
    /dev/sde3: UUID="4fe8fe31-f73a-4edf-aa46-3e01521e3203" TYPE="swap" PARTUUID="f4b86ff8-5036-424a-bcd1-88606989e14b"
    root@openmediavault:~# 

    Unless I'm missing something, I don't see how this effects a normal install unless users start trying to set up custom mount points.


    At that point, rather than using custom mount points (I can only assume they do this as filesystem paths).. Use the rootshare plugin and symlinks with the symlink plugin. Way less headache and it won't matter what device letter your OS drive is.

  • My experience however, has always been that once I start adding drives, my OS drive changes.. but it never has been an issue given it's mounted by UUID (as you can see in my fstab, it was sda during install.. the webUI and blkid shows it's sde now.

    That's exactly the problem. When this happens everything is ok until grub is updated. In that case, after update, grub will reconfigure and the boot partition will not be /dev/sda anymore but /dev/sde (as in your case) or any other device, so reconfiguration will fail and you will have to do it manually.

    If it didn't happen to you, may be there is a difference between UEFI and non UEFI installation. Mine is non UEFI, and perhaps the reconfiguration problem does not happen under UEFI.

    • Offizieller Beitrag

    That's exactly the problem. When this happens everything is ok until grub is updated. In that case, after update, grub will reconfigure and the boot partition will not be /dev/sda anymore but /dev/sde (as in your case) or any other device, so reconfiguration will fail and you will have to do it manually.

    If it didn't happen to you, may be there is a difference between UEFI and non UEFI installation. Mine is non UEFI, and perhaps the reconfiguration problem does not happen under UEFI.

    nope. The system I used with OMV for 10yrs until a month ago operated exactly like the install I have now (which has UEFI)

  • nope. The system I used with OMV for 10yrs until a month ago operated exactly like the install I have now (which has UEFI)

    That's what has been happening to me either, but this is the first OMV release using Debian 11. I found that my problem is an already reported issue: https://debian-handbook.info/b…ct.config-bootloader.html on section 8.8.2 it says:


    Zitat

    One of the most often reported issues when using GRUB is that users get an error like error symbol `grub_calloc' not found and they are unable to boot the system anymore. Most of the time this error is caused by installing an updated version of GRUB that causes new modules in /boot/grub to be incompatible with old core images in the boot sector that your firmware jumps to when booting your machine. This happens on systems that are configured to run grub-install to a target device that is not actually the one that the firmware uses to boot your system (e.g. after replacing disks or moving them around - one can see the issue when running dpkg-reconfigure grub-pc showing the wrong target device). With the release of Debian 11 Bullseye (the change was also populated to Buster) the update process now checks for this issue and exits with an error in case it finds such a constellation.

  • muchahagrande

    Hat den Titel des Themas von „Root FS appearing as diferent /dev/sdX on each boot“ zu „Grub update fails because root FS appearing as diferent /dev/sdX on each boot“ geändert.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!