Change boot address to UUID

[makem]

My Pi2 boots to a one primary partition USB stick -

cmdline.txt:
dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait rootdelay=5

Code: Select all

 blkid
/dev/mmcblk0p1: SEC_TYPE="msdos" LABEL="boot" UUID="15CD-3B79" TYPE="vfat"
/dev/mmcblk0p2: UUID="13d368bf-6dbf-4751-8ba1-88bed06bef77" TYPE="ext4"
/dev/sda1: LABEL="rootfs" UUID="cd3732a2-bd44-40f1-9947-8c89cfd05f29" TYPE="ext4"

Can I change:
root=/dev/mmcblk0p2
to
root=/dev/cd3732a2-bd44-40f1-9947-8c89cfd05f29

?

[DougieLawson]

Code: Select all

root@apollo ~ # blkid
/dev/mmcblk0p1: SEC_TYPE="msdos" LABEL="boot" UUID="140A-14B7" TYPE="vfat"
/dev/mmcblk0p2: UUID="eeee4949-ffff-cccc-aaaa-a138695079ec" TYPE="ext4"
/dev/sda1: UUID="aaaa7e22-bbbb-4970-dddd-c24fd4f03346" TYPE="ext4"
root@apollo ~ #

Code: Select all

root@apollo ~ # cat /boot/cmdline.txt
dwc_otg.lpm_enable=0 console=tty1 root=UUID=aaaa7e22-bbbb-4970-dddd-c24fd4f03346 rootfstype=ext4 elevator=deadline rootwait rootdelay=5
root@apollo ~ #

[makem]

[makem]

Code: Select all

root@HOME:~# blkid
/dev/mmcblk0p1: SEC_TYPE="msdos" LABEL="boot" UUID="15CD-3B79" TYPE="vfat"
/dev/mmcblk0p2: UUID="13d368bf-6dbf-4751-8ba1-88bed06bef77" TYPE="ext4"
/dev/sda1: LABEL="rootfs" UUID="cd3732a2-bd44-40f1-9947-8c89cfd05f29" TYPE="ext4"

root@HOME:~# 

Code: Select all

root@HOME:~# cat /boot/cmdline.txt
dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=UUID=cd3732a2-bd44-40f1-9947-8c89cfd05f29 rootfstype=ext4 elevator=deadline rootwait rootdelay=5

root@HOME:~#

During booting the pi stopped waiting for cd3732a2-bd44-40f1-9947-8c89cfd05f29

So I assume the USB was not ready at that time?

[edit] I remembered there was an change to an fstab which would also need to be done here too.

Code: Select all

proc            /proc           proc    defaults          0       0
/dev/sda1    /   ext4    defaults,noatime  0       1
/dev/mmcblk0p1  /boot           vfat    defaults          0       2
#/dev/mmcblk0p2  /               ext4    defaults,noatime  0       1
# a swapfile is not a swap partition, so no using swapon|off from here on, use  dphys-swapfile swap[on|off]  for that

I am not sure how to deal with the sda1 there.

[DougieLawson]

Change rootdelay to allow more time for /dev/sda1 to appear.

/etc/fstab needs

Code: Select all

proc            /proc           proc    defaults          0       0
/dev/mmcblk0p1  /boot           vfat    defaults          0       2
#/dev/mmcblk0p2  /               ext4    defaults,noatime  0       1
UUID=aaaa7e22-bbbb-4970-dddd-c24fd4f03346 /     ext4    defaults,noatime       0 1

[Tom_A]

Still unable to get this to work. Everything I've read about it seems to indicate you have to compile the kernel to make this work. This did work with RaspBMC, but never been able to get it to work with Raspbian.

[DougieLawson]

You DO NOT need to build your own kernel. You just have to get the right parms in the right places.

#1 most important thing is adding rootdelay=nnn (where nnn is a number greater than 4) to allow the USB enumeration to complete before your attempt to mount the root filesystem.

[makem]

Still unable to get this to work. Everything I've read about it seems to indicate you have to compile the kernel to make this work. This did work with RaspBMC, but never been able to get it to work with Raspbian.

I followed this guide to get mine working but as a beginner I opted for the simple installation but now need to use all of the USB sockets.

Rather than start again using the 'more complex' install as I only have one partition, I want to change my current install.

viewtopic.php?f=29&t=44177

[makem]

Help!

I have lost the USB stick fstab and it is still working! (without the UUID change in /boot)

Code: Select all

sudo nano /mnt/etc/fstab

Is a new empty file! I am sure I followed the instructions and made that file. I wonder if Webmin could have made changes.


