Bug 834746
| Summary: | F17 update causes separate /usr partition to be mounted read-only | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | bob mckay <urilabob> | ||||||||||||||||||||||||||
| Component: | anaconda | Assignee: | Anaconda Maintenance Team <anaconda-maint-list> | ||||||||||||||||||||||||||
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||||||||||||||||||
| Severity: | unspecified | Docs Contact: | |||||||||||||||||||||||||||
| Priority: | unspecified | ||||||||||||||||||||||||||||
| Version: | 17 | CC: | anaconda-maint-list, andrew, g.kaviyarasu, jonathan, mads, vanmeeuwen+fedora | ||||||||||||||||||||||||||
| Target Milestone: | --- | ||||||||||||||||||||||||||||
| Target Release: | --- | ||||||||||||||||||||||||||||
| Hardware: | Unspecified | ||||||||||||||||||||||||||||
| OS: | Unspecified | ||||||||||||||||||||||||||||
| Whiteboard: | |||||||||||||||||||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||||||||||||||||||
| Doc Text: | Story Points: | --- | |||||||||||||||||||||||||||
| Clone Of: | Environment: | ||||||||||||||||||||||||||||
| Last Closed: | 2013-05-07 23:39:56 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: | |||||||||||||||||||||||||||
| Embargoed: | |||||||||||||||||||||||||||||
| Attachments: |
|
||||||||||||||||||||||||||||
|
Description
bob mckay
2012-06-23 06:15:12 UTC
Please attach all the anaconda log files. Created attachment 596205 [details]
Original anaconda ks file
Original anaconda kickstart file. From the date, this was probably originally an F15 install, which would have been upgraded, probably by preupgrade, to F16, and then upgraded again to F17, this time via DVD because I had previously been bitten by preupgrade bugs with F17. Unfortunately the F15->F16 logs appear to have been overwritten by the latest upgrade.
Created attachment 596206 [details]
F15 install log
Created attachment 596207 [details]
F15 install syslog
Created attachment 596208 [details]
F16->F17 upgrade log
Created attachment 596209 [details]
F16->F17 upgrade syslog
You don't have any anaconda logs - https://fedoraproject.org/wiki/Anaconda/Logging#Anaconda_logs_on_the_running_system ? dmesg from the first ro boot would perhaps also tell something. What changes do the yum distrosync do - and which of them will make it work? When and why do you get the yum kernel update error? Is it right? If not then it seems to be something that should be filed as a separate bug. Created attachment 596299 [details]
Anaconda F16->F17 ifcfg log
Created attachment 596300 [details]
Anaconda F16->F17 log
Created attachment 596301 [details]
Anaconda F16->F17 program log
Created attachment 596302 [details]
Anaconda F16->F17 storage log
Created attachment 596303 [details]
Anaconda F16->F17 syslog
Created attachment 596304 [details]
Anaconda F16->F17 xlog
Created attachment 596305 [details]
Anaconda F16->F17 yum log
(In reply to comment #7) > You don't have any anaconda logs - > https://fedoraproject.org/wiki/Anaconda/ > Logging#Anaconda_logs_on_the_running_system ? Sorry Mads, my misunderstanding, I have supplied these now. > > dmesg from the first ro boot would perhaps also tell something. I'm sorry, I don't think I'm going to be able to supply this. I didn't think to do it before I fixed the systems which failed. I only have three more systems to upgrade, and unfortunately they are mission critical (which is why I have left them to last). I will have to upgrade them by preupgrade (which seems to be more reliable) rather than a DVD upgrade. > > When and why do you get the yum kernel update error? Is it right? If not > then it seems to be something that should be filed as a separate bug. This specific error is what I was seeing when I first rebooted the system. Of course, the first thing I tried to do was a full yum update - which fails (with the misleading message about /usr space) because /usr is ro. If I'd done something else first, I may have seen a different consequence, but I thought it was worth showing because I think most people are likely to do a yum update soon after upgrading the system, so it's likely to be the first time they encounter problems resulting from the ro mount. I don't think it's a separate bug, it is a direct consequence of the ro mount of /usr, and goes away as soon as that is fixed. > > What changes do the yum distrosync do - and which of them will make it work? Even once /usr is mounted rw, yum update throws hundreds of errors about duplicate packages (seems a lot of f16 packages are not removed) and then aborts with errors about sane backends and cups libraries. Manually removing the sane and cups culprits gets the system to the stage where yum --skip-broken distro-sync works (yum --skip-broken update still fails, I think it is probably just bug 820351, but not sure). The distrosync does hundreds of updates; I'm sorry, I have no way to find out which one actually fixes the ro mount problem. Finally, I manually restore the removed sane backends and cups libraries. My memory about this is a little hazy because once I encountered so many scary problems with DVD upgrade, I decided to go back to using preupgrade - it also has problems, but they seem to be less serious. (In reply to comment #15) > > Even once /usr is mounted rw, yum update throws hundreds of errors about > duplicate packages (seems a lot of f16 packages are not removed) and then > aborts with errors about sane backends and cups libraries. Checking further, this looks to be bug 826621. That is, the ro mount of /usr is a new bug, but once /usr is remounted rw, bug 826621 manifests itself. I seem to have the same problem. I have /usr on separate LVM partition. /usr-move has completed successfully but DVD x86_64 FC16->17 upgrade failed, I think due to lack of space on /usr. Upgrade DVD now doesn't recognise existing FC16 installation (see https://bugzilla.redhat.com/show_bug.cgi?id=835307). A complicating factor is that /usr now mounts read-only, as far as I can see as a consequence of /usr-move. Tried editing fstab without effect. mount -o rw/remount /usr doesn't work either - I get mount: /dev/mapper/VolGroup00-LogVol02 already mounted or /usr busy mount: according to mtab, /dev/mapper/VolGroup00-LogVol02 is already mounted on /usr and still mounts ro at next reboot. It seems like updating from f16 with a separete /usr simply isn't very well supported. (Preupgrade might be convenient, but it is also a moving target and I consider it much more fragile than upgrading from a media.) My first step to diagnose the ro mount would be to try to boot from a live / rescue disk and verify that the /usr partition really can be mounted rw - and perhaps also run a fsck. The reason to why it is mounted ro is somewhere on your disk. F17 is long done and Anaconda no longer handles upgrades. |