| 1 |
On 01/29/2019 12:33 PM, Rich Freeman wrote: |
| 2 |
> If all my boxes could function reliably without an initramfs I probably |
| 3 |
> would do it that way. |
| 4 |
|
| 5 |
;-) |
| 6 |
|
| 7 |
> However, as soon as you throw so much as a second hard drive in a system |
| 8 |
> that becomes unreliable. |
| 9 |
|
| 10 |
I disagree. |
| 11 |
|
| 12 |
I've been reliably booting and running systems with multiple drives for |
| 13 |
almost two decades. Including various combinations of PATA, SATA, SCSI, |
| 14 |
USB, SAN, drives. |
| 15 |
|
| 16 |
Mounting the root based on UUID (or labels) is *WONDERFUL*. It makes |
| 17 |
the system MUCH MORE resilient. Even if a device somehow gets inserted |
| 18 |
before your root device in the /dev/sd* order. |
| 19 |
|
| 20 |
> I'm not saying you can't use linux without an initramfs. I'm just |
| 21 |
> questioning why most normal people would want to. I bet that 98% of |
| 22 |
> people who use Linux run an initramfs, and there is a reason for that... |
| 23 |
|
| 24 |
I don't doubt your numbers. |
| 25 |
|
| 26 |
But I do question the viability of them. How many people that are |
| 27 |
running Linux even know that they have an option? |
| 28 |
|
| 29 |
I suspect the answer to that question is less extreme than you are |
| 30 |
wanting. I also suspect that it's more in your favor than I want. But |
| 31 |
70 / 30 (I pulled those from you know where) is significantly different |
| 32 |
than 98 / 2. |
| 33 |
|
| 34 |
> A lot of that is situational. If you have a kernel without btrfs support, |
| 35 |
> and you build btrfs as a module and switch your root filesystem to btrfs, |
| 36 |
> then obviously you'll need to rebuild your initramfs since the one you |
| 37 |
> have can't do btrfs. But, most people would just rebuild their initramfs |
| 38 |
> anytime they rebuild a kernel just to be safe. If you added btrfs support |
| 39 |
> to the kernel (built-in) then it is more of a toss-up, though in the case |
| 40 |
> of btrfs specifically you might still need to regenerate the initramfs |
| 41 |
> to add the btrfs userspace tools to it if you didn't already have them |
| 42 |
> in /usr when you generated it the first time. |
| 43 |
> |
| 44 |
> But, if you're running btrfs you're probably forced to use an initramfs |
| 45 |
> in any case. |
| 46 |
|
| 47 |
That's one of many reasons that I'm not using btrfs. |
| 48 |
|
| 49 |
> In any case, it isn't some kind of automatic thing. Just as some things |
| 50 |
> require rebuilding a kernel, some things require rebuilding an initramfs. |
| 51 |
> I just find it simplest to build an initramfs anytime I build a kernel, |
| 52 |
> and use the make install naming convention so that grub-mkconfig just |
| 53 |
> does its thing automatically. |
| 54 |
|
| 55 |
Simplicity is completely independent of necessity. |
| 56 |
|
| 57 |
You have made a choice. That's your choice to make. |
| 58 |
|
| 59 |
> IMO Dracut is one of the most robust solutions for these sorts of |
| 60 |
> situations. It is highly modular, easy to extend, and it really tries |
| 61 |
> hard to respect your existing config in /etc. In fact, not only does |
| 62 |
> it put a copy of fstab in the initramfs to help it find your root, but |
| 63 |
> after it mounts the root it checks that version of fstab to see if it |
| 64 |
> is different and then remounts things accordingly. |
| 65 |
|
| 66 |
I find it simpler and more robust to remove the initramfs complexity if |
| 67 |
I have no /need/ for it. |
| 68 |
|
| 69 |
> If you haven't guessed I'm a bit of a Dracut fan. :) |
| 70 |
|
| 71 |
And I'm a fan of simplicity. |
| 72 |
|
| 73 |
|
| 74 |
|
| 75 |
-- |
| 76 |
Grant. . . . |
| 77 |
unix || die |
Archives