dracutdevs / dracut Goto Github PK

Booted with

rd.debug=1 rd.verbose=1 rd.live.overlay.readonly=1 rd.live.overlay=/run/initramfs/isoscan/boot/hello.img iso-scan/filename=/boot/iso/Fedora-Live-Desktop-i686-19-1.iso root=live:CDLABEL=Fedora-Live-Desktop-i686-19-1 rootfstype=auto ro rd.live.image quiet rhgb rd.luks=0 rd.md=0 rd.dm=0

/boot/hello.img is a 1 MB ext2 image that is stored on the same partition as the booted Live ISO and contains a file that I would like to see appear in / of the Live filesystem.

Instead, I am caught into an infinite loop with some "sleep 0.5" being visible on the screen (but no chance getting the logs).

When I leave out the rd.live.overlay.readonly=1 then it does boot, but the contents of /boot/hello.img do not appear in / of the booted system.

Here is the log

14]: /sbin/dmsquash-live-root@90(do_live_overlay): u=2013-06-27-17-22-52-00
dracut-initqueue[214]: /sbin/dmsquash-live-root@92(do_live_overlay): '[' -z /run/initramfs/isoscan/boot/hello.img ']'
dracut-initqueue[214]: /sbin/dmsquash-live-root@94(do_live_overlay): grep -q :
dracut-initqueue[214]: /sbin/dmsquash-live-root@94(do_live_overlay): echo /run/initramfs/isoscan/boot/hello.img
dracut-initqueue[214]: /sbin/dmsquash-live-root@99(do_live_overlay): '[' -z '' -o '' = auto ']'
dracut-initqueue[214]: /sbin/dmsquash-live-root@100(do_live_overlay): pathspec=/LiveOS/overlay-Fedora-Live-Desktop-i686-19-1-2013-06-27-17-22-52-00
dracut-initqueue[214]: //sbin/dmsquash-live-root@102(do_live_overlay): sed -e 's/:.*$//'
dracut-initqueue[214]: //sbin/dmsquash-live-root@102(do_live_overlay): echo /run/initramfs/isoscan/boot/hello.img
dracut-initqueue[214]: /sbin/dmsquash-live-root@102(do_live_overlay): devspec=/run/initramfs/isoscan/boot/hello.img
dracut-initqueue[214]: /sbin/dmsquash-live-root@105(do_live_overlay): setup=
dracut-initqueue[214]: /sbin/dmsquash-live-root@106(do_live_overlay): '[' -n /run/initramfs/isoscan/boot/hello.img -a -n /LiveOS/overlay-Fedora-Live-Desktop-i686-19-1-2013-06-27-17-22-52-00 -a -n /run/initramfs/isoscan/boot/hello.img ']'
dracut-initqueue[214]: /sbin/dmsquash-live-root@107(do_live_overlay): mkdir -m 0755 /run/initramfs/overlayfs
dracut-initqueue[214]: /sbin/dmsquash-live-root@108(do_live_overlay): mount -n -t auto /run/initramfs/isoscan/boot/hello.img /run/initramfs/overlayfs
dracut-initqueue[214]: /sbin/dmsquash-live-root@109(do_live_overlay): '[' -f /run/initramfs/overlayfs/LiveOS/overlay-Fedora-Live-Desktop-i686-19-1-2013-06-27-17-22-52-00 -a -w /run/initramfs/overlayfs/LiveOS/overlay-Fedora-Live-Desktop-i686-19-1-2013-06-27-17-22-52-00 ']'
dracut-initqueue[214]: /sbin/dmsquash-live-root@116(do_live_overlay): umount -l /run/initramfs/overlayfs
dracut-initqueue[214]: /sbin/dmsquash-live-root@119(do_live_overlay): '[' -z '' -o -n '' ']'
dracut-initqueue[214]: /sbin/dmsquash-live-root@120(do_live_overlay): '[' -n '' ']'
dracut-initqueue[214]: /sbin/dmsquash-live-root@122(do_live_overlay): '[' -n /run/initramfs/isoscan/boot/hello.img -a -n /LiveOS/overlay-Fedora-Live-Desktop-i686-19-1-2013-06-27-17-22-52-00 ']'
dracut-initqueue[214]: /sbin/dmsquash-live-root@123(do_live_overlay): warn 'Unable to find persistent overlay; using temporary'
dracut-initqueue[214]: /lib/dracut-lib.sh@426(warn): echo 'Warning: Unable to find persistent overlay; using temporary'
dracut-initqueue[214]: Warning: Unable to find persistent overlay; using temporary
dracut-initqueue[214]: /sbin/dmsquash-live-root@124(do_live_overlay): sleep 5
dracut-initqueue[214]: /sbin/dmsquash-live-root@127(do_live_overlay): dd if=/dev/null of=/overlay bs=1024 count=1 seek=524288
dracut-initqueue[214]: /sbin/dmsquash-live-root@128(do_live_overlay): '[' -n '' -a -n '' ']'
dracut-initqueue[214]: /sbin/dmsquash-live-root@132(do_live_overlay): losetup /dev/loop5 /overlay
dracut-initqueue[214]: //sbin/dmsquash-live-root@137(do_live_overlay): blockdev --getsz /dev/loop4
dracut-initqueue[214]: /sbin/dmsquash-live-root@137(do_live_overlay): sz=16777216
dracut-initqueue[214]: /sbin/dmsquash-live-root@138(do_live_overlay): '[' -n '' ']'
dracut-initqueue[214]: /sbin/dmsquash-live-root@143(do_live_overlay): base=/dev/loop4
dracut-initqueue[214]: /sbin/dmsquash-live-root@144(do_live_overlay): over=/dev/loop5
dracut-initqueue[214]: /sbin/dmsquash-live-root@146(do_live_overlay): dmsetup create live-rw
dracut-initqueue[214]: /sbin/dmsquash-live-root@146(do_live_overlay): echo 0 16777216 snapshot /dev/loop4 /dev/loop5 p 8
dracut-initqueue[214]: /sbin/dmsquash-live-root@217(): '[' -b /dev/loop2 ']'
dracut-initqueue[214]: /sbin/dmsquash-live-root@220(): dmsetup create --readonly live-osimg-min
dracut-initqueue[214]: //sbin/dmsquash-live-root@220(): blockdev --getsz /dev/loop4
dracut-initqueue[214]: /sbin/dmsquash-live-root@220(): echo '0 16777216 snapshot /dev/loop4 /dev/loop2 p 8'
dracut-initqueue[214]: //sbin/dmsquash-live-root@223(): getarg rootflags
dracut-initqueue[214]: //lib/dracut-lib.sh@122(getarg): debug_off
dracut-initqueue[214]: //lib/dracut-lib.sh@9(debug_off): set +x
dracut-initqueue[214]: //lib/dracut-lib.sh@162(getarg): return 1
dracut-initqueue[214]: /sbin/dmsquash-live-root@223(): ROOTFLAGS=
dracut-initqueue[214]: /sbin/dmsquash-live-root@224(): '[' -n '' ']'
dracut-initqueue[214]: /sbin/dmsquash-live-root@228(): '[' -b /dev/loop4 ']'
dracut-initqueue[214]: /sbin/dmsquash-live-root@229(): ln -s /dev/loop4 /run/initramfs/live-baseloop
dracut-initqueue[214]: /sbin/dmsquash-live-root@231(): ln -s /dev/mapper/live-rw /dev/root
dracut-initqueue[214]: /sbin/dmsquash-live-root@232(): printf 'mount %s /dev/mapper/live-rw %s\n' '' /sysroot
[�[32m  OK  �[0m] Started dracut initqueue hook.
dracut-initqueue[214]: /sbin/dmsquash-live-root@234(): need_shutdown
         Starting dracut pre-mount hook...
(...)

from #dracut @freenode
15:04 where is to read about kernel line parameters for initramfs from dracut?
15:24 i.e. where is "dracut.cmdline(5)" on the web ?
15:25 I don't see such file in source code - https://github.com/haraldh/dracut
15:26 but this page references it - https://www.kernel.org/pub/linux/utils/boot/dracut/dracut.html#_boot_parameters

15:29 there is dracut.cmdline(7), I think this is a typo and there is no dracut.cmdline(5) (as 5 is for config files)

I've attempted to use the syslog module and here are the list of breaking issues i've found.

config template is never installed as the destination is incomplete.

inst_simple "${moddir}/rsyslog.conf" /etc/templates

rsyslogd-stop.sh does not source dracut-lib and references warn() which fails

I'm no udev expert but no matter what tweaks I tired this rule does not start the service upon ifup

printf 'ACTION=="online", SUBSYSTEM=="net", RUN+="/sbin/initqueue --onetime /sbin/'${syslogtype}'-start $env{INTERFACE}"\n' > /etc/udev/rules.d/70-syslog.rules

rsyslogd-start.sh filter variables are not properly quoted allowing shell expansion for filter wildcards

for filter in $filters; do
    echo "${filter} @${server}"
done

When using a multi-device btrfs root and specifying the root device by UUID on the kernel command line, dracut tests the existence of the device to which the by-uuid symlink points before mounting the root device. However, the other devices may not be ready.

This appears to be because when the btrfs module is included, the rules file 64-btrfs.rules is tested for locally and if it exists, the scripts to wait for the btrfs device(s) to be ready are not added to the ramdisk:

modules.d/90btrfs/module-setup.sh:33

    if ! inst_rules 64-btrfs.rules; then
        inst_rules "$moddir/80-btrfs.rules"
        case "$(btrfs --help)" in
            *device\ ready*)
                inst_script "$moddir/btrfs_device_ready.sh" /sbin/btrfs_finished ;;
            *)
                inst_script "$moddir/btrfs_finished.sh" /sbin/btrfs_finished ;;
        esac
    fi

