Bug 208093 - Try to be more intelligent in handling of noauto filesystems which should be auto mounted
Try to be more intelligent in handling of noauto filesystems which should be ...
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Anaconda Maintenance Team
: Reopened
: 208193 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-09-26 09:04 EDT by Gilboa Davara
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-08-22 16:16:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Anaconda log. (14.88 KB, text/plain)
2006-09-27 18:03 EDT, Gilboa Davara
no flags Details
Upgrade logs. (8.03 KB, application/x-compressed-tar)
2006-10-03 02:06 EDT, Gilboa Davara
no flags Details

  None (edit)
Description Gilboa Davara 2006-09-26 09:04:19 EDT
Description of problem:
I usually setup a different partition for /boot (a very common practice).
When Anaconda mounts the previous FC in /sysimage, it only mounts the root and
home partitions, neglecting to mount (and use) the previous /boot partition.
The information itself is available under /etc/fstab (+partition label).

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

How reproducible:
Always.

Steps to Reproduce:
1. Install FCx with /boot under a different partition.
2. Upgrade to FCx+1.
3.
  
Actual results:
Anaconda does not detect and mount the old /boot partition, installing the
kernel in the old root partition.

Expected results:
Anaconda should scan the /etc/fstab, detect the /boot configuration and mount it.

Additional info:
Same problem exists if /boot uses an software RAID1 array.
Comment 1 Jeremy Katz 2006-09-27 14:45:17 EDT
/boot should be mounted as long as it's in /etc/fstab and findable.  Can you
provide /var/log/anaconda*?
Comment 2 Gilboa Davara 2006-09-27 16:08:37 EDT
Sadly enough the FC5 imaged died due to a botched upgrade attempt. :(
(https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208193)

- Gilboa

Comment 3 Jeremy Katz 2006-09-27 16:09:41 EDT
*** Bug 208193 has been marked as a duplicate of this bug. ***
Comment 4 Jeremy Katz 2006-09-27 16:29:48 EDT
Hrmm... without that (or /tmp/anaconda.log from the install), it's hard to
figure out exactly what happened here.  I've definitely done an upgrade and
/boot got properly mounted :/
Comment 5 Gilboa Davara 2006-09-27 18:03:44 EDT
Created attachment 137259 [details]
Anaconda log.

I've recreated the FC5 vmware image and started over.
As before, anaconda failed to mount the boot partition.

- Gilboa
Comment 6 Jeremy Katz 2006-09-28 10:34:50 EDT
What did /etc/fstab look like -- there's no indication in the log at all that it
ever saw /boot there :/
Comment 7 Gilboa Davara 2006-09-28 11:09:48 EDT
LABEL=/boot				/boot				ext3	noauto,defaults	1 2
devpts					/dev/pts			devpts	gid=5,mode=620	0 0
tmpfs					/dev/shm			tmpfs	defaults		0 0
/dev/VolRoot/LogHome	/home				ext3	defaults		1 2
proc					/proc				proc	defaults		0 0
sysfs					/sys				sysfs	defaults		0 0
/dev/VolRoot/LogSwap	swap				swap	defaults		0 0
/dev/hdc				/media/cdrom		auto	noauto,defaults,users
/dev/VolRoot/LogRoot	/	   				ext3	defaults		1 2

Comment 8 Jeremy Katz 2006-09-28 11:30:57 EDT
Aha -- it's because it's marked as noauto, so we don't try to mount it as the
fstab says "don't mount this by default".  anaconda listens to that (otherwise,
we end up getting hosed by things like your cdrom entry)
Comment 9 Gilboa Davara 2006-09-28 13:01:38 EDT
... This leaves a very wierd problem.
Not mounting boot by default is a -good- thing. I'd recommend adding support for
hidden root to Anaconda and yum... but that's a different sory.

Two questions:
A. OK, boot wasn't mounted. Why did Anaconda crash?
(https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208193) It should have
created a brand new grub configuration instead of the missing one. (Wild guess:
Anaconda saw the grub.conf symbolic link [which points to nothing, as boot was
never mounted] tried to parse it and died.)

B. Shouldn't it be prudent to add special case support for /boot as unmounted
/boot is not uncommon in production machines.
Anaconda should have detected the missing /boot and ask the user for directions.

- Gilboa
Comment 10 Gilboa Davara 2006-10-03 01:58:21 EDT
Test4 didn't automount /boot, which is OK (It disabled the "grub update" option
until I manually mounted the /boot partition. (it'll be nicer if Anaconda didn't
just disable the update option).
Installation worked just fine, no exceptions.
However, when I tried to reboot the machine, I got the dreaded "GRUB GRUB GRUB
GRUB..."
I had to rebooted the test4 ISO in rescue mode and fix the grub configuration
(grub; root (hd0,0); setup (hd0); quit) in-order to get the grub working again.

Logs attached.

- Gilboa
Comment 11 Gilboa Davara 2006-10-03 02:06:50 EDT
Created attachment 137626 [details]
Upgrade logs.
Comment 12 Jeremy Katz 2006-10-04 11:31:16 EDT
Changing the summary to reflect reality a little bit more.

Although, realistically, I'm not sure how much we can reasonably do without
making the upgrade UI impossible for ordinary users.
Comment 13 Gilboa Davara 2006-10-04 12:00:08 EDT
Repost of my -testing message:

It seems to me that there's a bigger problem at stake here.
Currently the user is unable to detect (and correct) FS/hardware/etc problems
during the mount phase, such as failed mounts (due to FS errors), failed
software RAID arrays (due to missing/failed drives), etc - all of this might
generate botched upgrades or unexplained Anaconda exceptions.
In-order to solve the bigger problem, I suggest that:

A. Once Anaconda is done scanning the fstab, it should display the list of
detected devices and partitions. This options is a must - especially when
upgrading a machine with LVM and/or MD array(s). 

B. Either (1) enable the "Back" button, giving the user an option to restart the
fstab detection phase or (2) add a UI button "Terminal", giving the user an
option to load missing drivers/fix the fstab/fix a bad software RAID array/etc.

C. Once the user selects "Back" (B1) or exists the terminal (B2), goto step A.

Of the top of my head, A -> B1 -> C -> A sounds like a rather simple solution to
implement (that requires 0 UI changes) - but I don't know Python and/or Anaconda
well enough to verify this bold assessment.

- Gilboa
Comment 14 Red Hat Bugzilla 2007-06-11 23:18:24 EDT
requested by Jams Antill
Comment 15 David Cantrell 2007-08-22 16:16:00 EDT
This is a CANTFIX bug.  Anaconda has to obey fstab on systems it's upgrading. 
If you change your /boot partition to be noauto, we obey that.  Breaking the
rules in anaconda opens the door to future problems, i.e., there is always a
special case.

The suggestions in comment #13 are ok for an advanced user, but severely
complicate the UI for ordinary users.

Note You need to log in before you can comment on or make changes to this bug.