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 > Gentoo > Gentoo User

 
 
LinkBack Thread Tools
 
Old 03-27-2012, 09:24 PM
Alan Mackenzie
 
Default After /usr conflation: why not copy booting software to /sbin rather than initramfs?

Hi, Mike.

On Tue, Mar 27, 2012 at 03:56:01PM -0400, Mike Edenfield wrote:
> > From: che@chrekh.se [mailto:che@chrekh.se]

> > Neil Bothwick <neil@digimed.co.uk> writes:

> > > On Tue, 27 Mar 2012 14:26:46 +0000, Alan Mackenzie wrote:

> > >> > As you move more and more software off of /usr into / you start to
> > >> > realize that the idea of "tiny partition that contains just what I
> > >> > need to boot and mount /usr" is becoming "not so tiny" anymore. The
> > >> > distinction between what is "boot" software versus "user" software
> > >> > gets less clear.

> > >> Again, isn't this the same for an initramfs?

> > > No, because an initramfs only needs enough to mount / and /usr, then
> > > everything else comes from the usual source. If you're not using and
> > > fancy block devices, the initramfs only needs busybox and an init
> script.
> > > Even adding LVM, RAID and encryption only requires three more binaries
> > > - and those are all disposed of once switch_root is run and the tmpfs
> > > released.

> > The question remains. If it's possible to do that from an initramfs, then
> > shouldn't it be possible to put the same tools and binarias on /, and
> mount
> > /usr early?


I don't think you've understood the question - you certainly haven't
answered it.

> Yes , of course it's /possible/, it's just not /practical/.

Why not?

> Changing the contents of your initramfs is a decision you, as an admin, make
> that affects your system(s).

s%initramfs%/sbin%, then how does the sentence not apply?

> Changing the installed location of, say, udevd and bluetoothd and whatever
> other tools need to get pulled out of /usr is a decision that affects
> everyone who is using those packages. Changing the order of init scripts is
> an even bigger mess, but mostly because of the software requirements to make
> it function.

That is precisely what the question was NOT about. The idea was to copy
(not move) booting software to /sbin instead of an initramfs - the exact
same programs, modulo noise - to have the SW in /sbin necessary to mount
/usr.

Our loveable upstream suppliers are making us mount /usr early in the
boot process. Why can't this be done as well from /sbin as from
initramfs?

[ .... ]

> --Mike

--
Alan Mackenzie (Nuremberg, Germany).
 
Old 03-27-2012, 10:01 PM
Alan Mackenzie
 
Default After /usr conflation: why not copy booting software to /sbin rather than initramfs?

Hello, Neil.

On Tue, Mar 27, 2012 at 10:41:53PM +0100, Neil Bothwick wrote:
> On Tue, 27 Mar 2012 21:24:22 +0000, Alan Mackenzie wrote:

> > That is precisely what the question was NOT about. The idea was to copy
> > (not move) booting software to /sbin instead of an initramfs - the exact
> > same programs, modulo noise - to have the SW in /sbin necessary to mount
> > /usr.

> Your package manager only knows about the copy in the original location.

So? The same applies to a copy in the initramfs.

> When you update you'll have multiple versions of the same program or
> library in your path.

Well, with the manual/script copying which needs doing either for /sbin
or initramfs, that will be several copies of a program, not several
versions.

I'm still trying to see the reason why an /sbin with the same contents as
a putative initramfs won't work.

> --
> Neil Bothwick

--
Alan Mackenzie (Nuremberg, Germany).
 
Old 03-27-2012, 10:35 PM
Alan Mackenzie
 
Default After /usr conflation: why not copy booting software to /sbin rather than initramfs?

Hi, Alan.

On Tue, Mar 27, 2012 at 11:48:19PM +0200, Alan McKinnon wrote:
> On Tue, 27 Mar 2012 21:24:22 +0000
> Alan Mackenzie <acm@muc.de> wrote:

> > That is precisely what the question was NOT about. The idea was to
> > copy (not move) booting software to /sbin instead of an initramfs -
> > the exact same programs, modulo noise - to have the SW in /sbin
> > necessary to mount /usr.

