Bug 1236937

Created attachment 1044542 [details]
bad fstab

Created attachment 1044543 [details]
anaconda.log

Created attachment 1044544 [details]
program.log

Created attachment 1044545 [details]
storage.log

Proposed as a Blocker for 23-alpha by Fedora user chrismurphy using the blocker tracking app because:

 "The installed system must be able to download and install updates with the default console package manager."

Since /boot isn't in fstab, kernel updates definitely won't succeed. There may be other things that fail too, but /home not mounting just means the /home directory on root fs is used instead, which is a silent soft fail.

what image, exactly, did you install with?

Fedora-Live-Workstation-x86_64-rawhide-20150628.iso

100% reproducible on vbox uefi with Fedora-Live-Workstation-x86_64-rawhide-20150704.iso, even without encryption. I haven't tried BIOS yet. +1 blocker.

Also happens in qemu-kvm (virt-manager and boxes), so BIOS is affected. This happens with both automatic/guided and custom installations. So far I can't avoid hitting this bug.

The same problem has been reported today by twohot on #fedora-qa IRC.

This /etc/fstab was written by systemd or dracut -- not anaconda or blivet. Note the missing header indicating it was written by anaconda.

I think the problem is actually that anaconda isn't writing out an /etc/fstab so the system is getting the /etc/fstab from the live environment. My money's on commit 3e800998.

Discussed at 2015-07-13 F23 blocker review meeting: http://meetbot-raw.fedoraproject.org/fedora-blocker-review/2015-07-13/f23-blocker-review.2015-07-13-16.03.log.txt . Accepted as an Alpha blocker per criterion cited in comment #5.

Looks like this doesn't affect boot.iso installs, only lives - I did an install from the 2015-07-14 nightly boot.iso (with updates.img fixing the various other bugs in that) and got a /etc/fstab written by anaconda which has a /boot entry. I agree with dlehman that 3e800998 looks like the obvious suspect, I'll try and dig into that and figure out what's going wrong.

So it seems that self.method.method is 'harddrive' when that test is triggered, not 'liveimg'. That's why the test fails. I don't know if that's right or wrong.

Oh, sorry, missed a bit. Where this goes wrong is the first 'if' statement in writeStorageLate():

if self.data.method.method == "liveimg" and not flags.dirInstall:

I stuck in a debug log message to report what self.data.method.method actually is, and it seems that with a 2015-07-04 nightly live install (the last image I have handy that works), it's 'harddrive', not 'liveimg'. That's the problem. I don't know if the 'if' statement is incorrect or if self.data.method.method really ought to be 'liveimg'.

Note that before 3e800998 , the equivalent test looked like this:

    write_storage_late = (flags.flags.livecdInstall or ksdata.ostreesetup.seen
                          or ksdata.method.method == "liveimg")

i.e. it also checked for flags.flags.livecdInstall (and OStree cases). The only other point in anaconda source which looks for a 'liveimg' method is the Anaconda class's 'payload' property:

                elif flags.livecdInstall:
                    from pyanaconda.packaging.livepayload import LiveImagePayloa
d
                    klass = LiveImagePayload
                elif self.ksdata.method.method == "liveimg":
                    from pyanaconda.packaging.livepayload import LiveImageKSPayload
                    klass = LiveImageKSPayload

that leads me to suspect that the 'liveimg' method is something fairly unusual (some kind of kickstarted live payload?) and we should be checking for flags.livecdInstall as well as 'liveimg' method here, as the old check did.

Per https://github.com/rhinstaller/pykickstart/blob/master/docs/kickstart-docs.rst#liveimg , I think ksdata.method.method is only 'liveimg' if we're installing from a kickstart with the 'liveimg' parameter, it isn't 'liveimg' on a normal live image install.

https://github.com/rhinstaller/anaconda/pull/209

This is fixed in 23.16, and the 07-17 nightlies.