Re: [gentoo-user] After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On Tue, Mar 27, 2012 at 9:37 AM, Alan Mackenzie a...@muc.de wrote:
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?
Dynamic linking is probably going to be the killer piece. After every
update, you'd need to make sure all the libraries the binary needs are
also accessible on the / mount.
The other piece is probably somewhere along the lines of if you're
going to use an initramfs anyway, now you can put / on
$composite_block_device, too! (Which is something I'll probably start
doing on any system where I'd want /usr on a composite block device
anyway. Which is pretty much all of them; I like the load consumer
balancing behaviors I get from RAID{0|5|6})
--
:wq
RE: [gentoo-user] After /usr conflation: why not copy booting software to /sbin rather than initramfs?
From: Alan Mackenzie [mailto:a...@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
Re: [gentoo-user] After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On Tue, Mar 27, 2012 at 10:02 AM, Mike Edenfield kut...@kutulu.org wrote: [snip] 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 :) This extends directly by analogy to having binaries on /usr mounted on anything other than plain disk. Say you wanted to have / on LVM on RAID6. Now you don't have any choice but to move stuff from /usr/* to your initramfs, since the kernel isn't even going to automount your RAID for you if you're not using the 0.9 metadata format, and you've still got to cope with LVM. As you say, the boundary between user software and boot software grows less and less clear, and your *initramfs* grows bigger and bigger. How long will there remain *any point* to LVM or software RAID, once you have to preload the bulk of your operating system into RAM before you can access their contents? One shouldn't need an entire operating system preloaded into RAM before being able to access the current versions of anything. The *real* fun is going to start once you get daemons which happen to need to be launched while you're still in your initramfs stage, and then you need to restart those daemons as part of an update later in the system's uptime. That's going to be a fun one to solve. -- :wq
Re: [gentoo-user] After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On Tue, Mar 27, 2012 at 10:02:02AM -0400, Mike Edenfield wrote:
From: Alan Mackenzie [mailto:a...@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.
Surely this is the same, whether one copies the booting software to
initramfs or /sbin, isn't it?
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?
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 :)
I've decided that, if push comes to shove, I'm going to go for /usr on /
rather than a fragile initramfs system. I've got everything bar / on
RAID 1/LVM at the moment, but I don't really use LVM, so I could
dismantle that too, losing all the baggage that brings with it.
Having said that, my system (including Gnome) is working perfectly well
with mdev, and see no reason why that shouldn't continue.
--Mike
--
Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On Tue, Mar 27, 2012 at 7:26 AM, Alan Mackenzie a...@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
Re: [gentoo-user] After /usr conflation: why not copy booting software to /sbin rather than initramfs?
On Tue, 27 Mar 2012 14:26:46 +, 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. signature.asc Description: PGP signature
RE: [gentoo-user] After /usr conflation: why not copy booting software to /sbin rather than initramfs?
From: Alan Mackenzie [mailto:a...@muc.de]
Sent: Tuesday, March 27, 2012 10:27 AM
On Tue, Mar 27, 2012 at 10:02:02AM -0400, Mike Edenfield wrote:
From: Alan Mackenzie [mailto:a...@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.
Surely this is the same, whether one copies the booting software to
initramfs
or /sbin, isn't it?
No, because very little of my booting software is on my initramfs; it
contains the kernel modules for my SATA drive and a script to mount /usr
before launching /sbin/init. You *could* build an initramfs that included
all of those other items, including udev and fsck tools if you wanted to,
but you don't have to. (You might want to, for example, to have a more
fully-features rescue shell, but I have a LiveCD for that.)
The difference is what part of the booting process you need the software
for. Without an initramfs, your boot loader loads your kernel, your kernel
launches /sbin/init, and /sbin/init starts running your startup scripts.
Everything that needs to happen must happen in those startup scripts. The
problems occur when script #1 (say, start udev) sometimes needs script #2
(mount /usr) to have run, but script #2 sometimes needs script #1 to have
run. You can solve this in a number of ways:
* Fix script #1 to never need script #2 (move everything you need off /usr)
* Fix script #2 to never need script #1 (put /usr on the same partition as
/sbin/init)
* Adjust the order of the scripts on a case-by-case bases (move script #2 to
an initrd when needed)
Option one has traditionally been the way to solve these kinds of problems,
but with dynamic linking and external hooks the reach of the boot-time
software is getting overly broad. Option #2 is the simplest and lowest-risk
option, but not everyone has a hardware configuration that makes that a
viable choice. So option #3 is basically you do whatever you have to do to
get a /usr before /sbin/init runs.
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?
This part is, true, but the point of an initramfs is that, once you switch
over to init, the initramfs is out of the picture. With a traditional boot,
the stuff you move into your rootfs to make booting work is there forever.
With an initramfs, you don't need (for example) all of the udev rules and
libraries and such; you just need enough statically linked binaries to mount
/usr; when the init switch happens, your real, production binaries show up
and the trimmed-down copies from your initramfs go away.
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 :)
I've decided that, if push comes to shove, I'm going to go for /usr on /
rather
than a fragile initramfs system. I've got everything bar / on RAID 1/LVM
at
the moment, but I don't really use LVM, so I could dismantle that too,
losing
all the baggage that brings with it.
I'm using both on most of my systems now, though admittedly on my laptop
it's just to get the boot animation from plymouth :)
Having said that, my system (including Gnome) is working perfectly well
with
mdev, and see no reason why that shouldn't continue.
And that's a perfectly legitimate option; you're continuing to use a process
that has worked for decades. The problem with that option is not that it
doesn't work for plenty of people, it's that it doesn't *scale* very well.
If you're writing the software that needs to work out-of-the-box for every
Fedora/Debian/Gentoo/etc system installed from this point forward, you need
to worry about scale. If you're setting up a few hundred nearly identical
servers with much more limited hardware that is under your direct control,
you can focus your solution to a much narrow scope.