Is this because dracut assumes the local 64-btrfs.rules file will perform the necessary tasks? Certainly in my case (udev-225) it does not, and I can work around the issue by commenting out the if/fi lines above.

I need to boot from an IPv6 NFS server. The documentation specifies that the IPv6 address should be in brackets, which implies that dracut should support it. But it fails miserably.

If I supply:

ip=eth0:auto6 root=nfs:[fd00:1::1]:/diskless/desktop:vers=3,proto=tcp6

then dracut ends up executing:

mount -t nfs -oro,[fd00,nolock 1::1]:/diskless/desktop:vers=3,proto=tcp6 /sysroot

which inevitably fails.

This works:

dracut … -i /usr/lib/systemd/systemd-veritysetup /usr/lib/systemd/systemd-veritysetup …

This does not:

dracut … -I /usr/lib/systemd/systemd-veritysetup …

No idea why it fails, I assumed that -I and -i are pretty much the same, except that one expects source and destination paths and the other just one path that is used for both.

The error message this generates is useless:

…
dracut-install: ERROR: installing '/usr/lib/systemd/systemd-veritysetup'
dracut: FAILED: /usr/lib/dracut/dracut-install -D /var/tmp/dracut.PTU63J/initramfs -a /usr/lib/systemd/systemd-veritysetup
…

"FAILED" and "ERROR" aren't really all that useful as error messages... No idea what went wrong here... all i know is that something went wrong...

--kerneldir option should only be about where to get kernel modules from, not about where to place them inside initramfs. But the actual result is that modules are copied preserving the full path, effectively making the modules "missing" in the initramfs (because are placed outside of /lib/modules).

Example test case:

