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