Hi, I am fighting a little with a strange effect that I already observed on a BeagleBone but not yet on OMAP5 boards:
the mapping of the mmc interfaces as named/numbered in the kernel has no stable relation to the device names.
This makes it very difficult to set the root=/dev/mmcblk0p2 boot arg in a stable way so that it works on all boards.
This was not a problem on devices with a single SD slot and no eMMC.
What I also don't understand are the rules behind. Or is it indeed random and based on delays how fast the kernel finds the devices connected to the interfaces?
Then we should develop some patch to enforce a well defined mmcblk number to mmc slot mapping because everything else is really unuseable.
Does someone of you know about such an issue and/or a patch?
BR, Nikolaus
On 2016-01-18, H. Nikolaus Schaller wrote:
the mapping of the mmc interfaces as named/numbered in the kernel has no stable relation to the device names.
This makes it very difficult to set the root=/dev/mmcblk0p2 boot arg in a stable way so that it works on all boards.
What about using filesystems labels or UUIDs? Then it doesn't matter what order the mmcblk devices are initialized in...
live well, vagrant
Hi,
Am 18.01.2016 um 18:40 schrieb Vagrant Cascadian vagrant@debian.org:
On 2016-01-18, H. Nikolaus Schaller wrote:
the mapping of the mmc interfaces as named/numbered in the kernel has no stable relation to the device names.
This makes it very difficult to set the root=/dev/mmcblk0p2 boot arg in a stable way so that it works on all boards.
What about using filesystems labels or UUIDs? Then it doesn't matter what order the mmcblk devices are initialized in...
Hm. Does this work for µSD cards and the boot command line to define the location of the root file system?
How can I find out the UUID of an µSD card of a system that does not yet boot?
And are UUIDs the same if I create a new µSD card with the same OS on it or do they change, i.e. do I need a different boot script for every µSD card?
BR, Nikolaus
Hi,
Am 18.01.2016 um 18:44 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi,
Am 18.01.2016 um 18:40 schrieb Vagrant Cascadian vagrant@debian.org:
On 2016-01-18, H. Nikolaus Schaller wrote:
the mapping of the mmc interfaces as named/numbered in the kernel has no stable relation to the device names.
This makes it very difficult to set the root=/dev/mmcblk0p2 boot arg in a stable way so that it works on all boards.
What about using filesystems labels or UUIDs? Then it doesn't matter what order the mmcblk devices are initialized in...
Hm. Does this work for µSD cards and the boot command line to define the location of the root file system?
This appears to give some hints:
http://unix.stackexchange.com/questions/93767/why-cant-i-specify-my-root-fs-...
How can I find out the UUID of an µSD card of a system that does not yet boot?
Ok, this appears to be easier:
http://www.sudo-juice.com/how-to-change-the-uuid-of-a-linux-partition/
Therefore I can run blkid on the host where I create the µSD card:
root@gta04:~# blkid /dev/sda1: UUID="849370e1-e883-4e06-8ffd-49e19e6b3976" TYPE="ext3" /dev/sda5: UUID="4a80732f-e295-4b40-9751-9e416b0a2647" TYPE="swap" /dev/sdc1: LABEL="boot" UUID="39F2-FF2F" TYPE="vfat" /dev/sdc2: LABEL="rootfs" UUID="a9f9f0cf-3c97-4e21-b256-be42ca50c234" TYPE="ext3" root@gta04:~#
And are UUIDs the same if I create a new µSD card with the same OS on it or do they change, i.e. do I need a different boot script for every µSD card?
Hm. After reading all this, I think it will be different for each µSD card.
So I have to dynamically generate bootscripts if I want to program 10 µSD cards that all can boot...
Or I have to tunefs2 the partition my makesd before filling with data so that all µSD cards have the same UUID... Which would not be a big problem since I rarely have two such cards in a single Pyra board. But if I do, I will run into problems.
Anyways, it might work, but does not look very practical :(
Other proposals?
BR, Nikolaus
On 2016-01-18, H. Nikolaus Schaller wrote:
Am 18.01.2016 um 18:40 schrieb Vagrant Cascadian vagrant@debian.org:
On 2016-01-18, H. Nikolaus Schaller wrote:
the mapping of the mmc interfaces as named/numbered in the kernel has no stable relation to the device names.
This makes it very difficult to set the root=/dev/mmcblk0p2 boot arg in a stable way so that it works on all boards.
What about using filesystems labels or UUIDs? Then it doesn't matter what order the mmcblk devices are initialized in...
Hm. Does this work for µSD cards and the boot command line to define the location of the root file system?
I use UUID on numerous other boards, though they all use an initramfs that supports UUIDs.
How can I find out the UUID of an µSD card of a system that does not yet boot?
I usually look in /dev/disk/by-uuid/, it also prints out the UUID when you run mkfs to create the filesystem, and I'm pretty sure there's some utility to print the UUID of a specified partition...
And are UUIDs the same if I create a new µSD card with the same OS on it or do they change, i.e. do I need a different boot script for every µSD card?
You would need a different boot script for every OS image. If you use the same OS image on multiple SD cards, each SD card would have the same UUIDs for the partitions on that particular OS image.
My general impression is specifying the rootfs via hard-coded device is frowned upon as predictible device naming is no longer reliable on many forms of media.
live well, vagrant
Hi Vagrant,
Am 18.01.2016 um 18:58 schrieb Vagrant Cascadian vagrant@debian.org:
On 2016-01-18, H. Nikolaus Schaller wrote:
Am 18.01.2016 um 18:40 schrieb Vagrant Cascadian vagrant@debian.org:
On 2016-01-18, H. Nikolaus Schaller wrote:
the mapping of the mmc interfaces as named/numbered in the kernel has no stable relation to the device names.
This makes it very difficult to set the root=/dev/mmcblk0p2 boot arg in a stable way so that it works on all boards.
What about using filesystems labels or UUIDs? Then it doesn't matter what order the mmcblk devices are initialized in...
Hm. Does this work for µSD cards and the boot command line to define the location of the root file system?
I use UUID on numerous other boards, though they all use an initramfs that supports UUIDs.
Yes, that makes it easier and in the long run we will need initramfs anyways on the Pyra since otherwise we can't use the MIPI display panel for boot splash, boot options etc.
But for board bring-up and testing it is one level of additional complexity that I want (and have so far) avoided.
How can I find out the UUID of an µSD card of a system that does not yet boot?
I usually look in /dev/disk/by-uuid/, it also prints out the UUID when you run mkfs to create the filesystem, and I'm pretty sure there's some utility to print the UUID of a specified partition...
Ok, that is an alternative.
And are UUIDs the same if I create a new µSD card with the same OS on it or do they change, i.e. do I need a different boot script for every µSD card?
You would need a different boot script for every OS image.
Hm. That is what I did expect not to like :)
If you use the same OS image on multiple SD cards, each SD card would have the same UUIDs for the partitions on that particular OS image.
Well, that works if SD cards are created by cloning (e.g. dd). But since the cards have different size, I fdisk + mkfs new partitions and untar all components. So each SD card will apparently get a different UUID.
My general impression is specifying the rootfs via hard-coded device is frowned upon as predictible device naming is no longer reliable on many forms of media.
Yes, indeed. But UUIDs hard-coded in boot scripts and/or initramfs makes me frown... It has worked in the past 5 years to avoid both :)
Many thanks for the prompt help to better understand the situation.
BR, Nikolaus
Am 18.01.2016 um 19:09 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi Vagrant,
Am 18.01.2016 um 18:58 schrieb Vagrant Cascadian vagrant@debian.org:
On 2016-01-18, H. Nikolaus Schaller wrote:
Am 18.01.2016 um 18:40 schrieb Vagrant Cascadian vagrant@debian.org:
On 2016-01-18, H. Nikolaus Schaller wrote:
the mapping of the mmc interfaces as named/numbered in the kernel has no stable relation to the device names.
This makes it very difficult to set the root=/dev/mmcblk0p2 boot arg in a stable way so that it works on all boards.
What about using filesystems labels or UUIDs? Then it doesn't matter what order the mmcblk devices are initialized in...
Hm. Does this work for µSD cards and the boot command line to define the location of the root file system?
I use UUID on numerous other boards, though they all use an initramfs that supports UUIDs.
Yes, that makes it easier and in the long run we will need initramfs anyways on the Pyra since otherwise we can't use the MIPI display panel for boot splash, boot options etc.
But for board bring-up and testing it is one level of additional complexity that I want (and have so far) avoided.
How can I find out the UUID of an µSD card of a system that does not yet boot?
I usually look in /dev/disk/by-uuid/, it also prints out the UUID when you run mkfs to create the filesystem, and I'm pretty sure there's some utility to print the UUID of a specified partition...
Ok, that is an alternative.
And are UUIDs the same if I create a new µSD card with the same OS on it or do they change, i.e. do I need a different boot script for every µSD card?
You would need a different boot script for every OS image.
Hm. That is what I did expect not to like :)
If you use the same OS image on multiple SD cards, each SD card would have the same UUIDs for the partitions on that particular OS image.
Well, that works if SD cards are created by cloning (e.g. dd). But since the cards have different size, I fdisk + mkfs new partitions and untar all components. So each SD card will apparently get a different UUID.
My general impression is specifying the rootfs via hard-coded device is frowned upon as predictible device naming is no longer reliable on many forms of media.
Yes, indeed. But UUIDs hard-coded in boot scripts and/or initramfs makes me frown... It has worked in the past 5 years to avoid both :)
Many thanks for the prompt help to better understand the situation.
BR, Nikolaus
Hm. Another idea: can U-Boot extract the UUID of a partition? But its shell processing capabilities are very limits.
Another trick:
http://dev.shyd.de/2013/06/booting-with-uuid-not-device-name/
it should be possible to boot by LABEL!
I.e.:
root=LABEL=rootfs
This appears to be the most portable and stable solution!
It might mix up the rootfs of eMMC and µSD if both have the same partition label. But for testing purposes I just want to see that the eMMC can be accessed. I have currently no need to install a partition on it.
BR, Nikolaus
Am 18.01.2016 um 19:09 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi Vagrant,
Am 18.01.2016 um 18:58 schrieb Vagrant Cascadian vagrant@debian.org:
On 2016-01-18, H. Nikolaus Schaller wrote:
Am 18.01.2016 um 18:40 schrieb Vagrant Cascadian vagrant@debian.org:
On 2016-01-18, H. Nikolaus Schaller wrote:
the mapping of the mmc interfaces as named/numbered in the kernel has no stable relation to the device names.
This makes it very difficult to set the root=/dev/mmcblk0p2 boot arg in a stable way so that it works on all boards.
What about using filesystems labels or UUIDs? Then it doesn't matter what order the mmcblk devices are initialized in...
Hm. Does this work for µSD cards and the boot command line to define the location of the root file system?
I use UUID on numerous other boards, though they all use an initramfs that supports UUIDs.
Yes, that makes it easier and in the long run we will need initramfs anyways on the Pyra since otherwise we can't use the MIPI display panel for boot splash, boot options etc.
But for board bring-up and testing it is one level of additional complexity that I want (and have so far) avoided.
How can I find out the UUID of an µSD card of a system that does not yet boot?
I usually look in /dev/disk/by-uuid/, it also prints out the UUID when you run mkfs to create the filesystem, and I'm pretty sure there's some utility to print the UUID of a specified partition...
Ok, that is an alternative.
And are UUIDs the same if I create a new µSD card with the same OS on it or do they change, i.e. do I need a different boot script for every µSD card?
You would need a different boot script for every OS image.
Hm. That is what I did expect not to like :)
If you use the same OS image on multiple SD cards, each SD card would have the same UUIDs for the partitions on that particular OS image.
Well, that works if SD cards are created by cloning (e.g. dd). But since the cards have different size, I fdisk + mkfs new partitions and untar all components. So each SD card will apparently get a different UUID.
My general impression is specifying the rootfs via hard-coded device is frowned upon as predictible device naming is no longer reliable on many forms of media.
Yes, indeed. But UUIDs hard-coded in boot scripts and/or initramfs makes me frown... It has worked in the past 5 years to avoid both :)
Many thanks for the prompt help to better understand the situation.
BR, Nikolaus
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Just for completeness here probably the correct and best solution:
There is an U-Boot command
part uuid mmc 0:2 uuid
which writes the partition uuid into the variable 'uuid' which then can be used in the boot= string.
So U-Boot provides a translation mechanism from its device & partition numbering into one that the Kernel can use during boot.
This seems to be used by the default boot environment setup for TI processors (include/configs/ti_armv7_common.h). Maybe I have broken it by my U-Boot patches...
BR, Nikolaus
Am 18.01.2016 um 19:18 schrieb H. Nikolaus Schaller hns@goldelico.com:
Another trick:
http://dev.shyd.de/2013/06/booting-with-uuid-not-device-name/
it should be possible to boot by LABEL!
I.e.:
root=LABEL=rootfs
This appears to be the most portable and stable solution!
It might mix up the rootfs of eMMC and µSD if both have the same partition label. But for testing purposes I just want to see that the eMMC can be accessed. I have currently no need to install a partition on it.
BR, Nikolaus
Am 18.01.2016 um 19:09 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi Vagrant,
Am 18.01.2016 um 18:58 schrieb Vagrant Cascadian vagrant@debian.org:
On 2016-01-18, H. Nikolaus Schaller wrote:
Am 18.01.2016 um 18:40 schrieb Vagrant Cascadian vagrant@debian.org:
On 2016-01-18, H. Nikolaus Schaller wrote:
the mapping of the mmc interfaces as named/numbered in the kernel has no stable relation to the device names.
This makes it very difficult to set the root=/dev/mmcblk0p2 boot arg in a stable way so that it works on all boards.
What about using filesystems labels or UUIDs? Then it doesn't matter what order the mmcblk devices are initialized in...
Hm. Does this work for µSD cards and the boot command line to define the location of the root file system?
I use UUID on numerous other boards, though they all use an initramfs that supports UUIDs.
Yes, that makes it easier and in the long run we will need initramfs anyways on the Pyra since otherwise we can't use the MIPI display panel for boot splash, boot options etc.
But for board bring-up and testing it is one level of additional complexity that I want (and have so far) avoided.
How can I find out the UUID of an µSD card of a system that does not yet boot?
I usually look in /dev/disk/by-uuid/, it also prints out the UUID when you run mkfs to create the filesystem, and I'm pretty sure there's some utility to print the UUID of a specified partition...
Ok, that is an alternative.
And are UUIDs the same if I create a new µSD card with the same OS on it or do they change, i.e. do I need a different boot script for every µSD card?
You would need a different boot script for every OS image.
Hm. That is what I did expect not to like :)
If you use the same OS image on multiple SD cards, each SD card would have the same UUIDs for the partitions on that particular OS image.
Well, that works if SD cards are created by cloning (e.g. dd). But since the cards have different size, I fdisk + mkfs new partitions and untar all components. So each SD card will apparently get a different UUID.
My general impression is specifying the rootfs via hard-coded device is frowned upon as predictible device naming is no longer reliable on many forms of media.
Yes, indeed. But UUIDs hard-coded in boot scripts and/or initramfs makes me frown... It has worked in the past 5 years to avoid both :)
Many thanks for the prompt help to better understand the situation.
BR, Nikolaus
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel