Bug 208093
Summary: | Try to be more intelligent in handling of noauto filesystems which should be auto mounted | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Gilboa Davara <gilboad> | ||||||
Component: | anaconda | Assignee: | Anaconda Maintenance Team <anaconda-maint-list> | ||||||
Status: | CLOSED CANTFIX | QA Contact: | |||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | medium | ||||||||
Version: | rawhide | Keywords: | Reopened | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | All | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2007-08-22 20:16:00 UTC | Type: | --- | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Attachments: |
|
Description
Gilboa Davara
2006-09-26 13:04:19 UTC
/boot should be mounted as long as it's in /etc/fstab and findable. Can you provide /var/log/anaconda*? Sadly enough the FC5 imaged died due to a botched upgrade attempt. :( (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208193) - Gilboa *** Bug 208193 has been marked as a duplicate of this bug. *** 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 :/ 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
What did /etc/fstab look like -- there's no indication in the log at all that it ever saw /boot there :/ 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 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) ... 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 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 Created attachment 137626 [details]
Upgrade logs.
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. 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 requested by Jams Antill 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. |