| 1 |
On Tue, Aug 6, 2019 at 11:54 AM Canek Peláez Valdés <caneko@×××××.com> wrote: |
| 2 |
> |
| 3 |
> Arguing against this trivial (and IMHO, elegant) solution is tilting at windmills. Specially if it is for ideological reasons instead of technical ones. |
| 4 |
> |
| 5 |
|
| 6 |
++ |
| 7 |
|
| 8 |
Some of the solutions I've seen tossed out in this thread are more |
| 9 |
complex than just building your own initramfs from scratch. |
| 10 |
|
| 11 |
An initramfs is just a userspace bootloader that runs on top of linux. |
| 12 |
Nobody has any problem with conventional bootloaders, and if you want |
| 13 |
to do anything with one of those you have to muck around in low-level |
| 14 |
C or assembly. |
| 15 |
|
| 16 |
There has been talk of gathering up all the stuff you need from /usr |
| 17 |
to bootstap everything, and then adding some scripting to mount |
| 18 |
everything. The proposals have been to shove all that in / somewhere |
| 19 |
(perhaps even in /bin or /sbin). If instead you just stick it all in |
| 20 |
a cpio archive you basically have an initramfs, and you don't need to |
| 21 |
have cruft all over your filesystem to do it. There are already |
| 22 |
configurable and modular solutions like dracut which do a really nice |
| 23 |
job of building one, and they make your bootstrapping process |
| 24 |
infinitely flexible. |
| 25 |
|
| 26 |
If you want root to be a zip file hosted on a webserver somewhere that |
| 27 |
isn't a problem. If you want root to be a rar file on a gpg-encrypted |
| 28 |
attachment to a message stored on some IMAP server, you could do that |
| 29 |
too. To make all that work you can just script it in bash using |
| 30 |
regular userspace tools like curl or fetchmail, without any need to go |
| 31 |
mucking around with lower-level code. Then once your root filesystem |
| 32 |
is mounted all that bootstrapping code just deletes itself and the |
| 33 |
system operates as if it was never there (strictly speaking this isn't |
| 34 |
required but this is usually how it is done). |
| 35 |
|
| 36 |
I doubt we'll see a /usr merge anytime soon, or any huge rush to break |
| 37 |
a separate /usr completely without an initramfs. However, there are |
| 38 |
already use cases known where a separate /usr can cause problems |
| 39 |
without either an initramfs or some kind of early-boot shell script |
| 40 |
(there have already been solutions tossed out for that which are much |
| 41 |
simpler than the ones in this thread). The biggest example I've heard |
| 42 |
is bluetooth keyboards - that was what made most of the zealots give |
| 43 |
up on supporting anything that could possibly be needed for |
| 44 |
bootstrapping being in /, as bluetooth has a bunch of deps and at that |
| 45 |
point you might as well shove gnome in /bin. |
| 46 |
|
| 47 |
So, for the forseeable future your system probably won't break if you |
| 48 |
are using a separate /usr, but if it does the policy has been |
| 49 |
established for a long time that nobody is obligated to fix it (nor |
| 50 |
are they prohibited from doing so). |
| 51 |
|
| 52 |
Really, though, you should take the time to appreciate an initramfs |
| 53 |
whether you decide to use one or not. They're a really elegant |
| 54 |
solution to the problem. Sometimes I think that half the objection is |
| 55 |
due to the fact that they use cpio which is a bit obscure - if they |
| 56 |
were tarballs people would be tearing them apart and playing with them |
| 57 |
more. |
| 58 |
|
| 59 |
-- |
| 60 |
Rich |
Archives