> Two words:

> shared libraries

> Copying binaries is not enough. You have to find and copy every shared
> library those binaries use. Plus all the data and other files they
> might need.

> This is non-trivial.

<silently screams>. It's equally non-trivial for initramfs, yet nobody
seems to be raising this objection for that.

Why is nobody else on this thread willing to take up its main point, the
exact equivalence between the known, ugly, initramfs solution and the as
yet half-baked idea of putting the same binaries into /sbin?

> --
> Alan McKinnnon
> alan.mckinnon@gmail.com

--
Alan Mackenzie (Nuremberg, Germany).
 
Old 03-27-2012, 11:32 PM
Alan Mackenzie
 
Default After /usr conflation: why not copy booting software to /sbin rather than initramfs?

Hello again, Alan.

On Wed, Mar 28, 2012 at 12:39:27AM +0200, Alan McKinnon wrote:
> On Tue, 27 Mar 2012 22:01:28 +0000
> Alan Mackenzie <acm@muc.de> wrote:

> > Hello, Neil.

> > On Tue, Mar 27, 2012 at 10:41:53PM +0100, Neil Bothwick wrote:
> > > On Tue, 27 Mar 2012 21:24:22 +0000, Alan Mackenzie wrote:

> > > > That is precisely what the question was NOT about. The idea was
> > > > to copy (not move) booting software to /sbin instead of an
> > > > initramfs - the exact same programs, modulo noise - to have the
> > > > SW in /sbin necessary to mount /usr.

> > > Your package manager only knows about the copy in the original
> > > location.

> > So? The same applies to a copy in the initramfs.

> No it doesn't. The initramfs is a transient file system contained
> within a single file. To the package manager, it is just a file, one
> with a rather unique name that portage is highly unlikely to try and
> overwrite.

> Copying binaries into / means you are copying a large number of files
> into an area managed by the package manager. Those files have names and
> locations that are rather likely to be used by ebuilds.

Ah. I was looking forward to the sad time when package managers will be
installing things exclusively on /usr. Well, OK, on /etc too, but
certainly not to /sbin (which will probably have been abolished).

> Do we really have to spell out to you why this is a bad idea?

No, I can get that. ;-)

> > > When you update you'll have multiple versions of the same program or
> > > library in your path.

> > Well, with the manual/script copying which needs doing either
> > for /sbin or initramfs, that will be several copies of a program, not
> > several versions.

> Your copies will be used in preference to the originals in /usr. You
> will have to detect this yourself when this occurs and re-copy them and
> portage cannot help you.

I was thinking of using /sbin for booting, then removing it from $PATH as
soon as /usr gets mounted.

> Remember the primary difference between / and an initramfs:

> The initramfs is transient and it's contents are not available to
> confuse the system once early boot is over.

> / is a permanent file system that is always around, and always there to
> confuse the issue.

OK. I take /sbin off $PATH, like I said above.

> This is not a small trivial issue, it is huge, and a magnificent
> bug-injection system.

OK2. I don't like BI systems.

> > I'm still trying to see the reason why an /sbin with the same
> > contents as a putative initramfs won't work.

> Oh, it will work for booting all right. It's the issues it will cause
> after booting when it should no longer be there that is the problem.

We're going to be stuck with some issues anyway, no matter how we cope
with things. At the moment, I've got my /usr on RAID1, which I think
doubles up the speed things load at. (It's on LVM2 too, but that's by
the way.) I really don't want a fragile initramfs. Sooner or later, I'd
put some slight glitch into it and the result would be a dead PC. Either
that or I'll be scared stiff of touching it, which isn't how a Gentoo
user is supposed to be. Do I really want to take my /usr off RAID1, just
so I can amalgamate it with /?

There's no getting round duplicating executables once the single /usr
crowd have got their way. The only question is where you put the
duplicates, and how you make sure they don't foul things up.


> --
> Alan McKinnnon
> alan.mckinnon@gmail.com

--
Alan Mackenzie (Nuremberg, Germany).
 
