Raspberry Pi: alternatives for root= in /boot/cmdline.txt

    • OMV 3.x
    • Resolved

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Raspberry Pi: alternatives for root= in /boot/cmdline.txt

      I have two RPi3 OMV3 installations which each have an SSD for booting and OMV, then a data disk HDD. When I use root=/dev/sda2 in /boot/cmdline.txt OMV tries to use the data disk HDD as the root device, rather than the SSD when the HDD is connected, but works fine when it is not. I have tried put the UUID in /etc/fstab and tried using root=UUID=ae708a4d-982a-4a20-965c-01ec7e1f32b3 in cmdline.txt, but the boot just hangs. This happens even if I disconnect the HDD before powering up.

      It looks like OMV does not like UUID for booting, or this is not supported but it is very hard to figure out which it is. Is there a simple reliable way of making sure the right partition is used as root when booting? I suppose I could try pointing to /dev/sdb2 and see if that works, but I would rather have a foolproof setup if possible.

      ARMBIAN 5.42 experimental Debian GNU/Linux 8 (jessie) 4.14.30-v7+
    • vinntec wrote:

      It looks like OMV does not like UUID for booting
      This is not related to OMV at all but only a matter of kernel configuration and settings.

      Using LABEL or any of the UUIDs requires adjusting /etc/fstab as well. And since it's 2018 I would use PARTUUID instead: raspberrypi.org/forums/viewtopic.php?p=1161764#p1161764

      BTW: Pretty strange setup using something that unreliable as an RPi and then even waste an SSD to put the OS on it. These things have only one single USB2 bus so avoiding this bus is always a great idea (using a good, genuine and reliable SanDisk A1 SD card for example). But as long as you leave the defaults in place (flashmemory plugin active and no monitoring) it shouldn't matter anyway where the rootfs is since only some read activity at boot and some writes from time to time.
    • @tkaiser Rest assured this is an interim measure to get the backups and media server working again. Rock64 Transformer which will take 3.5" disks would be perfect, but not available yet.

      As far as UUID is concerned, /etc/fstab already has them defined no problem. Putting UUID for /dev/sda2 into cmdline.txt for booting doesn't work. It seems there might be a delay, so I might try adding rootdelay and see what happens. PARTUUID is probably the right one to use for booting anyway, but letting it find a partition called boot might also work.
    • Making this change to cmdline.txt to use PARTUUID made the boot work reliably with the HDD attached, although the SSD is still /dev/sdb afterwards but that doesn't matter.

      Source Code: /boot/cmdline.txt

      1. dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=PARTUUID=c5ac05a5-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet

      However if I then change /etc/fstab to match then I get an error a-start-job-is-running-for-dev-disk-by pointing to the boot partition then a kernel panic.

      Source Code

      1. PARTUUID=c5ac05a5-01 /boot vfat defaults 0 2
      2. PARTUUID=c5ac05a5-02 / ext4 defaults,noatime 0 1
      3. #UUID=CE83-8CE1 /boot vfat defaults 0 2
      4. #UUID=ae708a4d-982a-4a20-965c-01ec7e1f32b3 / ext4 defaults,noatime 0 1
      Commenting out line 1 above caused it to boot and I could mount it from OMV no problem. This put this entry into /etc/fstab in the OMV section at the bottom:

      Source Code

      1. /dev/disk/by-label/boot /srv/dev-disk-by-label-boot vfat defaults,nofail 0 2
      Then I thought, why didn't it mount as /boot? Hang on a doggone minute, is there a boot folder on the root partition? Yes, but there is nothing in it. Hence the problem. Using UUID must have given the same error, but in this case OMV started up OK but I noticed it wasn't mounted later on.

      I created the boot and root partitions on the SSD by installing the current RPi image on SD card first, saving the image of the card (three partitions), then using Etcher to burn it onto the SSD. Just checked the other OMV and that is the same. Not an issue now I know.