blkid & fstype implementations

[frikiluser]

Hi,

blkid and fstype implementations differ from util-linux and klibc-utils implementations.
As initramfs-tools use both programs I think it make worth to mention it.

blkid

Some details already noted at: #239

The initramfs-tools scripts run blkid like this:

blkid -o value -s TYPE "${FS}"

(${FS} is /dev/sda1, etc)

The generated output, in my case, are ext4 or swap.

By now, toybox implementation can't handle -o value option.

fstype

The initramfs-tools scripts run fstype like this:

eval "$(fstype "${FS}" 2> /dev/null)"

(${FS} is /dev/sda1, etc)

The generated output, in my case, is:

FSTYPE=ext4
FSSIZE=1072693248

(FSSIZE is ignored, by initramfs-tools)

Toybox implementation write ext4 and swap to stdout.

An eval() of that fstype output generate errors like the one reported here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013074

Hope there is a way to fix that mess with different implementations 😸

Best regards,
Thanks for your time!

[landley]

I added blkid -o (commit 8ed78cf) but my devuan doesn't have fstype installed by default so I dunno what the default value is, and am curious how initramfs-tools is depending on it?

[frikiluser]

Hi,

I'll try last toybox-blkid release, thanks!

fstype is included in klibc-utils Debian package.

$ aptitude why klibc-utils
[...]
i A initramfs-tools           Depends initramfs-tools-core (= 0.142)
i A initramfs-tools-core      Depends klibc-utils (>= 2.0.4-8~)

Regards,

[landley]

Ah, "dpkg-query -L klibc-utils" says it lives in /usr/lib/klibc/bin/fstype (not in the PATH), no wonder I couldn't find it. Let's see, what's using this...

https://salsa.debian.org/kernel-team/initramfs-tools/-/blob/master/scripts/functions#L196

Ok, how is klibc code "more robust"? More robust in what way? I ran "fstype --help" which says "--help: No such file or directory", when run with no arguments it says "stdin: Illegal seek", there is no fstype man page (which is why I thought it wasn't installed when I couldn't find it in the $PATH), the output when run on an ext2.img I have lying around is two random keyword=value pairs with no obvious reason why, I ran it on the first image in tests/files/blkid (cramfs.img) which it identified the type of and said was size zero (so it's not just showing me the file size, it's pulling info out of the superblock, and getting it wrong there)...

While I can gratuitously glue "FSTYPE=" to the start of all output, that makes the tool less generally useful? (It is a terrible, non-unix design.) The debian tool linked above looks like it's already falling back to use blkid when fstype produces a type name that doesn't "eval"?

[frikiluser]

I was just testing blkid changes. I think it will fit perfectly with initramfs-tools scripts 😻

About fstype, I can't answer your questions. I think I agree with your comments and can't add more.

Runing the eval line in the boot scripts seems a bit scary with toybox.
In the best case it will raise the error message:
/init: eval: line 207: ext4: not found
Or it may found and run a random binary found in the $PATH if the filesystem typename matches. Probably no one have programs called ext2, vfat, swap... IDK.

If we can't found a better solution for fstype I'll try to wrapp the toybox version in a initramfs-only script containing:
echo "FSTYPE=$(toybox fstype $1)"

Thanks a lot for looking into that. I appreciate so much your time and work.

[landley]

Doing an eval of random output is scary, yes, but you're kind of already doing that with the klibc output? Removing quotes from the blkid -o export creeped me out, here's hoping nobody has a fat filesystem with LABEL=;rm -rf /home

In bash I could at least do:

FSTYPE="$(thingy)"; [ "${FSTYPE/=//}" != "$FSTYPE" ] && eval "$FSTYPE"

But I dunno what dash supports...

[landley]

Is there any way to tell microsoft github NOT to randomly eat puncutation and turn it into wiki formatting I didn't ask for? Some sort of "pre" tag around the entire reply, perhaps? Oh well, my fault for trying to post a code snippet to microsoft github: it's clearly not designed for that. (No, I don't remember their wiki syntax months after the last time this happened...)

[enh-google]

start and end with ``` and you'll be the equivalent of <PRE>, as you can see here. personally i just do that around actual <CODE> blocks because (as you can see here) otherwise you end up needing to insert your own line breaks or suffer a horizontal scrollbar.

personally, i get frustrated by things that don't accept markdown syntax!

[landley]

That put your text in a box showing about the first 1/5 of it, with a scrollbar underneath. (I ctrl-+ my font size a bit.)

[enh-google]

indeed... scroll to see the bit where i say "this is why you don't want to do this, and should backquote just the code blocks instead" :-)