Old 03-28-2012, 04:24 AM
"Mike Edenfield"
 
Default After /usr conflation: why not copy booting software to /sbin rather than initramfs?

> From: Alan Mackenzie [mailto:acm@muc.de]
>
> Hi, Alan.
>
> On Tue, Mar 27, 2012 at 11:48:19PM +0200, Alan McKinnon wrote:
> > On Tue, 27 Mar 2012 21:24:22 +0000
> > Alan Mackenzie <acm@muc.de> wrote:
>
> > > That is precisely what the question was NOT about. The idea was to
> > > copy (not move) booting software to /sbin instead of an initramfs -
> > > the exact same programs, modulo noise - to have the SW in /sbin
> > > necessary to mount /usr.
>
> > Two words:
>
> > shared libraries
>
> > Copying binaries is not enough. You have to find and copy every shared
> > library those binaries use. Plus all the data and other files they
> > might need.
>
> > This is non-trivial.
>
> <silently screams>. It's equally non-trivial for initramfs, yet nobody
> seems to be raising this objection for that.
>
> Why is nobody else on this thread willing to take up its main point, the
> exact equivalence between the known, ugly, initramfs solution and the as
> yet half-baked idea of putting the same binaries into /sbin?

Well, for one, the initramfs solution is not generally considered "ugly"
except by a select vocal few who object to it on vague, unarticulated
grounds. That notwithstanding:

The binaries on the initramfs are not always the same as the ones installed
in the system; frequently they are statically linked versions, or
stripped-down versions, or otherwise unsuitable for being used after the
full system is booted. (Dracut, for example, forces you to add
USE=static-libs to a lot of the packages it wants to put into your initramfs
image.) Putting those binaries into the execution path of the system is a
bad idea because you don't always them to run once the system has booted --
I want the full set of udev rules, not the bare handful that my initramfs
has on it.

You could fix this by arranging for them to be put somewhere outside the
normal path, where they can be found by the init system at boot-time but
then ignored once /usr was up. This would also mean managing two copies of
these packages on your system, which means the package manager would need to
ensure that both static and dynamic versions, or full and minimal version,
or whatever else, were built and installed in the correct locations. And
this is ignoring the possible side-effects of reordering the boot scripts to
unilaterally try to mount /usr very early; I don't know what, if any, those
would be but someone would need to figure those out. The initramfs solution
doesn't change the order of boot scripts, so people who are not using one
see no change.

Again, this is all *possible*. It is one option for solving the
missing-/usr-at-boot problem, it is just not the option that has taken hold
in the community. The people who are writing the software consider an
initramfs a more elegant, cleaner, *less* ugly solution that what you are
proposing, in the context of a general-purpose solution suitable for the
most number of users. As they are the ones doing all the work, they get to
make that call. The fact that most of us seem to agree with, or at least not
actively disagree with, that opinion is just an added bonus.

Your solution would be equally as successful at solving the problem, once
someone put in the effort to actually make it work, make it repeatable, make
it stable, and document/automate it for others to use. All of those steps
have /already happened/ for an initramfs, so until someone comes up with a
concrete reason why initramfs will not work, there is absolutely no
motivation to waste time on anything else.

--Mike
 
Old 03-28-2012, 02:01 PM
Alan Mackenzie
 
Default After /usr conflation: why not copy booting software to /sbin rather than initramfs?

On Wed, Mar 28, 2012 at 12:55:20AM +0200, Alan McKinnon wrote:
> > On Tue, Mar 27, 2012 at 11:48:19PM +0200, Alan McKinnon wrote:
> > > On Tue, 27 Mar 2012 21:24:22 +0000
> > > Alan Mackenzie <acm@muc.de> wrote:

> > > > That is precisely what the question was NOT about. The idea was
> > > > to copy (not move) booting software to /sbin instead of an
> > > > initramfs - the exact same programs, modulo noise - to have the
> > > > SW in /sbin necessary to mount /usr.

> > > Two words:

> > > shared libraries

> > > Copying binaries is not enough. You have to find and copy every
> > > shared library those binaries use. Plus all the data and other
> > > files they might need.

