FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 08-30-2012, 12:34 AM
 
Default Stuff from /bin, /sbin, /lib depending on /usr/lib libraries

On Aug 30, Russ Allbery <rra@debian.org> wrote:

> And yet, when we discussed this just a little bit ago, several people
> asked to keep the distinction because, for them, it provides value.
A few people ask for silly things all the time, but this in itself is
not a good enough reason to satisfy their requests.

> I think there's an open question on whether it's worth the effort to
> support use cases for a separate /usr, but people aren't saying to keep
> support for a separate /usr just out of meaningless consistency or because
> they want other developers to waste time.
Yes, the most popular argument was "I have always done it this way and
I will reject alternative solutions to my needs".

--
ciao,
Marco
 
Old 08-30-2012, 12:59 AM
Russ Allbery
 
Default Stuff from /bin, /sbin, /lib depending on /usr/lib libraries

md@Linux.IT (Marco d'Itri) writes:
> On Aug 30, Russ Allbery <rra@debian.org> wrote:

>> And yet, when we discussed this just a little bit ago, several people
>> asked to keep the distinction because, for them, it provides value.

> A few people ask for silly things all the time, but this in itself is
> not a good enough reason to satisfy their requests.

Sure, we can't do everything that provides value, or even maintain
everything we're currently doing that provides some value to someone. No
argument at all. But I think we need to say when we're making tradeoffs,
rather than asserting that there is no tradeoff because there is no value
in the alternative.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 877gshxkie.fsf@windlord.stanford.edu">http://lists.debian.org/877gshxkie.fsf@windlord.stanford.edu
 
Old 08-30-2012, 01:25 AM
Henrique de Moraes Holschuh
 
Default Stuff from /bin, /sbin, /lib depending on /usr/lib libraries

On Thu, 30 Aug 2012, Marco d'Itri wrote:
> On Aug 30, Michael Biebl <biebl@debian.org> wrote:
> > The obvious way is to not use a separate /usr anymore or simply mount
> > /usr via the initramfs.
> >
> > Wasn't there a patch for initramfs-tools floating around doing that?
> Yes, there is one but the maintainer has not applied or rejected it
> so far.
>
> Fellow developers, please do not waste your time moving stuff to /lib:
> it's a task both endless and futile because nowadays it is clear that
> the upstream maintainers of various stuff do not support a standalone
> /usr mounted by the init scripts: if /usr is a standalone file system
> then it must be mounted in the initramfs.

Yes, because after all, an outdated initramfs already craps all over your md
arrays and hoses the kernel and let's not even touch the root-on-lvm and
encrypted-root break-me-plenty scenarios. Why not make sure it will also
break the world if you change /etc/fstab [and forget to update the
initramfs] ?

It is getting to the point we will have to deploy machinery to actually
check whether the damn thing needs an update automatically using filesystem
monitors.

Fellow developers: if your stuff is in /bin or /sbin, and it needs something
that is currently in /usr, take a long breath, and think VERY HARD whether
your stuff should be in /bin or /sbin in the first place. If it *does* have
to live in /, think EXTREMELY HARD whether it should depend on the stuff
that is in /usr (hint: no linking to bling or overly complex crap on
mission-critical early userspace stuff!).

As for PAM, AFAIK neither sulogin nor anything important for early userspace
will care. IMHO, that means it could move to /usr if it wanted, or we could
just leave it as-is: it does NOT matter whether it works or not with a
separate /usr if it is only used after /usr is available in the first place
and it is of no help in a disaster recovery scenario.

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120830012523.GA22084@khazad-dum.debian.net">http://lists.debian.org/20120830012523.GA22084@khazad-dum.debian.net
 
Old 08-30-2012, 03:44 AM
Thomas Goirand
 
Default Stuff from /bin, /sbin, /lib depending on /usr/lib libraries

On 08/30/2012 07:15 AM, Marco d'Itri wrote:
> nowadays it is clear that
> the upstream maintainers of various stuff do not support a standalone
> /usr mounted by the init scripts: if /usr is a standalone file system
> then it must be mounted in the initramfs.
>
Instead of advertizing about (hostile) upstream's (bad) design and
decisions, you might as well, as the maintainer of udev, find ways
around this non-sense and uncruft all this. This would be a lot more
productive than acting as a lemming following every stupid decision
of RedHat, and in the process give us choices in how we setup things
(like using RAID and LVM to store /usr while still being to use an
early boot (recovery) system in / without it).

Thomas


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 503EE1B5.1080006@debian.org">http://lists.debian.org/503EE1B5.1080006@debian.org
 
Old 08-30-2012, 05:59 AM
Ben Hutchings
 
Default Stuff from /bin, /sbin, /lib depending on /usr/lib libraries

On Wed, 2012-08-29 at 22:25 -0300, Henrique de Moraes Holschuh wrote:
> On Thu, 30 Aug 2012, Marco d'Itri wrote:
> > On Aug 30, Michael Biebl <biebl@debian.org> wrote:
> > > The obvious way is to not use a separate /usr anymore or simply mount
> > > /usr via the initramfs.
> > >
> > > Wasn't there a patch for initramfs-tools floating around doing that?
> > Yes, there is one but the maintainer has not applied or rejected it
> > so far.
> >
> > Fellow developers, please do not waste your time moving stuff to /lib:
> > it's a task both endless and futile because nowadays it is clear that
> > the upstream maintainers of various stuff do not support a standalone
> > /usr mounted by the init scripts: if /usr is a standalone file system
> > then it must be mounted in the initramfs.
>
> Yes, because after all, an outdated initramfs already craps all over your md
> arrays and hoses the kernel and let's not even touch the root-on-lvm and
> encrypted-root break-me-plenty scenarios. Why not make sure it will also
> break the world if you change /etc/fstab [and forget to update the
> initramfs] ?
[...]

I don't believe anyone proposed to copy /etc/fstab into the initramfs.
We can just as well read it directly once we've mounted the 'real root'.

Ben.

--
Ben Hutchings
Quantity is no substitute for quality, but it's the only one we've got.
 
Old 08-30-2012, 06:04 AM
Ben Hutchings
 
Default Stuff from /bin, /sbin, /lib depending on /usr/lib libraries

On Thu, 2012-08-30 at 11:44 +0800, Thomas Goirand wrote:
> On 08/30/2012 07:15 AM, Marco d'Itri wrote:
> > nowadays it is clear that
> > the upstream maintainers of various stuff do not support a standalone
> > /usr mounted by the init scripts: if /usr is a standalone file system
> > then it must be mounted in the initramfs.
> >
> Instead of advertizing about (hostile) upstream's (bad) design and
> decisions, you might as well, as the maintainer of udev, find ways
> around this non-sense and uncruft all this.

And I suppose Marco must remove all /usr dependencies from everything
that installs a udev hook too?

> This would be a lot more
> productive than acting as a lemming following every stupid decision
> of RedHat, and in the process give us choices in how we setup things
> (like using RAID and LVM to store /usr while still being to use an
> early boot (recovery) system in / without it).

The initramfs is your early boot system.

Ben.

--
Ben Hutchings
Quantity is no substitute for quality, but it's the only one we've got.
 
Old 08-30-2012, 11:03 AM
Henrique de Moraes Holschuh
 
Default Stuff from /bin, /sbin, /lib depending on /usr/lib libraries

On Wed, 29 Aug 2012, Ben Hutchings wrote:
> On Wed, 2012-08-29 at 22:25 -0300, Henrique de Moraes Holschuh wrote:
> > On Thu, 30 Aug 2012, Marco d'Itri wrote:
> > > On Aug 30, Michael Biebl <biebl@debian.org> wrote:
> > > > The obvious way is to not use a separate /usr anymore or simply mount
> > > > /usr via the initramfs.
> > > >
> > > > Wasn't there a patch for initramfs-tools floating around doing that?
> > > Yes, there is one but the maintainer has not applied or rejected it
> > > so far.
> > >
> > > Fellow developers, please do not waste your time moving stuff to /lib:
> > > it's a task both endless and futile because nowadays it is clear that
> > > the upstream maintainers of various stuff do not support a standalone
> > > /usr mounted by the init scripts: if /usr is a standalone file system
> > > then it must be mounted in the initramfs.
> >
> > Yes, because after all, an outdated initramfs already craps all over your md
> > arrays and hoses the kernel and let's not even touch the root-on-lvm and
> > encrypted-root break-me-plenty scenarios. Why not make sure it will also
> > break the world if you change /etc/fstab [and forget to update the
> > initramfs] ?
> [...]
>
> I don't believe anyone proposed to copy /etc/fstab into the initramfs.
> We can just as well read it directly once we've mounted the 'real root'.

Hmm, indeed we can. Don't I feel stupid right now...

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120830110343.GA4489@khazad-dum.debian.net">http://lists.debian.org/20120830110343.GA4489@khazad-dum.debian.net
 
Old 08-30-2012, 07:39 PM
Steve Langasek
 
Default Stuff from /bin, /sbin, /lib depending on /usr/lib libraries

Hi Russ,

On Wed, Aug 29, 2012 at 04:06:22PM -0700, Russ Allbery wrote:
> Michael Biebl <biebl@debian.org> writes:

> > Imho moving pam modules around is just wasted (maintainer) time.
> > A much more sensible approach is to just lift the /-vs-/usr restriction.

> We just had a long discussion about this. I think it's fairly safe to say
> that while there are a number of people who think the distinction is not
> particularly meaningful, there are others who still use it for various
> reasons, and there's no consensus for doing this right now.

Much of this lack of consensus comes down to a misunderstanding of the
actual parameters.

The Fedora implementation does not require us to drop support for /usr as a
separate filesystem. It only requires us to ensure /usr is mounted before
init is started.

- /usr as a separate filesystem mounted from an initramfs: supported
- /usr on the root filesystem: supported
- /usr on a separate filesystem without the use of an initramfs: not
supported... and no discernable user demand for this.

My knee-jerk reaction to the Fedora proposal had been that it was sick and
wrong and would cause unacceptable breakage for users on upgrades if Debian
adopted the same plan. However, I struggled to formulate a concrete
scenario where losing support for that last configuration would actually
make a difference.

No one in the various threads on debian-devel has presented such a scenario.
They've all been arguing the straw man that "/usr as a separate fs is not
supported", which is not what's on the table.

I brought this topic up for discussion at the last Ubuntu Developer Summit
as well; there again, no one was able to come up with a real use case that
is not handled by the Fedora design.

So Ubuntu is intending to follow suit on this and mount /usr from the
initramfs. It's just not worth the effort to do otherwise - and up to this
point, Ubuntu actually has done the work to make sure /lib was
self-contained for boot, so we do have some experience there with how much
work is actually required (and btw, some experience with how quick Debian
maintainers are to pick up the related fixes, since many of the changes were
forwarded to Debian and sat for quite a while without being merged). It's
not just the one-time effort to change the packaging, either; remember that
the *-dev* package has to always go to /usr/lib even if the *runtime*
library goes to /lib, which causes some maintenance overhead in splitting
the files this finely (i.e., debian/rules basically needs some horrible code
to re-make symlinks dynamically). As I recall, e2fsprogs and util-linux in
particular have required some real ongoing effort to maintain this split
correctly, and I've seen plenty of packages getting this wrong and putting
.so symlinks in /lib (where ld doesn't see them!), or worse, .a files,
defeating the purpose of a small / partition.

This, plus the extensive upstream use (IMHO misuse) of software installed to
/usr as part of udev rules, means that in reality an ever increasing number
of libraries need to be shipped in /lib to properly handle bootstrapping the
mount of /usr using only the contents of /.

In contrast, if we use an initramfs to handle mounting of /usr, we move all
the complexity out of the packaging and instead pull components into the
small initramfs only as needed. As far as I've been able to determine,
there really is no downside to the user from making this switch.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
 
Old 08-30-2012, 10:27 PM
Steve Langasek
 
Default Stuff from /bin, /sbin, /lib depending on /usr/lib libraries

On Thu, Aug 30, 2012 at 12:11:44AM +0100, Roger Leigh wrote:
> > > [Russ Allbery]
> > >> All PAM modules are installed under /lib, because that's the path
> > >> used by libpam to load them. However, I don't think the vast
> > >> majority of PAM modules could be considered critical for early boot
> > >> or need to be usable without /usr mounted

> > > It seems pam already looks in both /lib/security and /lib/{triplet}/security.
> > > Why not add /usr/lib/{triplet}/security to the mix?

> > Imho moving pam modules around is just wasted (maintainer) time.
> > A much more sensible approach is to just lift the /-vs-/usr restriction.
> > The obvious way is to not use a separate /usr anymore or simply mount
> > /usr via the initramfs.

> > Wasn't there a patch for initramfs-tools floating around doing that?

> I started looking into it while doing the /run-in-initramfs stuff
> last year, but didn't get anything working at the time--initramfs-
> tools needs refactoring to remove the assumption that only one
> filesystem will be mounted, before we can mount /usr as well
> (and also maybe /etc).

Supporting /etc on a separate filesystem from / violates half a dozen
invariants that the Fedora design lets us retain. We should absolutely not
do this.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
 
Old 08-31-2012, 03:39 AM
Serge
 
Default Stuff from /bin, /sbin, /lib depending on /usr/lib libraries

2012/8/30 Michael Biebl wrote:

>> All PAM modules are installed under /lib, because that's the path
>> used by libpam to load them. However, I don't think the vast
>> majority of PAM modules could be considered critical for early boot
>> or need to be usable without /usr mounted

> Imho moving pam modules around is just wasted (maintainer) time.

Are they needed to mount other filesystems? Are they needed for `root`
user to log in? If not, why bother? (see a long explanation below)

> A much more sensible approach is to just lift the /-vs-/usr restriction.
> The obvious way is to not use a separate /usr anymore or simply mount
> /usr via the initramfs.

It doesn't really solve a problem, it just turns one problem into
another one. I'll try to put some details in.

It was long time ago, there may be some mistakes in my explanation,
please correct me if they are.

Many (most?) major successes in IT history were about inventing a good
standard communication interface to do things. IBM PC was successful
because it could be assembled from standard easily accessible components,
and was easy to upgrade by just replacing those components with newer
ones. That worked so good because there were standard interfaces for
devices (ISA, PCI, AGP, etc).

Similar things happened to the systems, installed on IBM PC. For many years
typical OS booting looked very simple: BIOS just executes first 512 bytes
of HDD (MBR, aka Master Boor Record) and it did not care what those bytes
do. That simple idea allowed to install any OS, one just had to wrote its
OS loader into MBR. And that made it possible to write many different OSes,
which brought more success to BIOS approach and IBM PC.

Then the dual(multi)-boot idea arose. To make it possible to install several
systems there came boot loaders (I've seen some ancient DOS-time boot
managers but don't remember their names any more). They also worked for
UNIXes (and linux). Boot loader just started OS kernel and did not care what
it's going to do next.

POSIX was so great that it allowed a great idea of network file systems.
Each machine did not have to contain everything locally any more, it could
just have a bare minimum, and mount everything else from a local server.
For linux it meant that kernel mounts a small root partition, which in turn
mounts everything else.

Kernel, obviously had to reach its root partition. Thus all the disk
controllers drivers and filesystem modules had to be built into the kernel.
When one wanted to change disk controller he had to rebuild the kernel,
otherwise kernel could not get to root filesystem. That was not good, so
initrd came to the rescue. It was basically a small root-like image, it's
only goal was to help kernel reach the root partition (which could mount
everything else anyway).

All this turns into a standard boot sequence:
1. BIOS runs boot loader
2. Boot loader boots kernel (optionally with initrd/initramfs)
3. Kernel mounts root partition (/)
4. Root partition mounts everything else (/usr, /var, /home, /srv, /opt...)
5. Then all the programs are started
And each of these steps appeared for a reason.

This standard boot sequence brought a great flexibility and allowed people
to turn their systems into whatever they need. Separation between steps was
very clear:
* Things that might be needed to mount other filesystems belong to /.
* Things needed to reach / belong to initrd.
* If something does not mount, admin must be able to log in and check/fix
things (that's why /root is not /home/root).
That allowed a small (even read-only) root partition that should probably
never break because of power outage, which is good for servers.

Everything was good. The problem came from the Internet and network-mounted
filesystems. Modern networks allow to mount filesystems using nfs/samba,
and an Internet connection to do that could be brought up with help of such
things as network manager, wpa_supplicant, usb_modeswitch, and so on. So
the problem is that if we continue to literally follow that separation
("things that might be needed to mount other filesystems belong to /")
we should put more and more software to /, thus defeating the purpose of
good small root partition.

And here comes the question: where to put new programs, to / or somewhere
else (/usr, or maybe /opt)? Things were even worse because almost nobody
remembers anymore what this separation was used for.

Then a radical suggestion appeared: since nobody remembers why it was done
that way, change the historical sequence and merge #4 into #3, by having
initramfs mount not just root partition but also mount /usr (and then even
move /s?bin to /usr). But it does not really solves the problem. It just
turns the question "what should be a part of the root partition" into
question "what should be a part of initramfs".

This approach has an advantage: initramfs can be generated dynamically, so
one can dynamically rebuild it including required network stuff there. But
it also have major disadvantage — it's limited by the initramfs size (which
is much smaller then root partition and can support fewer boot options),
thus it reduces flexibility, breaking use cases, that were working before.
And, which is more important, it still does not solve the initial problem.
For example if filesystem is supposed to be network-mounted, and network is
brought by the user, which logs into GNOME session and manually selects wifi
connection in nm-applet, initramfs still does not help there, since you
can't put entire gnome session into initramfs anyway.

Either historical or new radical approach is chosen — they both are limited.
None of them can support all possible cases of network mounting.
But at least one of these approaches should be supported.
Having none of them working is kind of pointless.

I suggest:
1. Define (implicitly or explicitly) where we would allow to mount subroot
filesystems from (that decision mainly affects /usr and partially /var,
/home and others) and what tools are needed to do that.
2. Make sure that all the tools from #1 are on / partition.
3. Make sure that everything required for `root` user to login (and do basic
stuff, i.e. move files, read logs and edit scripts) is on / partition.
4. Don't move anything else around — unless it fixes something,
it will just add more bugs and more problems for users.

These steps are rather easy, and make sure that at least historical
approach is fully supported.

--
Serge


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/CAOVenEpAOYEKRgJ=XpCh59q4bQnSf+9jwX9vSOmS6-zw5FYHsA@mail.gmail.com
 

Thread Tools




All times are GMT. The time now is 04:06 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org