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, 01:37 PM
Alan Mackenzie
 
Default After /usr conflation: why not copy booting software to /sbin rather than initramfs?

Hello, Gentoo.

I've been thinking about the problem of the conflation of every
executable into /usr. If /usr isn't on /, the system can't boot without
special preperations. Nothing new here.

The method usually discussed is to copy the booting software into an
initramfs on a partition other than /usr, and use this to mount /usr.

My question: what, technically, prevents me from copying the booting
software instead to /sbin and booting the system that way?

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

> From: Alan Mackenzie [mailto:acm@muc.de]
> Sent: Tuesday, March 27, 2012 9:37 AM

> My question: what, technically, prevents me from copying the booting
> software instead to /sbin and booting the system that way?

Nothing; in fact, this was the general solution to the problem of "something
else in /usr/{sbin,bin,lib} is needed at boot" for a long time. More and
more software was getting moved into /{s,}bin, and in particular into /lib,
to make it available in the early boot stages.

There's nothing wrong with that, as long as you can ensure that any
hard-coded paths to those binaries are updated properly.

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. Then it's just
question of how far you take this process before you reach your personal
threshold of questioning why you have two partitions at all. Whether you
reach that point or not depends on how complex your boot process is, what
you actually need running to boot, and how personally invested in a split
/usr you happen to be

--Mike
 
Old 03-27-2012, 02:46 PM
Neil Bothwick
 
Default After /usr conflation: why not copy booting software to /sbin rather than initramfs?

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.


--
Neil Bothwick

This is as bad as it can get; but don't bet on it.
 
Old 03-27-2012, 05:55 PM
 
Default After /usr conflation: why not copy booting software to /sbin rather than initramfs?

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?
 
Old 03-27-2012, 06:41 PM
Alan McKinnon
 
Default After /usr conflation: why not copy booting software to /sbin rather than initramfs?

On Tue, 27 Mar 2012 19:55:37 +0200
che@chrekh.se wrote:

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

Of course it's possible, it's merely a gigantic list of cd commands.

The question is, is it advisable?

I offer you two choices:

a. Move a few commands into an initramfs, truly only the ones you
really do need, or
b. Move 7G of files onto / (i.e. everything) and lose any benefit you
(and everyone else with different ideas to you) may want by having a
separate /usr. Oh, and you get to deal with finding the hardcoded paths
and fixing the code yourself.

Those are your choices. Pick one.



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

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

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

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

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.

Most Linux users, by a vast but very silent majority, are plenty happy to
put / and /usr on one partition, wipe their hands on their pants, and move
on with life. Thus, the people developing and packaging those required boot
packages can leave them right where they are, and everything works. Some
Linux users have reasons (largely legitimate ones) why this is not a valid
option. Those users have three choices

* Move the required packages away from their default installation locations
on their machines, as you're suggestion, and fix the order of your boot
scripts to mount /usr earlier than anything that needs it.
* Install (or develop) alternative versions of the tools that do not have
the same boot-time requirements, thus allowing you to ignore the whole mess.
This is what Walt and his mdev team are making happen.
* Use an initramfs to do whatever specific thing your machine(s) need to do
to make the rest of the software work out-of-the-box.

So, it's not a matter of one choice working and one not. It's a matter of
one choice being much lower maintenance for the people donating their time
to produce the software in the first place. If someone (maybe you) were to
figure out the actual steps needed to mount /usr early in the boot, without
and initramfs, without swapping out udev for busybox or whatever, I'm sure a
lot of people would be interested in seeing how that's done. There's a
possibility that it turns out to be way easier than anyone thought, and that
supporting a split /usr becomes "no big deal". In practice, I'm going to
guess that it turns out to be a way bigger maintenance nightmare (and
probably more fragile) than:

root # emerge dracut
root # dracut -H

And probably won't be something that the developers or package maintainers
are going to commit to supporting.

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

Alan McKinnon <alan.mckinnon@gmail.com> writes:
>
> I offer you two choices:
>
> a. Move a few commands into an initramfs, truly only the ones you
> really do need, or
> b. Move 7G of files onto / (i.e. everything) and lose any benefit you
> (and everyone else with different ideas to you) may want by having a
> separate /usr. Oh, and you get to deal with finding the hardcoded paths
> and fixing the code yourself.
>
> Those are your choices. Pick one.

In that case I pick a. It's not a big deal.

I don't have anything against initrd, and use it on several places. It's
useful for many things including enabling / on raid or lvm.

But I also see the usefulnes of having / on a real partition, and being
able to start a kernel with init=/bin/bash when I have screwed something
up, which I tend to do quite often,

--
Christer
 
Old 03-28-2012, 07:14 PM
 
Default After /usr conflation: why not copy booting software to /sbin rather than initramfs?

"Mike Edenfield" <kutulu@kutulu.org> writes:
>
> Yes , of course it's /possible/, it's just not /practical/.

Perhaps, but still?
I don't se how that is less practical than collecting them to a ramdisk?

Just do exactly the same steps up to the "cpio | gzip" -part

I do agree with most of what you say
>
> Most Linux users, by a vast but very silent majority, are plenty happy to
> put / and /usr on one partition, wipe their hands on their pants, and move
> on with life. Thus, the people developing and packaging those required boot
> packages can leave them right where they are, and everything works.

I agree with that.

> Some
> Linux users have reasons (largely legitimate ones) why this is not a valid
> option. Those users have three choices
>
> * Move the required packages away from their default installation locations
> on their machines, as you're suggestion, and fix the order of your boot
> scripts to mount /usr earlier than anything that needs it.
> * Install (or develop) alternative versions of the tools that do not have
> the same boot-time requirements, thus allowing you to ignore the whole mess.
> This is what Walt and his mdev team are making happen.
> * Use an initramfs to do whatever specific thing your machine(s) need to do
> to make the rest of the software work out-of-the-box.
>
> So, it's not a matter of one choice working and one not. It's a matter of
> one choice being much lower maintenance for the people donating their time
> to produce the software in the first place.

Yes, that is a very valid point.

> If someone (maybe you) were to
> figure out the actual steps needed to mount /usr early in the boot, without
> and initramfs, without swapping out udev for busybox or whatever, I'm sure a
> lot of people would be interested in seeing how that's done. There's a
> possibility that it turns out to be way easier than anyone thought, and that
> supporting a split /usr becomes "no big deal". In practice, I'm going to
> guess that it turns out to be a way bigger maintenance nightmare (and
> probably more fragile) than:
>
> root # emerge dracut
> root # dracut -H

That's probably the way I'll proceed when I update udev later. But I'll
wait a while longer before doing that.

I'll going to miss the posibility of starting a kernel with only
init=/bin/bash for rescue purposes. But it's not a big deal.

>
> And probably won't be something that the developers or package maintainers
> are going to commit to supporting.
>
> --Mike

Thanks Mike.

This is my migration-plan

Today I have two disks with both three partitions

sda1 / -- sdb1 reserve-root. Regulary rsynced from sda1
sda2 swap -- sdb2 swap
sda3 lvm -- sdb3 lvm

sda3 and sdb3 is combined to the volume-group vg0, and I have all my
other filesystems in vg0.

I'm planing to create a vg0/root and copy the contents of / to that, and
later remove everything but /boot from the old /

How does that sound?

--
Christer
 

Thread Tools




All times are GMT. The time now is 01:00 AM.

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