Bug 787893 - Anaconda needs to handle /usr move preparation on upgrade for F17
Summary: Anaconda needs to handle /usr move preparation on upgrade for F17
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: rawhide
Hardware: All
OS: All
unspecified
urgent
Target Milestone: ---
Assignee: Brian Lane
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
Depends On:
Blocks: F17Beta, F17BetaBlocker
TreeView+ depends on / blocked
 
Reported: 2012-02-07 01:30 UTC by Adam Williamson
Modified: 2012-03-24 16:07 UTC (History)
10 users (show)

Fixed In Version: anaconda-17.12-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-03-24 16:07:30 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Adam Williamson 2012-02-07 01:30:25 UTC
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".

Comment 1 Brian Lane 2012-02-07 17:54:21 UTC
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.

Comment 2 Harald Hoyer 2012-02-07 19:22:22 UTC
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.

Comment 3 Harald Hoyer 2012-02-07 20:06:05 UTC
(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

Comment 4 Harald Hoyer 2012-02-07 20:33:49 UTC
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

Comment 5 Harald Hoyer 2012-02-24 16:00:00 UTC
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.

Comment 6 Brian Lane 2012-02-24 17:06:06 UTC
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.

Comment 7 Harald Hoyer 2012-02-25 11:09:49 UTC
(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.

Comment 8 Adam Williamson 2012-03-02 17:19:02 UTC
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

Comment 9 Harald Hoyer 2012-03-05 12:25:47 UTC
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.

Comment 10 Brian Lane 2012-03-06 01:17:46 UTC
patch for this is on the list, tested with new install and with upgrade from F16.

Comment 11 Fedora Update System 2012-03-06 15:00:34 UTC
anaconda-17.12-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/anaconda-17.12-1.fc17

Comment 12 Fedora Update System 2012-03-07 07:21:00 UTC
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).

Comment 13 Adam Williamson 2012-03-19 23:46:21 UTC
We should verify this fix with TC2.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 14 Josef Skladanka 2012-03-20 12:04:24 UTC
As far as I can tell, it works OK with TC2.

Comment 15 Kamil Páral 2012-03-20 15:03:33 UTC
I can confirm I have successfully upgraded F16->F17 i386 using F17 Beta TC2 DVD.

Comment 16 Adam Williamson 2012-03-20 19:08:27 UTC

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 17 Adam Williamson 2012-03-24 16:07:30 UTC
17.14 is stable, closing.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers


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