> > > This is non-trivial.

> > <silently screams>. It's equally non-trivial for initramfs, yet
> > nobody seems to be raising this objection for that.

> > Why is nobody else on this thread willing to take up its main point,
> > the exact equivalence between the known, ugly, initramfs solution and
> > the as yet half-baked idea of putting the same binaries into /sbin?


> Read my other mail and pay attention to the difference between
> transient and persistent.

In my proposed solution, the executables in /sbin would only exist until
/usr had been mounted and the runtime PATH set up. After the unification
of /usr, /sbin won't even exist (apart from in schemes like mine).

> initramfs is an elegant engineering solution (albeit over-engineered
> for our specific case of being Gentoo users).

Maybe, maybe not. It couples the various bits of booting more tighly
together. I look at Allan Gottlieb's bug "WARNING latest lvm2 breaks
systems with older udev", and note that he recovered, essentially, by
mounting non-/ partitions by hand and going back to an old lvm2 version.
I had a similar problem when I was first trying out Walter's mdev
solution, which I also recovered by mounting by hand.

I look forward with foreboding to the time when such recovery will not be
possible. Only a legacy Gentoo system or a recovery CD will help then.
I think it highly probable that "can't boot" bugs will continue to happen
occasionally. I'd like to carry on having a bootable skeleton system for
when this happens.

> Your questions are about an extremely ill-advised action that has no
> sound basis. It copies stuff around to make one very specific thing
> work but with zero consideration for what it will do to everything
> else. That is bad, bad engineering.

I don't think that's a fair summary.

> If you want all this stuff in /, then do it correctly and modify the
> ebuilds to put the originals there (and troubleshoot the fallout from
> other faulty hard-coded stuffs). This is a lot of work, but it is sound.

I doubt that would work, for the reasons you give.

I feel I've been needlessly slammed, all for articulating an interesting
idea.

> --
> Alan McKinnnon
> alan.mckinnon@gmail.com

--
Alan Mackenzie (Nuremberg, Germany).
 
Old 03-28-2012, 05:07 PM
Alan Mackenzie
 
Default After /usr conflation: why not copy booting software to /sbin rather than initramfs?

Hi, Neil.

On Wed, Mar 28, 2012 at 03:56:36PM +0100, Neil Bothwick wrote:
> On Wed, 28 Mar 2012 14:01:32 +0000, Alan Mackenzie wrote:

> > > Read my other mail and pay attention to the difference between
> > > transient and persistent.

> > In my proposed solution, the executables in /sbin would only exist until
> > /usr had been mounted and the runtime PATH set up. After the
> > unification of /usr, /sbin won't even exist (apart from in schemes like
> > mine).

> What happens to files that are installed to /bin, /sbin or /lib by
> default?

Aren't they getting shoved into /usr? I thought that was the whole point
of the excercise.

> Where do kernel modules go?

I hadn't actually thought of that - I've never built a kernel with
modules enabled. Where do kernel modules go? Won't they be going into
/usr somewhere?

Incidentally, dracut says it won't work on a kernel without modules. I
don't know if it's true or not.

> > I look forward with foreboding to the time when such recovery will not
> > be possible. Only a legacy Gentoo system or a recovery CD will help
> > then. I think it highly probable that "can't boot" bugs will continue
> > to happen occasionally. I'd like to carry on having a bootable
> > skeleton system for when this happens.

> When an initramfs fails to boot, it drops you to a busybox shell, ...

You know, that cheers me up a lot.

> ...although I also have a SystemRescueCD ISO in /boot for such
> situations.

I suppose I could do with that, too. And I should learn how to use it.

> --
> Neil Bothwick

> Top Oxymorons Number 12: Plastic glasses

I wear spectacular glasses.

--
Alan Mackenzie (Nuremberg, Germany).
 
Old 03-28-2012, 05:40 PM
"Mike Edenfield"
 
Default After /usr conflation: why not copy booting software to /sbin rather than initramfs?

> From: Alan Mackenzie [mailto:acm@muc.de]

> Incidentally, dracut says it won't work on a kernel without modules. I
don't
> know if it's true or not.

