Description of problem: When upgrading an F16 system with a separate /usr partition to F17, the /usr partition gets mounted readonly on first reboot, which breaks all sorts of things... Sorry, I don't really know whether this is a bug in anaconda or something else. I guess it may well be related to bug 804913 but I'm not sure. Version-Release number of selected component (if applicable): F17 upgrade tools (DVD and preupgrade routes for certain). How reproducible: Reliably (about 6 systems so far, both DVD and preupgrade upgrades). Steps to Reproduce: 1. Install F16 2. Upgrade to F17 (DVD or preupgrade) 3. Reboot Actual results: /usr is mounted ro Expected results: /usr is mounted rw Additional info: For anyone hitting this problem, the following sequence seems to fix the problem mount -o rw/remount /usr yum --skip-broken distro-sync (if your yum configuration is really broken you may need to remove some packages to get this to work - I have had to remove some sane and cups library packages, the ones that actually generate the failure messages, to get through this) reboot After the reboot, /usr seems to mount rw as expected. Symptoms: ############################################################################### %yum update kernel: Transaction Check Error: installing package kernel-3.4.3-1.fc17.x86_64 needs 98MB on the /usr filesystem Error Summary ------------- Disk Requirements: At least 98MB more space needed on the /usr filesystem. ############################################################################### df output: /dev/mapper/vg_sc2-lv_usr 20415616 8343620 11047996 44% /usr (i.e. /usr has over 8GB space available).
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.