$ dracut --nomdadmconf --nolvmconf --kmoddir ~/install-mod/lib/modules/4.4.38-11.pvops.qubes.x86_64 --modules 'kernel-modules qubes-vm-simple' --conf '/dev/null' --confdir '/var/empty' -d 'xenblk xen-blkfront cdrom ext4 jbd2 crc16 dm_snapshot' -f initrd.test 4.4.38-11.pvops.qubes.x86_64
$ lsinitrd initrd.test |grep /lib/modules
Arguments: --nomdadmconf --nolvmconf --kmoddir '/home/user/install-mod/lib/modules/4.4.38-11.pvops.qubes.x86_64' --modules 'kernel-modules qubes-vm-simple' --conf '/dev/null' --confdir '/var/empty' -d 'xenblk xen-blkfront cdrom ext4 jbd2 crc16 dm_snapshot' -f
drwxr-xr-x   3 root     root            0 Nov  7 09:59 home/user/install-mod/lib/modules
drwxr-xr-x   3 root     root            0 Nov  7 09:59 home/user/install-mod/lib/modules/4.4.38-11.pvops.qubes.x86_64
drwxr-xr-x   6 root     root            0 Nov  7 09:59 home/user/install-mod/lib/modules/4.4.38-11.pvops.qubes.x86_64/kernel
drwxr-xr-x   3 root     root            0 Nov  7 09:59 home/user/install-mod/lib/modules/4.4.38-11.pvops.qubes.x86_64/kernel/crypto
drwxr-xr-x   2 root     root            0 Nov  7 09:59 home/user/install-mod/lib/modules/4.4.38-11.pvops.qubes.x86_64/kernel/crypto/async_tx
-rw-r--r--   1 root     root         6904 Nov  7 09:59 home/user/install-mod/lib/modules/4.4.38-11.pvops.qubes.x86_64/kernel/crypto/async_tx/async_memcpy.ko
-rw-r--r--   1 root     root        13288 Nov  7 09:59 home/user/install-mod/lib/modules/4.4.38-11.pvops.qubes.x86_64/kernel/crypto/async_tx/async_pq.ko
-rw-r--r--   1 root     root        13144 Nov  7 09:59 home/user/install-mod/lib/modules/4.4.38-11.pvops.qubes.x86_64/kernel/crypto/async_tx/async_raid6_recov.ko
-rw-r--r--   1 root     root         8120 Nov  7 09:59 home/user/install-mod/lib/modules/4.4.38-11.pvops.qubes.x86_64/kernel/crypto/async_tx/async_tx.ko
(...)
drwxr-xr-x   3 root     root            0 Nov  7 09:59 usr/lib/modules
drwxr-xr-x   2 root     root            0 Nov  7 09:59 usr/lib/modules/4.4.38-11.pvops.qubes.x86_64
-rw-r--r--   1 root     root           45 Nov  7 09:59 usr/lib/modules/4.4.38-11.pvops.qubes.x86_64/modules.alias
-rw-r--r--   3 root     root            0 Nov  7 09:59 usr/lib/modules/4.4.38-11.pvops.qubes.x86_64/modules.alias.bin
-rw-r--r--   1 root     root         6933 Nov  7 09:59 usr/lib/modules/4.4.38-11.pvops.qubes.x86_64/modules.builtin
-rw-r--r--   1 root     root         9440 Nov  7 09:59 usr/lib/modules/4.4.38-11.pvops.qubes.x86_64/modules.builtin.bin
-rw-r--r--   1 root     root            0 Nov  7 09:59 usr/lib/modules/4.4.38-11.pvops.qubes.x86_64/modules.dep
-rw-r--r--   3 root     root            0 Nov  7 09:59 usr/lib/modules/4.4.38-11.pvops.qubes.x86_64/modules.dep.bin
-rw-r--r--   1 root     root            0 Nov  7 09:59 usr/lib/modules/4.4.38-11.pvops.qubes.x86_64/modules.devname
-rw-r--r--   1 root     root       122893 Nov  7 09:59 usr/lib/modules/4.4.38-11.pvops.qubes.x86_64/modules.order
-rw-r--r--   1 root     root           55 Nov  7 09:59 usr/lib/modules/4.4.38-11.pvops.qubes.x86_64/modules.softdep
-rw-r--r--   1 root     root           49 Nov  7 09:59 usr/lib/modules/4.4.38-11.pvops.qubes.x86_64/modules.symbols
-rw-r--r--   3 root     root           12 Nov  7 09:59 usr/lib/modules/4.4.38-11.pvops.qubes.x86_64/modules.symbols.bin

Full debug output: https://gist.github.com/marmarek/2efecb1e4f74ce3a42bcc3e7c7aa64af

console output says sure you passed a valid root filesystem!

Starting dhcp for interface eth0
dhcp: PREINIT eth0 up
dhcp: BOND setting eth0
<30>dracut: fetching \
http://test.foo.demonware.net/cobbler/ks_mirror/CentOS6_Diskless_dev_test/rootfs.tgz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  308M  100  308M    0     0  81.9M      0  0:00:03  0:00:03 --:--:-- 81.9M
squashfs: version 4.0 (2009/01/31) Phillip Lougher
<30>dracut: Mounted root filesystem /dev/mapper/live-rw
//lib/dracut/hooks/pre-pivot/85-write-ifcfg.sh: line 278: echo: write error: No space left on device
//lib/dracut/hooks/pre-pivot/85-write-ifcfg.sh: line 279: echo: write error: No space left on device
attempt to access beyond end of device
dm-0: rw=0, want=4177936, limit=4054792
attempt to access beyond end of device
dm-0: rw=0, want=4177936, limit=4054792
Cannot find init!
<28>dracut Warning:  sure you passed a valid root filesystem!

however it seems not

