Hi, I recently flashed the eMMC of the OMAP5EVM and the Pyra and now a subtle issue has surfaced.
If I boot without SD card from eMMC everything is fine.
But if I boot from the SD card it works fine for U-Boot and loading the kernel, but the kernel loaded from SD card mounts the rootfs from eMMC and does not find any loadable modules (unless kernels are exactly the same version).
I could trace the u-boot-kernel interaction down to the uboot environment
finduuid=part uuid mmc ${mmcdev}:2 uuid args_mmc=run finduuid;setenv bootargs console=${console} ${optargs} root=PARTUUID=${uuid} rw rootfstype=${mmcrootfstype}
This is not at all wrong and should do what it is intended for: map the mmc device numbers from U-Boot in a way that the kernel can assign a different order (and it does!).
This is done by translating the device numbers into a unique code, i.e. the UUID.
Now why does it not work in my setup?
Breaking into the U-Boot console shows the problem:
=> part list mmc 0
Partition Map for MMC device 0 -- Partition Type: DOS
Part Start Sector Num Sectors UUID Type 1 128 778233 00000000-01 0c Boot 2 778361 14786439 00000000-02 83 => part list mmc 1
Partition Map for MMC device 1 -- Partition Type: DOS
Part Start Sector Num Sectors UUID Type 1 128 386656 00000000-01 0c Boot 2 386784 7346464 00000000-02 83 =>
Both, the eMMC and the SD card have the same UUIDs i U-Boot and therefore the kernel picks up the wrong one...
Now how can they have the same UUID? It should be unique, shouldn't it?
That is strange since after booting into Linux (still without kernel modules), I can look up how Linux sees the storage partitions:
root@letux:~# blkid /dev/mmcblk0p1: LABEL="boot" UUID="E052-71A6" TYPE="vfat" /dev/mmcblk0p2: LABEL="rootfs" UUID="5db8fefe-f8d2-46e4-828a-ab4fe1b8f9b4" TYPE="ext3" /dev/mmcblk1p1: LABEL="boot" UUID="ED66-B684" TYPE="vfat" /dev/mmcblk1p2: LABEL="rootfs" UUID="cd5f3d4c-c562-4aa0-893c-9fa9e9bd64a9" TYPE="ext3" /dev/mmcblk0: PTTYPE="dos" /dev/mmcblk1: PTTYPE="dos" root@letux:~#
And there, we have nice UUIDs!
Looks as if U-Boot does not recognize them. But the kernel still can mount some rootfs by "root=PARTUUID=00000000-02". Strange.
Unfortunately the U-Boot manual is not up to date: https://www.denx.de/wiki/DULG/Manual
Any ideas what puzzle piece we are missing here?
Could be in U-Boot, in Kernel or in formatting the SD/eMMC card. CONFIG_PARTITION_UUIDS is enabled in U-Boot (or we would not have the 'part' command).
BR, Nikolaus
Hi Nikoalus,
On Tue, May 23, 2017 at 10:42 AM, H. Nikolaus Schaller hns@goldelico.com wrote:
Hi, I recently flashed the eMMC of the OMAP5EVM and the Pyra and now a subtle issue has surfaced.
If I boot without SD card from eMMC everything is fine.
But if I boot from the SD card it works fine for U-Boot and loading the kernel, but the kernel loaded from SD card mounts the rootfs from eMMC and does not find any loadable modules (unless kernels are exactly the same version).
I could trace the u-boot-kernel interaction down to the uboot environment
finduuid=part uuid mmc ${mmcdev}:2 uuid args_mmc=run finduuid;setenv bootargs console=${console} ${optargs} root=PARTUUID=${uuid} rw rootfstype=${mmcrootfstype}
I was facing similar issue yesterday but my root looks like root=LABEL=rootfsA. I just drop LABEL=rootfsA and replace by /dev/sdb2 (in my case) and it works fine. I was trying shortly look to kernel source and I cannot find anything related to LABEL but for your case it should work (please loon for comment for function name_to_dev_t in ini/do_mounts.c) Hope this helps.
This is not at all wrong and should do what it is intended for: map the mmc device numbers from U-Boot in a way that the kernel can assign a different order (and it does!).
This is done by translating the device numbers into a unique code, i.e. the UUID.
Now why does it not work in my setup?
Breaking into the U-Boot console shows the problem:
=> part list mmc 0
Partition Map for MMC device 0 -- Partition Type: DOS
Part Start Sector Num Sectors UUID Type 1 128 778233 00000000-01 0c Boot 2 778361 14786439 00000000-02 83 => part list mmc 1
Partition Map for MMC device 1 -- Partition Type: DOS
Part Start Sector Num Sectors UUID Type 1 128 386656 00000000-01 0c Boot 2 386784 7346464 00000000-02 83 =>
Both, the eMMC and the SD card have the same UUIDs i U-Boot and therefore the kernel picks up the wrong one...
Now how can they have the same UUID? It should be unique, shouldn't it?
That is strange since after booting into Linux (still without kernel modules), I can look up how Linux sees the storage partitions:
root@letux:~# blkid /dev/mmcblk0p1: LABEL="boot" UUID="E052-71A6" TYPE="vfat" /dev/mmcblk0p2: LABEL="rootfs" UUID="5db8fefe-f8d2-46e4-828a-ab4fe1b8f9b4" TYPE="ext3" /dev/mmcblk1p1: LABEL="boot" UUID="ED66-B684" TYPE="vfat" /dev/mmcblk1p2: LABEL="rootfs" UUID="cd5f3d4c-c562-4aa0-893c-9fa9e9bd64a9" TYPE="ext3" /dev/mmcblk0: PTTYPE="dos" /dev/mmcblk1: PTTYPE="dos" root@letux:~#
And there, we have nice UUIDs!
Looks as if U-Boot does not recognize them. But the kernel still can mount some rootfs by "root=PARTUUID=00000000-02". Strange.
Unfortunately the U-Boot manual is not up to date: https://www.denx.de/wiki/DULG/Manual
Any ideas what puzzle piece we are missing here?
Could be in U-Boot, in Kernel or in formatting the SD/eMMC card. CONFIG_PARTITION_UUIDS is enabled in U-Boot (or we would not have the 'part' command).
BR, Nikolaus
http://projects.goldelico.com/p/gta04-kernel/ Letux-kernel mailing list Letux-kernel@openphoenux.org http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel
BR,
marek
Hi Marek,
Am 23.05.2017 um 11:25 schrieb Belisko Marek marek.belisko@gmail.com:
Hi Nikoalus,
On Tue, May 23, 2017 at 10:42 AM, H. Nikolaus Schaller hns@goldelico.com wrote:
Hi, I recently flashed the eMMC of the OMAP5EVM and the Pyra and now a subtle issue has surfaced.
If I boot without SD card from eMMC everything is fine.
But if I boot from the SD card it works fine for U-Boot and loading the kernel, but the kernel loaded from SD card mounts the rootfs from eMMC and does not find any loadable modules (unless kernels are exactly the same version).
I could trace the u-boot-kernel interaction down to the uboot environment
finduuid=part uuid mmc ${mmcdev}:2 uuid args_mmc=run finduuid;setenv bootargs console=${console} ${optargs} root=PARTUUID=${uuid} rw rootfstype=${mmcrootfstype}I was facing similar issue yesterday but my root looks like root=LABEL=rootfsA. I just drop LABEL=rootfsA and replace by /dev/sdb2 (in my case) and it works fine.
Yes, this is the "old style" way of defining the root by a hard-coded name.
But the problem is that there is no guarantee any more in modern kernels that sdb2 is not sdc2 on next boot. Depending on which other devices are plugged in.
And I want the bootargs to somehow be the same if I boot from eMMC or SD card. Or we have to ask users to configure uEnv.txt each time they plug in different cards...
As long as the device just has one device of each type it is stable.
I was trying shortly look to kernel source and I cannot find anything related to LABEL but for your case it should work (please loon for comment for function name_to_dev_t in ini/do_mounts.c) Hope this helps.
The problem with LABEL is that they all have the same label by the way the makesd script is doing the partitioning. It creates a "boot" and one "rootfs" partition. And then we have the same problem: the eMMC provides a "rootfs" partition as well as the SD card that is plugged in.
And, I can't make the label match the numbering scheme U-Boot is assuming (mmc 0:2 vs. mmc 1:2).
The UUID approach was invented to solve all these issues. But for that it should work...
This is not at all wrong and should do what it is intended for: map the mmc device numbers from U-Boot in a way that the kernel can assign a different order (and it does!).
This is done by translating the device numbers into a unique code, i.e. the UUID.
Now why does it not work in my setup?
Breaking into the U-Boot console shows the problem:
=> part list mmc 0
Partition Map for MMC device 0 -- Partition Type: DOS
Part Start Sector Num Sectors UUID Type 1 128 778233 00000000-01 0c Boot 2 778361 14786439 00000000-02 83 => part list mmc 1
Partition Map for MMC device 1 -- Partition Type: DOS
Part Start Sector Num Sectors UUID Type 1 128 386656 00000000-01 0c Boot 2 386784 7346464 00000000-02 83 =>
Both, the eMMC and the SD card have the same UUIDs i U-Boot and therefore the kernel picks up the wrong one...
Now how can they have the same UUID? It should be unique, shouldn't it?
That is strange since after booting into Linux (still without kernel modules), I can look up how Linux sees the storage partitions:
root@letux:~# blkid /dev/mmcblk0p1: LABEL="boot" UUID="E052-71A6" TYPE="vfat" /dev/mmcblk0p2: LABEL="rootfs" UUID="5db8fefe-f8d2-46e4-828a-ab4fe1b8f9b4" TYPE="ext3" /dev/mmcblk1p1: LABEL="boot" UUID="ED66-B684" TYPE="vfat" /dev/mmcblk1p2: LABEL="rootfs" UUID="cd5f3d4c-c562-4aa0-893c-9fa9e9bd64a9" TYPE="ext3" /dev/mmcblk0: PTTYPE="dos" /dev/mmcblk1: PTTYPE="dos" root@letux:~#
And there, we have nice UUIDs!
Looks as if U-Boot does not recognize them. But the kernel still can mount some rootfs by "root=PARTUUID=00000000-02". Strange.
I have digged a little into the U-Boot code and the 'part list' command
http://git.goldelico.com/?p=gta04-uboot.git;a=blob;f=cmd/part.c;h=414031e6f3...
calls part_print().
There appear to be different part_print subfunctions for each partition scheme.
iMac:src hns$ fgrep part_print -R System.map System.map:8001b084 T part_print System.map:8001b744 T part_print_dos System.map:8001bc58 t part_print_iso System.map:8001c118 T part_print_efi iMac:src hns$
And since I format the SD cards by MBR format, I guess part_print_dos() is called.
http://git.goldelico.com/?p=gta04-uboot.git;a=blob;f=disk/part_dos.c;h=ed783...
This finally calls
http://git.goldelico.com/?p=gta04-uboot.git;a=blob;f=disk/part_dos.c;h=ed783...
There it simply prints %08x-%02x which corresponds to our PARTUUID=00000000-02
So it appears as if U-Boot is not capable of detecting the full UUID of an ext3 partition on a MBR disk while the kernel does.
What I have seen while going through the code: there is some CONFIG_PARTITION_TYPE_GUID Maybe we need to define it?
BR Nikolaus
Hi Nikolaus,
On Tue, May 23, 2017 at 12:02 PM, H. Nikolaus Schaller hns@goldelico.com wrote:
Hi Marek,
Am 23.05.2017 um 11:25 schrieb Belisko Marek marek.belisko@gmail.com:
Hi Nikoalus,
On Tue, May 23, 2017 at 10:42 AM, H. Nikolaus Schaller hns@goldelico.com wrote:
Hi, I recently flashed the eMMC of the OMAP5EVM and the Pyra and now a subtle issue has surfaced.
If I boot without SD card from eMMC everything is fine.
But if I boot from the SD card it works fine for U-Boot and loading the kernel, but the kernel loaded from SD card mounts the rootfs from eMMC and does not find any loadable modules (unless kernels are exactly the same version).
I could trace the u-boot-kernel interaction down to the uboot environment
finduuid=part uuid mmc ${mmcdev}:2 uuid args_mmc=run finduuid;setenv bootargs console=${console} ${optargs} root=PARTUUID=${uuid} rw rootfstype=${mmcrootfstype}I was facing similar issue yesterday but my root looks like root=LABEL=rootfsA. I just drop LABEL=rootfsA and replace by /dev/sdb2 (in my case) and it works fine.
Yes, this is the "old style" way of defining the root by a hard-coded name.
Yes I know. I'm using grub as bootloader so there could be something else which prevent label to work. Maybe it's bootloader which needs to translate LABEL=something to map to correct block device? Do you have any idea about that?
But the problem is that there is no guarantee any more in modern kernels that sdb2 is not sdc2 on next boot. Depending on which other devices are plugged in.
And I want the bootargs to somehow be the same if I boot from eMMC or SD card. Or we have to ask users to configure uEnv.txt each time they plug in different cards...
As long as the device just has one device of each type it is stable.
I was trying shortly look to kernel source and I cannot find anything related to LABEL but for your case it should work (please loon for comment for function name_to_dev_t in ini/do_mounts.c) Hope this helps.
The problem with LABEL is that they all have the same label by the way the makesd script is doing the partitioning. It creates a "boot" and one "rootfs" partition. And then we have the same problem: the eMMC provides a "rootfs" partition as well as the SD card that is plugged in.
And, I can't make the label match the numbering scheme U-Boot is assuming (mmc 0:2 vs. mmc 1:2).
The UUID approach was invented to solve all these issues. But for that it should work...
This is not at all wrong and should do what it is intended for: map the mmc device numbers from U-Boot in a way that the kernel can assign a different order (and it does!).
This is done by translating the device numbers into a unique code, i.e. the UUID.
Now why does it not work in my setup?
Breaking into the U-Boot console shows the problem:
=> part list mmc 0
Partition Map for MMC device 0 -- Partition Type: DOS
Part Start Sector Num Sectors UUID Type 1 128 778233 00000000-01 0c Boot 2 778361 14786439 00000000-02 83 => part list mmc 1
Partition Map for MMC device 1 -- Partition Type: DOS
Part Start Sector Num Sectors UUID Type 1 128 386656 00000000-01 0c Boot 2 386784 7346464 00000000-02 83 =>
Both, the eMMC and the SD card have the same UUIDs i U-Boot and therefore the kernel picks up the wrong one...
Now how can they have the same UUID? It should be unique, shouldn't it?
That is strange since after booting into Linux (still without kernel modules), I can look up how Linux sees the storage partitions:
root@letux:~# blkid /dev/mmcblk0p1: LABEL="boot" UUID="E052-71A6" TYPE="vfat" /dev/mmcblk0p2: LABEL="rootfs" UUID="5db8fefe-f8d2-46e4-828a-ab4fe1b8f9b4" TYPE="ext3" /dev/mmcblk1p1: LABEL="boot" UUID="ED66-B684" TYPE="vfat" /dev/mmcblk1p2: LABEL="rootfs" UUID="cd5f3d4c-c562-4aa0-893c-9fa9e9bd64a9" TYPE="ext3" /dev/mmcblk0: PTTYPE="dos" /dev/mmcblk1: PTTYPE="dos" root@letux:~#
And there, we have nice UUIDs!
Looks as if U-Boot does not recognize them. But the kernel still can mount some rootfs by "root=PARTUUID=00000000-02". Strange.
I have digged a little into the U-Boot code and the 'part list' command
http://git.goldelico.com/?p=gta04-uboot.git;a=blob;f=cmd/part.c;h=414031e6f3e06a391d4c053ea6eefe7b72e0da75;hb=0c5e26e7886ea7d2d934f65e2e6cbf15a2b52bc8#l110calls part_print().
There appear to be different part_print subfunctions for each partition scheme.
iMac:src hns$ fgrep part_print -R System.map System.map:8001b084 T part_print System.map:8001b744 T part_print_dos System.map:8001bc58 t part_print_iso System.map:8001c118 T part_print_efi iMac:src hns$
And since I format the SD cards by MBR format, I guess part_print_dos() is called.
http://git.goldelico.com/?p=gta04-uboot.git;a=blob;f=disk/part_dos.c;h=ed78334a9dd85059c81dc744692fa6dd34308853;hb=0c5e26e7886ea7d2d934f65e2e6cbf15a2b52bc8#l261This finally calls
http://git.goldelico.com/?p=gta04-uboot.git;a=blob;f=disk/part_dos.c;h=ed78334a9dd85059c81dc744692fa6dd34308853;hb=0c5e26e7886ea7d2d934f65e2e6cbf15a2b52bc8#l50There it simply prints %08x-%02x which corresponds to our PARTUUID=00000000-02
So it appears as if U-Boot is not capable of detecting the full UUID of an ext3 partition on a MBR disk while the kernel does.
What I have seen while going through the code: there is some CONFIG_PARTITION_TYPE_GUID Maybe we need to define it?
Maybe yes. Did you try to use GPT partitioning? UUID then should be "real" UUID.
BR Nikolaus
http://projects.goldelico.com/p/gta04-kernel/ Letux-kernel mailing list Letux-kernel@openphoenux.org http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel
BR,
marek
On Tue, May 23, 2017 at 2:23 PM, Belisko Marek marek.belisko@gmail.com wrote:
Hi Nikolaus,
On Tue, May 23, 2017 at 12:02 PM, H. Nikolaus Schaller hns@goldelico.com wrote:
Hi Marek,
Am 23.05.2017 um 11:25 schrieb Belisko Marek marek.belisko@gmail.com:
Hi Nikoalus,
On Tue, May 23, 2017 at 10:42 AM, H. Nikolaus Schaller hns@goldelico.com wrote:
Hi, I recently flashed the eMMC of the OMAP5EVM and the Pyra and now a subtle issue has surfaced.
If I boot without SD card from eMMC everything is fine.
But if I boot from the SD card it works fine for U-Boot and loading the kernel, but the kernel loaded from SD card mounts the rootfs from eMMC and does not find any loadable modules (unless kernels are exactly the same version).
I could trace the u-boot-kernel interaction down to the uboot environment
finduuid=part uuid mmc ${mmcdev}:2 uuid args_mmc=run finduuid;setenv bootargs console=${console} ${optargs} root=PARTUUID=${uuid} rw rootfstype=${mmcrootfstype}I was facing similar issue yesterday but my root looks like root=LABEL=rootfsA. I just drop LABEL=rootfsA and replace by /dev/sdb2 (in my case) and it works fine.
Yes, this is the "old style" way of defining the root by a hard-coded name.
Yes I know. I'm using grub as bootloader so there could be something else which prevent label to work. Maybe it's bootloader which needs to translate LABEL=something to map to correct block device? Do you have any idea about that?
Too fast hitting Send button: http://mulix.livejournal.com/84768.html so it's completely in initrd not in kernel :-)
But the problem is that there is no guarantee any more in modern kernels that sdb2 is not sdc2 on next boot. Depending on which other devices are plugged in.
And I want the bootargs to somehow be the same if I boot from eMMC or SD card. Or we have to ask users to configure uEnv.txt each time they plug in different cards...
As long as the device just has one device of each type it is stable.
I was trying shortly look to kernel source and I cannot find anything related to LABEL but for your case it should work (please loon for comment for function name_to_dev_t in ini/do_mounts.c) Hope this helps.
The problem with LABEL is that they all have the same label by the way the makesd script is doing the partitioning. It creates a "boot" and one "rootfs" partition. And then we have the same problem: the eMMC provides a "rootfs" partition as well as the SD card that is plugged in.
And, I can't make the label match the numbering scheme U-Boot is assuming (mmc 0:2 vs. mmc 1:2).
The UUID approach was invented to solve all these issues. But for that it should work...
This is not at all wrong and should do what it is intended for: map the mmc device numbers from U-Boot in a way that the kernel can assign a different order (and it does!).
This is done by translating the device numbers into a unique code, i.e. the UUID.
Now why does it not work in my setup?
Breaking into the U-Boot console shows the problem:
=> part list mmc 0
Partition Map for MMC device 0 -- Partition Type: DOS
Part Start Sector Num Sectors UUID Type 1 128 778233 00000000-01 0c Boot 2 778361 14786439 00000000-02 83 => part list mmc 1
Partition Map for MMC device 1 -- Partition Type: DOS
Part Start Sector Num Sectors UUID Type 1 128 386656 00000000-01 0c Boot 2 386784 7346464 00000000-02 83 =>
Both, the eMMC and the SD card have the same UUIDs i U-Boot and therefore the kernel picks up the wrong one...
Now how can they have the same UUID? It should be unique, shouldn't it?
That is strange since after booting into Linux (still without kernel modules), I can look up how Linux sees the storage partitions:
root@letux:~# blkid /dev/mmcblk0p1: LABEL="boot" UUID="E052-71A6" TYPE="vfat" /dev/mmcblk0p2: LABEL="rootfs" UUID="5db8fefe-f8d2-46e4-828a-ab4fe1b8f9b4" TYPE="ext3" /dev/mmcblk1p1: LABEL="boot" UUID="ED66-B684" TYPE="vfat" /dev/mmcblk1p2: LABEL="rootfs" UUID="cd5f3d4c-c562-4aa0-893c-9fa9e9bd64a9" TYPE="ext3" /dev/mmcblk0: PTTYPE="dos" /dev/mmcblk1: PTTYPE="dos" root@letux:~#
And there, we have nice UUIDs!
Looks as if U-Boot does not recognize them. But the kernel still can mount some rootfs by "root=PARTUUID=00000000-02". Strange.
I have digged a little into the U-Boot code and the 'part list' command
http://git.goldelico.com/?p=gta04-uboot.git;a=blob;f=cmd/part.c;h=414031e6f3e06a391d4c053ea6eefe7b72e0da75;hb=0c5e26e7886ea7d2d934f65e2e6cbf15a2b52bc8#l110calls part_print().
There appear to be different part_print subfunctions for each partition scheme.
iMac:src hns$ fgrep part_print -R System.map System.map:8001b084 T part_print System.map:8001b744 T part_print_dos System.map:8001bc58 t part_print_iso System.map:8001c118 T part_print_efi iMac:src hns$
And since I format the SD cards by MBR format, I guess part_print_dos() is called.
http://git.goldelico.com/?p=gta04-uboot.git;a=blob;f=disk/part_dos.c;h=ed78334a9dd85059c81dc744692fa6dd34308853;hb=0c5e26e7886ea7d2d934f65e2e6cbf15a2b52bc8#l261This finally calls
http://git.goldelico.com/?p=gta04-uboot.git;a=blob;f=disk/part_dos.c;h=ed78334a9dd85059c81dc744692fa6dd34308853;hb=0c5e26e7886ea7d2d934f65e2e6cbf15a2b52bc8#l50There it simply prints %08x-%02x which corresponds to our PARTUUID=00000000-02
So it appears as if U-Boot is not capable of detecting the full UUID of an ext3 partition on a MBR disk while the kernel does.
What I have seen while going through the code: there is some CONFIG_PARTITION_TYPE_GUID Maybe we need to define it?
Maybe yes. Did you try to use GPT partitioning? UUID then should be "real" UUID.
BR Nikolaus
http://projects.goldelico.com/p/gta04-kernel/ Letux-kernel mailing list Letux-kernel@openphoenux.org http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel
BR,
marek
-- as simple and primitive as possible
Marek Belisko - OPEN-NANDRA Freelance Developer
Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com
BR,
marek
Hi Marek, regarding the "LABEL=" I think it is not handled by U-Boot. U-Boot only has some support for partition UUIDs.
What I have seen while going through the code: there is some CONFIG_PARTITION_TYPE_GUID Maybe we need to define it?
Maybe yes.
Doesn't seem to make a difference.
Did you try to use GPT partitioning? UUID then should be "real" UUID.
No, we have used MBR for all OMAP3/4/5/am335x devices so far.
I am not sure if the "MLO in FAT partition" approach works for GPT at all.
I have tried to find some background information about the MBR and UUID without great success... I start to hate open source because of the closed (aka missing) documentation :)
And to increase confusion, there even seems to be a difference between root=UUID=... and root=PARTUUID=...
https://wiki.archlinux.org/index.php/Persistent_block_device_naming#Boot_man...
So to all my knowledge so far:
* DOS knows a "disk label" - but that is not the partition UUID we need here. * U-Boot does not provide a good uuid for MBR based SD cards * OMAP needs a MBR formatted SD * the "UUID" shown by kernel blkid might be randomly assigned (have not tried to find out) * (s)fdisk has no mechanism to define UUIDs for partitions - tune2fs could, but that is not what U-Boot can identify
By the way: this UUID thing is a strong argument against creating SD cards by dd-ing some .img to the raw disk. They will all share the UUIDs and are not uniquely identified any more.
I have checked again the U.Boot code of print_part_dos() and it appears as it it should be able to print some "disksig" if CONFIG_PARTITION_UUIDS is enabled. But it is difficult to understand the code.
BR, Nikolaus
On 23 May 2017 at 15:31, H. Nikolaus Schaller hns@goldelico.com wrote:
U-Boot only has some support for partition UUIDs.
I know it can also determine filesystem UUIDs, since Robert Nelson's images use these for booting the system (provided an initramfs is present, since the kernel doesn't support them)
I am not sure if the "MLO in FAT partition" approach works for GPT at all.
Not afaik. Of course when MLO at fixed offset is used you can use any partition table format you want, but I don't know if older SoCs support this.
By the way: this UUID thing is a strong argument against creating SD cards by dd-ing some .img to the raw disk. They will all share the UUIDs and are not uniquely identified any more.
Yes it's recommended to randomize various ids after flashing: - disklabel (maybe, if you care) - filesystem uuid - machine id - ssh host keys
I generally use a script which does all that after dd'ing the image and expanding it to fit using resize2fs.
I also try to avoid using UUIDs anywhere in the first place.
Matthijs
On 23 May 2017 at 10:42, H. Nikolaus Schaller hns@goldelico.com wrote:
This is not at all wrong and should do what it is intended for: map the mmc device numbers from U-Boot in a way that the kernel can assign a different order (and it does!).
Of course you already know that can be easily fixed with two tiny patches that are in my tree
On 23 May 2017 at 10:42, H. Nikolaus Schaller hns@goldelico.com wrote:
Now how can they have the same UUID? It should be unique, shouldn't it?
When a pc-style partition table is used, PARTUUIDs don't really exist and $DISKID-$N is used as substitute, where the disk id is extracted from the partition table and N is the partition number.
As for why the disk id is zero for your cards I dunno. You should be able to reset them to a random number by generating a new partition table using fdisk.
And there, we have nice UUIDs!
You're confusing partition UUIDs (PARTUUID) with filesystem UUIDs. The kernel only understands the former, while blkid is showing you the latter.
Matthijs
Hi Matthijs,
Am 23.05.2017 um 15:07 schrieb Matthijs van Duin matthijsvanduin@gmail.com:
On 23 May 2017 at 10:42, H. Nikolaus Schaller hns@goldelico.com wrote: This is not at all wrong and should do what it is intended for: map the mmc device numbers from U-Boot in a way that the kernel can assign a different order (and it does!).
Of course you already know that can be easily fixed with two tiny patches that are in my tree
Hm. No, I don't know that. Otherwise I would not ask...
Did you announce that fix to the greater public (so that I have a chance to get known to it)? Or do you expect me to track your private git repo for changes?
On 23 May 2017 at 10:42, H. Nikolaus Schaller hns@goldelico.com wrote: Now how can they have the same UUID? It should be unique, shouldn't it?
When a pc-style partition table is used, PARTUUIDs don't really exist and $DISKID-$N is used as substitute, where the disk id is extracted from the partition table and N is the partition number.
Yes, that is what I have found out in the meantime.
As for why the disk id is zero for your cards I dunno. You should be able to reset them to a random number by generating a new partition table using fdisk.
They were created by sfdisk and maybe it does not define it properly/randomly...
And there, we have nice UUIDs!
You're confusing partition UUIDs (PARTUUID) with filesystem UUIDs. The kernel only understands the former, while blkid is showing you the latter.
Yes, that makes sense...
BR and thanks, Nikolaus
On 23 May 2017 at 15:54, H. Nikolaus Schaller hns@goldelico.com wrote:
Hm. No, I don't know that. Otherwise I would not ask...
Did you announce that fix to the greater public (so that I have a chance to get known to it)? Or do you expect me to track your private git repo for changes?
I pointed you to these patches in the "faster mmc/sd" thread not long ago:
On 27 March 2017 at 07:20, H. Nikolaus Schaller hns@goldelico.com wrote:
Am 27.03.2017 um 04:18 schrieb Matthijs van Duin <
matthijsvanduin@gmail.com>:
I just noticed that your kernel called eMMC "mmc0" instead of "mmc1",
that's confusing as hell. Please apply:
Has this been suggested upstream?
Matthijs
Hi Matthijs
Am 23.05.2017 um 16:00 schrieb Matthijs van Duin matthijsvanduin@gmail.com:
On 23 May 2017 at 15:54, H. Nikolaus Schaller hns@goldelico.com wrote:
Hm. No, I don't know that. Otherwise I would not ask...
Did you announce that fix to the greater public (so that I have a chance to get known to it)? Or do you expect me to track your private git repo for changes?
I pointed you to these patches in the "faster mmc/sd" thread not long ago:
Ah, very you much overestimate how good my memories are :)
It is more a worn out NAND flash without ECC and CRC... Writing is also much slower than reading out :)
On 27 March 2017 at 07:20, H. Nikolaus Schaller hns@goldelico.com wrote:
Am 27.03.2017 um 04:18 schrieb Matthijs van Duin matthijsvanduin@gmail.com: I just noticed that your kernel called eMMC "mmc0" instead of "mmc1", that's confusing as hell. Please apply: https://github.com/mvduin/linux/tree/patch/of-alias
Has this been suggested upstream?
Well, this is a solution on kernel side and I asked if it has been suggested upstream for a reason. The reason is that I doubt that it can easily be upstreamed because maintainers will immediately point us to the UUID magic of U-Boot which everyone seems to use successfully. Except us as I found with my current tests.
And since we have enough tough upstream topics I hesitate to add another one. The goal of Letux is to come closer to upstream than go away...
On 23 May 2017 at 16:10, H. Nikolaus Schaller hns@goldelico.com wrote:
Well, this is a solution on kernel side and I asked if it has been suggested upstream for a reason.
Well it has, but the mmc subsystem maintainers are obnoxious asshats :P
Matthijs
Ok, based on
http://www.linuxquestions.org/questions/linux-general-1/what-is-disk-identif...
this seems to do the trick to assign a random disk identifier:
dd if=/dev/urandom bs=1 count=4 seek=440 of=/dev/mmcblk1
BR, Nikolaus
Am 23.05.2017 um 15:07 schrieb Matthijs van Duin matthijsvanduin@gmail.com:
Of course you already know that can be easily fixed with two tiny patches that are in my tree
It looks as if I need a more precise pointer to locate them:
https://github.com/mvduin/u-boot/commits/master
BR, Nikolaus
Hi Matthijs,
Am 23.05.2017 um 15:07 schrieb Matthijs van Duin matthijsvanduin@gmail.com: Now how can they have the same UUID? It should be unique, shouldn't it?
When a pc-style partition table is used, PARTUUIDs don't really exist and $DISKID-$N is used as substitute, where the disk id is extracted from the partition table and N is the partition number.
As for why the disk id is zero for your cards I dunno. You should be able to reset them to a random number by generating a new partition table using fdisk.
Trying fdisk was a very good hint (sdb is a Pyra SD card on an external SD card reader):
root@letux:~# fdisk /dev/sdb
Welcome to fdisk (util-linux 2.25.2). Changes will remain in memory only, until you decide to write them. Be careful before using the write command.
Command (m for help): p Disk /dev/sdb: 29.7 GiB, 31914983424 bytes, 62333952 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x00000000
^^^ oops
Device Boot Start End Sectors Size Id Type /dev/sdb1 * 128 3116818 3116691 1.5G c W95 FAT32 (LBA) /dev/sdb2 3116819 62333951 59217133 28.2G 83 Linux
Command (m for help):
The disk identifier is indeed not randomized but 0. Maybe sfdisk isn't setting it by default. Ah, I also dd in=/dev/null out=/dev/sdb so that I wipe out the MBR completely. This means that a fresh pre-formatted SD card looses any randomized disk identifier.
So all this shows: * U-Boot and default scripts seem to be basically fine * kernel does what it should and does not necessarily need the mmc alias patch (although it would be nice to have) * I have to look into the makesd partitioning step to solve the subject issue by providing really unique disk labels
Something like: https://johnkastler.net/2012/02/05/changing-disk-identifier-using-fdisk/
BR and thanks, Nikolaus
Am 23.05.2017 um 16:17 schrieb H. Nikolaus Schaller hns@goldelico.com:
Something like: https://johnkastler.net/2012/02/05/changing-disk-identifier-using-fdisk/
I now changed the disk identifier to some random value and voilà, even blkid shows that as PARTUUID (it knows both UUID and PARTUID)
root@letux:~# blkid /dev/mmcblk0p1: LABEL="boot" UUID="E052-71A6" TYPE="vfat" /dev/mmcblk0p2: LABEL="rootfs" UUID="5db8fefe-f8d2-46e4-828a-ab4fe1b8f9b4" TYPE="ext3" /dev/mmcblk1p1: LABEL="boot" UUID="7BFC-21B7" TYPE="vfat" PARTUUID="00bc614e-01" /dev/mmcblk1p2: LABEL="rootfs" UUID="256560b9-884a-4f26-b910-e3735446c9bb" TYPE="ext3" PARTUUID="00bc614e-02" /dev/mmcblk0: PTTYPE="dos" /dev/mmcblk1: PTUUID="00bc614e" PTTYPE="dos" root@letux:~#
U-Boot:
=> part list mmc 0
Partition Map for MMC device 0 -- Partition Type: DOS
Part Start Sector Num Sectors UUID Type 1 128 3116691 00bc614e-01 0c Boot 2 3116819 59217133 00bc614e-02 83 => part list mmc 1
Partition Map for MMC device 1 -- Partition Type: DOS
Part Start Sector Num Sectors UUID Type 1 128 386656 00000000-01 0c Boot 2 386784 7346464 00000000-02 83 =>
Kernel Boot:
[ 0.000000] Kernel command line: console=ttyO2,115200n8 root=PARTUUID=00bc614e-02 rw rootfstype=ext4 rootwait console=ttyO2,115200n8 vram=12M omapfb.vram=0:8M,1:4M omapfb.rotate_type=0 omapdss.def_disp=lcd rootwait twl4030_charger.allow_usb=1 musb_hdrc.preserve_vbus=1 log_buf_len=8M ignore_loglevel earlyprintk
This means the PARTUUID mechanism *is* working. It is only that I have no unique IDs on the SD cards!
So it is really a bug in creating SD cards by makesd. This should be easy to fix.
Thanks for all comments which show again that group work is superior to work in a hidden chamber...
BR, Nikolaus
-
Belisko Marek -
H. Nikolaus Schaller -
Matthijs van Duin