dracut wants you to have loadable module /support/ in your kernel so it can
scan for modules needed by the rootfs. The kernel-module support in dracut
is just another module; you could omit that module and I believe dracut will
carry on fine. Of course, if you have nothing compiled as a module then your
initramfs just won't have any modules built into it either way.

--Mike
 
Old 03-29-2012, 03:56 PM
Alan Mackenzie
 
Default After /usr conflation: why not copy booting software to /sbin rather than initramfs?

Hi, Mike.

On Wed, Mar 28, 2012 at 12:24:14AM -0400, Mike Edenfield wrote:
> > From: Alan Mackenzie [mailto:acm@muc.de]

> > Hi, Alan.

> > On Tue, Mar 27, 2012 at 11:48:19PM +0200, Alan McKinnon wrote:
> > > On Tue, 27 Mar 2012 21:24:22 +0000
> > > Alan Mackenzie <acm@muc.de> wrote:

> > Why is nobody else on this thread willing to take up its main point,
> > the exact equivalence between the known, ugly, initramfs solution and
> > the as yet half-baked idea of putting the same binaries into /sbin?

> Well, for one, the initramfs solution is not generally considered "ugly"
> except by a select vocal few who object to it on vague, unarticulated
> grounds.

I'll articulate a few. (i) The initramfs involves having two copies of
lots of software around. (ii) What's more, these two copies are often
different, one being built with static libraries, the other with dynamic
ones. (iii) This situation is not (as far as I know) yet handled by
Portage, which means in building such software statically, you've got to
save the dynamic version somewhere else whilst you're doing it. (iv) The
initramfs requires a potentially long script to make it work.

I think that qualifies the initramfs solution as ugly.

> That notwithstanding:

> The binaries on the initramfs are not always the same as the ones installed
> in the system; frequently they are statically linked versions, or
> stripped-down versions, or otherwise unsuitable for being used after the
> full system is booted. (Dracut, for example, forces you to add
> USE=static-libs to a lot of the packages it wants to put into your initramfs
> image.) Putting those binaries into the execution path of the system is a
> bad idea because you don't always them to run once the system has booted --
> I want the full set of udev rules, not the bare handful that my initramfs
> has on it.

My idea was for /sbin to vanish from $PATH just as soon as the boot had
been completed; PATH gets set anyway on the initialisation of something
or other, so this would happen automatically, just like the initramfs
disappears when the switch_root is done.

> [ more criticism, a lot of which I accept. ]

I think I have the elegant solution: that would be for the kernel to be
able to mount several partitions at system initialisation rather than
just the root partition. With this, all the issues we've been discussing
simply wouldn't arise.

I accept that this solution will never happen. Sadly.

> --Mike

--
Alan Mackenzie (Nuremberg, Germany).
 
Old 03-29-2012, 05:29 PM
Alan Mackenzie
 
Default After /usr conflation: why not copy booting software to /sbin rather than initramfs?

Evening, Neil.

On Thu, Mar 29, 2012 at 05:35:35PM +0100, Neil Bothwick wrote:
> On Thu, 29 Mar 2012 15:56:28 +0000, Alan Mackenzie wrote:

> > I think I have the elegant solution: that would be for the kernel to be
> > able to mount several partitions at system initialisation rather than
> > just the root partition. With this, all the issues we've been
> > discussing simply wouldn't arise.

> That's an excellent idea.

> > I accept that this solution will never happen. Sadly.

> It's already happened here. My kernel mounts / and /usr thanks to the
> inbuilt initramfs

That's exactly what I didn't mean, and I think you might have been aware
of that.

What I did mean was being able to mount subsequent partitions by giving
kernel parameters in the boot loader configuration file. Something like
"mount=8,3:/usr" for mount /dev/sda3 /usr.

This would avoid the need to spend any effort whatsoever on building an
initramfs, yet /usr would be mounted early in boot.

> --
> Neil Bothwick

--
Alan Mackenzie (Nuremberg, Germany).
 

Thread Tools




All times are GMT. The time now is 10:50 AM.

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