dracut:/#   mount
rootfs on / type rootfs (rw)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
devtmpfs on /dev type devtmpfs (rw,nosuid,size=2012468k,nr_inodes=503117,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
/dev/mapper/live-rw on /sysroot type ext2 (rw,relatime,errors=continue)
rpc_pipefs on /sysroot/var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime

Hi,
There's a few bugs elsewhere such as this one from RedHat Bugzilla and this one on the Fedora Forums that cover this issue.

Conditions:

• Dracut is using the systemd module and associated modules (dracut-systemd, systemd-initrd)
• A LUKS key file is desired (e.g.: rd.luks.key=test-key.LUKS)
• The crypttab file is expected to be automatically generated (rd.luks.crypttab=1 and rd.auto=1)

Results:

• The key file is probed for under module 90crypt/probe-keydev.sh and a result written to /tmp/luks.keys
• The crypttab is written to by module 90crypt/crypt-run-generator.sh, but this file does not check the contents of /tmp/luks.keys, instead leaving the third field as a dash(-) which means ask the user for a password
• The crypttab is converted to systemd unit files by running systemctl daemon-reload at the end of module 90crypt/crypt-run-generator.sh, and then the cryptsetup.target is started from the same script

Expected results:

• The key file is probed for as specified above
• The module file 90crypt/crypt-run-generator.sh is modified to fill in the third crypttab parameter as follows:
  • If a LUKS device is specified in rd.luks.key and the key file was found, then testing will be done to make sure that the LUKS device specified matches the LUKS device that is about to be added to the crypttab
  • If a LUKS device is not specified in rd.luks.key and a key file was found, then select the first key file that matches the device about to be added to the crypttab
  • If no key file is specified then set the field to a dash(-). If a key file is specified and found, the field will be set to a temporary path that the key file was read into

This should be as simple as some modifications within 90crypt/crypt-run-generator.sh to:

1. Determine if the rd.luks.key option was specified
2. Match it against the current LUKS device as required
3. Look for the matching key file and copy it to a temporary file
4. Set the password field. This field will be dash(-) if the rd.luks.key option isn't set, or the key file couldn't be found.

The following basic code can be added after the allow discards check in 90crypt/crypt-run-generator.sh until the end of the file. I haven't taken into account what happens when systemd isn't used in dracut, so some conditions will need to be added. I thought it better to get some code out first. I don't believe this file actually is used without systemd.

luks_key='-'
for arg in $(getargs rd.luks.key); do
    unset keypath keydev luksdev
    splitsep : "$arg" keypath keydev luksdev

    if [ -n "$keypath" ] ; then
        # Try to match the key file to only this device
        if [ -n "$luksdev" ] ; then
            if [ match_dev $luks $luksdev ] ; then
                luks_key="$keypath"
            fi
        else
            luks_key="$keypath"
        fi
    else
        continue
    fi

    unset arg keypath keydev luksdev
done

if [ -f $luks_key ] ; then
    # An absolute key path was specified so use it
    true
elif [ "$luks_key" != '-' ] ; then
    # By now the key would've already been probed for and found, so use it
    key_data=$(getkey /tmp/luks.keys $luks)
    if [ $? -ne 0 ] ; then
        # Couldn't find key file. Default to asking for password
        luks_key='-'
    else
        splitsep : "$key_data" keydev keypath
        luks_key=$(mktemp)
        readkey "$keypath" $keydev $luks > $luks_key
    fi

    unset keydev keypath key_data
fi

echo "$luks $dev $luks_key timeout=0,$allowdiscards" >> /etc/crypttab

if command -v systemctl >/dev/null; then
    systemctl daemon-reload
    systemctl start cryptsetup.target
fi
exit 0

In C, the strstr() function is a literal substring match, not a pattern match; in dracut-lib, there is a strstr() function, but it will perform a pattern match if the search argument contains shell glob characters *?[...]. The comments in dracut-lib do not say it is a pattern match, and perhaps it was not intended to be. My first instinct would be to call it a bug, and fix it to be a literal substring match. As it is, modules may be prone to unwanted behavior if certain characters are present in input, if the module authors assumed it was a safe substring match.

However, there are about 100 uses of strstr throughout the dracut source tree. Most of them use it as a literal string match (as far as I can see from a lazy grep). But there are about eleven places where code actually depends on strstr being a pattern match:

./modules.d/40network/net-lib.sh:    if strstr "$autoconf" "*.*.*.*"; then
./modules.d/40network/ifup.sh:    strstr $ip '*:*:*' && load_ipv6
./modules.d/40network/ifup.sh:    if strstr $ip '*:*:*'; then
./modules.d/95nfs/nfs-lib.sh:    if strstr "$arg" ':/*' ; then
./modules.d/99base/dracut-lib.sh:    if strstr "$arg" ':/*' ; then
./modules.d/80cms/cms-write-ifcfg.sh:    strstr "$IPADDR" '*:*:*' && ipv6=1
./modules.d/80cms/cmsifup.sh:strstr "$IPADDR" '*:*:*' && ipv6=1
./modules.d/45ifcfg/write-ifcfg.sh:    strstr "$netif" ":*:*:*:*:" && continue
./modules.d/45ifcfg/write-ifcfg.sh:            if strstr "$ip" '*:*:*'; then
./modules.d/45ifcfg/write-ifcfg.sh:            if strstr "$gw" '*:*:*'; then
./test/TEST-50-MULTINIC/client-init.sh: strstr "$i" ":*:*:*:*:" && continue

So there's a dilemma. Fixing strstr to be a literal string match would definitely break about 11% of uses in the dracut source tree (and some unknown number of uses in modules that might be maintained elsewhere) - but it would protect the other 89% from possible breakage by unexpected input (and some unknown number maintained out-of-tree).

Leaving it as is, and documenting that it is a glob match, would avoid breaking the 12% that use it that way, and eventually people could inspect the other 88% for the risk of misbehavior with strange input.

Either way, people who maintain modules (especially out of the dracut source tree) would need to know the decision, so they could inspect or update their code.

My proposal would probably be to rename the existing strstr to something like strglob, and change the known existing sites that use it that way to use strglob, and define a new strstr that is a literal match.

That's probably what I would do, but I won't presume to make the call.

There are also str_starts and str_ends that are glob matches but do not say so, but I did not find any instances of them being used that way, so it is probably an easier call to simply fix them to do literal matching.

I have a start on patches in a topic branch, but before making a pull request I wanted to check what the preferred approach would be.

dracut-lib defined info in such a way that it echoes to stdout.

Module writers have to be careful not to use info inside a function, if the function will be used in $(...) because the info message will then contaminate the function result instead of appearing at the console.

I would suggest either redefininginfo to write to stderr just as warn does (does the user care, or even have any way to find out, which messages appearing during boot were written to stderr and which to stdout?), or, if the stdout/stderr distinction really is important for some purpose I've missed, have init.sh do something very early on like:

exec 9>&1
export DRACUT_INFO_FD=9

and have dracut-lib redefine info to echo >&$DRACUT_INFO_FD

... which would require being sure that no module code also does file descriptor opens using the same number, and whatever number is chosen is available at the chosen point in init.sh.

It appears the virtio kernel drivers are missing from the initrd in no-host-only mode.

See:

systemd/mkosi#56

I've tried generating initramfs with the latest dracut and bash 4.4. The command I use is:
"dracut --debug -v -f -L 3 /boot/initramfs 4.7.6"

but the dracut debug mode hangs with this message:

/usr/lib/dracut/dracut-init.sh@955(instmods): local _optional=-o
/usr/lib/dracut/dracut-init.sh@956(instmods): local _silent
/usr/lib/dracut/dracut-init.sh@957(instmods): local _ret
/usr/lib/dracut/dracut-init.sh@959(instmods): [[ '' = yes ]]
/usr/lib/dracut/dracut-init.sh@961(instmods): [[ '' = -\c ]]
/usr/lib/dracut/dracut-init.sh@965(instmods): [[ '' = -\s ]]
/usr/lib/dracut/dracut-init.sh@970(instmods): (( 0 == 0 ))
/usr/lib/dracut/dracut-init.sh@971(instmods): read -r -d '' -a args

I believe that maybe the "read -r -d '' -a args"[1] is waiting for stdin and this is why dracut hangs.

1. https://github.com/dracutdevs/dracut/blob/master/dracut-init.sh#L971

Hello!

I've stumbled across a small issue trying to boot RHEL7 from an iSCSI LUN. (Emulex adapter with firmware-configured targets) /proc/cmdline: BOOT_IMAGE=/vmlinuz-3.10.0-123.el7.x86_64 root=UUID=**** ro iscsi_firmware rd.lvm.lv=rhel/root vconsole.keymap=us rd.lvm.lv=rhel/swap crashkernel=auto vconsole.font=latarcyrheb-sun16 ifname=**** rd.debug

Note: Results are identical on the latest kernel. I know iscsi_firmware is deprecated, but this is what Anaconda still generates today, will report this some other time. They still appear to have the same functionality. Specifying netroot=iscsi and/or rd.iscsi.firmware has no effect.

In modules.d/99base/initqueue.sh:

44: [ -x "$exe" ] || exe=$(command -v $exe)

results in the following behaviour:

dracut-cmdline[265]: /usr/sbin/initqueue@37(): job=395
dracut-cmdline[265]: /usr/sbin/initqueue@43(): exe='/sbin/iscsiroot dummy '\''iscsi:'\'' '\''/sysroot'\'''
dracut-cmdline[265]: /usr/sbin/initqueue@44(): shift
dracut-cmdline[265]: /usr/sbin/initqueue@46(): '[' -x '/sbin/iscsiroot dummy '\''iscsi:'\'' '\''/sysroot'\''' ']'
dracut-cmdline[265]: //usr/sbin/initqueue@46(): command -v /sbin/iscsiroot dummy ''\''iscsi:'\''' ''\''/sysroot'\'''
dracut-cmdline[265]: /usr/sbin/initqueue@46(): exe=/sbin/iscsiroot
dracut-cmdline[265]: /usr/sbin/initqueue@49(): '[' -n yes ']'
dracut-cmdline[265]: /usr/sbin/initqueue@49(): echo '[ -e "$job" ] && rm -f -- "$job"'
dracut-cmdline[265]: /usr/sbin/initqueue@50(): '[' -n '' ']'
dracut-cmdline[265]: /usr/sbin/initqueue@51(): echo '/sbin/iscsiroot '

