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 |