Hello Testers and rawhide Users,
Fedora 17 will locate the entire base operating system in /usr. The directories /bin, /sbin, /lib, /lib64 will only be symlinks: /bin → /usr/bin /sbin → /usr/sbin /lib → /usr/lib /lib64 → /usr/lib64
Some reasoning behind this change is outlined here: http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge
The official Fedora 17 feature page is here: https://fedoraproject.org/wiki/Features/UsrMove
The needed changes to implement the unified filesystem are about to land in rawhide soon. New installations of rawhide/Fedora 17 will install the symlinks right away, and no special care needs to be taken
Currently installed systems need some manual steps to convert the current system to match the layout of rawhide/Fedora 17. After that, the system can continue to be updated with YUM as usual.
Some RPM packages in rawhide/Fedora 17 will carry a RPM dependency guard, which will make sure, they can only be installed when /bin, /sbin, /lib, /lib64 are symlinks and not directories like in Fedora 16 and older.
The installed system’s base filesystem layout can not be safely altered, while the system itself is running on top of it. Dracut, the initramfs used to find and mount the root filesystem, can be instructed to convert the filesystem to match rawhide/Fedora 17’s expectations.
A screenshot of a successful conversion process is here: http://people.freedesktop.org/~kay/usrmove-convert-log.png
The packages, which are about to land in rawhide, are at this moment available via the ‘f17-usrmove’ koji tag. They are ready for testing now. Any tests, preferably in virtual machines or snapshots, where failures are acceptable, are more than welcome, and any feedback is greatly appreciated.
Keep in mind, that this still needs wider testing and a possible bug in the conversion logic might break an installed system. Please be careful with your data, do not try this on a production system, and always have a backup of your data.
If your system has a split-off /usr, a separate mount point, the dracut /usr mount conversion logic for /usr on NFS is not yet supported; we are working on it. /usr on iSCSI, FCoE, NBD although is supported, as long as “netroot=...” is specified on the kernel command line for these disks (see man dracut.kernel(7)).
Please report any issues regarding the /usr-move test (not general rawhide bugs) by replying to this email, by sending an email to the fedora-test list test@lists.fedoraproject.org, or by grabbing ‘haraldh’ or ‘kay’ on IRC #fedora-devel on freenode, or contact us by email directly.
The final guard in RPM is not yet enabled in the ‘f17-usrmove’ koji tag version of the packages. Make sure you never install any of the packages below this tag on an unconverted system, it will not be able to bootup. Before the packages hit rawhide, the guard will be enabled and safely prevent these packages to be installed on unconverted systems.
At the moment, we are still waiting for an updated RPM in the koji buildsystem, which provides the runtime check for the filesystem guard. After this is resolved by Fedora Release Engineering, we can go ahead and enable the needed guard and move the packages from the ‘f17-usrmove’ koji tag to ‘rawhide’: https://fedorahosted.org/rel-eng/ticket/5034
This is the screen log of a full conversion and update process: http://people.freedesktop.org/~kay/usrmove-convert-log.txt
Here are the steps to prepare your system, to convert it, and to be able to continue updating your installed system with YUM:
Download and install the most recent dracut package from rawhide: # yum --enablerepo=rawhide update dracut
Update the installed initramfs image for your current kernel, and instruct dracut to include the dracut module to convert your current filesystem: # dracut --force --add usrmove
If dracut detects ‘rd.usrmove’ on the kernel command line at bootup, it starts the filesystem conversion of the root filesystem.
Change the following kernel commandline parameter directly in the bootloader menu, which is shown during bootup, or edit the line in /etc/grub*.cfg. - remove “ro” - append “rw” to let dracut mount your root filesystem writeable - remove “rhgb” to hide the graphical bootsplash - append “rd.info” to get a more verbose output from dracut - append “rd.usrmove” to enable the /usr-move conversion script in dracut - append “selinux=0” for now, because the relabeling in a converted F16 system does not seem to work properly at this moment
During bootup, dracut will now convert your filesystem, and /lib, /lib64, /bin and /sbin should then all be symbolic links to the corresponding directories in /usr.
After the conversion, the system needs to be immediately updated to rawhide. No packages from F16 or F15, or older rawhide packages must be installed anymore. Make sure to disable any F15 and F16 repositories in yum!
Any files with conflicting names, which the conversion could not resolve, will be backed up to files named *.usrmove~ residing in /usr/lib, /usr/lib64, /usr/bin and /usr/sbin.
The log messages, which dracut has generated during bootup, can be retrieved with: # dmesg | grep dracut
After a successful conversion, revert the changes made to the kernel command line in the bootloader config file /etc/grub*.cfg.
SELinux relabelling should take effect after you rebooted your updated system and can take a long time (at least in a VM it takes insanely long and is still not finished). We are currently investigating, what seem to take so long, so you might consider to test with SELinux disabled for now.
Until the rawhide repository gets all the converted rpms, use the f17-usrmove repository to update the system after the filesystem conversion and disable rawhide in the file /etc/yum.repos.d/fedora-rawhide.repo
Add f17-usrmove in the file /etc/yum.repos.d/f17-usrmove.repo [f17-usrmove] name=Fedora $releasever - $basearch failovermethod=priority baseurl=http://koji.fedoraproject.org/repos/f17-usrmove/latest/$basearch enabled=1 metadata_expire=1d gpgcheck=0
# yum clean all # yum upgrade
After upgrading, all should be set and done.
Have fun with your system and say “Good bye” to /bin, /sbin, /lib, /lib64 and meet them in /usr.
:-)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/27/2012 08:10 AM, Harald Hoyer wrote:
Hello Testers and rawhide Users,
Fedora 17 will locate the entire base operating system in /usr. The directories /bin, /sbin, /lib, /lib64 will only be symlinks: /bin → /usr/bin /sbin → /usr/sbin /lib → /usr/lib /lib64 → /usr/lib64
Some reasoning behind this change is outlined here: http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge
The official Fedora 17 feature page is here: https://fedoraproject.org/wiki/Features/UsrMove
The needed changes to implement the unified filesystem are about to land in rawhide soon. New installations of rawhide/Fedora 17 will install the symlinks right away, and no special care needs to be taken
Currently installed systems need some manual steps to convert the current system to match the layout of rawhide/Fedora 17. After that, the system can continue to be updated with YUM as usual.
Some RPM packages in rawhide/Fedora 17 will carry a RPM dependency guard, which will make sure, they can only be installed when /bin, /sbin, /lib, /lib64 are symlinks and not directories like in Fedora 16 and older.
The installed system’s base filesystem layout can not be safely altered, while the system itself is running on top of it. Dracut, the initramfs used to find and mount the root filesystem, can be instructed to convert the filesystem to match rawhide/Fedora 17’s expectations.
A screenshot of a successful conversion process is here: http://people.freedesktop.org/~kay/usrmove-convert-log.png
The packages, which are about to land in rawhide, are at this moment available via the ‘f17-usrmove’ koji tag. They are ready for testing now. Any tests, preferably in virtual machines or snapshots, where failures are acceptable, are more than welcome, and any feedback is greatly appreciated.
Keep in mind, that this still needs wider testing and a possible bug in the conversion logic might break an installed system. Please be careful with your data, do not try this on a production system, and always have a backup of your data.
If your system has a split-off /usr, a separate mount point, the dracut /usr mount conversion logic for /usr on NFS is not yet supported; we are working on it. /usr on iSCSI, FCoE, NBD although is supported, as long as “netroot=...” is specified on the kernel command line for these disks (see man dracut.kernel(7)).
Please report any issues regarding the /usr-move test (not general rawhide bugs) by replying to this email, by sending an email to the fedora-test list test@lists.fedoraproject.org, or by grabbing ‘haraldh’ or ‘kay’ on IRC #fedora-devel on freenode, or contact us by email directly.
The final guard in RPM is not yet enabled in the ‘f17-usrmove’ koji tag version of the packages. Make sure you never install any of the packages below this tag on an unconverted system, it will not be able to bootup. Before the packages hit rawhide, the guard will be enabled and safely prevent these packages to be installed on unconverted systems.
At the moment, we are still waiting for an updated RPM in the koji buildsystem, which provides the runtime check for the filesystem guard. After this is resolved by Fedora Release Engineering, we can go ahead and enable the needed guard and move the packages from the ‘f17-usrmove’ koji tag to ‘rawhide’: https://fedorahosted.org/rel-eng/ticket/5034
This is the screen log of a full conversion and update process: http://people.freedesktop.org/~kay/usrmove-convert-log.txt
Here are the steps to prepare your system, to convert it, and to be able to continue updating your installed system with YUM:
Download and install the most recent dracut package from rawhide: # yum --enablerepo=rawhide update dracut
Update the installed initramfs image for your current kernel, and instruct dracut to include the dracut module to convert your current filesystem: # dracut --force --add usrmove
If dracut detects ‘rd.usrmove’ on the kernel command line at bootup, it starts the filesystem conversion of the root filesystem.
Change the following kernel commandline parameter directly in the bootloader menu, which is shown during bootup, or edit the line in /etc/grub*.cfg. - remove “ro” - append “rw” to let dracut mount your root filesystem writeable - remove “rhgb” to hide the graphical bootsplash - append “rd.info” to get a more verbose output from dracut - append “rd.usrmove” to enable the /usr-move conversion script in dracut - append “selinux=0” for now, because the relabeling in a converted F16 system does not seem to work properly at this moment
During bootup, dracut will now convert your filesystem, and /lib, /lib64, /bin and /sbin should then all be symbolic links to the corresponding directories in /usr.
After the conversion, the system needs to be immediately updated to rawhide. No packages from F16 or F15, or older rawhide packages must be installed anymore. Make sure to disable any F15 and F16 repositories in yum!
Any files with conflicting names, which the conversion could not resolve, will be backed up to files named *.usrmove~ residing in /usr/lib, /usr/lib64, /usr/bin and /usr/sbin.
The log messages, which dracut has generated during bootup, can be retrieved with: # dmesg | grep dracut
After a successful conversion, revert the changes made to the kernel command line in the bootloader config file /etc/grub*.cfg.
SELinux relabelling should take effect after you rebooted your updated system and can take a long time (at least in a VM it takes insanely long and is still not finished). We are currently investigating, what seem to take so long, so you might consider to test with SELinux disabled for now.
Until the rawhide repository gets all the converted rpms, use the f17-usrmove repository to update the system after the filesystem conversion and disable rawhide in the file /etc/yum.repos.d/fedora-rawhide.repo
Add f17-usrmove in the file /etc/yum.repos.d/f17-usrmove.repo [f17-usrmove] name=Fedora $releasever - $basearch failovermethod=priority baseurl=http://koji.fedoraproject.org/repos/f17-usrmove/latest/$basearch
enabled=1
metadata_expire=1d gpgcheck=0
# yum clean all # yum upgrade
After upgrading, all should be set and done.
Have fun with your system and say “Good bye” to /bin, /sbin, /lib, /lib64 and meet them in /usr.
:-)
WHy not do this with enforcing=0 rather then selinux=0, then the relabel should not be required.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/27/2012 04:08 PM, Daniel J Walsh wrote:
On 01/27/2012 08:10 AM, Harald Hoyer wrote:
The packages, which are about to land in rawhide, are at this moment available via the ‘f17-usrmove’ koji tag. They are ready for testing now. Any tests, preferably in virtual machines or snapshots, where failures are acceptable, are more than welcome, and any feedback is greatly appreciated.
...
SELinux relabelling should take effect after you rebooted your updated system and can take a long time (at least in a VM it takes insanely long and is still not finished). We are currently investigating, what seem to take so long, so you might consider to test with SELinux disabled for now.
WHy not do this with enforcing=0 rather then selinux=0, then the relabel should not be required.
I can report that on my laptop (Sony Vaio SA3), starting from a clean Fedora 16 x86_64 install and pulling kernel, kernel-devel and gcc from updates-testing (I have to compile acpi_call to turn off my new "fusion" AMD card), the upgrade went without a hitch.
Answering Dan's SELinux suggestion -- I tried doing the migration with enforcing=0 -- at the next boot it still tries to relabel the filesystem (I aborted once and booted with selinux=0 to verify everything is working, and am now doing the relabeling).
Does the usrmove script have to be modified, perhaps?
- -- Michel Alexandre Salim
() ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/29/2012 05:33 PM, Michel Alexandre Salim wrote:
On 01/27/2012 04:08 PM, Daniel J Walsh wrote:
On 01/27/2012 08:10 AM, Harald Hoyer wrote:
The packages, which are about to land in rawhide, are at this moment available via the ‘f17-usrmove’ koji tag. They are ready for testing now. Any tests, preferably in virtual machines or snapshots, where failures are acceptable, are more than welcome, and any feedback is greatly appreciated.
..
SELinux relabelling should take effect after you rebooted your updated system and can take a long time (at least in a VM it takes insanely long and is still not finished). We are currently investigating, what seem to take so long, so you might consider to test with SELinux disabled for now.
WHy not do this with enforcing=0 rather then selinux=0, then the relabel should not be required.
I can report that on my laptop (Sony Vaio SA3), starting from a clean Fedora 16 x86_64 install and pulling kernel, kernel-devel and gcc from updates-testing (I have to compile acpi_call to turn off my new "fusion" AMD card), the upgrade went without a hitch.
Answering Dan's SELinux suggestion -- I tried doing the migration with enforcing=0 -- at the next boot it still tries to relabel the filesystem (I aborted once and booted with selinux=0 to verify everything is working, and am now doing the relabeling).
Does the usrmove script have to be modified, perhaps?
Yes grep autorelabel /usr/lib/dracut/modules.d/30usrmove/* /usr/lib/dracut/modules.d/30usrmove/usrmove-convert.sh:echo "Set autorelabel flag." /usr/lib/dracut/modules.d/30usrmove/usrmove-convert.sh:> "$ROOT/.autorelabel"
On Fri, 2012-01-27 at 14:10 +0100, Harald Hoyer wrote:
Hello Testers and rawhide Users,
Fedora 17 will locate the entire base operating system in /usr. The directories /bin, /sbin, /lib, /lib64 will only be symlinks: /bin → /usr/bin /sbin → /usr/sbin /lib → /usr/lib /lib64 → /usr/lib64
Some reasoning behind this change is outlined here: http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge
The official Fedora 17 feature page is here: https://fedoraproject.org/wiki/Features/UsrMove
The needed changes to implement the unified filesystem are about to land in rawhide soon. New installations of rawhide/Fedora 17 will install the symlinks right away, and no special care needs to be taken
Thanks for your work, Harald.
So, as I mentioned in another follow-up, we didn't really establish any 'ground rules' for when we're going to re-tag the builds into Rawhide. Aside from the questions other groups may have, from the QA side, I'd suggest we want at least:
* two or three successful tests of the yum process with an existing Rawhide install
* a successful test of a fresh install with the /usr move packages (assuming we're in a state where we can even do a fresh install *without* the /usr move stuff: we will know more on that front shortly)
and ideally:
* a successful test of a media-based upgrade from F16
before we go ahead and PULL SOME LEVERS.
I have the /usr move feature on the agenda for the QA meeting on Monday morning, so we'll plan the testing out in more detail then. I guess we'll look at building a special install image for testing, if that's necessary. If you and/or kay could be at the meeting - 1600 UTC on Monday - that'd be a big help. Thanks!
On 28/01/12 02:22, Adam Williamson wrote:
suggest we want at least:
- two or three successful tests of the yum process with an existing
Rawhide install
I have updated an Rawhide to /usr no problems.
- a successful test of a fresh install with the /usr move packages
(assuming we're in a state where we can even do a fresh install *without* the /usr move stuff: we will know more on that front shortly)
I have upgraded a clean install fully updated default F16.Xfce_32 kvm_gust // installed and updated today, from Xfce LiveCD.
dracuted the F16 initramfs did the grub2.cfg rebooted the move was on. yum update from init 3 only problems an Xfce conflict, and libselinux dep.
On Sat, Jan 28, 2012 at 11:31 AM, Frank Murphy frankly3d@gmail.com wrote:
On 28/01/12 02:22, Adam Williamson wrote:
suggest we want at least:
- two or three successful tests of the yum process with an existing
Rawhide install
I have updated an Rawhide to /usr no problems.
+1
On Sat, 2012-01-28 at 16:31 +0000, Frank Murphy wrote:
On 28/01/12 02:22, Adam Williamson wrote:
suggest we want at least:
- two or three successful tests of the yum process with an existing
Rawhide install
I have updated an Rawhide to /usr no problems.
- a successful test of a fresh install with the /usr move packages
(assuming we're in a state where we can even do a fresh install *without* the /usr move stuff: we will know more on that front shortly)
I have upgraded a clean install fully updated default F16.Xfce_32 kvm_gust // installed and updated today, from Xfce LiveCD.
dracuted the F16 initramfs did the grub2.cfg rebooted the move was on. yum update from init 3 only problems an Xfce conflict, and libselinux dep.
Thanks for the report, Frank, that's very helpful! Anyone else have experience with the change yet?
On Fri, Jan 27, 2012 at 10:10 PM, Harald Hoyer harald@redhat.com wrote:
Hello Testers and rawhide Users,
Fedora 17 will locate the entire base operating system in /usr. [...]
You guys really are going to do this?
If it were I, instead of combining, I'd be working through the list of what is where and starting to move things out of /bin, et. al., that don't belong there, and starting to split /usr even further.
I guess this is what you get when you start using ACLs.
-- Joel Rees
On 01/27/2012 06:10 AM, Harald Hoyer wrote:
Until the rawhide repository gets all the converted rpms, use the f17-usrmove repository to update the system after the filesystem conversion and disable rawhide in the file /etc/yum.repos.d/fedora-rawhide.repo
Add f17-usrmove in the file /etc/yum.repos.d/f17-usrmove.repo [f17-usrmove] name=Fedora $releasever - $basearch failovermethod=priority baseurl=http://koji.fedoraproject.org/repos/f17-usrmove/latest/$basearch enabled=1 metadata_expire=1d gpgcheck=0
# yum clean all # yum upgrade
Looks like a no-go with multilib:
Error: Protected multilib versions: libacl-2.2.51-5.fc17.x86_64 != libacl-2.2.51-3.fc17.i686 Error: Protected multilib versions: db4-4.8.30-7.fc17.x86_64 != db4-4.8.30-5.fc17.i686 Error: Protected multilib versions: nspr-4.9-0.2.fc17.beta3.1.x86_64 != nspr-4.9-0.2.fc17.beta3.i686 Error: Protected multilib versions: krb5-libs-1.10-1.fc17.x86_64 != krb5-libs-1.10-0.fc17.beta1.2.i686 Error: Protected multilib versions: libuuid-2.20.1-5.fc17.x86_64 != libuuid-2.20.1-4.fc17.i686 Error: Protected multilib versions: nss-softokn-3.13.1-19.fc17.x86_64 != nss-softokn-3.13.1-17.fc17.i686 Error: Protected multilib versions: libattr-2.4.46-5.fc17.x86_64 != libattr-2.4.46-3.fc17.i686 Error: Protected multilib versions: libselinux-2.1.9-6.fc17.x86_64 != libselinux-2.1.9-3.fc17.i686 Error: Protected multilib versions: nss-softokn-freebl-3.13.1-19.fc17.x86_64 != nss-softokn-freebl-3.13.1-17.fc17.i686 Error: Protected multilib versions: libdb-5.2.36-4.fc17.x86_64 != libdb-5.2.36-2.fc17.i686
I suppose I could add in the i386 repo...
On Mon, Jan 30, 2012 at 10:17 AM, Orion Poplawski orion@cora.nwra.com wrote:
I suppose I could add in the i386 repo...
Is this just a side effect of the special repository structure? For rawhide itself, once tagged in, would the 32bit packages be available on the 64bit system without additional intervention? Or is there a defect in the specfiles?
-jef
Jef Spaleta (jspaleta@gmail.com) said:
On Mon, Jan 30, 2012 at 10:17 AM, Orion Poplawski orion@cora.nwra.com wrote:
I suppose I could add in the i386 repo...
Is this just a side effect of the special repository structure? For rawhide itself, once tagged in, would the 32bit packages be available on the 64bit system without additional intervention? Or is there a defect in the specfiles?
It's a side-effect of the special repo structure - koji repos aren't multilib.
Bill
On 01/30/2012 12:17 PM, Orion Poplawski wrote:
On 01/27/2012 06:10 AM, Harald Hoyer wrote:
Until the rawhide repository gets all the converted rpms, use the f17-usrmove repository to update the system after the filesystem conversion and disable rawhide in the file /etc/yum.repos.d/fedora-rawhide.repo
Add f17-usrmove in the file /etc/yum.repos.d/f17-usrmove.repo [f17-usrmove] name=Fedora $releasever - $basearch failovermethod=priority baseurl=http://koji.fedoraproject.org/repos/f17-usrmove/latest/$basearch enabled=1 metadata_expire=1d gpgcheck=0
# yum clean all # yum upgrade
Looks like a no-go with multilib:
Error: Protected multilib versions: libacl-2.2.51-5.fc17.x86_64 != libacl-2.2.51-3.fc17.i686 Error: Protected multilib versions: db4-4.8.30-7.fc17.x86_64 != db4-4.8.30-5.fc17.i686 Error: Protected multilib versions: nspr-4.9-0.2.fc17.beta3.1.x86_64 != nspr-4.9-0.2.fc17.beta3.i686 Error: Protected multilib versions: krb5-libs-1.10-1.fc17.x86_64 != krb5-libs-1.10-0.fc17.beta1.2.i686 Error: Protected multilib versions: libuuid-2.20.1-5.fc17.x86_64 != libuuid-2.20.1-4.fc17.i686 Error: Protected multilib versions: nss-softokn-3.13.1-19.fc17.x86_64 != nss-softokn-3.13.1-17.fc17.i686 Error: Protected multilib versions: libattr-2.4.46-5.fc17.x86_64 != libattr-2.4.46-3.fc17.i686 Error: Protected multilib versions: libselinux-2.1.9-6.fc17.x86_64 != libselinux-2.1.9-3.fc17.i686 Error: Protected multilib versions: nss-softokn-freebl-3.13.1-19.fc17.x86_64 != nss-softokn-freebl-3.13.1-17.fc17.i686 Error: Protected multilib versions: libdb-5.2.36-4.fc17.x86_64 != libdb-5.2.36-2.fc17.i686
I suppose I could add in the i386 repo...
I added:
[f17-usrmove-i386] name=Fedora $releasever - $basearch failovermethod=priority baseurl=http://koji.fedoraproject.org/repos/f17-usrmove/latest/i386 enabled=1 metadata_expire=1d gpgcheck=0
And got the following errors:
Updating : coreutils-8.15-5.fc17.x86_64 7/223 /var/tmp/rpm-tmp.T9mWTk: line 1: /usr/bin/grep: No such file or directory
Updating : filesystem-3-1.fc17.x86_64 23/223 Error unpacking rpm package filesystem-3-1.fc17.x86_64 error: unpacking of archive failed on file /bin: cpio: rename error: filesystem-3-1.fc17.x86_64: install failed
error: filesystem-2.4.46-1.fc17.x86_64: erase skipped
Non-fatal POSTTRANS scriptlet failure in rpm package kdesdk-okteta-4.8.0-1.fc17.x86_64 Non-fatal POSTTRANS scriptlet failure in rpm package kdesdk-kompare-4.8.0-1.fc17.x86_64 Non-fatal POSTTRANS scriptlet failure in rpm package kdesdk-kioslave-4.8.0-1.fc17.x86_64 Non-fatal POSTTRANS scriptlet failure in rpm package kdesdk-cervisia-4.8.0-1.fc17.x86_64 Non-fatal POSTTRANS scriptlet failure in rpm package kdesdk-kcachegrind-4.8.0-1.fc17.x86_64 Non-fatal POSTTRANS scriptlet failure in rpm package kdesdk-umbrello-4.8.0-1.fc17.x86_64 Non-fatal POSTTRANS scriptlet failure in rpm package kdesdk-kapptemplate-4.8.0-1.fc17.x86_64 Non-fatal POSTTRANS scriptlet failure in rpm package kdesdk-kuiviewer-4.8.0-1.fc17.x86_64
filesystem-2.4.46-1.fc17.x86_64 was supposed to be removed but is not!
Now I get:
# ls -l / -bash: /bin/ls: No such file or directory
Shutdown did not complete. Boot now fails with:
dracut: Switching root switch_root: failed to execute /etc/init: Permission denied Kernel panic - not syncing: Attempted to kill init!
even with enforcing=0
Anyone want any postmortem info before I reinstall the VM?
you forgot to convert with dracut before yum upgrade... right?? Am 30.01.2012 22:11 schrieb "Orion Poplawski" orion@cora.nwra.com:
On 01/30/2012 12:17 PM, Orion Poplawski wrote:
On 01/27/2012 06:10 AM, Harald Hoyer wrote:
Until the rawhide repository gets all the converted rpms, use the f17-usrmove repository to update the system after the filesystem conversion and disable rawhide in the file /etc/yum.repos.d/fedora-**rawhide.repo
Add f17-usrmove in the file /etc/yum.repos.d/f17-usrmove.**repo [f17-usrmove] name=Fedora $releasever - $basearch failovermethod=priority baseurl=http://koji.**fedoraproject.org/repos/f17-** usrmove/latest/$basearchhttp://koji.fedoraproject.org/repos/f17-usrmove/latest/$basearch enabled=1 metadata_expire=1d gpgcheck=0
# yum clean all # yum upgrade
Looks like a no-go with multilib:
Error: Protected multilib versions: libacl-2.2.51-5.fc17.x86_64 != libacl-2.2.51-3.fc17.i686 Error: Protected multilib versions: db4-4.8.30-7.fc17.x86_64 != db4-4.8.30-5.fc17.i686 Error: Protected multilib versions: nspr-4.9-0.2.fc17.beta3.1.x86_**64 != nspr-4.9-0.2.fc17.beta3.i686 Error: Protected multilib versions: krb5-libs-1.10-1.fc17.x86_64 != krb5-libs-1.10-0.fc17.beta1.2.**i686 Error: Protected multilib versions: libuuid-2.20.1-5.fc17.x86_64 != libuuid-2.20.1-4.fc17.i686 Error: Protected multilib versions: nss-softokn-3.13.1-19.fc17.**x86_64 != nss-softokn-3.13.1-17.fc17.**i686 Error: Protected multilib versions: libattr-2.4.46-5.fc17.x86_64 != libattr-2.4.46-3.fc17.i686 Error: Protected multilib versions: libselinux-2.1.9-6.fc17.x86_64 != libselinux-2.1.9-3.fc17.i686 Error: Protected multilib versions: nss-softokn-freebl-3.13.1-19.** fc17.x86_64 != nss-softokn-freebl-3.13.1-17.**fc17.i686 Error: Protected multilib versions: libdb-5.2.36-4.fc17.x86_64 != libdb-5.2.36-2.fc17.i686
I suppose I could add in the i386 repo...
I added:
[f17-usrmove-i386] name=Fedora $releasever - $basearch failovermethod=priority baseurl=http://koji.**fedoraproject.org/repos/f17-**usrmove/latest/i386http://koji.fedoraproject.org/repos/f17-usrmove/latest/i386 enabled=1 metadata_expire=1d gpgcheck=0
And got the following errors:
Updating : coreutils-8.15-5.fc17.x86_64 7/223 /var/tmp/rpm-tmp.T9mWTk: line 1: /usr/bin/grep: No such file or directory
Updating : filesystem-3-1.fc17.x86_64 23/223 Error unpacking rpm package filesystem-3-1.fc17.x86_64 error: unpacking of archive failed on file /bin: cpio: rename error: filesystem-3-1.fc17.x86_64: install failed
error: filesystem-2.4.46-1.fc17.x86_**64: erase skipped
Non-fatal POSTTRANS scriptlet failure in rpm package kdesdk-okteta-4.8.0-1.fc17.**x86_64 Non-fatal POSTTRANS scriptlet failure in rpm package kdesdk-kompare-4.8.0-1.fc17.**x86_64 Non-fatal POSTTRANS scriptlet failure in rpm package kdesdk-kioslave-4.8.0-1.fc17.**x86_64 Non-fatal POSTTRANS scriptlet failure in rpm package kdesdk-cervisia-4.8.0-1.fc17.**x86_64 Non-fatal POSTTRANS scriptlet failure in rpm package kdesdk-kcachegrind-4.8.0-1.**fc17.x86_64 Non-fatal POSTTRANS scriptlet failure in rpm package kdesdk-umbrello-4.8.0-1.fc17.**x86_64 Non-fatal POSTTRANS scriptlet failure in rpm package kdesdk-kapptemplate-4.8.0-1.**fc17.x86_64 Non-fatal POSTTRANS scriptlet failure in rpm package kdesdk-kuiviewer-4.8.0-1.fc17.**x86_64
filesystem-2.4.46-1.fc17.x86_**64 was supposed to be removed but is not!
Now I get:
# ls -l / -bash: /bin/ls: No such file or directory
Shutdown did not complete. Boot now fails with:
dracut: Switching root switch_root: failed to execute /etc/init: Permission denied Kernel panic - not syncing: Attempted to kill init!
even with enforcing=0
Anyone want any postmortem info before I reinstall the VM?
-- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane orion@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.**org/mailman/listinfo/testhttps://admin.fedoraproject.org/mailman/listinfo/test
On 01/30/2012 10:38 PM, Harald Hoyer wrote:
you forgot to convert with dracut before yum upgrade... right??
Yes, my bad.
On Fri, 2012-01-27 at 14:10 +0100, Harald Hoyer wrote:
Hello Testers and rawhide Users,
Fedora 17 will locate the entire base operating system in /usr. The directories /bin, /sbin, /lib, /lib64 will only be symlinks: /bin → /usr/bin /sbin → /usr/sbin /lib → /usr/lib /lib64 → /usr/lib64
I've just tested building a live image from the /usr move repository. It boots, and the /usr move changes appear to be implemented. I'm currently testing if it can be installed successfully.
One thing I already noticed is that there seems to be a problem with the ntfs-3g executables. /bin/ntfs-3g seems to be a symlink to itself - it shows as "/bin/ntfs-3g -> /bin/ntfs-3g" in ls output. Trying to do 'ls -l /usr/bin/ntfs-3g' results in 'cannot access /usr/bin/ntfs-3g: Too many levels of symbolic links'. /bin/ntfsmount is similarly affected.
On a pre-/usr move system it seems that these executables are actually located in /bin but have symlinks in /usr/bin - /usr/bin/ntfs-3g is a symlink to /bin/ntfs-3g . Perhaps the existence of these symlinks in /usr/bin confused things?
On Tue, 2012-01-31 at 14:23 -0800, Adam Williamson wrote:
On Fri, 2012-01-27 at 14:10 +0100, Harald Hoyer wrote:
Hello Testers and rawhide Users,
Fedora 17 will locate the entire base operating system in /usr. The directories /bin, /sbin, /lib, /lib64 will only be symlinks: /bin → /usr/bin /sbin → /usr/sbin /lib → /usr/lib /lib64 → /usr/lib64
I've just tested building a live image from the /usr move repository. It boots, and the /usr move changes appear to be implemented. I'm currently testing if it can be installed successfully.
One thing I already noticed is that there seems to be a problem with the ntfs-3g executables. /bin/ntfs-3g seems to be a symlink to itself - it shows as "/bin/ntfs-3g -> /bin/ntfs-3g" in ls output. Trying to do 'ls -l /usr/bin/ntfs-3g' results in 'cannot access /usr/bin/ntfs-3g: Too many levels of symbolic links'. /bin/ntfsmount is similarly affected.
On a pre-/usr move system it seems that these executables are actually located in /bin but have symlinks in /usr/bin - /usr/bin/ntfs-3g is a symlink to /bin/ntfs-3g . Perhaps the existence of these symlinks in /usr/bin confused things?
Installation fails at partitioning stage, with udisksd hitting "Error opening /etc/crypttab file: Failed to open file '/etc/crypttab': No such file or directory (g-file-error-quark, 4)"
The file /etc/crypttab indeed doesn't exist. I'm not sure if this is actually specific to the /usr move stuff, but it does prevent me being able to ensure that installation works from a /usr-moved live image. I have a non-usr-move image also, I'll test install with that.
On Tue, Jan 31, 2012 at 5:23 PM, Adam Williamson awilliam@redhat.com wrote:
On Fri, 2012-01-27 at 14:10 +0100, Harald Hoyer wrote:
Fedora 17 will locate the entire base operating system in /usr. The directories /bin, /sbin, /lib, /lib64 will only be symlinks: /bin → /usr/bin /sbin → /usr/sbin /lib → /usr/lib /lib64 → /usr/lib64
Regarding bug 786261.
Frank Murphy's found that creating a "/etc/ld.so.conf.d/usrmove.conf" containing "/usr/lib" (as well as "/usr/lib64" for amd64) before running ldconfig allows dracut to create a bootable initramfs after the /usr move. Would doing so before running ldconfig in "usrmove-convert.sh" be enough of a fix?
On Wed, 2012-02-01 at 18:04 -0500, Tom H wrote:
On Tue, Jan 31, 2012 at 5:23 PM, Adam Williamson awilliam@redhat.com wrote:
On Fri, 2012-01-27 at 14:10 +0100, Harald Hoyer wrote:
Fedora 17 will locate the entire base operating system in /usr. The directories /bin, /sbin, /lib, /lib64 will only be symlinks: /bin → /usr/bin /sbin → /usr/sbin /lib → /usr/lib /lib64 → /usr/lib64
Regarding bug 786261.
Frank Murphy's found that creating a "/etc/ld.so.conf.d/usrmove.conf" containing "/usr/lib" (as well as "/usr/lib64" for amd64) before running ldconfig allows dracut to create a bootable initramfs after the /usr move. Would doing so before running ldconfig in "usrmove-convert.sh" be enough of a fix?
That seems strange. /usr/lib and /usr/lib64 should be in the linker path already anyway...
On Wed, Feb 1, 2012 at 6:32 PM, Adam Williamson awilliam@redhat.com wrote:
On Wed, 2012-02-01 at 18:04 -0500, Tom H wrote:
On Tue, Jan 31, 2012 at 5:23 PM, Adam Williamson awilliam@redhat.com wrote:
On Fri, 2012-01-27 at 14:10 +0100, Harald Hoyer wrote:
Fedora 17 will locate the entire base operating system in /usr. The directories /bin, /sbin, /lib, /lib64 will only be symlinks: /bin → /usr/bin /sbin → /usr/sbin /lib → /usr/lib /lib64 → /usr/lib64
Regarding bug 786261.
Frank Murphy's found that creating a "/etc/ld.so.conf.d/usrmove.conf" containing "/usr/lib" (as well as "/usr/lib64" for amd64) before running ldconfig allows dracut to create a bootable initramfs after the /usr move. Would doing so before running ldconfig in "usrmove-convert.sh" be enough of a fix?
That seems strange. /usr/lib and /usr/lib64 should be in the linker path already anyway...
I would've thought so too. (Is there something special about libc in respect of its linker path?)
[root@localhost ~]# mv /etc/ld.so.conf.d/usrmove.conf . [root@localhost ~]# ldconfig [root@localhost ~]# ldconfig -p | grep 'libc.so' libc.so.6 (libc6, OS ABI: Linux 2.6.32) => /lib/libc.so.6 [root@localhost ~]# mv usrmove.conf /etc/ld.so.conf.d/ [root@localhost ~]# ldconfig [root@localhost ~]# ldconfig -p | grep 'libc.so' libc.so.6 (libc6, OS ABI: Linux 2.6.32) => /usr/lib/libc.so.6 [root@localhost ~]#
Also, Frank pointed out, either here or in the bug report, that the problem might come from "/lib/libc.so.6" being a double symlink.
[root@localhost ~]# ls -l /lib/libc.so.6 lrwxrwxrwx. 1 root root 12 Jan 29 20:08 /lib/libc.so.6 -> libc-2.15.so [root@localhost ~]# ls -l /usr/lib/libc.so.6 lrwxrwxrwx. 1 root root 12 Jan 29 20:08 /usr/lib/libc.so.6 -> libc-2.15.so [root@localhost ~]#
-
Adam Williamson -
Bill Nottingham -
Daniel J Walsh -
Frank Murphy -
Harald Hoyer -
Harald Hoyer -
Jef Spaleta -
Joel Rees -
Michel Alexandre Salim -
Orion Poplawski -
Tom H