Bash does not deem /sbin/iscsiroot dummy '\''iscsi:'\'' '\''/sysroot'\'' executable and uses command to get rid of the arguments.

modules.d/95iscsi/iscsiroot.sh doesn't appreciate this:

# Huh? Empty $1?
[ -z "$1" ] && exit 1

# Huh? Empty $2?
[ -z "$2" ] && exit 1

.. and never finishes the iscsi logins that are meant to follow.

As a workaround, I've simply commented out line 44 in initqueue.sh, as I honestly don't see the point in sanitizing input that has been generated by Dracut's own (trusted) scripts in the first place. If a user installs a hook that sends a malformed command line to the initqueue, that script needs to be fixed. It seems rather illogical to throw away the arguments to a command and execute it without them none the less. If anything, apparently this causes scripts to silently fail (which is something that should never happen anyway), which in turn causes headaches for the end user.

Commenting out line 44 works fine for me, but because of my very limited experience with this framework, it's rather difficult to judge whether or not this will break other functionality.

What do you think, @haraldh ?

Cheers!

Timo

Hi,

I'm currently building a distro for my personal needs which runs on my HDD from a live Fedora ISO. But I'd like to make the filesystem writeable using overlayfs. I'm using https://github.com/probonopd/SystemImageKit which is doing exactly what I want, except persisting data on the same partition.

So what I need to do is boot from the ISO on the HDD, this is working fine using SystemImageKit. I then need to use dracut to mount the root filesystem as an overlayfs of the live ISO's root filesystem and a directory on my HDD.

Essentially what I need to do is the following in the initramfs

mount --move / /os
mount <isodevice> /system
mount -t overlayfs -o lowerdir=/os,upperdir=/system/data overlayfs /

I'm just having trouble moving the root filesystem to another mount point. Then I can mount the HDD as read/write under /system then mount the root filesystem as an overlayfs of /os (original ISO root filesystem) and /system/data (a real directory on the HDD which sits alongside /boot).

In theory this should work if I can move the root filesystem.

I've tried this from the terminal my mounting the HDD under /mnt then running:

mount -t overlayfs -o lowerdir=/,upperdir=/mnt/data overlayfs /test

Then all my files are then stored in /mnt/data, and are merged with the root filesystem under the /test mount point, which is exactly what I need, but on the root filesystem.

I just need a way to get this same functionality working but under the root mount point instead of /test.

I have Dracut using Gentoo and system and zfs file systems. Dracut will mount the root fs, if I don't specify any root on the kernel command line, but will not mount anything else, including /usr. initrd-switchroot service fails because it can't find the system binary. Even if I mount /usr manually from the emergency shell, none of the other datasets will mount automatically, even though /etc/fstab has them correctly. I don't know if this is a bug in system or Dracut.

I noticed that "dracut --uefi --kernel-cmdline …" will always result in a kernel command line embedded in the resulting image prefixed by a single space character. This doesn't break anything, but is a tiny bit ugly...

