Some groundwork is needed to 'prepare' the system for the /usr move feature - https://fedoraproject.org/wiki/Features/UsrMove - when upgrading to a Fedora which implements it, from one that doesn't (so, anything pre-F17, to anything F17 or later). The groundwork required is documented for yum-based upgrades here: https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_16_-.3E_Fedora_17 This should be implemented in anaconda so that anaconda-based (and preupgrade-based) upgrades can go through without manual intervention. CCing Harald and Kay in case anaconda team has implementation questions, suggestions for improvements to be made on the dracut side of the process etc. Proposing as a Beta blocker, as lack of this will torpedo any F16->F17 upgrade from working: Beta criterion "The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria".
preupgrade should be fairly easy since it reboots the system to do the install. It can build a new initramfs and pass rd.convertfs. In anaconda it is going to be more difficult since we first need to find the existing system to upgrade and mount it before we can operate on it. Harald, can the dracut scripts handling the upgrade be run directly by anaconda? That would be the best solution.
so... if the installer images add the "convertfs" module to the dracut of the installer, you can always call: /run/initramfs/usr/bin/convertfs <path_to_sysroot> from within anconda or whatever tool.
(In reply to comment #2) > so... if the installer images add the "convertfs" module to the dracut of the > installer, you can always call: > > /run/initramfs/usr/bin/convertfs <path_to_sysroot> > > from within anconda or whatever tool. of course the script needs some helper tools like: bash find mv ln rm ldconfig setfiles
in case /run/initramfs/usr/bin/convertfs is not available inside the anaconda installer, you will have to copy: /usr/lib/dracut/modules.d/30convertfs/convertfs.sh
Ok, we have an additional requirement. anaconda has to add the dracut parameters for the /usr (like for root=) device, if the _updated_ or newly installed system has a separate /usr. I am speaking of rd.lvm*=, rd.md*=, rd.dm*=, netroot=. For /usr on nfs, we need "rd.neednet=1" and the network configuration.
Is there any reason why the convertfs can't do that? I'd rather keep the amount of specific details that Anaconda needs to know to to a minimum. I'm also not sure of exactly what you mean -- examples would be helpful.
(In reply to comment #6) > Is there any reason why the convertfs can't do that? I'd rather keep the amount > of specific details that Anaconda needs to know to to a minimum. I'm also not > sure of exactly what you mean -- examples would be helpful. Well, anaconda needs to add these parameters anyway for new installations with a split /usr. So the logic has to be there anyway.
Discussed at 2011-03-02 blocker review meeting. Accepted as a blocker per criterion "The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria". Brian, I'm a bit worried there's been no clear reply to harald's 'additional request' (and I also find it slightly confusingly written). can you guys make sure it doesn't fall between any cracks? thanks! -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
In essence: every "rd.*" option anaconda adds to the kernel command line, to let dracut assemble some devices, which are needed pre-F17 for "/" and swap are needed for "/usr" now as well, if "/usr" is a separate mountpoint.
patch for this is on the list, tested with new install and with upgrade from F16.
anaconda-17.12-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/anaconda-17.12-1.fc17
Package anaconda-17.12-1.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing anaconda-17.12-1.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-3157/anaconda-17.12-1.fc17 then log in and leave karma (feedback).
We should verify this fix with TC2. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
As far as I can tell, it works OK with TC2.
I can confirm I have successfully upgraded F16->F17 i386 using F17 Beta TC2 DVD.
-- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
17.14 is stable, closing. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers