Bug 1236937

Summary: anaconda does not write /etc/fstab on live install
Product: [Fedora] Fedora Reporter: Chris Murphy <bugzilla>
Component: anacondaAssignee: Anaconda Maintenance Team <anaconda-maint-list>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 23CC: amulhern, anaconda-maint-list, awilliam, bcl, bugzilla, dlehman, g.kaviyarasu, johannbg, jonathan, jsynacek, kparal, lnykryn, msekleta, robatino, s, systemd-maint, vanmeeuwen+fedora, vpodzime, zbyszek
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: AcceptedBlocker
Fixed In Version: anaconda-23.16-1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-07-20 23:22:02 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 1170817    
Description Flags
bad fstab
storage.log none

Description Chris Murphy 2015-06-30 04:14:30 UTC
Description of problem: /etc/fstab is malformed, /boot, /boot/efi, /home are not mounted, and swap is not activated. (Actually I don't mind that /boot and /boot/efi aren't persistently mounted, they shouldn't be anyway, but this is probably unintended).

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Default automatic installation to a blank drive, only added option was encryption enabled.
2. install and reboot

Actual results:

Per above, things that are normally mounted/activated aren't. See /etc/fstab attached.

Expected results:

A proper fstab so the system assembles correctly at boot time.

Additional info:

Comment 1 Chris Murphy 2015-06-30 04:15:06 UTC
Created attachment 1044542 [details]
bad fstab

Comment 2 Chris Murphy 2015-06-30 04:15:18 UTC
Created attachment 1044543 [details]

Comment 3 Chris Murphy 2015-06-30 04:15:28 UTC
Created attachment 1044544 [details]

Comment 4 Chris Murphy 2015-06-30 04:15:38 UTC
Created attachment 1044545 [details]

Comment 5 Fedora Blocker Bugs Application 2015-06-30 04:23:37 UTC
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.

Comment 6 Adam Williamson 2015-06-30 05:51:36 UTC
what image, exactly, did you install with?

Comment 7 Chris Murphy 2015-06-30 14:32:02 UTC

Comment 8 Chris Murphy 2015-07-06 19:02:54 UTC
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.

Comment 9 Chris Murphy 2015-07-07 14:24:10 UTC
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.

Comment 10 Kamil Páral 2015-07-10 11:28:13 UTC
The same problem has been reported today by twohot on #fedora-qa IRC.

Comment 11 David Lehman 2015-07-10 16:15:43 UTC
This /etc/fstab was written by systemd or dracut -- not anaconda or blivet. Note the missing header indicating it was written by anaconda.

Comment 12 David Lehman 2015-07-10 16:19:02 UTC
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.

Comment 13 Adam Williamson 2015-07-13 16:26:46 UTC
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.

Comment 14 Adam Williamson 2015-07-15 20:52:13 UTC
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.

Comment 15 Adam Williamson 2015-07-15 21:45:15 UTC
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.

Comment 16 Adam Williamson 2015-07-15 21:46:57 UTC
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'.

Comment 17 Adam Williamson 2015-07-15 21:50:36 UTC
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
                    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.

Comment 18 Adam Williamson 2015-07-15 21:51:57 UTC
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.

Comment 19 Adam Williamson 2015-07-15 22:41:43 UTC

Comment 20 Adam Williamson 2015-07-20 23:22:02 UTC
This is fixed in 23.16, and the 07-17 nightlies.