# rpm -qf /usr/bin/dracut
dracut-044-78.fc25.x86_64

Issue is referenced here:

https://bugzilla.redhat.com/show_bug.cgi?id=1282679

I'm experiencing the same behavior, the patch provided on the bug link seems to resolve the issue.

Two of the dracut unit files should really set DefaultDependencies=no, but currently do not. All early-boot stuff should really set this. Specifically, these are the pre-pivot and mount service files. But there might be more, I didn't look into this in all detail.

(and while we are at it, some of the dracut unit files reference systemd.special(7) as documentation, and really shouldn't, since that man page doesn't cover dracut units...)

Hi,

with bash 4.4 (currently on RC stage) dracut stucks forever on building image:

/usr/lib/dracut/modules.d/90kernel-modules/module-setup.sh: line 15: warning: command substitution: ignored null byte in input

https://github.com/haraldh/dracut/blob/master/modules.d/90kernel-modules/module-setup.sh#L15

I have dracut set up to unlock a LUKS root drive by passphrase on boot - which it does just fine. Immediately after unlocking the root drive, it appears to hang for a few minutes before deciding it wants to get on with the rest of the boot process. I dropped into a shell and checked out the debugging information (pasted here: https://gist.github.com/749adbf0e908645bc6771cc41148bc5e) and it appears that check_finished (from dracut-lib.sh) is being run many, many times and doing the exact same operation.

I can't make heads or tails of this problem myself. Is it a problem with dracut-lib.sh or something? My cmdline is pretty sparse, I don't know what else I could do.

Hi I noticed that on line 128 in modules.d/95iscsi/iscsiroot.sh the path to initiator-name is wrong:
/sys/firmware/ibft/initiator-name should be /sys/firmware/ibft/initiator/initiator-name

In the "while pop include_src src && pop include_target tgt; do" loop, you do

ddebug "Including directory: $src"
....
s=${initdir}/${tgt}/${i#$src/}

s could be a filename or a directory name depending on the file type.
In the case it's a file, you are doing
cp --reflink=auto --sparse=auto -fa -t "$s" "$i"

But in that case, it's wrong. We should use ${initdir}/${tgt} instead of $s isn't it ?

Current behaviour:
When instmods_1 cannot find a module (for example), it returns an error (1). It's caller, instmods, aborts the installation of any further modules and returns also an error (1). dracut then ignores that error and does not even output a warning.

Expected behaviour:
Variant 1: instmods outputs a warning when instmods_1 returns an error, but continues to install the other modules.
Variant 2: dracut outputs an error message, including the module that failed, and aborts the whole operation.

The overlayfs module seems to be non-existent in dracut, but when my system has booted, the module is there.

How would I go about getting the overlayfs module available in my dracut hook? I've tried modprobe on overlayfs and overlay, but haven't had any luck.

There is a semi-related bug here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787553;msg=5 (basically that systemd 220 does not work; prior versions did)

My system has 2 physical disks, both using LUKS. They get decrypted via a flash drive that is mentioned in the initramfs's /etc/fstab. (This is due to limitations with systemd being in the initramfs and not being able to parse the better format (rd.luks.key=KEY=VALUE:/some.key)).

The drives once unlocked show a single LVM volume, then /dev/mapper/vg0-root will exist for starting up. Dracut would then set up this symlink to /dev/root and boot as normal.

In the broken boot up with systemd 220, manually doing the /dev/root symlink in the emergency shell works but obviously this is not a solution.

I downgraded to systemd 219 (provided by Gentoo's ebuild), rebuilt the initramfs, and booting works fine with that.

Configuration:

omit_dracutmodules+="gensplash bootchart dash plymouth btrfs mdraid multipath iscsi ndb biosdevname network fcoe-uefi ndb dmraid"
add_dracutmodules+="crypt crypt-gpg dm uefi-lib systemd crypt-loop lvm uvesafb"
add_fstab+="/usr/src/initrd-fstab"
omit_drivers+="nvidia vboxdrv vboxnetflt vboxnetadp"
hostonly="yes"

Log of 220 failing: https://gist.githubusercontent.com/Tatsh/03dd946a1ea2fc4ff690/raw/rdsosreport.txt

I ran across this while debugging https://bugzilla.redhat.com/show_bug.cgi?id=1347436 . Pasting from there:

each dracut module has a check() function which is used to indicate whether the module can and/or should be included in the initramfs being built. the check() function for the fcoe module does this:

check() {
    [[ $hostonly ]] || [[ $mount_needs ]] && {
        for c in /sys/bus/fcoe/devices/ctlr_* ; do
            [ -L $c ] || continue
            fcoe_ctlr=$c
        done
        [ -z "$fcoe_ctlr" ] && return 255
    }

    require_binaries dcbtool fipvlan lldpad ip readlink fcoemon fcoeadm || return 1
    return 0
}

So I think the first part there is basically a 'is this module needed' check: if we're in hostonly mode (or 'mount_needs', dunno what that is), let's check and see if there are actually any FCoE devices, and if not, return 255, indicating 'module isn't needed'.

The second part means 'make sure we can include these binaries in the initramfs, otherwise return 1 indicating the module should be included, but cannot be because some required binaries are missing'.

However, we have this 95fcoe-uefi module, too. How does setup() for that module look?

check() {
    [[ $hostonly ]] || [[ $mount_needs ]] && {
        [ -d /sys/firmware/efi ] || return 255
    }
    require_binaries dcbtool fipvlan lldpad ip readlink || return 1
    return 0
}

note it doesn't, AFAICS, include the check from the fcoe module. It just checks whether this is a UEFI boot, and wants to be enabled if it is. It also has this:

depends() {
    echo fcoe uefi-lib
    return 0
}

which obviously indicates a requirement for the 'fcoe' module. So I think what happens when you build a 'hostonly' initramfs on UEFI is that the fcoe module check() returns 255 (meaning 'nope, I don't need to be included'), but the fcoe-uefi module check() returns 0 (meaning 'yes, I do want to be included!') and drags fcoe along via dependencies (presumably a dependency beats out a 255 check() return code).

So you wind up with the fcoe module always included in initramfs'es built on UEFI systems, even though there are no FCoE mounts.

I dunno what the right way to fix this is - just duplicate the fcoe module's 'are there any FCoE mounts?' check into fcoe-uefi, or if there's a better way.

I am working a lot with systems using a squashfs root. Unless I manually add squasfs.ko to the list of kmods to include in the initrd I can't boot from them, even in --no-host-only mode. Would be good to include that module in that case.

As reported in Gentoo bug 585106, dracut 044 has problems on Gentoo when prelinking:

dracut: *** Resolving executable dependencies ***
dracut: *** Resolving executable dependencies done***
dracut: *** Pre-linking files ***
/usr/sbin/prelink: error while loading shared libraries: libelf.so.1: cannot open shared object file: No such file or directory
dracut: *** Pre-linking files done ***
dracut: *** Stripping files ***
dracut: *** Stripping files done ***

The corresponding dracut code reads thus:

        dinfo "*** Pre-linking files ***"
        inst_multiple -o prelink /etc/prelink.conf /etc/prelink.conf.d/*.conf
        chroot "$initdir" "$PRELINK_BIN" -a
        rm -f -- "$initdir/$PRELINK_BIN"
        rm -fr -- "$initdir"/etc/prelink.*
        dinfo "*** Pre-linking files done ***"

So apparently it lists the files prelink will probably need, does the prelink step, then uninstalls said files again. But it misses the libelf reported by ldd:

# ldd /usr/sbin/prelink 
    linux-vdso.so.1 (…)
    libelf.so.1 => /usr/lib64/libelf.so.1 (…)
    libc.so.6 => /lib64/libc.so.6 (…)
    libz.so.1 => /lib64/libz.so.1 (…)
    /lib64/ld-linux-x86-64.so.2 (…)

I think dracut-install --ldd (or some shell function invoking this, e.g. DRACUT_RESOLVE_DEPS=1 inst_multiple) should be able to install the prelink binary with all accompanying files. But cleaning that up again might be tricky.

If the kernel is built without modules, /proc/modules does not exist

In a situation where I am live booting a rootfs.img tarball, on its own this works perfectly.

Upon expanding my configuration to include a bond, it seems the bond is built and ifup'd before bootdev is. This causes livenet to trigger fetch-liveupdate.sh on a network connection that will not have access to the provided live image.

Example configuration

bootdev=enp0s3 bond=bond0:p3p1,p2p1:mode=4 ip=enp0s3:dhcp ip=192.168.0.5::192.168.0.1:255.255.0.0::bond0::none

I suspect the better approach is to ensure the network module ifup's bootdev first if it exists. Otherwise livenet needs to ingore taking action unless bootdev is what triggered the initqueue.

Hi , I have verified that livenet with a rootfs with ext2 format works well, it use curl to download real rootfs.

Can you add a feature to detect if compressed image? if yes , add a decompress step before switching root.

Thank you!

Kernel 4.6.3-300.fc24.x86_64 fails to boot when the root partition is f2fs with the following messages in rdsosreport.txt:

[   23.384898] Mobile-PC systemd[1]: Mounting /sysroot...
[   23.486479] Mobile-PC kernel: F2FS-fs (sda6): Cannot load crc32 driver.
[   23.432164] Mobile-PC mount[338]: mount: mount(2) failed: No such file or directory
[   23.490025] Mobile-PC kernel: F2FS-fs (sda6): Cannot load crc32 driver.

The fix for this is to force dracut to include the crc32_generic module by adding it to a file in /etc/dracut.conf.d. Here are the results when it is added:

# lsblk -f /dev/sda[56]
NAME FSTYPE LABEL        UUID                                 MOUNTPOINT
sda5 ext4   fedora24boot 5f07705e-354e-4768-8bc5-f28bfe79bc89 /boot
sda6 f2fs   fedora24     32b90059-3fe7-4f2d-9985-bcb486bf7ea9 /

# uname -sr                                                                  
Linux 4.6.3-300.fc24.x86_64

# sudo lsinitrd | grep crc32
-rw-r--r--   1 root     root         5496 Feb  3 12:28 usr/lib/modules/4.6.3-300.fc24.x86_64/kernel/arch/x86/crypto/crc32c-intel.ko.xz
-rw-r--r--   1 root     root         1912 Feb  3 12:28 usr/lib/modules/4.6.3-300.fc24.x86_64/kernel/crypto/crc32_generic.ko.xz
-rw-r--r--   1 root     root         1860 Feb  3 12:28 usr/lib/modules/4.6.3-300.fc24.x86_64/kernel/lib/libcrc32c.ko.xz

# cat /etc/dracut.conf.d/99-f2fs.conf
add_drivers+=" f2fs libcrc32c crc32_generic "

Notice that I added libcrc32c as well. The system boots without that module, but that module is loaded when the root partion is btrfs. I don't know if libcrc32c is required by f2fs, but since it's included for btrfs, I added it to the dracut.conf.d file.

Thanks,
Gene

Trying to run master (be27ef2) branch on a Fedora 23 machine.

$ sudo ./dracut.sh -M --kver 4.7.10-100.fc23.x86_64 --force 
bash
systemd
systemd-initrd
nss-softokn
i18n
network
ifcfg
drm
plymouth
btrfs
crypt
dm
kernel-modules
/usr/lib/dracut/dracut-functions.sh: line 1588: 3w_9xxx: value too great for base (error token is "3w_9xxx")
kernel-network-modules
/usr/lib/dracut/dracut-functions.sh: line 1588: 3c589_cs: value too great for base (error token is "3c589_cs")
/usr/lib/dracut/dracut-functions.sh: line 1588: 8021q: value too great for base (error token is "8021q")
installkernel failed in module kernel-network-modules

Bisected this issue to commit 3f60444 (removed obsolete kernel module functions and host_modules variable).

I haven't looked into this more than that. I'll just stick with the revision that works for the moment and will upgrade the machine soon anyway.

It is defined in dracut-lib.sh and in 95nfs/nfs-lib.sh. The definitions are identical.

It's used in 95nfs/nfs-lib.sh and in 95nfs/parse-nfsroot.sh, but the latter only sources dracut-lib, not nfs-lib.

Commit 9fcfa04 updated 95nfs/nfsroot.sh to source and use nfs-lib.sh, but it doesn't seem that was ever done to 95nfs/parse-nfsroot.sh. Was it supposed to be? That would allow the copy of nfsroot_to_var() in dracut-lib to be removed, I assume, in favor of the one in nfs-lib where it seems most at home.

If systemd-module used, resume from hibernate do not work, if in kernel cmdline specified device as LABEL:

resume=LABEL=SWAP

With resume=/dev/sda8 resume work.

I would like to create a github "dracut" organization, but the @dracut user is in the way

Maybe dracut should provide .pc files specifying path to directory with modules.

rhbz#1397853

It's been a while since the last release, are there any plans to cut a new one?

Thanks!

I have the exact same issue as described on https://lists.fedoraproject.org/pipermail/users/2015-July/463627.html and https://lists.fedoraproject.org/pipermail/devel/2015-July/212956.html

The fact is with overlayfs (or aufs from 2014 Ubuntu release) Live Linux you can apt-get install whatever (write to /) as much data as possible; till it becomes full and returns -ENOSPACE (and continues usable if clean some data), on this Fedora Live OS with device-mapper and simple sudo dnf install a few packages crashes kernel. Which is more mature?

The live system crashes when installing large packages despite having 8GB or RAM in the system. Other live systems such as casper do not have this issue. As far as I can see, there is no solution for this yet.

The difference for me as a user is that I can use casper-based live systems for my actual daily work (do not crash) while I cannot do the same with dracut-based Fedora live images (always crash).

Please make it possible to overlay-mount a large(!) amount of RAM so that the live system can handle large file system operations without crashing.

Thanks for your consideration.

Description of problem:

When booting a Fedora 19 Live ISO with "vconsole.font=latarcyrheb-sun16 vconsole.keymap=de-latin1-nodeadkeys locale.LANG=de_DE.UTF-8" the language and keyboard are still English rather than German as intended. This effectively prevents from booting Dracut-based Live ISOs in languages other than English

How reproducible:

Always

Steps to Reproduce:

Boot Fedora-Live-Desktop-i686-19-1.iso with the following kernel arguments:

BOOT_IMAGE=(loop)/isolinux/vmlinuz0 iso-scan/filename=/boot/iso/Fedora-Live-Desktop-i686-19-1.iso vconsole.font=latarcyrheb-sun16 vconsole.keymap=de-latin1-nodeadkeys locale.LANG=de_DE.UTF-8 root=live:CDLABEL=Fedora-Live-Desktop-i686-19-1 rootfstype=auto ro rd.live.image quiet rhgb rd.luks=0 rd.md=0 rd.dm=0

Additional information:

The kernel arguments above are copied verbatim from the section "a typical german kernel command would contain" on Dracut's documentation page on https://www.kernel.org/pub/linux/utils/boot/dracut/dracut.html

Now that Dracut has started to harmonize Live image boot options with Ubuntu (such as "iso-scan/filename"), it might be reasonable to standardize on these ones as well:

console-setup/layoutcode=de locale=de_DE.UTF-8 timezone=Europe/Berlin

I think this may be related to https://bugzilla.redhat.com/show_bug.cgi?id=827187

[chris@f25h ~]$ sudo dracut --print-cmdline
rd.lvm.lv=vg/swap
resume=/dev/mapper/vg-swap root=PARTUUID=b9f0e09b-c6cf-4f48-8511-e63e3ec26f1f rootfstype=btrfs rootflags=rw,relatime,seclabel,ssd,space_cache,subvolid=257,subvol=/root,subvol=root

All of the listed rootflags options are unnecessary except subvol=root (or subvol=/root or subvolid=257), not all three are needed. And the other options are defaults so I don't know why they're being recommended by print-cmdline.

Adding something like ifname=foo:aa:bb:cc:dd:ee:ff to kernel boot arguments causes dracut to die "Invalid arguments for ifname=". After adding rd.break=cmdline, I can see that /proc/cmdline has it as ifname=foo:aabbccddeeff. Is dracut defining /proc/cmdline or is that something else like the kernel or systemd? Should dracut be made to be more accepting of the ifname parameter? If so, I can submit a PR - just want to know how best to address this.

If dracut is run with a relative --tmpdir path, then the corresponding $DRACUT_TMPDIR subdirectory will also be a relative path.
dracut changes working directory before attempting to output files under $DRACUT_TMPDIR , e.g.

1701     # The microcode blob is _before_ the initramfs blob, not after
1702     if ! (
1703             cd "$early_cpio_dir/d"
1704             find . -print0 | sort -z \
1705                 | cpio ${CPIO_REPRODUCIBLE:+--reproducible} --null $cpio_owner_root -H newc -o --quiet > "${DRACUT_TMPDIR}/initramfs.img"
1706         ); then
1707         dfatal "dracut: creation of $outfile failed"
1708         exit 1
1709     fi

In this case, the $DRACUT_TMPDIR is assumed relative to the "$early_cpio_dir/d" working directory ("${DRACUT_TMPDIR}/earlycpio/d"), so the file redirect fails.

AFAICT, this is a regression introduced with 62c00a8 .

If I boot with rd.break=pre-mount, for example, it breaks before mounting, and then also breaks again before switching root. I'm pretty sure this is just because init.sh uses a plain getarg rd.break (with no =value) for the last breakpoint before switching root, and getarg returns true for that regardless of what value was on the command line.

I was going to submit a patch but figured I'd ask first whether that was intended behavior for any reason.

see commit b070c1d
ndb-generator.sh is not in the $moddir

dracut(8) describes --hostonly-i18n and --no-hostonly-i18n as below, which I take as --hostonly-i18n is the default behavior of dracut when handling i18n files. But actually dracut installs all keyboard and font files when neither of these two options is specified (e.g. dracut foo.img).

--hostonly-i18n: Install only needed keyboard and font files according to the host configuration (default).
--no-hostonly-i18n: Install all keyboard and font files available.

If $no_kernel != yes, /proc/modules is populated, and $srcmods/modules.dep is missing I would expect dracut to exit fatally. At present it's only a warning.

If /dev/block is non-existent, fail or fallback to some other mechanism