7:10 a.m.
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(a)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.
:-)
7:33 a.m.
Hi,
thanks for the detailed instructions for testing. I am not sure
though, whether any of this is applicable on a system already running
rawhide?
Reading this, I surmise that I have to do the following steps once
these packages hit rawhide. Can you comment on the correctness?
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.
Download and install the most recent dracut package from rawhide:
# yum --enablerepo=rawhide update dracut
This will hit me soon automatically (as it is in rawhide proper, and I
update regularly).
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
These two steps are needed as well, however...
- append “selinux=0” for now, because the relabeling in a converted
F16 system does not seem to work properly at this moment
... do you know if this is applicable for a correctly labeled rawhide
as well?
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.
Sidenote: should we file these as bugs?
After a successful conversion, revert the changes made to the kernel
command line in the bootloader config file /etc/grub*.cfg.
This step is needed.
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.
Again, is this only for hosts based on F16?
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
When the tag hits rawhide proper, I assume this can be skipped?
Can I update dracut now, and wait for the rest of the tag to hit
rawhide before adding the rd.usrmove flag?
Regards,
--Stijn
7:37 a.m.
Am 27.01.2012 14:33, schrieb Stijn Hoop:
Hi,
thanks for the detailed instructions for testing. I am not sure
though, whether any of this is applicable on a system already running
rawhide?
Reading this, I surmise that I have to do the following steps once
these packages hit rawhide. Can you comment on the correctness?
> 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.
> Download and install the most recent dracut package from rawhide:
> # yum --enablerepo=rawhide update dracut
This will hit me soon automatically (as it is in rawhide proper, and I
update regularly).
yes
> 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
These two steps are needed as well, however...
> - append “selinux=0” for now, because the relabeling in a converted
> F16 system does not seem to work properly at this moment
... do you know if this is applicable for a correctly labeled rawhide
as well?
might be, please test :-)
> 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.
Sidenote: should we file these as bugs?
> After a successful conversion, revert the changes made to the kernel
> command line in the bootloader config file /etc/grub*.cfg.
This step is needed.
> 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.
Again, is this only for hosts based on F16?
might be. please test.
> 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
When the tag hits rawhide proper, I assume this can be skipped?
Yes, we will announce this, if we move the tag after the testing.
Can I update dracut now, and wait for the rest of the tag to hit
rawhide before adding the rd.usrmove flag?
sure
Regards,
--Stijn
7:35 a.m.
On 01/27/2012 02:10 PM, Harald Hoyer wrote:
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.
It takes so long because:
- it runs setfiles with "-l" to log the label changes.
- journald runs, syslog.socket is active, but syslog.service is not.
- journald blocks for some time on every attempt to write a line to
the syslog socket.
http://lists.fedoraproject.org/pipermail/devel/2012-January/161530.html
Michal
10:02 a.m.
Finally my VM relabeled everything after 8 hours. Seems to work fine with
selinux enabled.
Should have booted with "enforce=0" and removed the .autorelabel creation
from the conversion script.
Will test that version on Monday.
Am 27.01.2012 14:36 schrieb "Michal Schmidt" <mschmidt(a)redhat.com>:
On 01/27/2012 02:10 PM, Harald Hoyer wrote:
> 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.
>
It takes so long because:
- it runs setfiles with "-l" to log the label changes.
- journald runs, syslog.socket is active, but syslog.service is not.
- journald blocks for some time on every attempt to write a line to
the syslog socket.
http://lists.fedoraproject.**org/pipermail/devel/2012-**
January/161530.html<http://lists.fedoraproject.org/pipermail/devel/201...
Michal
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.**org/mailman/listinfo/devel<https://admin...
7:51 a.m.
On 27/01/12 13:10, Harald Hoyer wrote:
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
Is it only a one off this image?
The next update for kernel,
will know of /usr*
--
Regards,
Frank Murphy, friend of fedoraproject
UTF_8 Encoded
8:03 a.m.
On Fri, 2012-01-27 at 14:10 +0100, Harald Hoyer wrote:
- append “selinux=0” for now, because the relabeling in a converted
F16 system
does not seem to work properly at this moment
Have you checked "enforcing=0" instead? If this worked, you'd not need
to relabel the whole system, but only the parts affected by the move. Or
so I'd like to believe ;-).
Nils
--
Nils Philippsen "Those who would give up Essential Liberty to purchase
Red Hat a little Temporary Safety, deserve neither Liberty
nils(a)redhat.com nor Safety." -- Benjamin Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
8:12 a.m.
Am 27.01.2012 15:03, schrieb Nils Philippsen:
On Fri, 2012-01-27 at 14:10 +0100, Harald Hoyer wrote:
> - append “selinux=0” for now, because the relabeling in a converted F16 system
> does not seem to work properly at this moment
Have you checked "enforcing=0" instead? If this worked, you'd not need
to relabel the whole system, but only the parts affected by the move. Or
so I'd like to believe ;-).
Nils
Feel free to test! :-)
11:02 a.m.
On 27/01/12 14:12, Harald Hoyer wrote:
>
> Have you checked "enforcing=0" instead? If this worked, you'd not need
> to relabel the whole system, but only the parts affected by the move. Or
> so I'd like to believe ;-).
>
> Nils
Feel free to test! :-)
Finished fist kvm_guest
selinux=1 enforcing=1
no problems booting.
--
Regards,
Frank Murphy, friend of fedoraproject
UTF_8 Encoded
9:08 a.m.
-----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(a)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 SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk8ivd8ACgkQrlYvE4MpobNHNACfSp7CG7IT9EN/UOibqU+uaYM3
8E8AoJUpm24iz4UgyD6Mw96ilMO7QyjB
=3JXA
-----END PGP SIGNATURE-----
4:33 p.m.
-----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 SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk8lyUkACgkQNd069XiIR3gCLQCfX13j8qORKZwgZgFcAMl0FPGQ
TqsAn08vOu0nt5g+gJMq3Wnr/o9SZxXU
=goH8
-----END PGP SIGNATURE-----
8:28 a.m.
-----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"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk8mqQAACgkQrlYvE4MpobPiQwCgn5M5yzSZoUrJXKzkvYk964Hi
F2sAnRAKxSlREAzk1v+Z3tBlFElK2ln7
=GcyP
-----END PGP SIGNATURE-----
8:34 a.m.
On 30/01/12 14:28, Daniel J Walsh wrote:
>
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"
What about on an already done box.
Anything to be aware of?
--
Regards,
Frank Murphy
UTF_8 Encoded
1:32 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/30/2012 09:34 AM, Frank Murphy wrote:
On 30/01/12 14:28, Daniel J Walsh wrote:
>>
> 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"
What about on an already done box. Anything to be aware of?
Doubt it. It looks like the only things that need to be relabled are
the symlinks /sbin, /bin, /lib, /lib64, best if we did this with
setfiles. /etc/ld.so.cache seems to need a label also.
Here is a patch that I think we should consider, which would eliminate
the relabel, if it works...
Sadly I updated my machine with a previous version of this script and
the script broke. If anyone has a good test environment, that could
try it out, would be great.
Theoretically if this patch works, you would not need to disable
SELinux at all.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk8m8DoACgkQrlYvE4MpobO1wACeNjHDlNpntQeu42hprMUIc41y
0L8An1weo4Qt/Ayfce1szzeXC9Qs/03M
=YuXP
-----END PGP SIGNATURE-----
3:55 p.m.
Harald Hoyer wrote:
A screenshot of a successful conversion process is here:
http://people.freedesktop.org/~kay/usrmove-convert-log.png
So this copies the whole affected directories and then swaps in the copy,
right? That means it needs enough disk space left in / to carry full copies
of bin, sbin, lib and lib64, which is another annoying constraint. :-(
Kevin Kofler
4:57 p.m.
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
Mostly worked as described.
One issue is that the default user's PATH needs to be cleaned up:
/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/guest/.local/bin:/home/guest/bin
No point in having the primary PATH going through softlinks all the
time. Probably should be:
/usr/local/bin:/usr/bin:/home/guest/.local/bin:/home/guest/bin
Everything was being found in /bin before /usr/bin, and this caused an
obscure breakage in the graphviz build scripts
because it found /bin/tclsh instead of /usr/bin/tclsh.
(Where does this default PATH come from??)
There may be a similar problem with ldconfig. At the moment
"ldconfig -p" show most libs being resolved from /lib instead of from
/usr/lib.
Another issue is that I have:
/bin/sh: error while loading shared libraries: libc.so.6: cannot
open shared object file: No such file or directory
[ 1.796642] Kernel panic - not syncing: attempted to kill init!
when trying to boot kernel-3.3.0-0.rc1.git4.1.fc17.i686 from f17-usrmove
repo. Reverting to kernel-3.3.0-0.rc1.git3.1.fc17.i686 from the
Rawhide repo works ok.
John
5:48 a.m.
On Fri, Jan 27, 2012 at 5:57 PM, John Ellson <john.ellson(a)comcast.net> wrote:
Another issue is that I have:
/bin/sh: error while loading shared libraries: libc.so.6: cannot open
shared object file: No such file or directory
[ 1.796642] Kernel panic - not syncing: attempted to kill init!
when trying to boot kernel-3.3.0-0.rc1.git4.1.fc17.i686 from f17-usrmove
repo. Reverting to kernel-3.3.0-0.rc1.git3.1.fc17.i686 from the Rawhide
repo works ok.
That means your initramfs for the git4.1 kernel is probably broken. It has
nothing to do with the kernel itself.
There is a patch needed for kernel.spec eventually, but it isn't integrated
yet and I think the patch I've seen needs to be updated slightly.
josh
11:02 a.m.
On 01/28/2012 06:48 AM, Josh Boyer wrote:
On Fri, Jan 27, 2012 at 5:57 PM, John
Ellson<john.ellson(a)comcast.net> wrote:
> Another issue is that I have:
>
> /bin/sh: error while loading shared libraries: libc.so.6: cannot open
> shared object file: No such file or directory
> [ 1.796642] Kernel panic - not syncing: attempted to kill init!
>
> when trying to boot kernel-3.3.0-0.rc1.git4.1.fc17.i686 from f17-usrmove
> repo. Reverting to kernel-3.3.0-0.rc1.git3.1.fc17.i686 from the Rawhide
> repo works ok.
That means your initramfs for the git4.1 kernel is probably broken. It has
nothing to do with the kernel itself.
There is a patch needed for kernel.spec eventually, but it isn't integrated
yet and I think the patch I've seen needs to be updated slightly.
josh
Is there a workaround, or do I need to wait for a kernel update?
I tried to rebuild initramfs using:
dracut -f initramfs-3.3.0-0.rc1.git4.1.fc17.i686.img
3.3.0-0.rc1.git4.1.fc17.i686
but that made no difference.
John
12:41 p.m.
On 01/27/2012 05:57 PM, John Ellson wrote:
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
>
Mostly worked as described.
One issue is that the default user's PATH needs to be cleaned up:
/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/guest/.local/bin:/home/guest/bin
...
There may be a similar problem with ldconfig. At the moment
"ldconfig -p" show most libs being resolved from /lib instead of from
/usr/lib.
I'm not against this change, but it would be better if it resulted in a
performance gain rather than a performance loss.
I wrote a test to stat() the 2000+ files in /usr/bin/*, or /bin/*, 100
times.
The time cost of a stat() of /usr/bin/foo was ~ 12.4 microseconds; the
time cost of a stat() of /bin/foo was ~17.8 microseconds.
So to me, it is important that the default PATHs are changed to minimize
the traversal of softlinks.
At the moment, having /bin early in the PATH means that a softlink has
been *introduced* into most lookups, thus degrading performance.
The same issue exists for libs.
John
8:22 p.m.
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!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
1:49 p.m.
On 2012-01-27 5:10, Harald Hoyer wrote:
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.
To which file does the conversion script append this suffix when it
resolves a conflict: the one under / or the one under /usr?
5:49 a.m.
Am 28.01.2012 20:49, schrieb Garrett Holmstrom:
On 2012-01-27 5:10, Harald Hoyer wrote:
> 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.
To which file does the conversion script append this suffix when it resolves a
conflict: the one under / or the one under /usr?
the one under /usr is backed up and has the *.usrmove~ suffix.
6:26 a.m.
On Fri, Jan 27, 2012 at 10:10 PM, Harald Hoyer <harald(a)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
8:40 a.m.
On Fri, Jan 27, 2012 at 8:10 AM, Harald Hoyer <harald(a)redhat.com> 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
Interesting!
Do we need to teach rpm / yum about the equivalence, when resolving
dependencies?
For a trivial example -- if package A depends on /bin/foo, will yum &
rpm be satisfied with /usr/bin/foo?
cheers,
m
--
martin.langhoff(a)gmail.com
martin(a)laptop.org -- Software Architect - OLPC
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
2:47 p.m.
Martin Langhoff (martin.langhoff(a)gmail.com) said:
On Fri, Jan 27, 2012 at 8:10 AM, Harald Hoyer
<harald(a)redhat.com> 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
Interesting!
Do we need to teach rpm / yum about the equivalence, when resolving
dependencies?
For a trivial example -- if package A depends on /bin/foo, will yum &
rpm be satisfied with /usr/bin/foo?
Assuming /bin -> /usr/bin link is packaged, yes.
Bill
2:52 p.m.
On Mon, Jan 30, 2012 at 3:47 PM, Bill Nottingham <notting(a)redhat.com> wrote:
Assuming /bin -> /usr/bin link is packaged, yes.
Wow, it follows the symlink created by a 3rd package.
clever,
m
--
martin.langhoff(a)gmail.com
martin(a)laptop.org -- Software Architect - OLPC
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
2:56 p.m.
Martin Langhoff (martin.langhoff(a)gmail.com) said:
On Mon, Jan 30, 2012 at 3:47 PM, Bill Nottingham
<notting(a)redhat.com> wrote:
> Assuming /bin -> /usr/bin link is packaged, yes.
Wow, it follows the symlink created by a 3rd package.
Technically, the link doesn't even need to be packaged; as long as /bin
exists in the RPM db (as a dir or as a symlink), RPM will follow the link
and resolve the dependency.
Bill
4:37 p.m.
On Mon, 2012-01-30 at 15:47 -0500, Bill Nottingham wrote:
Martin Langhoff (martin.langhoff(a)gmail.com) said:
> On Fri, Jan 27, 2012 at 8:10 AM, Harald Hoyer <harald(a)redhat.com> 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
>
> Interesting!
>
> Do we need to teach rpm / yum about the equivalence, when resolving
> dependencies?
>
> For a trivial example -- if package A depends on /bin/foo, will yum &
> rpm be satisfied with /usr/bin/foo?
Assuming /bin -> /usr/bin link is packaged, yes.
No, not in any meaningful way, although I assume all of the problems
have been worked out in the testing done already.
Yum just uses text matching. Yum doesn't even know if something is a
symlink in the repodata, and I'd assume it would be a massive depsolving
expense to resolve those even if we had that data.
rpm _kind of_ knows about it, Eg.:
% rpm -qf /etc/init.d/httpd
httpd-0:2.2.21-1.fc15.x86_64
% rpm -qf /etc/rc.d/init.d/httpd
httpd-0:2.2.21-1.fc15.x86_64
% repoquery -qf /etc/init.d/httpd
% repoquery -qf /etc/rc.d/init.d/httpd
httpd-0:2.2.17-10.fc15.1.x86_64
httpd-0:2.2.21-1.fc15.x86_64
...but I assume rpm uses realpath() to "cheat" because if you create two
packages where one provides "/etc/rc.d/init.d/sym2" and the other
requires "/etc/init.d/sym2" ... rpm _doesn't_ let you install them, like
yum.
But you can add:
Provides: /bin/foo
...to your packages, and you can pretend they are installed into /bin
(keeping compat. with everything) ... at which point rpm/yum won't care
that the /bin => /usr/bin symlink has actually moved where they are
installed from build time (but note that Requires: /usr/bin/foo won't
work, in the later case).
6:06 p.m.
On Jan 30, 2012 5:37 PM, "James Antill" <james(a)fedoraproject.org> wrote:
> > For a trivial example -- if package A depends on /bin/foo,
will yum &
> > rpm be satisfied with /usr/bin/foo?
>
> Assuming /bin -> /usr/bin link is packaged, yes.
No, not in any meaningful way, although I assume all of the problems
have been worked out in the testing done already.
Yum just uses text matching.
So some work needs to be done at the yum layer to make upgrades and install
of foreign rpms reasonably smooth, I gather?
But you can add:
Provides: /bin/foo
Ugh! Will that be needed that across the distro for a release or two?
cheers,
martin
12:03 a.m.
On Tue, Jan 31, 2012 at 1:06 AM, Martin Langhoff
<martin.langhoff(a)gmail.com> wrote:
> But you can add:
>
> Provides: /bin/foo
Ugh! Will that be needed that across the distro for a release or two?
http://pkgs.fedoraproject.org/gitweb/?p=coreutils.git;a=commitdiff;h=0922...
As you say, ugh!.
Mirek
3:29 a.m.
Miloslav Trmač wrote:
Yeah, this is awful!
Can't you push more strongly in FESCo for a revote? This "feature" really
needs
to be reconsidered, and hopefully thrown out by revoking its approval.
Kevin Kofler
9:25 a.m.
Miloslav Trmač (mitr(a)volny.cz) said:
On Tue, Jan 31, 2012 at 1:06 AM, Martin Langhoff
<martin.langhoff(a)gmail.com> wrote:
>> But you can add:
>>
>> Provides: /bin/foo
>
> Ugh! Will that be needed that across the distro for a release or two?
http://pkgs.fedoraproject.org/gitweb/?p=coreutils.git;a=commitdiff;h=0922...
That should not be needed.
Bill
9:52 a.m.
Bill Nottingham (notting(a)redhat.com) said:
Miloslav Trmač (mitr(a)volny.cz) said:
> On Tue, Jan 31, 2012 at 1:06 AM, Martin Langhoff
> <martin.langhoff(a)gmail.com> wrote:
> >> But you can add:
> >>
> >> Provides: /bin/foo
> >
> > Ugh! Will that be needed that across the distro for a release or two?
>
>
http://pkgs.fedoraproject.org/gitweb/?p=coreutils.git;a=commitdiff;h=0922...
That should not be needed.
To be precise:
[root@nostromo ~]# mv /bin /cow
[root@nostromo ~]# /cow/ln -s /cow /bin
[root@nostromo ~]# rpm -qf /cow/bash
bash-4.2.20-1.fc16.x86_64
[root@nostromo ~]# rpm -qf /bin/bash
bash-4.2.20-1.fc16.x86_64
rpm should already handle this, no need for the provides.
Bill
9:53 a.m.
On Tue, Jan 31, 2012 at 4:52 PM, Bill Nottingham <notting(a)redhat.com> wrote:
Bill Nottingham (notting(a)redhat.com) said:
> Miloslav Trmač (mitr(a)volny.cz) said:
> > On Tue, Jan 31, 2012 at 1:06 AM, Martin Langhoff
> > <martin.langhoff(a)gmail.com> wrote:
> > >> But you can add:
> > >>
> > >> Provides: /bin/foo
> > >
> > > Ugh! Will that be needed that across the distro for a release or two?
> >
> >
http://pkgs.fedoraproject.org/gitweb/?p=coreutils.git;a=commitdiff;h=0922...
>
> That should not be needed.
To be precise:
[root@nostromo ~]# mv /bin /cow
[root@nostromo ~]# /cow/ln -s /cow /bin
[root@nostromo ~]# rpm -qf /cow/bash
bash-4.2.20-1.fc16.x86_64
[root@nostromo ~]# rpm -qf /bin/bash
bash-4.2.20-1.fc16.x86_64
rpm should already handle this, no need for the provides.
Elsewhere in this thread it was pointed out that yum doesn't handle it
the same way.
Mirek
10:03 a.m.
Miloslav Trmač (mitr(a)volny.cz) said:
> To be precise:
>
> [root@nostromo ~]# mv /bin /cow
> [root@nostromo ~]# /cow/ln -s /cow /bin
> [root@nostromo ~]# rpm -qf /cow/bash
> bash-4.2.20-1.fc16.x86_64
> [root@nostromo ~]# rpm -qf /bin/bash
> bash-4.2.20-1.fc16.x86_64
>
> rpm should already handle this, no need for the provides.
Elsewhere in this thread it was pointed out that yum doesn't handle it
the same way.
When calculating local on-system provides, it should - in fact, I'd be
surprised if it doesn't. Admins sometimes move directories around and
replace them with symlinks.
Is the statement that it won't take it into account for an initial install
transaction?
(The solution then would be to merely not change the packaging outside of
the filesystem package.)
Bill
10:22 a.m.
On Tue, Jan 31, 2012 at 11:03 AM, Bill Nottingham <notting(a)redhat.com> wrote:
Miloslav Trmač (mitr(a)volny.cz) said:
When calculating local on-system provides, it should - in fact, I'd be
surprised if it doesn't. Admins sometimes move directories around and
replace them with symlinks.
Well, that's a very different scenario.
Is the statement that it won't take it into account for an
initial install
transaction?
My statement is that packages on a F17 system won't declare that they
install /bin/foo (unless an explicit "compat" provides is written into
the spec file).
So external packages (_not_ coming from Fedora) may depend on
/bin/foo, and yum won't know what to install.
Perhaps yum can be taught explicitly about these symlinks, or perhaps
the whole repo needs a whole lot of "provides" added. Cannot right now
see a practical 3rd option.
Note that I'm _for_ the /usr move, just being curious (perhaps
annoying) about some technical details. The benefits are compelling
for many things I do in my personal computing, and for the work we do
@ OLPC.
From the OLPC angle, I favour yum being taught about the symlinks -- a
big pile of provides will only grow the yum sqlite database, and
that's _not_ good news for bandwidth-limited users, nor for
RAM-limited devices. Like XOs :-)
cheers,
m
--
martin.langhoff(a)gmail.com
martin(a)laptop.org -- Software Architect - OLPC
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
11:16 a.m.
On Tue, 2012-01-31 at 11:03 -0500, Bill Nottingham wrote:
Miloslav Trmač (mitr(a)volny.cz) said:
> > To be precise:
> >
> > [root@nostromo ~]# mv /bin /cow
> > [root@nostromo ~]# /cow/ln -s /cow /bin
> > [root@nostromo ~]# rpm -qf /cow/bash
> > bash-4.2.20-1.fc16.x86_64
> > [root@nostromo ~]# rpm -qf /bin/bash
> > bash-4.2.20-1.fc16.x86_64
> >
> > rpm should already handle this, no need for the provides.
>
> Elsewhere in this thread it was pointed out that yum doesn't handle it
> the same way.
When calculating local on-system provides, it should - in fact, I'd be
surprised if it doesn't. Admins sometimes move directories around and
replace them with symlinks.
Is the statement that it won't take it into account for an initial install
transaction?
Perhaps it'd be nice for someone to be sure about this? The competing
uncertain 'I think it's sort of like this' assertions are making me
nervous.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
2:41 p.m.
On Tue, 2012-01-31 at 11:03 -0500, Bill Nottingham wrote:
Miloslav Trmač (mitr(a)volny.cz) said:
> > To be precise:
> >
> > [root@nostromo ~]# mv /bin /cow
> > [root@nostromo ~]# /cow/ln -s /cow /bin
> > [root@nostromo ~]# rpm -qf /cow/bash
> > bash-4.2.20-1.fc16.x86_64
> > [root@nostromo ~]# rpm -qf /bin/bash
> > bash-4.2.20-1.fc16.x86_64
> >
> > rpm should already handle this, no need for the provides.
>
> Elsewhere in this thread it was pointed out that yum doesn't handle it
> the same way.
When calculating local on-system provides, it should - in fact, I'd be
surprised if it doesn't. Admins sometimes move directories around and
replace them with symlinks.
I would be _very_ surprised if rpm let you install "foo" which
requires /bin/bash ... if bash _only_ provided /usr/bin/bash and another
package (or even the same one) provided /bin => /usr/bin.
I'm not 100% sure what -qf is doing, but I'd guess it's just walking
the basename list and seeing if anything matches the inode of what is
passed in ... which is fine for query, to help the sysadmin. out, but
I'd guess would be very expensive at install time.
2:32 p.m.
On Tue, 2012-01-31 at 10:52 -0500, Bill Nottingham wrote:
Bill Nottingham (notting(a)redhat.com) said:
> Miloslav Trmač (mitr(a)volny.cz) said:
> > On Tue, Jan 31, 2012 at 1:06 AM, Martin Langhoff
> > <martin.langhoff(a)gmail.com> wrote:
> > >> But you can add:
> > >>
> > >> Provides: /bin/foo
> > >
> > > Ugh! Will that be needed that across the distro for a release or two?
> >
> >
http://pkgs.fedoraproject.org/gitweb/?p=coreutils.git;a=commitdiff;h=0922...
>
> That should not be needed.
To be precise:
[root@nostromo ~]# mv /bin /cow
[root@nostromo ~]# /cow/ln -s /cow /bin
[root@nostromo ~]# rpm -qf /cow/bash
bash-4.2.20-1.fc16.x86_64
[root@nostromo ~]# rpm -qf /bin/bash
bash-4.2.20-1.fc16.x86_64
rpm should already handle this, no need for the provides.
Good to see everyone still doesn't read what I write.
As I said, rpm _does something_ to make the above work for -qf (the
above even works if you inside /cow ... as long as the /bin symlink
exists!).
However, it _does not_ work, if you put the above in package
provides/requires and try to install them. Eg.
http://james.fedorapeople.org/yum/sym1.spec
http://james.fedorapeople.org/yum/sym2.spec
...you _cannot_ install these packages, even via. local only rpm.
Also, even if someone could fix rpm to work this out, making this work
at the yum layer is _much_ harder ... because the repodata does not
currently specify that /path/to/blah is a regular file or a symlink (and
if it's a symlink, what it points to).
So the coreutils provides _are needed_ (along with all others), or the
coreutils package has to "lie" and say it is installing the packages
into a dir. /bin.
2:58 p.m.
James Antill (james(a)fedoraproject.org) said:
> [root@nostromo ~]# mv /bin /cow
> [root@nostromo ~]# /cow/ln -s /cow /bin
> [root@nostromo ~]# rpm -qf /cow/bash
> bash-4.2.20-1.fc16.x86_64
> [root@nostromo ~]# rpm -qf /bin/bash
> bash-4.2.20-1.fc16.x86_64
>
> rpm should already handle this, no need for the provides.
Good to see everyone still doesn't read what I write.
As I said, rpm _does something_ to make the above work for -qf (the
above even works if you inside /cow ... as long as the /bin symlink
exists!).
However, it _does not_ work, if you put the above in package
provides/requires and try to install them. Eg.
It does, in some cases. Which makes it even more fun.
Take a system with /usr/bin/sdiff.
...
Name: cow
Summary: cow
Version: 1.0
Release: 1
URL: http://redhat.com/
License: Moo
Requires: /bin/sdiff
%description
Moo
%setup
%build
%install
mkdir -p $RPM_BUILD_ROOT/usr/bin
touch $RPM_BUILD_ROOT%{_bindir}/this-cow-goes-moo
%files
%{_bindir}/*
...
root@nostromo x86_64]# rpm -ivh cow-1.0-1.x86_64.rpm --test
error: Failed dependencies:
/bin/sdiff is needed by cow-1.0-1.x86_64
[root@nostromo x86_64]# mv /bin /cow
[root@nostromo x86_64]# /cow/ln /usr/bin -s /bin
[root@nostromo x86_64]# /cow/rpm -ivh cow-1.0-1.x86_64.rpm --test
Preparing... ########################################### [100%]
Yum installs the package as well.
Bill
3:06 p.m.
Bill Nottingham (notting(a)redhat.com) said:
> Good to see everyone still doesn't read what I write.
>
> As I said, rpm _does something_ to make the above work for -qf (the
> above even works if you inside /cow ... as long as the /bin symlink
> exists!).
> However, it _does not_ work, if you put the above in package
> provides/requires and try to install them. Eg.
It does, in some cases. Which makes it even more fun.
<example snipped>
Confirmed with a quick check - following of symlinks works for extrapolating
provides from the installed system. It does not work for extrapolating
provides from to-be-installed-in-the-same-transaction packages.
Hooray corner cases!
Bill ("obviously we should split everything into individual transactions")
3:30 p.m.
On Tue, 2012-01-31 at 15:58 -0500, Bill Nottingham wrote:
James Antill (james(a)fedoraproject.org) said:
> > [root@nostromo ~]# mv /bin /cow
> > [root@nostromo ~]# /cow/ln -s /cow /bin
> > [root@nostromo ~]# rpm -qf /cow/bash
> > bash-4.2.20-1.fc16.x86_64
> > [root@nostromo ~]# rpm -qf /bin/bash
> > bash-4.2.20-1.fc16.x86_64
> >
> > rpm should already handle this, no need for the provides.
>
> Good to see everyone still doesn't read what I write.
>
> As I said, rpm _does something_ to make the above work for -qf (the
> above even works if you inside /cow ... as long as the /bin symlink
> exists!).
> However, it _does not_ work, if you put the above in package
> provides/requires and try to install them. Eg.
It does, in some cases. Which makes it even more fun.
Take a system with /usr/bin/sdiff.
...
Name: cow
Summary: cow
Version: 1.0
Release: 1
URL: http://redhat.com/
License: Moo
Requires: /bin/sdiff
...
root@nostromo x86_64]# rpm -ivh cow-1.0-1.x86_64.rpm --test
error: Failed dependencies:
/bin/sdiff is needed by cow-1.0-1.x86_64
[root@nostromo x86_64]# mv /bin /cow
[root@nostromo x86_64]# /cow/ln /usr/bin -s /bin
[root@nostromo x86_64]# /cow/rpm -ivh cow-1.0-1.x86_64.rpm --test
Preparing... ########################################### [100%]
IMO this is pretty crazy, because by changing the symlink back you've
broken the prco constraints in the DB (but everything would verify as
"correct").
It also seems like rpm is doing a _lot_ of work it doesn't need to do
here, but who knows ... it looks pretty magic (and I'm scared to go find
out why/how it's doing the above :).
Cc'ing rpm maintainers for their opinion on what rpm is doing and why.
Yum installs the package as well.
Yeh, if it asks rpm if something is installed which satisfies that and
is told yes, it will. However ... yum currently caches file
requires/providers from rpm (among other things).
So it's very possible that yum doesn't "DTRT" when it has cached data
saying diffutils owns /usr/bin/sdiff and not /bin/sdiff (but it might,
because it's a negative failure).
In general I think only a huge amount of pain can come from relying on
this (and you can't install into this situation, easily).
6:32 a.m.
New subject: [Rpm-maint] Fedora 17’s unified filesystem (/usr-move)
On 01/31/2012 11:30 PM, James Antill wrote:
On Tue, 2012-01-31 at 15:58 -0500, Bill Nottingham wrote:
> James Antill (james(a)fedoraproject.org) said:
>>> [root@nostromo ~]# mv /bin /cow
>>> [root@nostromo ~]# /cow/ln -s /cow /bin
>>> [root@nostromo ~]# rpm -qf /cow/bash
>>> bash-4.2.20-1.fc16.x86_64
>>> [root@nostromo ~]# rpm -qf /bin/bash
>>> bash-4.2.20-1.fc16.x86_64
>>>
>>> rpm should already handle this, no need for the provides.
>>
>> Good to see everyone still doesn't read what I write.
>>
>> As I said, rpm _does something_ to make the above work for -qf (the
>> above even works if you inside /cow ... as long as the /bin symlink
>> exists!).
>> However, it _does not_ work, if you put the above in package
>> provides/requires and try to install them. Eg.
>
> It does, in some cases. Which makes it even more fun.
>
> Take a system with /usr/bin/sdiff.
>
> ...
> Name: cow
> Summary: cow
> Version: 1.0
> Release: 1
> URL: http://redhat.com/
> License: Moo
> Requires: /bin/sdiff
> ...
>
> root@nostromo x86_64]# rpm -ivh cow-1.0-1.x86_64.rpm --test
> error: Failed dependencies:
> /bin/sdiff is needed by cow-1.0-1.x86_64
> [root@nostromo x86_64]# mv /bin /cow
> [root@nostromo x86_64]# /cow/ln /usr/bin -s /bin
> [root@nostromo x86_64]# /cow/rpm -ivh cow-1.0-1.x86_64.rpm --test
> Preparing... ########################################### [100%]
IMO this is pretty crazy, because by changing the symlink back you've
broken the prco constraints in the DB (but everything would verify as
"correct").
Actually verify does notice this breakage (using slightly different
sample specimen to avoid having to muck with /bin):
[root@localhost ~]# rpm -Uvh
/home/pmatilai/rpmbuild/RPMS/noarch/cow-1.0-1.noarch.rpm
error: Failed dependencies:
/moo/sdiff is needed by cow-1.0-1.noarch
[root@localhost ~]# ln -s /usr/bin /moo
[root@localhost ~]# rpm -Uvh
/home/pmatilai/rpmbuild/RPMS/noarch/cow-1.0-1.noarch.rpm
Preparing... ###########################################
[100%]
Updating / installing...
1:cow ###########################################
[100%]
[root@localhost ~]# rpm -V cow
[root@localhost ~]# rm -f /moo
[root@localhost ~]# rpm -V cow
Unsatisfied dependencies for cow-1.0-1.noarch:
/moo/sdiff is needed by (installed) cow-1.0-1.noarch
[root@localhost ~]#
It also seems like rpm is doing a _lot_ of work it doesn't need
to do
here, but who knows ... it looks pretty magic (and I'm scared to go find
out why/how it's doing the above :).
Cc'ing rpm maintainers for their opinion on what rpm is doing and why.
This is the somewhat infamous and magical "fingerprinting" at work,
whether you actually wanted to know it or not :)
Roughly speaking, rpm doesn't look up installed file matches by
comparing the entire path, it compares the "fingerprint" (basically
inode + device combination) of all matching basenames for equality.
So what happens in the above /moo/sdiff case is that rpm looks up all
files with 'sdiff' basename from the rpmdb (in this case returning
/usr/bin/sdiff from diffutils), and compares the fingerprint of
/moo/sdiff and /usr/bin/sdiff for equality. When the /moo -> /usr/bin
link is in place, /moo/sdiff and /usr/bin/sdiff are the same physical
file regardless of the actual path used to reach it, and thus considered
a match.
As for the why-part: its a caching and tracking mechanism for dealing
with directories vs symlinks to directories. Whether the issue discussed
here should be considered a side-effect or an intentional feature is
perhaps another question, but that's how rpm has worked since very very
early days.
To-be-installed files obviously have no on-disk fingerprints, so it wont
work for initial installation. So yes, those "fake" compatibility
provides are needed. Strictly speaking, compatibility provides would be
needed for ALL the moved files, not just /bin, as it's technically
perfectly legal for a package to depend on an arbitrary path in
/lib[64], not just /[s]bin.
- Panu -
7:49 a.m.
On 02/01/2012 01:32 PM, Panu Matilainen wrote:
To-be-installed files obviously have no on-disk fingerprints, so it
wont work for initial installation. So yes, those "fake" compatibility
provides are needed. Strictly speaking, compatibility provides would
be needed for ALL the moved files, not just /bin, as it's technically
perfectly legal for a package to depend on an arbitrary path in
/lib[64], not just /[s]bin.
- Panu -
Would it be possible to leave out these provides and fix each individual
package to require in the new path instead?
8:41 a.m.
Once upon a time, Emanuel Rietveld <codehotter(a)gmail.com> said:
On 02/01/2012 01:32 PM, Panu Matilainen wrote:
>To-be-installed files obviously have no on-disk fingerprints, so it
>wont work for initial installation. So yes, those "fake" compatibility
>provides are needed. Strictly speaking, compatibility provides would
>be needed for ALL the moved files, not just /bin, as it's technically
>perfectly legal for a package to depend on an arbitrary path in
>/lib[64], not just /[s]bin.
>
> - Panu -
Would it be possible to leave out these provides and fix each individual
package to require in the new path instead?
It isn't practical to "fix" every package that requires /bin/sh.
There sure seems to be a lot of uncertainty for a "feature" that is
supposedly ready to land.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
8:48 a.m.
On 02/01/2012 09:41 AM, Chris Adams wrote:
Once upon a time, Emanuel Rietveld <codehotter(a)gmail.com>
said:
> On 02/01/2012 01:32 PM, Panu Matilainen wrote:
>> To-be-installed files obviously have no on-disk fingerprints, so it
>> wont work for initial installation. So yes, those "fake" compatibility
>> provides are needed. Strictly speaking, compatibility provides would
>> be needed for ALL the moved files, not just /bin, as it's technically
>> perfectly legal for a package to depend on an arbitrary path in
>> /lib[64], not just /[s]bin.
>>
>> - Panu -
>
> Would it be possible to leave out these provides and fix each individual
> package to require in the new path instead?
It isn't practical to "fix" every package that requires /bin/sh.
There sure seems to be a lot of uncertainty for a "feature" that is
supposedly ready to land.
Just asking - does a bind mount of /bin instead of a soft link help?
9:29 a.m.
Once upon a time, Genes MailLists <lists(a)sapience.com> said:
Just asking - does a bind mount of /bin instead of a soft link help?
That doesn't affect RPM database and yum metadata issues.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
8:54 a.m.
On 02/01/2012 04:41 PM, Chris Adams wrote:
Once upon a time, Emanuel Rietveld<codehotter(a)gmail.com>
said:
> On 02/01/2012 01:32 PM, Panu Matilainen wrote:
>> To-be-installed files obviously have no on-disk fingerprints, so it
>> wont work for initial installation. So yes, those "fake" compatibility
>> provides are needed. Strictly speaking, compatibility provides would
>> be needed for ALL the moved files, not just /bin, as it's technically
>> perfectly legal for a package to depend on an arbitrary path in
>> /lib[64], not just /[s]bin.
>>
>> - Panu -
>
> Would it be possible to leave out these provides and fix each individual
> package to require in the new path instead?
It isn't practical to "fix" every package that requires /bin/sh.
It's not "just" that the impracticality either - not providing /bin/sh,
/sbin/ldconfig and the like would mean a huge incompatibility break with
nearly every existing package in the wild. Not really an option.
- Panu -
10:38 a.m.
Panu Matilainen (pmatilai(a)laiskiainen.org) said:
>>>To-be-installed files obviously have no on-disk
fingerprints, so it
>>>wont work for initial installation. So yes, those "fake"
compatibility
>>>provides are needed. Strictly speaking, compatibility provides would
>>>be needed for ALL the moved files, not just /bin, as it's technically
>>>perfectly legal for a package to depend on an arbitrary path in
>>>/lib[64], not just /[s]bin.
>>>
>>> - Panu -
>>
>>Would it be possible to leave out these provides and fix each individual
>>package to require in the new path instead?
>
>It isn't practical to "fix" every package that requires /bin/sh.
It's not "just" that the impracticality either - not providing
/bin/sh, /sbin/ldconfig and the like would mean a huge
incompatibility break with nearly every existing package in the
wild. Not really an option.
I'm not convinced of the "all" case, though. /bin/sh, /sbin/ldconfig,
etc. could be reasonable for a package to require, and should be provided.
Requires: /lib/modules/3.1.2-1.fc16/kernel/drivers/net/3c59x.ko is likely
too dumb to live, though.
Bill
11:38 a.m.
On 02/01/2012 06:38 PM, Bill Nottingham wrote:
Panu Matilainen (pmatilai(a)laiskiainen.org) said:
>>>> To-be-installed files obviously have no on-disk fingerprints, so it
>>>> wont work for initial installation. So yes, those "fake"
compatibility
>>>> provides are needed. Strictly speaking, compatibility provides would
>>>> be needed for ALL the moved files, not just /bin, as it's
technically
>>>> perfectly legal for a package to depend on an arbitrary path in
>>>> /lib[64], not just /[s]bin.
>>>>
>>>> - Panu -
>>>
>>> Would it be possible to leave out these provides and fix each individual
>>> package to require in the new path instead?
>>
>> It isn't practical to "fix" every package that requires /bin/sh.
>
> It's not "just" that the impracticality either - not providing
> /bin/sh, /sbin/ldconfig and the like would mean a huge
> incompatibility break with nearly every existing package in the
> wild. Not really an option.
I'm not convinced of the "all" case, though. /bin/sh, /sbin/ldconfig,
etc. could be reasonable for a package to require, and should be provided.
Requires: /lib/modules/3.1.2-1.fc16/kernel/drivers/net/3c59x.ko is likely
too dumb to live, though.
Oh, sure. Hence the "strictly speaking".
I'm not arguing for adding provides for eg /lib/modules (although I
think I've seen such dependencies in the wonderful world of kernel
module packaging ;), just pointing out that it's not 100% transparent
change for package(r)s. Made ever more fun by the rpm behavior on
installed files where you test a package on your machine, see it
installs fine and then scratch head when it fails to work as part of
initial install.
- Panu -
2:36 a.m.
Le Mar 31 janvier 2012 21:32, James Antill a écrit :
Also, even if someone could fix rpm to work this out, making this
work
at the yum layer is _much_ harder ... because the repodata does not
currently specify that /path/to/blah is a regular file or a symlink (and
if it's a symlink, what it points to).
This, BTW, is a PITA whenever you need to check repo compliance with any
packaging guideline that specifies file location or ownership.
It's not possible to do a simple repoquery to find problem packages, you have
to download every single package with a file name in the wrong location, just
in case it's not actually wrong but contains a compat symlink pointing to the
right file (that may or may not be installed by the same package).
That makes simple repo checks astonishingly long and bandwidth-expensive.
--
Nicolas Mailhot
12:46 p.m.
On Fri, 2012-01-27 at 14:10 +0100, Harald Hoyer wrote:
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
As a heads up for x86-64 users:
The f17-usrmove koji repo for x86-64 is missing x86-32 rpms which are
normally copied from the x86-32 to x86-64 as part of the rawhide
compose.
Workaround is to add a second entry to the repo file pointing directly
to the x86-32 (i386) repo. Otherwise yum will bail out eventually
because of protected multilib versions.
[f17-usrmove-x86-32]
name=Fedora $releasever - $basearch
failovermethod=priority
baseurl=http://koji.fedoraproject.org/repos/f17-usrmove/latest/i386
enabled=1
metadata_expire=1d
gpgcheck=0
Regards,
Andreas
--
Andreas Bierfert <andreas.bierfert(a)lowlatency.de>
12:49 p.m.
What would be the pros/cons of a bind mount instead of a soft link for
/bin et al?
gene
4:23 p.m.
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?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
4:36 p.m.
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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
7:38 p.m.
On Tue, Jan 31, 2012 at 23:36, Adam Williamson <awilliam(a)redhat.com> wrote:
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?
Oh, for some reason, we missed to add ntfs-3g to the packages in the
f17-usrmove repo. The unconverted package contains:
/usr/bin/ntfs-3g -> /bin/ntfs-3g
which needs to be fixed to work properly for the usrmove.
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.
Sounds unlikely that this is related. But tests should show.
Unrelated: Do you know if the installer uses udisks? If, it should
probably switch to the current udisks2, because udisks will not much
longer be supported, and we should people give a note about that.
Thanks,
Kay
10:58 p.m.
On Wed, 2012-02-01 at 02:38 +0100, Kay Sievers wrote:
> 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.
Sounds unlikely that this is related. But tests should show.
Unrelated: Do you know if the installer uses udisks? If, it should
probably switch to the current udisks2, because udisks will not much
longer be supported, and we should people give a note about that.
Confirmed that this bug is not related to /usr move. I'm working with
anaconda team now to try and get an anaconda that's actually capable of
completing a live install, with or without the /usr move stuff.
I'm not sure if anaconda uses udisks directly, or if it's something else
calling udisksd. The udisksd error may not actually have been the cause
of the anaconda crash, according to bcl.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
4:47 a.m.
New subject: @ Harald Re: Fedora 17’s unified filesystem (/usr-move)
On 27/01/12 13:10, 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
if before the /usrmove.
There is a symlink:
/lib/foo > /usr/lib/foo2
and a hardlink was created before the move.
/usr/lib/foo > /usr/lib/foo2
Would the /usrmove script
replace the hardlink with the softlink?
--
Regards,
Frank Murphy, friend of fedoraproject
UTF_8 Encoded
6:42 a.m.
New subject: @ Harald Re: Fedora 17’s unified filesystem (/usr-move)
Frank Murphy wrote:
On 27/01/12 13:10, 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
>
if before the /usrmove.
There is a symlink:
/lib/foo > /usr/lib/foo2
and a hardlink was created before the move.
/usr/lib/foo > /usr/lib/foo2
Would the /usrmove script
replace the hardlink with the softlink?
no.
-- rex
6:44 a.m.
New subject: @ Harald Re: Fedora 17’s unified filesystem (/usr-move)
On 02/02/12 12:42, Rex Dieter wrote:
> Would the /usrmove script
> replace the hardlink with the softlink?
no.
-- rex
Thanks Rex,
Unfortunatly I'm not a scripter.
--
Regards,
Frank Murphy, friend of fedoraproject
UTF_8 Encoded
12:47 p.m.
On Fri, Jan 27, 2012 at 14:10, Harald Hoyer <harald(a)redhat.com> 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.
The former dracut ‘usrmove’ module has been renamed to ‘convertfs’. We
need to carry that option for quite some time through future releases
and want to name the module more generic for possible future needs in
that category.
This is the current version/build number:
dracut-014-81.git20120202.fc17
Please build the custom dracut image now with:
# dracut --force --add convertfs
On the kernel commandline dracut now looks for:
rd.convertfs
In some cases, we still do not properly support multi-lib updates with
the current testing repo, without adding also the i386 repository to
the updated system; the f17-usrmove repo does not automatically copy
the 32bit libs in the 64bit repo. This issue will not happen when all
moves to rawhide.
These known bugs are fixed:
- rebuild of the dracut initramfs on the converted system had problems
with optimized i686 libs, which is fixed now
- the ntfs-3g was not part of the f17-usrmove repository and
installing the old package on the converted system broke its symlink
logic. The fixed package is built for f17-usrmove now.
4:25 a.m.
On 02/02/12 18:47, Kay Sievers wrote:
The former dracut ‘usrmove’ module has been renamed to ‘convertfs’. We
need to carry that option for quite some time through future releases
Does this mean that ‘convertfs’ will be build into dracut-*?
Does the user\tester have to keep doing "--force --add"?
Does rd.convertfs have to stay on /etc/grub.cfg
Shoule we adjust /etc/dracut.conf "add_extramodules=convertfs"
Apologies if, it's only me that doesn't understand.
--
Regards,
Frank Murphy, friend of fedoraproject
UTF_8 Encoded
4:33 a.m.
On Fri, Feb 3, 2012 at 11:25, Frank Murphy <frankly3d(a)gmail.com> wrote:
On 02/02/12 18:47, Kay Sievers wrote:
>
> The former dracut ‘usrmove’ module has been renamed to ‘convertfs’. We
> need to carry that option for quite some time through future releases
Does this mean that ‘convertfs’ will be build into dracut-*?
The module will be provided by dracut for at least the next two Fedora
releases, to be able to upgrade older installations with just yum.
Does the user\tester have to keep doing "--force --add"?
For now, the module is not included by default. We will have a call to
that script in anaconda, so updates from media will not need any of
these steps. Manual updates with dracut will need that.
Does rd.convertfs have to stay on /etc/grub.cfg
Shoule we adjust /etc/dracut.conf "add_extramodules=convertfs"
Only once, It can also be be entered one time at the bootloader.
Kay
7:56 a.m.
Am 03.02.2012 11:33, schrieb Kay Sievers:
On Fri, Feb 3, 2012 at 11:25, Frank Murphy
<frankly3d(a)gmail.com> wrote:
> On 02/02/12 18:47, Kay Sievers wrote:
>>
>> The former dracut ‘usrmove’ module has been renamed to ‘convertfs’. We
>> need to carry that option for quite some time through future releases
>
> Does this mean that ‘convertfs’ will be build into dracut-*?
The module will be provided by dracut for at least the next two Fedora
releases, to be able to upgrade older installations with just yum.
> Does the user\tester have to keep doing "--force --add"?
For now, the module is not included by default. We will have a call to
that script in anaconda, so updates from media will not need any of
these steps. Manual updates with dracut will need that.
> Does rd.convertfs have to stay on /etc/grub.cfg
> Shoule we adjust /etc/dracut.conf "add_extramodules=convertfs"
Only once, It can also be be entered one time at the bootloader.
Kay
https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_16_-.3E_...
4467
days inactive
4475
days old
64 comments
27 participants
participants (27)
-
Adam Williamson -
Andreas Bierfert -
Bill Nottingham -
Chris Adams -
Daniel J Walsh -
Emanuel Rietveld -
Frank Murphy -
Frank Murphy -
Garrett Holmstrom -
Genes MailLists -
Harald Hoyer -
Harald Hoyer -
James Antill -
Joel Rees -
John Ellson -
Josh Boyer -
Kay Sievers -
Kevin Kofler -
Martin Langhoff -
Michal Schmidt -
Michel Alexandre Salim -
Miloslav Trmač -
Nicolas Mailhot -
Nils Philippsen -
Panu Matilainen -
Rex Dieter -
Stijn Hoop