I finally managed to build a vaguely working F19 live image today, with latest systemd and dracut and livecd-tools and a bunch of GNOME-level workarounds that shouldn't affect this. I can even run a full install process, which is surprising.
However, the installed system fails to boot. Bit hard to get the journalctl output out, but here are the interesting lines:
systemd-modules-load: Failed to find module 'uinput'
systemd: systemd-modules-load.service: main process exited, code=exited, status=1/FAILURE
systemd: Failed to start Load Kernel Modules.
systemd: Unit systemd-modules-load.service entered failed state
systemd: Job dev-mapper-fedora\x2droot.device/start timed out.
systemd: Timed out waiting for device dev-mapper-fedora\x2droot.device.
systemd: Dependency failed for /sysroot.
systemd: Dependency failed for Initrd Root File System.
systemd: Dependency failed for Reload Configuration from the Real Root.
I'm guessing this may have something to do with dracut, but CCing systemd devs too.
Hmm. So it looks like spice-vdagent package contains:
# load uinput.ko for spice input
But this isn't new; my installed F18 system has the same thing. uinput is not in the initramfs either on that (working) system or the (broken) system here. So I don't know what changed that causes this not to work in this test.
Hm. Moving that config file out of the way doesn't seem to make any difference, it still tries to load uinput. Don't really know where to go from there.
Proposing as an Alpha Blocker. New-style criterion:
"A system installed with a graphical package set must boot to the 'firstboot' utility on the first boot after installation. The firstboot utility must be able to create a working user account."
Where can I get this image?
For the record, it was a private side build, but I provided Harald with a copy. If anyone's playing along at home, to build a desktop live with current F19 repos, you'll need this kickstart recipe:
and make sure you use the latest f19 livecd-tools (even if you build on f18).
(In reply to comment #1)
> Hmm. So it looks like spice-vdagent package contains:
> which reads:
> # load uinput.ko for spice input
> But this isn't new; my installed F18 system has the same thing. uinput is
> not in the initramfs either on that (working) system or the (broken) system
> here. So I don't know what changed that causes this not to work in this test.
Created attachment 712730 [details]
No /sys after installation!
Directory "/sys" does not exist after installing from the Live-CD !
Created attachment 712788 [details]
systemd cannot mount /sys
So Harald and I seem to be seeing different problems...but in my case, we've traced it down to using virtio disk interface. If I switch to an 'IDE' disk in my VM, it boots successfully to firstboot.
lsinitrd | grep virt shows only usr/lib/sysctl.d/libvirtd.conf - no virtio modules.
after 'dracut -f', lsinitrd shows the virtio modules. So it looks like they're missing from the initramfs after a live install.
harald suggested running this during the postInstall:
new-kernel-pkg --rpmposttrans <kernel_version>
(In reply to comment #11)
> harald suggested running this during the postInstall:
> new-kernel-pkg --rpmposttrans <kernel_version>
doesn't help in this case
But I see that /sys is not mounted on /mnt/sysimage, while installing.
And I also see, that /mnt/sysimage/sys does not exist.
(In reply to comment #13)
> But I see that /sys is not mounted on /mnt/sysimage, while installing.
> And I also see, that /mnt/sysimage/sys does not exist.
And, when I mount bind /mnt/sysimage/sys manually, while rsync syncs, the initramfs contains the proper virtio drivers.
started livecd with "selinux=0"
ERR anaconda: unknown selinux state: None
And I need:
# mount --bind /run /mnt/sysimage/run
to be able to read the udev database.
(In reply to comment #16)
> And I need:
> # mount --bind /run /mnt/sysimage/run
> to be able to read the udev database.
oh, and you want to exclude /run from rsync also
dracut-026-72.git20130320.fc19 has a safety check and turns off hostonly mode, if one of the essential filesystems is not mounted or the udev database not available.
Discussed at 2013-03-20 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-03-20/f19alpha-blocker-review-2.2013-03-20-16.00.log.txt . We decided to delay decision on blocker status to find out how bad the impact is (how many modules may be missing), as the impact on virtual machines alone is not enough to constitute Alpha blocker status.
Really, though, we expect the bug to be closed by next week, so we wouldn't have to worry about it: Harald's dracut adjustment should paper over the anaconda issue, and it should not be difficult to fix the anaconda issue, so we ought to be able to fix this from both ends.
(In reply to comment #19)
> Discussed at 2013-03-20 blocker review meeting:
> blocker-review-2.2013-03-20-16.00.log.txt . We decided to delay decision on
> blocker status to find out how bad the impact is (how many modules may be
> missing), as the impact on virtual machines alone is not enough to
> constitute Alpha blocker status.
> Really, though, we expect the bug to be closed by next week, so we wouldn't
> have to worry about it: Harald's dracut adjustment should paper over the
> anaconda issue, and it should not be difficult to fix the anaconda issue, so
> we ought to be able to fix this from both ends.
The impact is really bad, because hostonly mode would fail completely in this situation. And we don't want to fallback to generic mode, just because the installer does not mount /sys and /run.
Created attachment 713771 [details]
Created attachment 713815 [details]
Proposed patch for anaconda
also call new-kernel-pkg with --rpmposttrans
This will build the rescue initramfs image.
This will be fixed in blivet 0.9 and anaconda 19.13
Just as a note, the dracut-side band-aid does work in Alpha TC1: I was able to install it to a KVM with virtio disk and boot the installed system. But we should certainly fix anaconda-side too.
Discussed at 2013-03-27 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-03-27/f19alpha-blocker-review-3.2013-03-27-16.01.log.txt . Agreed to drop the blocker nomination as the dracut band-aid fixed this effectively for TC1. We can close it when blivet 0.9 goes out.
I finally got TC2 installed in a VM, and now it's hanging at boot with:
systemd: Failed to mount /run: No such file or directory
Not sure if it's related to this TBH
OK just booted there with init=/bin/sh and did:
mount -o remount,rw /
mount -o remount,ro /
And now it boots normally.
So this looks like a blocker to me?
For now that's being tracked separately:
if anaconda team reckons they should be combined, though, they can be.
*** Bug 928339 has been marked as a duplicate of this bug. ***
Discussed at 2013-04-03 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-04-03/f19alpha-blocker-review-4.2013-04-03-16.01.log.txt . We can transfer AcceptedBlocker status from 928339. We are unclear if all symptoms of this bug are fixed in blivet 0.9 / TC3, further testing would help clear that up, and we should also check with TC4 when it lands.
So far as I can tell, everyone complaining in this bug or in one of the ones that has been marked as a dupe says things are fixed as of TC3 (hence blivet 0.9, which is stable). So let's close this.