| 1 |
On Tue, Mar 27, 2012 at 10:24 PM, Mike Edenfield <kutulu@××××××.org> wrote: |
| 2 |
>> From: Alan Mackenzie [mailto:acm@×××.de] |
| 3 |
>> |
| 4 |
>> Hi, Alan. |
| 5 |
>> |
| 6 |
>> On Tue, Mar 27, 2012 at 11:48:19PM +0200, Alan McKinnon wrote: |
| 7 |
>> > On Tue, 27 Mar 2012 21:24:22 +0000 |
| 8 |
>> > Alan Mackenzie <acm@×××.de> wrote: |
| 9 |
>> |
| 10 |
>> > > That is precisely what the question was NOT about. The idea was to |
| 11 |
>> > > copy (not move) booting software to /sbin instead of an initramfs - |
| 12 |
>> > > the exact same programs, modulo noise - to have the SW in /sbin |
| 13 |
>> > > necessary to mount /usr. |
| 14 |
>> |
| 15 |
>> > Two words: |
| 16 |
>> |
| 17 |
>> > shared libraries |
| 18 |
>> |
| 19 |
>> > Copying binaries is not enough. You have to find and copy every shared |
| 20 |
>> > library those binaries use. Plus all the data and other files they |
| 21 |
>> > might need. |
| 22 |
>> |
| 23 |
>> > This is non-trivial. |
| 24 |
>> |
| 25 |
>> <silently screams>. It's equally non-trivial for initramfs, yet nobody |
| 26 |
>> seems to be raising this objection for that. |
| 27 |
>> |
| 28 |
>> Why is nobody else on this thread willing to take up its main point, the |
| 29 |
>> exact equivalence between the known, ugly, initramfs solution and the as |
| 30 |
>> yet half-baked idea of putting the same binaries into /sbin? |
| 31 |
> |
| 32 |
> Well, for one, the initramfs solution is not generally considered "ugly" |
| 33 |
> except by a select vocal few who object to it on vague, unarticulated |
| 34 |
> grounds. That notwithstanding: |
| 35 |
> |
| 36 |
> The binaries on the initramfs are not always the same as the ones installed |
| 37 |
> in the system; frequently they are statically linked versions, or |
| 38 |
> stripped-down versions, or otherwise unsuitable for being used after the |
| 39 |
> full system is booted. (Dracut, for example, forces you to add |
| 40 |
> USE=static-libs to a lot of the packages it wants to put into your initramfs |
| 41 |
> image.) Putting those binaries into the execution path of the system is a |
| 42 |
> bad idea because you don't always them to run once the system has booted -- |
| 43 |
> I want the full set of udev rules, not the bare handful that my initramfs |
| 44 |
> has on it. |
| 45 |
|
| 46 |
I agree with most of what you say; however, I believe you are mistaken |
| 47 |
about the static nature of the binaries in the initramfs created by |
| 48 |
dracut. I use dracut with the whole bang (plymouth, systemd, udev, you |
| 49 |
name it), and I don't have *any* of my packages compiled with |
| 50 |
"static-libs". Even more, my system right now runs everything with |
| 51 |
"-static-libs". I like to think (and, unless I missed something, |
| 52 |
that's in fact the truth) that my initramfs is actually more or less |
| 53 |
in sync with my running system, and I update it a lot, since it's |
| 54 |
trivial to do so with dracut. |
| 55 |
|
| 56 |
Outside of that, I agree with everything you say. |
| 57 |
|
| 58 |
Regards. |
| 59 |
-- |
| 60 |
Canek Peláez Valdés |
| 61 |
Posgrado en Ciencia e Ingeniería de la Computación |
| 62 |
Universidad Nacional Autónoma de México |
Archives