From Fedora Project Wiki

< User talk:Wwoods

Revision as of 18:43, 9 August 2011 by Wwoods (talk | contribs) (Add comment about hamzy's issue, add "Slow" section from jreiser)

Boot problem (jreiser)

[2011-08-06 0000 UTC] Upon boot of DVD, then dracut drops to shell with the message:

 Warning: No root device "live:/dev/disk/by-label/Fedora" found.

The file is present as

 /dev/disk/by-label/Fedora 16 x86_64 DVD

with those three spaces. Reboot with quoting (single, or double, or backslash) also fails. Altering the boot parameter to


also fails [that name is in my /dev/disk/by-id].

[2011-08-06 1700 UTC] After modifying pungi so that the label of the DVD has dashes "Fedora-16-x86_64-DVD" and changing the boot command line to include the dashes "root=live:CDLABEL=Fedora-16-x86_64-DVD", then dracut still complains "No root device \"live:/dev/disk/by-label/Fedora-16-x86_64-DVD\" found". The device is there, symlinked to ../../sr0 ==> /dev/sr0, and that is the correct name of the hardware drive.

[2011-08-07 0400 UTC] In the emergency shell after dracut cannot find the root, I can find it by:

 mkdir /mnt1 /mnt2 /mnt3
 mount -o ro,loop /dev/sr0 /mnt1
 mount -o ro,loop /mnt1/images/install.img /mnt2
 mount -o ro,loop /mnt2/LiveOS/rootfs.img /mnt3

but I cannot find how to specify that in a "root=live..." that dracut understands. It's also a mystery why so many mounts are necessary.

notes/solutions (wwoods)

  1. The DVD isn't built correctly - pungi changes the label of the image without changing the boot config file. Pungi will need to be fixed to handle that. (boot.iso should work fine.)
    • I believe dracut expects spaces to be escaped, so it would need to be: root=live:CDLABEL=Fedora%x2016%x20x86_64%x20DVD
    • As a workaround, you could just boot with root=live:/dev/sr0
  2. The mounts are necessary because treebuilder images are live images, and all live images are ext4 images inside squashfs images inside an iso (CD/DVD) or vfat (USB stick) filesystem.
    • Yes, that does seem needlessly complicated
    • No, there isn't a simpler way to do it right now

mount traps when systemd mounts /tmp (hamzy)

Seen during booting:

... [ 11.992445] systemd[1]: tmp.mount mount process exited, code=killed status=11 [ 12.029660] systemd[1]: Job loader.service/start failed with result 'dependency'. [ 12.029695] systemd[1]: Unit tmp.mount entered failed state. ...

bash-4.2# systemctl status tmp.mount [ 71.988204] systemd[1]: Accepted connection on private bus. [ 71.988860] systemd[1]: Got D-Bus request: org.freedesktop.systemd1.Manager.LoadUnit() on /org/freedesktop/systemd1 [ 71.989077] systemd[1]: Got D-Bus request: org.freedesktop.DBus.Properties.GetAll() on /org/freedesktop/systemd1/unit/tmp_2emount tmp.mount - Runtime Directory

         Loaded: loaded (/lib/systemd/system/tmp.mount)
         Active: inactive (dead)
          Where: /tmp
           What: tmpfs
         CGroup: name=systemd:/system/tmp.mount

[ 71.990451] systemd[1]: Got D-Bus request: org.freedesktop.DBus.Local.Disconnected() on /org/freedesktop/DBus/Local


boot with the following options

  linux systemd.log_target=kmsg systemd.log_level=debug rd.break

run the following command in the shell

  sed -i -e 's/tmp\.mount //' /sysroot/lib/systemd/system/loader.service

(should be fixed in images built Aug. 9 and later)

Slow (jreiser)

Treebuilder is slower. The first culprit looks like dracut.

number execve
7606 /bin/egrep
2578 /bin/cp
1633 /lib64/
1434 /usr/bin/ldd
1413 /bin/ln
1303 /usr/local/bin/ln
1303 /usr/bin/ln
1087 /sbin/modinfo

The second culprit is not honoring $TMPDIR, and not putting yumroot-$PID and installroot-$PID inside it.

count filename
1693845 *
253387 $DESTDIR/yumroot/...
79977 $DESTDIR/installroot/...
44486 /etc/xattr.conf
41713 /proc/self/task/31818/attr/fscreate
25919 /proc/self/task/1070/attr/fscreate
20220 /usr
19487 /etc/localtime
18485 /lib64/
18294 /usr/share
18184 /etc/
18074 /etc/
17213 /usr/bin/ldd
14471 /bin/egrep
9861 /usr/share/locale
9090 /var/log/dracut.log
9013 /dev/null
7529 /sbin/modprobe
6110 .

commentary (wwoods)

This is pretty useless without some hard numbers. On my years-old test systems, I can complete a run in the following times:

Arch Time
x86_64 19m15s (20m35s user, 2m56s system)
ppc64 40m10s (28m46s user, 16m37s system)

If time is your primary concern, here's some speedup suggestions:

  • Add this to /etc/lorax/lorax.conf: