Re: Fedora 17’s unified filesystem (/usr-move)
Am 03.02.2012 11:33, schrieb Kay Sievers: On Fri, Feb 3, 2012 at 11:25, Frank Murphy frankl...@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_Fedora_17 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
On Fri, Feb 3, 2012 at 11:25, Frank Murphy frankl...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
@ 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: @ 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: @ 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
On Fri, Jan 27, 2012 at 14:10, Harald Hoyer har...@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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [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 (ja...@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 - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
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? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
Once upon a time, Emanuel Rietveld codehot...@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 cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
On 02/01/2012 09:41 AM, Chris Adams wrote: Once upon a time, Emanuel Rietveld codehot...@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? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
On 02/01/2012 04:41 PM, Chris Adams wrote: Once upon a time, Emanuel Rietveldcodehot...@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 - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
Once upon a time, Genes MailLists li...@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 cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
Panu Matilainen (pmati...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
On 02/01/2012 06:38 PM, Bill Nottingham wrote: Panu Matilainen (pmati...@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 - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
Miloslav Trmač wrote: http://pkgs.fedoraproject.org/gitweb/?p=coreutils.git;a=commitdiff;h=09220fef36dcc2fe06bd858578119872f889c7e2 As you say, ugh!. 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
Miloslav Trmač (m...@volny.cz) said: On Tue, Jan 31, 2012 at 1:06 AM, Martin Langhoff martin.langh...@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=09220fef36dcc2fe06bd858578119872f889c7e2 That should not be needed. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
Bill Nottingham (nott...@redhat.com) said: Miloslav Trmač (m...@volny.cz) said: On Tue, Jan 31, 2012 at 1:06 AM, Martin Langhoff martin.langh...@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=09220fef36dcc2fe06bd858578119872f889c7e2 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
On Tue, Jan 31, 2012 at 4:52 PM, Bill Nottingham nott...@redhat.com wrote: Bill Nottingham (nott...@redhat.com) said: Miloslav Trmač (m...@volny.cz) said: On Tue, Jan 31, 2012 at 1:06 AM, Martin Langhoff martin.langh...@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=09220fef36dcc2fe06bd858578119872f889c7e2 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
Miloslav Trmač (m...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
On Tue, Jan 31, 2012 at 11:03 AM, Bill Nottingham nott...@redhat.com wrote: Miloslav Trmač (m...@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.langh...@gmail.com mar...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
On Tue, 2012-01-31 at 11:03 -0500, Bill Nottingham wrote: Miloslav Trmač (m...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
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.bierf...@lowlatency.de signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
What would be the pros/cons of a bind mount instead of a soft link for /bin et al? gene -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
On Tue, 2012-01-31 at 10:52 -0500, Bill Nottingham wrote: Bill Nottingham (nott...@redhat.com) said: Miloslav Trmač (m...@volny.cz) said: On Tue, Jan 31, 2012 at 1:06 AM, Martin Langhoff martin.langh...@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=09220fef36dcc2fe06bd858578119872f889c7e2 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
On Tue, 2012-01-31 at 11:03 -0500, Bill Nottingham wrote: Miloslav Trmač (m...@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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
James Antill (ja...@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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
Bill Nottingham (nott...@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) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
On Tue, 2012-01-31 at 15:58 -0500, Bill Nottingham wrote: James Antill (ja...@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). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
On Tue, Jan 31, 2012 at 23:36, Adam Williamson awill...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
On Fri, Jan 27, 2012 at 10:10 PM, Harald Hoyer har...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
-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- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
On Fri, Jan 27, 2012 at 8:10 AM, Harald Hoyer har...@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.langh...@gmail.com mar...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
-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-
156,157c156,164
echo Set autorelabel flag.
$ROOT/.autorelabel
---
. $ROOT/etc/selinux/config
if [ $SELINUX != disabled ]; then
echo Fixing SELinux lables
if [ $SELINUX != disabled ]; then
echo Fixing SELinux lables
/usr/sbin/setfiles -r $ROOT -p /etc/selinux/${SELINUXTYPE}/contexts/files/file_contexts $ROOT/sbin $ROOT/bin $ROOT/lib $ROOT/lib64 $ROOT/usr/lib $ROOT/usr/lib64 $ROOT/etc/ld.so.cache $ROOT/var/cache/ldconfig
fi
fi
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
Martin Langhoff (martin.langh...@gmail.com) said: On Fri, Jan 27, 2012 at 8:10 AM, Harald Hoyer har...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
On Mon, Jan 30, 2012 at 3:47 PM, Bill Nottingham nott...@redhat.com wrote: Assuming /bin - /usr/bin link is packaged, yes. Wow, it follows the symlink created by a 3rd package. clever, m -- martin.langh...@gmail.com mar...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
Martin Langhoff (martin.langh...@gmail.com) said: On Mon, Jan 30, 2012 at 3:47 PM, Bill Nottingham nott...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
On Mon, 2012-01-30 at 15:47 -0500, Bill Nottingham wrote: Martin Langhoff (martin.langh...@gmail.com) said: On Fri, Jan 27, 2012 at 8:10 AM, Harald Hoyer har...@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). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
On Jan 30, 2012 5:37 PM, James Antill ja...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
On Tue, Jan 31, 2012 at 1:06 AM, Martin Langhoff martin.langh...@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=09220fef36dcc2fe06bd858578119872f889c7e2 As you say, ugh!. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
-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- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
On Fri, Jan 27, 2012 at 5:57 PM, John Ellson john.ell...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
On 01/28/2012 06:48 AM, Josh Boyer wrote: On Fri, Jan 27, 2012 at 5:57 PM, John Ellsonjohn.ell...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
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? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora 17’s unified filesystem (/usr-move)
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 t...@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
Re: Fedora 17’s unified filesystem (/usr-move)
Am 27.01.2012 14:10, schrieb Harald Hoyer: ... Download and install the most recent dracut package from rawhide: # yum --enablerepo=rawhide update dracut ... you should have at least: dracut-014-77.git20120126.fc17 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
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 n...@redhat.com nor Safety. -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
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! :-) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
-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 t...@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
Re: Fedora 17’s unified filesystem (/usr-move)
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 mschm...@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.htmlhttp://lists.fedoraproject.org/pipermail/devel/2012-January/161530.html Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.**org/mailman/listinfo/develhttps://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
