On Wed, 2020-06-10 at 12:33 -0500, Roger Heflin wrote: > No idea if this would still work, but back before label/uuid and lvm > in initird I had a staticly linked "C" program that ran inside > initrd, > it searched for likely places a boot device could be (mounted them > and > looked for a file to confirm it was the right device, then unmounted > it), and when it found the right one, it then echo's is major/minor > numbers into /proc/sys/kernel/real-root-dev and that is used for > root= > without it being on the command line. Assuming you could get > something similar started by sytemd and/or udev inside the initrd it > might still work. Using an initramfs is obviously an option, but it complicates both the build setup and boot process, so we would like to avoid making this a hard requirement if possible. > > On Wed, Jun 10, 2020 at 11:51 AM Ulf Hansson <ulf.hansson@xxxxxxxxxx> > wrote: > > > > On Wed, 10 Jun 2020 at 15:15, Matthias Schiffer > > <matthias.schiffer@xxxxxxxxxxxxxxx> wrote: > > > > > > Hello all, > > > > > > there have been numerous attempts to make the numbering of mmcblk > > > devices consistent, mostly by using aliases from the DTS ([1], > > > [2], > > > [3]), but all have been (rightfully) rejected. Unless I have > > > overlooked > > > a more recent development, no attempts for a different solution > > > were > > > made. > > > > According to aliases attempts, I think those have failed, mainly > > because of two reasons. > > > > 1. Arguments stating that LABELs/UUIDs are variable alternatives. > > This > > isn't the case, which I think was also concluded from the several > > earlier discussions. > > 2. Patches that tried adding support for mmc aliases, were not > > correctly coded. More precisely, what needs to be addressed is that > > the mmc core also preserves the same ids to be set for the host > > class > > as the block device, mmc[n] must correspond to mmcblk[n]. > > > > > > > > As far as I can tell, the core of the issue seems to be the > > > following: > > > > > > The existing solutions like LABELs and UUIDs are viable > > > alternatives in > > > many cases, but in particular on embedded systems, this is not > > > quite > > > sufficient: In addition to the problem that more knowledge about > > > the > > > system to boot is required in the bootloader, this approach fails > > > completely when the same firmware image exists on multiple > > > devices, for > > > example on an eMMC and an SD card - not an entirely uncommon > > > situation > > > during the development of embedded systems. > > > > > > With udev, I can refer to a specific partition using a path like > > > /dev/disk/by-path/platform-2194000.usdhc-part2. In [4] it was > > > proposed > > > to add a way to refer to a device path/phandle from the kernel > > > command > > > line. Has there been any progress on this proposal? > > > > Lots of time during the years I have been approached, both publicly > > and offlist, about whether it would be possible to add support for > > "consistent" mmcblk devices. To me, I am fine with the aliases > > approach, as long as it gets implemented correctly. > > > > > > > > Kind regards, > > > Matthias > > > > > > > > > [1] https://patchwork.kernel.org/patch/8685711/ > > > [2] https://lore.kernel.org/patchwork/cover/674381/ > > > [3] https://www.spinics.net/lists/linux-mmc/msg26586.html > > > [4] https://www.spinics.net/lists/linux-mmc/msg26708.html > > > > > > > Kind regards > > Uffe