With the rootdelay at 10 in /boot it still hangs waiting as before.

Code: Select all

makem@HOME / $ 
sudo cat /boot/cmdline.txt
dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=UUID=cd3732a2-bd44-40f1-9947-8c89cfd05f29 rootfstype=ext4 elevator=deadline rootwait rootdelay=10

#dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait rootdelay=5

makem@HOME / $

I will add the fstab without the UUID change first and then make the UUID changes in both.

[makem]

If the filesystem is on the SD card then I should be able to remove the SD card after boot, right?

Well, I cannot.

After moving (or so I thought) the filesystem to the USB stick I meticulously saved an image of the USB stick before I made any major change.

Twice I needed to go back to the previous image to remove for example changes I had made using Webmin in my attempts to decide if I wanted to keep it.

Each time I refomatted the USB stick and put the previously saved image on it and away we go!

My conclusion from that is that the filesystem IS on the USB stick, so why can't I now remove the SD card? I thought one reason for moving the filesystem was to prevent many writes to the card as well as an increase in speed.

[rpdom]

The main root filesystem (/) will be on the USB stick, but the boot area (/boot) will still be on the SD card. /boot only gets written to when you upgrade the kernel/firmware, or you change the config files, so you can usually run with /boot unmounted.

[DougieLawson]

cmdline.txt can ONLY have ONE line in it. You can't leave comments or blank lines even if a line starts with # the kernel will still try to do something with it.

[makem]

The main root filesystem (/) will be on the USB stick, but the boot area (/boot) will still be on the SD card. /boot only gets written to when you upgrade the kernel/firmware, or you change the config files, so you can usually run with /boot unmounted.

In my case it appears I cannot remove the SD card after booting is complete and I thought it as possible.

I need to hunt for the missing fstab lol. Very strange that is. However, having messed around with this USB stick I will use another and start from scratch using what I have learned. I will keep the first USB because my wife still needs her fix of Chinese movies while I play and it would be more than my lifes worth to mess it up.

[makem]

The USB stick needed remounting to bring the fstab back.

Code: Select all

makem@HOME /$ cat /boot/cmdline.txt
dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=UUID=cd3732a2-bd44-40f1-9947-8c89cfd05f29 rootfstype=ext4 elevator=deadline rootwait rootdelay=10
makem@HOME /$

etc/fstab is:

Code: Select all

proc            /proc           proc    defaults          0       0
#/dev/sda1    /   ext4    defaults,noatime  0       1
/dev/mmcblk0p1  /boot           vfat    defaults          0       2
#/dev/mmcblk0p2  /               ext4    defaults,noatime  0       1
UUID=cd3732a2-bd44-40f1-9947-8c89cfd05f29 /     ext4    defaults,noatime       0 1

Still waiting for root device on booting.

[Tom_A]

If the filesystem is on the SD card then I should be able to remove the SD card after boot, right?

Well, I cannot.

After moving (or so I thought) the filesystem to the USB stick I meticulously saved an image of the USB stick before I made any major change.

Twice I needed to go back to the previous image to remove for example changes I had made using Webmin in my attempts to decide if I wanted to keep it.

Each time I refomatted the USB stick and put the previously saved image on it and away we go!

My conclusion from that is that the filesystem IS on the USB stick, so why can't I now remove the SD card? I thought one reason for moving the filesystem was to prevent many writes to the card as well as an increase in speed.

USB sticks use solid-state memory as well so are equally susceptible to the effects of repeated writes. The advantages of reduces writes to the SD card are that these are the opportunities for corruption to occur from overclocking and I'm not even sure that problem still exists. If you manage to remove the SD card and still have the Pi running, it's not going to reboot without the SD card. That being said, hope the next version of the Pi supports running from USB directly. It would be worth losing the SD card slot. Just give it enough on board flash to load the /boot files or one USB port that doesn't go through the internal hub in a way that now prevents booting directly from USB.

[makem]

If you manage to remove the SD card and still have the Pi running, it's not going to reboot without the SD card. That being said, hope the next version of the Pi supports running from USB directly. It would be worth losing the SD card slot. Just give it enough on board flash to load the /boot files or one USB port that doesn't go through the internal hub in a way that now prevents booting directly from USB.

I am aware that the SD card is still required. I was confirming the filesystem was on the USB stick and was curious.

[Tom_A]

Okay that makes some sense. The guide you linked to uses an alternative to UUID for the /boot/cmdline.txt file that would require reformatting the card. I've attempted to get this to work enough times with no success that I'm lacking motivation to put that much effort into it, even though I have a grsync'ed backup of the install I would like this to work with.

