Predictable device name for squashfs partition in initramfs

[satori420]

I've already posted this question somewhere else but you guys might have an answer for it, since it's a Gentoo install after all.

I've got a /boot partition, a squashfs root partition and a custom initramfs. The script looks like this:

[frostschutz]

There is no rescue shell in your rescue shell, just an echo of one...

You should probably add devtmpfs mount to it. https://wiki.gentoo.org/wiki/Custom_Initramfs#devtmpfs

Then the UUID stuff should start working as well. If it does not maybe a problem in your kernel, does it have built in support for all your storage, partition types, filesystems, ...?

[satori420]

You're right about the shell, I forgot to add the exec sh line to the code snippet, but it's in the compiled kernel already and I get dropped to a shell when anything fails.

It's not a device problem because everything works when there's only one disk in the system. squashfs boots normally and the tmpfs overlay is mounted properly. I can use /dev/sda2 in that case. The problem comes up when there are two disks connected and the /dev/sd{ab} names get reordered randomly. Sometimes /dev/sda2 is the partition we need, sometimes it's the second partition of the device we don't need and nothing boots. That's why we need an UUID in this case.

I already added devtmpfs with

[Ant P.]

[satori420]

That command does indeed detect squashfs partitions. I think I forgot to mention that both the pendrive and the disk have a squashfs filesystem in the second partition, so it doesn't work in my case. Sorry I didn't mention this important detail before.

I think it would be good enough if there were some way of detecting which device is the pendrive and which is the hard disk at initramfs time, at least for this case.

[frostschutz]

[satori420]

No, please don't worry about that, I've made many changes to the custom initramfs script and they are reflected in each reboot, I just made a mistake copying and pasting the script here. The exec sh is there in the original script.

Here's the output of blkid after I get dropped to a shell:

[frostschutz]

[Ant P.]

Try converting the disks to GPT? You might need hybrid MBR for the one you boot from but that should at least get you real PARTUUIDs everywhere.

[satori420]

Um, we hadn't changed that source to use our magic numbers yet.

I connected both the disk and the pendrive and now busybox blkid shows

[frostschutz]

Okay, so squashfs just isn't informative in any way

I guess you'll just have to look for another UUID on the same disk that blkid is able to find and then change the partition number of the returned device.

So use UUID to find /dev/sdx1 then change to /dev/sdx2.

If you're looking for hacks you could also use this method https://wiki.archlinux.org/index.php/Dm-crypt/Swap_encryption#UUID_and_LABEL

Put a bogus filesystem on it which provides the UUID and then mount squashfs at offset 1M. This will give you a slight overhead though (device mapping or loop device required). Speaking of device mappings you could just use LVM to properly name partitions.

Or you could take the Live CD isoloop approach, Live CDs mount all sorts of filesystem during boot in order to find their ISO image files which is located anywhere [on an usb stick or whatever], so you could iterate over all squashfs, mount them, then check if the file you're looking for is inside or not. (basically create a file UUID in each squashfs)

Or go with PARTUUID after all (no findfs, just mount PARTUUID=xyz /mnt/where)

[satori420]

I never thought of using another UUID, that's much simpler than what I had in mind. It works now, I just replaced

[frostschutz]

Glad it works.

Another option would be to fix the drive order after all, if the drives are connected through different channels (one onboard, another usb, or similar) this could be done by loading drivers in a specific order, alternatively you could go through the /sys/bus/platform/drivers/…/{bind,unbind} interface and unbind the disks from the driver, and then re-bind them in the desired order. That way you could make a specific sata port (or whatever) always be /dev/sda and nothing else.

[satori420]

Yes, they are connected through different channels. I had no idea you could force the order devices are named in, that's some incredibly useful info you've got there.