Modify

Opened 2 years ago

Last modified 2 years ago

#21457 new defect

Build system creates same UUIDs for both boot and rootfs partitions

Reported by: anonymous Owned by: developers
Priority: normal Milestone:
Component: toolchain Version: Chaos Calmer 15.05
Keywords: Cc:

Description

Hi!

I did build a custom x86 image for the Alix 2d13 using Chaos Calmer r47400. After transferring the combined image onto the CF card and copying the rootfs-only image to a third (manually created) partition, I ended up with the same UUID for the boot, rootfs and the third (/dev/sda3) partition, which I use as a backup rootfs for alternating between successive sysupgrades (flashA/flashB scheme).

While I can generate unique partition IDs manually thereafter, I thought it probably could be helpful for you to know, that the image generation process seems to re-use the same UUID for different disk partitions (if not, please delete the ticket).

Attachments (0)

Change History (1)

comment:1 Changed 2 years ago by anonymous

To clarify what I mean:

After compilation I copied the firmware using dd to the CF card. I created two more partitions (sda3 and sda4). sda3 holds the secondary rootfs image, sda4 is mkfs'ed to contain an empty filesystem directly on the target. Then I boot the system with sda2 as the (primary) rootfs. Next, I enable mounting of sda1 to mount point /mnt/sda1 in /etc/config/fstab:

config 'global'
	option	anon_swap	'0'
	option	anon_mount	'0'
	option	auto_swap	'1'
	option	auto_mount	'1'
	option	delay_root	'5'
	option	check_fs	'0'

config 'mount'
	option	target	'/mnt/sda1'
	option	uuid	'57f8f4bc-abf4-655f-bf67-946fc0f9f25b'
	option	enabled	'1'

config 'mount'
	option	target	'/mnt/sda2'
	option	uuid	'57f8f4bc-abf4-655f-bf67-946fc0f9f25b'
	option	enabled	'0'

config 'mount'
	option	target	'/mnt/sda3'
	option	uuid	'57f8f4bc-abf4-655f-bf67-946fc0f9f25b'
	option	enabled	'0'

config 'mount'
	option	target	'/mnt/sda4'
	option	uuid	'501deacc-42e7-408a-a836-dacc3c06f470'
	option	enabled	'0'

After next reboot, mount prints following output:

root@OpenWrt:/# mount
rootfs on / type rootfs (rw)
/dev/root on / type ext4 (rw,noatime,discard,data=ordered)
proc on /proc type proc (rw,nosuid,nodev,noexec,noatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,noatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime)
tmpfs on /dev type tmpfs (rw,nosuid,relatime,size=512k,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,mode=600)
/dev/sda1 on /mnt/sda1 type ext4 (rw,relatime)
/dev/sda2 on /mnt/sda1 type ext4 (rw,relatime,discard,data=ordered)
/dev/sda3 on /mnt/sda1 type ext4 (rw,relatime,data=ordered)
debugfs on /sys/kernel/debug type debugfs (rw,noatime)
root@OpenWrt:/#

But only the /mnt/sda1 directory shows any files, although the wrong ones (sda2 instead of sda1):

root@OpenWrt:/# ls /mnt/sda?
/mnt/sda1:
bin         lib         overlay     root        tmp         var
dev         lost+found  proc        sbin        usb         www
etc         mnt         rom         sys         usr

/mnt/sda2:

/mnt/sda3:

/mnt/sda4:
root@OpenWrt:/#

If I unmount and remount sda1 using the mount command, everything fits:

root@OpenWrt:/# umount /dev/sda1
root@OpenWrt:/# mount /dev/sda1 /mnt/sda1
root@OpenWrt:/# ls /mnt/sda1
boot        lost+found
root@OpenWrt:/#

If I mount sda1 again, but this time with UUID, I get the rootfs mounted as sda1 as shown above when using block mount.

Maybe I am old-fashioned, but I really prefer the short and descriptive device names instead of UUIDs on small embedded systems - I don't plan to add a plenty of JBODs there ;-)

I also would rather use mounting points or device names alone with the mount command - whether mount reads this info from /etc/fstab or from /etc/config/fstab is not the point, but improvements should definitely not break things which worked for a decade now (except the Linux community wants to go the Microsoft way in the future).

Currently mount tries to read /etc/fstab which does not exist anymore. As a quick solution for this I will add the /etc/init.d/fstab script again, but only to construct a /etc/fstab (actually /tmp/fstab) out of the /etc/config/fstab, not for actual mounting, which is done by block mount.

Hope this is helpful, best wishes and a happy new year to all the developers!

Add Comment

Modify Ticket

Action
as new .
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.