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, 02:38 PM
Mark Knecht
 
Default After /usr conflation: why not copy booting software to /sbin rather than initramfs?

On Tue, Mar 27, 2012 at 7:26 AM, Alan Mackenzie <acm@muc.de> wrote:
> On Tue, Mar 27, 2012 at 10:02:02AM -0400, Mike Edenfield wrote:
<SNIP>
>
>> There's nothing wrong with that, as long as you can ensure that any
>> hard-coded paths to those binaries are updated properly.
>
> Surely this is the same, whether one copies the booting software to
> initramfs or /sbin, isn't it?
>

If it's 'hard coded' then I think it's not the same. Imagine a text
script which specifically tries to find, say, '/usr/bin/ldd' as
opposed to 'ldd'. ldd isn't there any more so the script just fails.

Just a thought,
Mark
 
Old 03-27-2012, 09:41 PM
Neil Bothwick
 
Default After /usr conflation: why not copy booting software to /sbin rather than initramfs?

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.
When you update you'll have multiple versions of the same program or
library in your path.


--
Neil Bothwick

In space, no one can hear you fart.
 
Old 03-27-2012, 09:48 PM
Alan McKinnon
 
Default After /usr conflation: why not copy booting software to /sbin rather than initramfs?

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.

--
Alan McKinnnon
alan.mckinnon@gmail.com
 
Old 03-27-2012, 10:39 PM
Alan McKinnon
 
Default After /usr conflation: why not copy booting software to /sbin rather than initramfs?

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.

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

> > 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.

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.

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

> 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.




--
Alan McKinnnon
alan.mckinnon@gmail.com
 
Old 03-27-2012, 10:53 PM
Neil Bothwick
 
Default After /usr conflation: why not copy booting software to /sbin rather than initramfs?

On Tue, 27 Mar 2012 22:01:28 +0000, Alan Mackenzie wrote:

> > Your package manager only knows about the copy in the original
> > location.
>
> So? The same applies to a copy in the initramfs.

No it does not. the initramfs is built using the versions installed on
your system, and unloaded as soon as root is switched to /. At no time
are two different versions available in your path.

> > 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.

Multiple copies of the same version is inefficient, multiple versions is
potentially disastrous.

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

You seem to be trying very hard to ignore the point that the initramfs
does not need to contain as much as /usr or even /. It only needs to
contain the files required to mount / and /usr. this can be as few as 2,
busybox and the init script. Even with encrypted filesystems on LVM
volumes running on RAID, this box's initramfs contains only 5 files.

% grep file /usr/src/init.cfg
file /bin/busybox /bin/busybox 755 0 0
file /sbin/lvm.static /sbin/lvm.static 755 0 0
file /sbin/mdadm /sbin/mdadm 755 0 0
file /sbin/cryptsetup /sbin/cryptsetup 755 0 0
file /init /usr/src/init.sh 755 0 0


--
Neil Bothwick

"Press Return to Continue" - known as "The Mail Menupause".
 
Old 03-27-2012, 10:54 PM
Neil Bothwick
 
Default After /usr conflation: why not copy booting software to /sbin rather than initramfs?

On Tue, 27 Mar 2012 22:35:44 +0000, Alan Mackenzie 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?

Bewause everyone else realises they are in no way equivalent, or even
comparable?


--
Neil Bothwick

Access denied--nah nah na nah nah!
 
Old 03-27-2012, 10:55 PM
Alan McKinnon
 
Default After /usr conflation: why not copy booting software to /sbin rather than initramfs?

On Tue, 27 Mar 2012 22:35:44 +0000
Alan Mackenzie <acm@muc.de> wrote:

> 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?


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

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

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.

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.



--
Alan McKinnnon
alan.mckinnon@gmail.com
 
Old 03-28-2012, 04:55 AM
Canek Peláez Valdés
 
Default After /usr conflation: why not copy booting software to /sbin rather than initramfs?

On Tue, Mar 27, 2012 at 10:24 PM, Mike Edenfield <kutulu@kutulu.org> 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:
>>
>> > > 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.

I agree with most of what you say; however, I believe you are mistaken
about the static nature of the binaries in the initramfs created by
dracut. I use dracut with the whole bang (plymouth, systemd, udev, you
name it), and I don't have *any* of my packages compiled with
"static-libs". Even more, my system right now runs everything with
"-static-libs". I like to think (and, unless I missed something,
that's in fact the truth) that my initramfs is actually more or less
in sync with my running system, and I update it a lot, since it's
trivial to do so with dracut.

Outside of that, I agree with everything you say.

Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México
 
Old 03-28-2012, 06:17 AM
Pandu Poluan
 
Default After /usr conflation: why not copy booting software to /sbin rather than initramfs?

On Mar 28, 2012 11:27 AM, "Mike Edenfield" <kutulu@kutulu.org> wrote:

>

>

> 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.


Check out the email from William Kenworth in this mailing list; he's having trouble with initramfs being a blackbox.


As a (mostly) server guy, I much prefer using a whitebox.


I happen to have /usr on a VHD, so I don't need an initramfs for booting (that, plus my production servers are all udev-less). If push comes to shove, what I'll do is create a vestigial /usr in the root partition, and have it overlaid by mounting the actual root over it. Synchronizing can be automated by bindmounting root, after which I can access its (vestigial) usr directory.



Rgds,
 
Old 03-28-2012, 06:19 AM
Pandu Poluan
 
Default After /usr conflation: why not copy booting software to /sbin rather than initramfs?

On Mar 28, 2012 1:17 PM, "Pandu Poluan" <pandu@poluan.info> wrote:

>

>

> On Mar 28, 2012 11:27 AM, "Mike Edenfield" <kutulu@kutulu.org> wrote:

> >

> >

> > 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.

>

> Check out the email from William Kenworth in this mailing list; he's having trouble with initramfs being a blackbox.

>

> As a (mostly) server guy, I much prefer using a whitebox.

>

> I happen to have /usr on a VHD, so I don't need an initramfs for booting (that, plus my production servers are all udev-less). If push comes to shove, what I'll do is create a vestigial /usr in the root partition, and have it overlaid by mounting the actual root over it.



That should be: "mounting the actual /usr over it."


Rgds,
 

Thread Tools




All times are GMT. The time now is 07:22 AM.

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