Package: initramfs-tools-core Version: 0.130 On a machine recently upgraded to stretch, I found that 'update-initramfs -u' produced the following output:
> update-initramfs: Generating /boot/initrd.img-4.9.0-3-686
> Warning: couldn't identify filesystem type for fsck hook, ignoring.
and on a reboot, the machine's root filesystem was still mounted RO.
Re-running pieces of the filesystem type detection code manually, in an
instance of sh running under strace, suggested that the problem is in
the shell function get_fsck_type_fstab() in
/usr/share/initramfs-tools/hooks/fsck, which does this:
alias fstype="/usr/lib/klibc/bin/fstype"
get_fstype "${MNT_FSNAME}"
unalias fstype
But in spite of that, when get_fstype() executes
eval $(fstype "${FS}" 2> /dev/null)
strace shows that the shell is searching $PATH for 'fstype' and not
finding it. In other words, the alias is being ignored - which isn't
surprising, since commands executed from inside a shell function are
indeed not subject to alias expansion.
Replacing the alias and unalias with a shell function definition and an
'unset -f' solved the problem for me: now update-initramfs doesn't print
that warning message, and my system boots with its root fs writable as I
expect.
I attach the patch I've applied on my system, which solves the problem
for me.
Cheers,
Simon
--
for k in [pow(x,37,0x1a1298d262b49c895d47f) for x in [0x50deb914257022de7fff,
0x213558f2215127d5a2d1, 0x90c99e86d08b91218630, 0x109f3d0cfbf640c0beee7,
0xc83e01379a5fbec5fdd1, 0x19d3d70a8d567e388600e, 0x534e2f6e8a4a33155123]]:
print "".join([chr(32+3*((k>>x)&1))for x in range(79)]) # <ana...@pobox.com>
initramfs-tools.diff
Description: Binary data