[makem]

Okay that makes some sense. The guide you linked to uses an alternative to UUID for the /boot/cmdline.txt file that would require reformatting the card. I've attempted to get this to work enough times with no success that I'm lacking motivation to put that much effort into it, even though I have a grsync'ed backup of the install I would like this to work with.

Perhaps my understanding of the link I provided is wrong.

I thought it showed two methods of doing the same thing, one with only one stick and one with many. I did not see any need to reformat the card, just to use alternate ways of pointing the boot to the correct stick be it one or more, a simple way for one and a more complex way for many sticks.

That is why I m trying to change from the simple to UUID but it is not as simple as it appeared. My motivation is to learn but I rely heavily on outside help.

[brucetexpeditefile]

I was able to do something similar but with a USB hard disk. I have the PI rooted off the USB disk successfully with the 4.0 kernel with the cmdline.txt setup to have root=/dev/sda1 and the rootfstype=btrfs.

I ended up using 2 different PIs and Clonezilla because of the 4K sector issue on the hard disk, but it did work.

However, before the 4.0 kernel, I was able to set root=PARTUUID=XXX where XXX was the Partition unique GUID (from the output of gdisk).

This worked fine in the 3.18 kernel. Does anyone know if something changed with the 4.0 kernel? I can't seem to find any pointers.

Thanks!

Bruce

[Tom_A]

Perhaps my understanding of the link I provided is wrong.

I thought it showed two methods of doing the same thing, one with only one stick and one with many. I did not see any need to reformat the card, just to use alternate ways of pointing the boot to the correct stick be it one or more, a simple way for one and a more complex way for many sticks.

That is why I m trying to change from the simple to UUID but it is not as simple as it appeared. My motivation is to learn but I rely heavily on outside help.

The more complex method seems to require using GUID partitioning. The simpler method is what I've already accomplished. I'll just have to continue to only plug in one USB drive until booted to be sure the correct drive is detected. The method I used with RaspBMC was to set root=UUID="Mydrive'sUUIDNumber" in the cmdline.txt file. It looked like this is what you were attempting by the posts on this forum, however it doesn't work with the current Raspbian kernel. It's unfortunate that this is not part of the kernel so that it's easier to implement.

[DougieLawson]

Have you built an initrd?

sudo -i
cd /boot
mkinitramfs -o initrd.sda
nano config.txt # and add

Code: Select all

initramfs initrd.sda

reboot[/color]

[makem]

Have you built an initrd?

sudo -i
cd /boot
mkinitramfs -o initrd.sda
nano config.txt # and add

Code: Select all

initramfs initrd.sda

reboot[/color]

No I have not done this,

Would you explain the whys and workings of this method for a beginner?

[makem]

The more complex method seems to require using GUID partitioning. The simpler method is what I've already accomplished. I'll just have to continue to only plug in one USB drive until booted to be sure the correct drive is detected. The method I used with RaspBMC was to set root=UUID="Mydrive'sUUIDNumber" in the cmdline.txt file. It looked like this is what you were attempting by the posts on this forum, however it doesn't work with the current Raspbian kernel. It's unfortunate that this is not part of the kernel so that it's easier to implement.

I have started a new sd card and new usb stick and will attempt the 'complex' method just to learn something.

However if as you say I can just plug in other drives/equipment then that would be fine for my use which is the Chinese movies and learning. Maybe I shoud get another pi2 and use the current one solely for TV use. My other Pi has been happily running unattended for months apart from updating.

[Tom_A]

I have started a new sd card and new usb stick and will attempt the 'complex' method just to learn something.

However if as you say I can just plug in other drives/equipment then that would be fine for my use which is the Chinese movies and learning. Maybe I shoud get another pi2 and use the current one solely for TV use. My other Pi has been happily running unattended for months apart from updating.

My Solution is to use a network drive for movie storage. I mount the drive using the /etc/fstab file. This way I can have one storage for multiple Pi's and a NUC. The original Pi's do no handle having USB hot plugged very well, however the B+ and B2 do not have this issue. You could also experiment by swapping USB ports around until you found the one that was mounted first. I think that there is consistent behavior and once you find the port that loads first, you would just have to use that one for your USB flash drive.

[DougieLawson]

No I have not done this,

Would you explain the whys and workings of this method for a beginner?

The whys: it doesn't work without it, because the kernel needs to load driver modules from the ramfs.
The workings: viewtopic.php?f=28&t=104646