Red Hat is moving from / to /usr/
http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=12a362be5c1982f80dbfb75bda070208a2c99cdf Discuss. -- ciao, Marco signature.asc Description: Digital signature
Re: Red Hat is moving from / to /usr/
On Wed, 07 Dec 2011 at 01:43:34 +0100, Marco d'Itri wrote: > http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=12a362be5c1982f80dbfb75bda070208a2c99cdf > > Discuss. As far as I can make out, their position is that a separate /usr is now only supported if you mount it from the initrd - which to be honest seems a reasonable way to keep existing separate-/usr systems working, without defeating the "/ is small" justification for a separate /usr by gradually migrating more and more of /usr into the root filesystem. It doesn't really address the "/ as recovery system" use of a separate /usr if your root filesystem can't boot unaided, but I'm far from convinced that a separate /usr makes / significantly more reliable, and an entirely separate installation (Debian Live on removable media, or a smaller Debian install in a separate partition that isn't normally even mounted) makes an even more reliable recovery system. S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111207090035.ga12...@reptile.pseudorandom.co.uk
Re: Red Hat is moving from / to /usr/
m...@linux.it (Marco d'Itri) writes: > http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=12a362be5c1982f80dbfb75bda070208a2c99cdf > > Discuss. > > -- > ciao, > Marco Give everyone at least 10 years headstart to migrate existing systems away from having a seperate /usr partition and for people to stop making a seperate /usr on new installs. If you do this in Debian now a large portion of systems will self destruct because /usr is a seperate partition and you will be tared and feathered. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87hb1cog5a.fsf@frosties.localnet
Re: Red Hat is moving from / to /usr/
On Dec 07, Goswin von Brederlow wrote: > Give everyone at least 10 years headstart to migrate existing systems > away from having a seperate /usr partition and for people to stop making > a seperate /usr on new installs. Actually, Red Hat's goal *is* to support a separate /usr, they just want to have the initramfs mount it. I am not really looking forward to keep reverting these changes in my package, and since Red Hat controls most Linux infrastructure now other packages will face the same problem. -- ciao, Marco signature.asc Description: Digital signature
Re: Red Hat is moving from / to /usr/
On Wed, Dec 07, 2011 at 11:34:34AM +0100, Marco d'Itri wrote: Actually, Red Hat's goal *is* to support a separate /usr, they just want to have the initramfs mount it. But as was seen in the last discussion, not everyone *has* an initramfs, because it is not needed in many cases or sometimes even not supported on the platform. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | signature.asc Description: Digital signature
Re: Red Hat is moving from / to /usr/
On Wed, 7 Dec 2011 09:00:35 +, Simon McVittie wrote: > On Wed, 07 Dec 2011 at 01:43:34 +0100, Marco d'Itri wrote: > > http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=12a362be5c1982f80dbfb75bda070208a2c99cdf > > > > Discuss. > > As far as I can make out, their position is that a separate /usr is now only > supported if you mount it from the initrd - which to be honest seems a > reasonable way to keep existing separate-/usr systems working, without > defeating the "/ is small" justification for a separate /usr by gradually > migrating more and more of /usr into the root filesystem. > > It doesn't really address the "/ as recovery system" use of a separate /usr > if your root filesystem can't boot unaided, but I'm far from convinced that > a separate /usr makes / significantly more reliable, and an entirely > separate installation (Debian Live on removable media, or a smaller Debian > install in a separate partition that isn't normally even mounted) makes an > even more reliable recovery system. The problem with such rescue partitions is that if anything about your setup is peculiar, then they are likely to rot in a way that ensures that they will no longer support new features of the installed kernel on the machine to be rescued. Likewise, if you've had to build a custom kernel to support your hardware, then default rescue media may well not help you. RedHat can probably safely ignore that, because their users are not quite as inventive as ours, and they're only really trying to address the middle of the bell-curve anyway. That leaves us with disproportionately more odd use cases, because they're not being catered for by the commercial distros. Also, as far as I've seen the default method for fixing RedHat systems is to pop in a rescue disk (at least when I was an RHCX that was certainly the suggested approach in their exams for many of the failure modes). If that is the default solution anyway, then making it impossible to use other recovery methods is not so much of a leap. Personally, I think that resorting to rescue media is something of an admission of defeat, but I'm probably a bit odd ;-) I seem to occasionally find myself in situations where the machine that's failed is the one that you'd use for downloading or burning the rescue media, or for building the custom kernel needed for the hardware, so that I'd have real pain if my only solution was getting hold of a matching rescue disk. People using ARM seems likely to make this situation more likely, as there seem to be way to many flavours of ARM. Having said all that, it would be nice if we made the default setup include a rescue partition, with hooks to ensure that kernels are updated on the rescue partition (preferable after the system successfully boots with the new kernel, say), and it's generally kept happy and ready for use. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND pgpRaIscqxrrt.pgp Description: PGP signature
Re: Red Hat is moving from / to /usr/
07.12.2011 04:43, Marco d'Itri пишет: > http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=12a362be5c1982f80dbfb75bda070208a2c99cdf > > Discuss. > I don't see any reason to move all into /usr from /, and make initrd for minimal system: Making self-contained initrd is the same problem as making self-contained / So why overhead? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4edf4f21.7090...@gmail.com
Re: Red Hat is moving from / to /usr/
On Dec 07, Stephan Seitz wrote: > But as was seen in the last discussion, not everyone *has* an > initramfs, because it is not needed in many cases or sometimes even > not supported on the platform. And as was seen, most of these setups can be modified to support this scheme. I also have a few ideas about how to support systems whose boot loaders do not support loading an initramfs, does anybody have a list of them? But still, this does not change the original question: how will we deal with these significant upstream changes in many important packages. -- ciao, Marco signature.asc Description: Digital signature
Re: Red Hat is moving from / to /usr/
On Wed, Dec 07, 2011 at 01:11:56PM +0100, Marco d'Itri wrote: On Dec 07, Stephan Seitz wrote: But as was seen in the last discussion, not everyone *has* an initramfs, because it is not needed in many cases or sometimes even not supported on the platform. And as was seen, most of these setups can be modified to support this scheme. Yes, but by the admin, not by Debian, and the admin may not be interested in adding a new layer of possible failures, because it works. But still, this does not change the original question: how will we deal with these significant upstream changes in many important packages. Well, I think we should do the same we are doing with other packages whose upstream uses thinks we don’t want (e.g. /opt or non-free files): we patch it so that it fits the Debian way. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | signature.asc Description: Digital signature
Re: Red Hat is moving from / to /usr/
On Dec 07, Stephan Seitz wrote: > Yes, but by the admin, not by Debian, and the admin may not be > interested in adding a new layer of possible failures, because it > works. And other admins may be interested in the important features which everything-in-usr supports. Who is going to win? > Well, I think we should do the same we are doing with other packages > whose upstream uses thinks we don’t want (e.g. /opt or non-free > files): we patch it so that it fits the Debian way. This may not be practical in the long run, or even possible. -- ciao, Marco signature.asc Description: Digital signature
Re: Red Hat is moving from / to /usr/
On 12/07/2011 07:03 PM, Philip Hands wrote: > > Personally, I think that resorting to rescue media is something of an > admission of defeat, but I'm probably a bit odd ;-) > You're not Phil, I agree with the above statement! Thomas (zigo) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4edf5ddd.6010...@debian.org
Re: Red Hat is moving from / to /usr/
On 2011-12-07, Philip Hands wrote: > Personally, I think that resorting to rescue media is something of an > admission of defeat, but I'm probably a bit odd ;-) I recent followed a recovery in a irc channel after installing a wrong-architecture libc on a system. Only access was 2 existing root consoles. Recovering involved - a base64 decoder written in shell - a statically linked busybox - overwriting /bin/ln - /bin/ln /bin/ln /bin/busybox recovery would have been much faster if a rescue media was available, but there was several thousands km between the sysadm and the box. /Sune -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnjdup4m.p7v.nos...@sshway.ssh.pusling.com
Re: Red Hat is moving from / to /usr/
On Wed, Dec 07, 2011 at 01:44:28PM +0100, Marco d'Itri wrote: On Dec 07, Stephan Seitz wrote: Yes, but by the admin, not by Debian, and the admin may not be interested in adding a new layer of possible failures, because it works. And other admins may be interested in the important features which everything-in-usr supports. Who is going to win? If this is the future way and the way the developer want to go, then the way will succeed in time, but as Goswin said, it will take time. The admins who think the new way is bad will not change their systems. New admins may think otherwise, and if the old server will be replaced, they change the system to the new way. Of course, Redhat admins can be forced to change if they need the new version for their systems, but at least Debian does not work this way. Well, I think we should do the same we are doing with other packages whose upstream uses thinks we don’t want (e.g. /opt or non-free files): we patch it so that it fits the Debian way. This may not be practical in the long run, or even possible. Yes, this may happen, but I think for about ten years we have to support both ways as best as we can. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | signature.asc Description: Digital signature
Re: Red Hat is moving from / to /usr/
On 12687 March 1977, Marco d'Itri wrote: > http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=12a362be5c1982f80dbfb75bda070208a2c99cdf > Discuss. Nice link, though using https would be oh-so-much-more-secure. [BLA] Maybe you should actually deliver some content to discuss and not expect everyone to be able to read your mind what you want with a random link. Or expect them to be online all the time they read mail. -- bye, Joerg [...] While Debian is certainly about beer, and in some cases may even be about free beer, Debian is mainly about free speech. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fwgwjeb8@gkar.ganneff.de
Re: Red Hat is moving from / to /usr/
Philip Hands writes: > On Wed, 7 Dec 2011 09:00:35 +, Simon McVittie wrote: >> On Wed, 07 Dec 2011 at 01:43:34 +0100, Marco d'Itri wrote: >> > http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=12a362be5c1982f80dbfb75bda070208a2c99cdf >> > >> > Discuss. >> >> As far as I can make out, their position is that a separate /usr is now only >> supported if you mount it from the initrd - which to be honest seems a >> reasonable way to keep existing separate-/usr systems working, without >> defeating the "/ is small" justification for a separate /usr by gradually >> migrating more and more of /usr into the root filesystem. >> >> It doesn't really address the "/ as recovery system" use of a separate /usr >> if your root filesystem can't boot unaided, but I'm far from convinced that >> a separate /usr makes / significantly more reliable, and an entirely >> separate installation (Debian Live on removable media, or a smaller Debian >> install in a separate partition that isn't normally even mounted) makes an >> even more reliable recovery system. > > The problem with such rescue partitions is that if anything about your > setup is peculiar, then they are likely to rot in a way that ensures > that they will no longer support new features of the installed kernel on > the machine to be rescued. Likewise, if you've had to build a custom > kernel to support your hardware, then default rescue media may well not > help you. > > RedHat can probably safely ignore that, because their users are not > quite as inventive as ours, and they're only really trying to address > the middle of the bell-curve anyway. That leaves us with > disproportionately more odd use cases, because they're not being catered > for by the commercial distros. > > Also, as far as I've seen the default method for fixing RedHat systems > is to pop in a rescue disk (at least when I was an RHCX that was > certainly the suggested approach in their exams for many of the failure > modes). If that is the default solution anyway, then making it > impossible to use other recovery methods is not so much of a leap. > > Personally, I think that resorting to rescue media is something of an > admission of defeat, but I'm probably a bit odd ;-) > > I seem to occasionally find myself in situations where the machine > that's failed is the one that you'd use for downloading or burning the > rescue media, or for building the custom kernel needed for the hardware, > so that I'd have real pain if my only solution was getting hold of a > matching rescue disk. People using ARM seems likely to make this > situation more likely, as there seem to be way to many flavours of ARM. > > Having said all that, it would be nice if we made the default setup > include a rescue partition, with hooks to ensure that kernels are > updated on the rescue partition (preferable after the system > successfully boots with the new kernel, say), and it's generally kept > happy and ready for use. > > Cheers, Phil. I have a bug open about a grml.deb that adds a grml boot entry to the systems bootloader. With that you would always have an uptodate live CD. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8762hr5suz.fsf@frosties.localnet
Re: Red Hat is moving from / to /usr/
m...@linux.it (Marco d'Itri) writes: > On Dec 07, Goswin von Brederlow wrote: > >> Give everyone at least 10 years headstart to migrate existing systems >> away from having a seperate /usr partition and for people to stop making >> a seperate /usr on new installs. > Actually, Red Hat's goal *is* to support a separate /usr, they just want > to have the initramfs mount it. I guess mounting /usr is no more complicated than mounting / in initramfs. Finding out what modules and software is needed for that should be the same code as for /. And maybe that would at least give incentive to finally add fsck support to initramfs. Doing fsck on a mounted filesystem always sucks and you need to reboot on any change. Personally I've considered giving up a seperate /usr partition. Since I switched to Debian kernels (something I actually regretted the last days because alt-sysrq is bastardised in Debian) the / isn't that small anymore. And we are finally getting to a point where read-only / works out-of-the-box so /usr doesn't have to be seperate to be read-only. > I am not really looking forward to keep reverting these changes in my > package, and since Red Hat controls most Linux infrastructure now other > packages will face the same problem. One more reason to get away from udev. :) MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y5un4dqk.fsf@frosties.localnet
Re: Red Hat is moving from / to /usr/
Igor Pashev writes: > 07.12.2011 04:43, Marco d'Itri пиÑеÑ: >> http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=12a362be5c1982f80dbfb75bda070208a2c99cdf >> >> Discuss. >> > > I don't see any reason to move all into /usr from /, > and make initrd for minimal system: > > Making self-contained initrd is the same problem > as making self-contained / > > So why overhead? One problem for a "minimal" / is that there are so many different setups there, even more for Debian than for RH, and minimal has so many different meanings. Because of that more and more stuff has ended up in / over the years and it isn't quite so minimal anymore. The initramfs on the other hand is made to fit. So if /usr isn't on a networking filesystem (NFS) then you won't get networking stuff in the initramfs. No raid then mdadm isn't included. No lvm and the initramfs gets smaller again. And only select modules for one kernel are in there. Huge space saving again. So an initramfs will/can be minimal. The initramfs only needs to be self-contained for exactly one use case. The one where it is building on. The / needs to be self contained for every crazy setup any Debian user can think of. And initramfs is configurable by the admin. If something is missing he can add it. Properly fixing a not self-contained / on the other hand is difficult. So I don't agree that making a self-contained / is the same problem as making a self-contained initramfs. On the other hand initialy making initramfs support all the crazy things people do with /usr will be fun. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ty5b4d0r.fsf@frosties.localnet
Re: Red Hat is moving from / to /usr/
On Thu, Dec 08, 2011 at 10:25:07AM +0100, Goswin von Brederlow wrote: I guess mounting /usr is no more complicated than mounting / in initramfs. Finding out what modules and software is needed for that should be the same code as for /. That depends. I have some systems where all file systems except /boot are encrypted. Since I don’t use Debian kernels and initramfs, I created a small one myself to ask for the /-partition password. Now I would have to put the whole LVM stuff into it, because /usr is on a LVM (/ is not). So it is more complicated. One more reason to get away from udev. :) Yes, I think too, that udev sucks. Instead of merging / and /usr, udev should be enhanced to support runlevels (at least the difference between the early boot stage / single user and the multiuser mode). There is no need to configure the sound card mixer at the early boot stage, and so forcing the user to have /usr on the /-partition. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | signature.asc Description: Digital signature
Re: Red Hat is moving from / to /usr/
On Thu, 08 Dec 2011 at 11:06:46 +0100, Stephan Seitz wrote: > That depends. I have some systems where all file systems except > /boot are encrypted. Since I don’t use Debian kernels and initramfs, > I created a small one myself to ask for the /-partition password. > Now I would have to put the whole LVM stuff into it, because /usr is > on a LVM (/ is not). Debian's initramfs knows how to do this; d-i can even set it up for you automatically. (My rootfs is in LVM over an encrypted partition; I believe putting the stacking the other way round, so you have one or more encrypted LVs in otherwise-unencrypted LVM, also works.) Of course, if you decide to replace Debian's kernel/initramfs infrastructure, the down side of that is that you get to replace Debian's kernel/initramfs infrastructure... S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111208111331.gb23...@reptile.pseudorandom.co.uk
Re: Red Hat is moving from / to /usr/
08.12.2011 13:40, Goswin von Brederlow пишет: Igor Pashev writes: 07.12.2011 04:43, Marco d'Itri пишет: http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=12a362be5c1982f80dbfb75bda070208a2c99cdf Discuss. I don't see any reason to move all into /usr from /, and make initrd for minimal system: Making self-contained initrd is the same problem as making self-contained / So why overhead? One problem for a "minimal" / is that there are so many different setups there, even more for Debian than for RH, and minimal has so many different meanings. Because of that more and more stuff has ended up in / over the years and it isn't quite so minimal anymore. The initramfs on the other hand is made to fit. So if /usr isn't on a networking filesystem (NFS) then you won't get networking stuff in the initramfs. No raid then mdadm isn't included. No lvm and the initramfs gets smaller again. And only select modules for one kernel are in there. Huge space saving again. So an initramfs will/can be minimal. The initramfs only needs to be self-contained for exactly one use case. The one where it is building on. The / needs to be self contained for every crazy setup any Debian user can think of. And initramfs is configurable by the admin. If something is missing he can add it. Properly fixing a not self-contained / on the other hand is difficult. So I don't agree that making a self-contained / is the same problem as making a self-contained initramfs. On the other hand initialy making initramfs support all the crazy things people do with /usr will be fun. Goswin, thanks for the explanation. Now I'm inclined to move all to /usr :-) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ee0c591.3040...@gmail.com
Re: Red Hat is moving from / to /usr/
Stephan Seitz writes: > On Thu, Dec 08, 2011 at 10:25:07AM +0100, Goswin von Brederlow wrote: >>I guess mounting /usr is no more complicated than mounting / in >>initramfs. Finding out what modules and software is needed for that >>should be the same code as for /. > > That depends. I have some systems where all file systems except /boot > are encrypted. Since I donât use Debian kernels and initramfs, I > created a small one myself to ask for the /-partition password. Now I > would have to put the whole LVM stuff into it, because /usr is on a > LVM (/ is not). > > So it is more complicated. More complicated for YOUR setup. Not for initramfs-tools in general. What I mean is that there are already plenty of systems out there that have / on LVM. Initramfs-tools already knows when and how to include lvm. >>One more reason to get away from udev. :) > > Yes, I think too, that udev sucks. Instead of merging / and /usr, udev > should be enhanced to support runlevels (at least the difference > between the early boot stage / single user and the multiuser > mode). There is no need to configure the sound card mixer at the early > boot stage, and so forcing the user to have /usr on the /-partition. Hmm, adding the runlevel to the environment should be rather trivial. Couldn't you even add a rule (first rule to run) to query init for the runlevel and export it to the environment? And the rule that triggers configuring the soundcard could then match on the variable. This idea doesn't sound like it will need changes in udev itself. Just some configuration. > Shade and sweet water! > > Stephan MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pqfzdnlb.fsf@frosties.localnet
Re: Red Hat is moving from / to /usr/
Igor Pashev writes: > Goswin, thanks for the explanation. > Now I'm inclined to move all to /usr :-) We live to serve. :) I'm kind of undecided. I know eventualy this will just work and have eliminate all those "Hey, I have a strange setup and xyz needs to be in / for this" bugs. But I also am damn sure that it will break horribly inbetween. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874nxbdl3u.fsf@frosties.localnet
Re: Red Hat is moving from / to /usr/
On Wed, 2011-12-07 at 11:34:34 +0100, Marco d'Itri wrote: > I am not really looking forward to keep reverting these changes in my > package, and since Red Hat controls most Linux infrastructure now other > packages will face the same problem. I might be missing something but given the link your posted, and looking at the actual changes in the commit, I only see a change of default *with* support for the previous behaviour through configure options, so it would seem you only need to adapt your debian/rules. regards, guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111208174630.ga18...@gaara.hadrons.org
Re: Red Hat is moving from / to /usr/
On Dec 08, Guillem Jover wrote: > > I am not really looking forward to keep reverting these changes in my > > package, and since Red Hat controls most Linux infrastructure now other > > packages will face the same problem. > I might be missing something but given the link your posted, and looking > at the actual changes in the commit, I only see a change of default > *with* support for the previous behaviour through configure options, > so it would seem you only need to adapt your debian/rules. This is correct, but it is also another step towards requiring /usr to be available at the beginning of the boot process. Some (minor) parts of udev already have not worked for quite some time if /usr is not mounted. -- ciao, Marco signature.asc Description: Digital signature
Re: Red Hat is moving from / to /usr/
+++ Sune Vuorela [2011-12-07 13:05 +]: > > Recovering involved > - a base64 decoder written in shell > - a statically linked busybox uuencoded and pasted into the console > - overwriting /bin/ln > - /bin/ln /bin/ln /bin/busybox We all had hardcore geeking fun that afternoon :-) Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111208190039.gi28...@dream.aleph1.co.uk
Re: Red Hat is moving from / to /usr/
I demand that Stephan Seitz may or may not have written... > On Wed, Dec 07, 2011 at 11:34:34AM +0100, Marco d'Itri wrote: >> Actually, Red Hat's goal *is* to support a separate /usr, they just want >> to have the initramfs mount it. > But as was seen in the last discussion, not everyone *has* an initramfs, > because it is not needed in many cases or sometimes even not supported on > the platform. On any box for which I've built a kernel, there's no initramfs and (except in one case – netbook) there's a separate /usr. I'd quite like to keep it this way... / (without /usr) is often enough for rescue purposes (and if it isn't, it's enough to get /usr mounted). And if / is broken, then you have larger problems anyway. This mount-/usr/-in-initramfs looks to me like a means of reducing choice. -- | _ | Darren Salt, using Debian GNU/Linux (and Android) | ( ) | | X | ASCII Ribbon campaign against HTML e-mail | / \ | http://www.asciiribbon.org/ Take my advice, I'm not using it right now. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52455ef1f4%li...@youmustbejoking.demon.co.uk
Re: Red Hat is moving from / to /usr/
Darren Salt writes: > I demand that Stephan Seitz may or may not have written... > >> On Wed, Dec 07, 2011 at 11:34:34AM +0100, Marco d'Itri wrote: >>> Actually, Red Hat's goal *is* to support a separate /usr, they just want >>> to have the initramfs mount it. > >> But as was seen in the last discussion, not everyone *has* an initramfs, >> because it is not needed in many cases or sometimes even not supported on >> the platform. > > On any box for which I've built a kernel, there's no initramfs and (except in > one case â netbook) there's a separate /usr. I'd quite like to keep it this > way... To be honest most systems will have /usr localy and mounting it is no problem at all. So even with moving stuff from / to /usr it should not be a problem for them to mount /usr verry early during boot and have stuff keep working. I don't think anyone is considering moving /bin/mount just jet. > / (without /usr) is often enough for rescue purposes (and if it isn't, it's > enough to get /usr mounted). And if / is broken, then you have larger > problems anyway. > > This mount-/usr/-in-initramfs looks to me like a means of reducing choice. Or as a way to keep choices without complicating the standard case. If you do want to have a /usr mounted as NFS4 over wlan then you need an initramfs. If you have it as local partition then you don't. Consider it from that point of view. I'm still not for moving / to /usr but lets say I am less opposed now than I was at the initial mail. If it "breaks" less than 1% of setups and they need to use an initramfs to keep working then that is probably ok. Or another process that moves things to the / filesystem on a need by need basis. It MUST keep working though. Requiring that people repartition is no an option. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y5uj89gy.fsf@frosties.localnet
Re: Red Hat is moving from / to /usr/
On Thu, 08 Dec 2011 10:40:36 +0100 Goswin von Brederlow wrote: > Igor Pashev writes: > > > 07.12.2011 04:43, Marco d'Itri пишет: > >> http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=12a362be5c1982f80dbfb75bda070208a2c99cdf > >> > >> Discuss. > >> > > I don't see any reason to move all into /usr from /, > > and make initrd for minimal system: > The initramfs on the other hand is made to fit. So if /usr isn't on a > networking filesystem (NFS) then you won't get networking stuff in the > initramfs. No raid then mdadm isn't included. No lvm and the initramfs > gets smaller again. And only select modules for one kernel are in > there. Huge space saving again. So an initramfs will/can be minimal. I assume this means it will be impossible to swap the hdd from one system to another without rebuilding the initramfs? Seems like a step backwards for flexability. thanks, kk -- Karl Goetz, (Kamping_Kaiser / VK7FOSS) http://www.kgoetz.id.au No, I won't join your social networking group signature.asc Description: PGP signature
Re: Red Hat is moving from / to /usr/
On Mo, Dez 12, 2011 at 05:36:41 (CET), Karl Goetz wrote: [...] >> The initramfs on the other hand is made to fit. So if /usr isn't on a >> networking filesystem (NFS) then you won't get networking stuff in the >> initramfs. No raid then mdadm isn't included. No lvm and the initramfs >> gets smaller again. And only select modules for one kernel are in >> there. Huge space saving again. So an initramfs will/can be minimal. > > I assume this means it will be impossible to swap the hdd from one > system to another without rebuilding the initramfs? Seems like a step > backwards for flexability. Trimming the initramfs is an *optional* feature. cf. /etc/initramfs-tools/initramfs.conf Cheers, Reinhard -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87obve1cxw@faui43f.informatik.uni-erlangen.de
Re: Red Hat is moving from / to /usr/
Reinhard Tartler writes: > On Mo, Dez 12, 2011 at 05:36:41 (CET), Karl Goetz wrote: > > [...] > >>> The initramfs on the other hand is made to fit. So if /usr isn't on a >>> networking filesystem (NFS) then you won't get networking stuff in the >>> initramfs. No raid then mdadm isn't included. No lvm and the initramfs >>> gets smaller again. And only select modules for one kernel are in >>> there. Huge space saving again. So an initramfs will/can be minimal. >> >> I assume this means it will be impossible to swap the hdd from one >> system to another without rebuilding the initramfs? Seems like a step >> backwards for flexability. > > Trimming the initramfs is an *optional* feature. > > cf. /etc/initramfs-tools/initramfs.conf > > Cheers, > Reinhard If you swap the hdd from one system to another it doesn't suddenly start requiring raid support or need lvm. What can be a problem is suddenly missing the right module for the controler so no disk is found. This is something you already have for /. Including "mount /usr" in the initramfs in no way changes this. And default is, as Reinhard says, to build a big initramfs with lots of modules in there just in case. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87sjkphjxv.fsf@frosties.localnet
Re: Red Hat is moving from / to /usr/
On Mon, 12 Dec 2011 08:11:55 +0100 Reinhard Tartler wrote: > On Mo, Dez 12, 2011 at 05:36:41 (CET), Karl Goetz wrote: > > [...] > > >> The initramfs on the other hand is made to fit. So if /usr isn't > >> on a networking filesystem (NFS) then you won't get networking > >> stuff in the initramfs. No raid then mdadm isn't included. No lvm > >> and the initramfs gets smaller again. And only select modules for > >> one kernel are in there. Huge space saving again. So an initramfs > >> will/can be minimal. > > > > I assume this means it will be impossible to swap the hdd from one > > system to another without rebuilding the initramfs? Seems like a > > step backwards for flexability. > > Trimming the initramfs is an *optional* feature. > > cf. /etc/initramfs-tools/initramfs.conf Thanks for clearing that up. kk -- Karl Goetz, (Kamping_Kaiser / VK7FOSS) http://www.kgoetz.id.au No, I won't join your social networking group signature.asc Description: PGP signature
Re: options: was Red Hat is moving from / to /usr/
I'm a UN*X dinosaur. I started using UN*X in 1984. I don't like this idea of folding /bin, /sbin, /usr/sbin into /usr/bin. I think the reasons to segregate /bin, /sbin, /usr/bin, /usr/sbin and anything in /usr/local/* still exist today. I want more segregation, not less. Actually, I've wanted all the config for /usr to be in /etc/usr (which is a symlink to /usr/etc) for a long time. But, by the time anyone hear of efforts such as this, there seldom seems to be time to stop them. Hence, my question is, if this continues to happen, what do we move to for a kernel? Free-BSD? Plan 9? Something else? Is anyone working on a migration scheme? -- Gord -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201112121855.19263.ghave...@materialisations.com
Re: options: was Red Hat is moving from / to /usr/
On Mon, 2011-12-12 at 18:55 -0700, Gordon Haverland wrote: > I'm a UN*X dinosaur. I started using UN*X in 1984. > > I don't like this idea of folding /bin, /sbin, /usr/sbin into > /usr/bin. > > I think the reasons to segregate /bin, /sbin, /usr/bin, /usr/sbin > and anything in /usr/local/* still exist today. Which reasons? They changed from time to time. Last time I looked, on a Debian system /sbin did not contain statically-linked binaries. > I want more segregation, not less. Actually, I've wanted all the > config for /usr to be in /etc/usr (which is a symlink to /usr/etc) > for a long time. > > But, by the time anyone hear of efforts such as this, there seldom > seems to be time to stop them. > > Hence, my question is, if this continues to happen, what do we > move to for a kernel? Free-BSD? Plan 9? Something else? Is > anyone working on a migration scheme? FreeBSD userland is largely a throwback to the 90s, so it's probably just what you're looking for. Plan 9 has precisely the unification you so hate. Ben. -- Ben Hutchings Computers are not intelligent. They only think they are. signature.asc Description: This is a digitally signed message part
Re: options: was Red Hat is moving from / to /usr/
On Mon, Dec 12, 2011 at 06:55:18PM -0700, Gordon Haverland wrote: > I'm a UN*X dinosaur. I started using UN*X in 1984. > > I don't like this idea of folding /bin, /sbin, /usr/sbin into > /usr/bin. > > I think the reasons to segregate /bin, /sbin, /usr/bin, /usr/sbin > and anything in /usr/local/* still exist today. What are those reasons? I agree with /usr/local being separate, but /bin and /usr/bin? What is the advantage to having them separate on a running system? Other than historical practice? (http://lists.debian.org/debian-devel/2011/01/msg00152.html gives a bunch of historical uses which are no longer useful.) I don't agree with the Fedora strategy of migrating /bin to /usr/bin etc. I think if anything we should do what would make most sense in the long run, which would be to eliminate /usr entirely and most the content of /usr to /. Migrating to /usr is a bit simpler for partitioning, but not particularly logical. > I want more segregation, not less. Actually, I've wanted all the > config for /usr to be in /etc/usr (which is a symlink to /usr/etc) > for a long time. On a system managed with a package manager, this makes no sense-- the content of /usr is intimately tied to the content of /etc. In other contexts it might be useful, but for Debian it is not. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111213094451.ge17...@codelibre.net
