| 1 |
Mike Gilbert posted on Fri, 02 Aug 2013 10:32:10 -0400 as excerpted: |
| 2 |
|
| 3 |
> On Fri, Aug 2, 2013 at 8:06 AM, Duncan <1i5t5.duncan@×××.net> wrote: |
| 4 |
>> Steven J. Long posted... |
| 5 |
>>> you only really need an initramfs if [...] |
| 6 |
>> |
| 7 |
>> Or, unfortunately, for root on mult-device btrfs, since the usual |
| 8 |
>> kernel commandline rootflags=device=/dev/whatever doesn't seem to work |
| 9 |
>> for some reason. |
| 10 |
>> |
| 11 |
> Passing rootflags=device= is a little fragile anyway, since it depends |
| 12 |
> on the kernel detecting your devices in a certain order. Having a |
| 13 |
> multi-device btrfs root without an initramfs is asking for trouble. |
| 14 |
|
| 15 |
Well, yes and no. Pre-btrfs I used kernel commandline assembled mdraid |
| 16 |
with initr*less root on top of it for years. As I posted to the btrfs |
| 17 |
list when someone made the same argument, on my hardware anyway, /dev/sd* |
| 18 |
bring-up order is known stable for a particular kernel as long as I don't |
| 19 |
go changing the physical hardware or plugging. and if a new kernel ever |
| 20 |
changes that or I change the physical hardware, I can either drop to |
| 21 |
grub's commandline (grub2 here, but grub1 works too, with a bit more |
| 22 |
difficulty) and scan, then enter the new devices I need, or boot the old |
| 23 |
kernel and reconfigure as necessary. |
| 24 |
|
| 25 |
IOW, depending on the existing stable scan order with a known and |
| 26 |
demonstrated ability to adapt to changing scan order if it happens, is |
| 27 |
definitely no MORE fragile or asking for trouble (and arguably rather |
| 28 |
less so), than running and dynamically adapting to pre-release brokenness |
| 29 |
in for example the live-git kernels I'm running most of the time, or the |
| 30 |
live-git openrc-9999 I run, because I've found it easier to troubleshoot |
| 31 |
a couple commits at a time while using the additional information git |
| 32 |
whatchanged provides, than to effectively operate blind, with far less |
| 33 |
information and far more commits stacked up that the problem could be in |
| 34 |
when I DO find one if I simply follow regular releases. |
| 35 |
|
| 36 |
> If you just want a minimal initramfs that calls btrfs scan on boot |
| 37 |
> without hacking the crap out of dracut, feel free to use my little |
| 38 |
> homegrown project. Just adjust the paths, make sure your busybox is |
| 39 |
> static, and you should be good to go. |
| 40 |
> |
| 41 |
> https://bitbucket.org/floppym/initramfs/src |
| 42 |
|
| 43 |
Thanks, but... |
| 44 |
|
| 45 |
I don't even have busybox installed[1] nor am I really familiar with it, |
| 46 |
tho I've probably used it in embedded context a few times without knowing |
| 47 |
it. So hacking on dracut probably /is/ easier for me, here, especially |
| 48 |
since I already have that working. |
| 49 |
|
| 50 |
But I've personally found replies nominally aimed at someone else useful |
| 51 |
enough often enough, that I believe chances are quite high someone else |
| 52 |
reading will find it useful, and indeed, I myself may find it |
| 53 |
instructional if I ever decide to hack up my own initr* lite, as I've |
| 54 |
thought about doing, so thanks, indeed. =:^) |
| 55 |
|
| 56 |
--- |
| 57 |
[1] Busybox not installed: Back in 2004 when I setup my first gentoo |
| 58 |
system, there was some bug that prevented busybox compilation, so I |
| 59 |
simply package.provided it and continued, thinking I'd get back to that |
| 60 |
later. I did try it a couple times later without success, by that time I |
| 61 |
realized I didn't really need it since I use an operation system snapshot |
| 62 |
partition as both an emergency recovery method and backup and thus don't |
| 63 |
really need an additional tool such as busybox, so I really didn't have a |
| 64 |
lot of motivation to fix the problem, and probably last tried building |
| 65 |
busybox 7+ years ago, now. |
| 66 |
|
| 67 |
These days of course I have an entirely empty @system, negating the |
| 68 |
entries in the cascading profile one by one and adding entries to one of |
| 69 |
the sets listed in world-sets instead where necessary, triggered as an |
| 70 |
effort to make portage's parallel build process more efficient since it |
| 71 |
serializes @system package and dependencies builds (and an empty @system |
| 72 |
really does help with that). So for all I know busybox isn't even in the |
| 73 |
default @system any more, but in any case I no longer have to |
| 74 |
package.provide it. =:^) |
| 75 |
|
| 76 |
-- |
| 77 |
Duncan - List replies preferred. No HTML msgs. |
| 78 |
"Every nonfree program has a lord, a master -- |
| 79 |
and if you use the program, he is your master." Richard Stallman |
Archives