Bug 922988

Hmm. So it looks like spice-vdagent package contains:

/etc/modules-load.d/spice-vdagentd.conf

which reads:

# load uinput.ko for spice input
uinput

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:

%packages
-gnome-initial-setup
firstboot
gnome-screensaver
gnome-session-xsession
%end

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:
> 
> /etc/modules-load.d/spice-vdagentd.conf
> 
> which reads:
> 
> # load uinput.ko for spice input
> uinput
> 
> 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.

ignore that

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:
> 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.

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]
Proposed patch

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[1]: 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 /
mkdir /run
mount -o remount,ro /

And now it boots normally.
So this looks like a blocker to me?

For now that's being tracked separately:

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

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.