1 |
On Monday, August 15, 2016 08:41:31 AM Rich Freeman wrote: |
2 |
> On Mon, Aug 15, 2016 at 5:06 AM, J. Roeleveld <joost@××××××××.org> wrote: |
3 |
> > On Monday, August 15, 2016 04:32:29 AM Rich Freeman wrote: |
4 |
> >> It is also somewhat dependent on a correct fstab. Don't take that for |
5 |
> >> granted: the kernel doesn't look at fstab at all when mounting root, |
6 |
> >> and neither do most of the other tools, so if your root partition |
7 |
> >> isn't correctly defined in fstab you might never know it and dracut |
8 |
> >> will get confused. If nothing else once it does have it correctly |
9 |
> >> mounted it will read fstab and then mess it up when it re-mounts root |
10 |
> >> per "your" instructions. |
11 |
> > |
12 |
> > I understand what you're saying. Except in my case, that wasn't the cause. |
13 |
> |
14 |
> Oh, I agree. I just said that in lieu of replying to every single |
15 |
> other email in this thread. :) |
16 |
> |
17 |
> >> If you just need to tweak dracut behavior you may be better off with a |
18 |
> >> dracut module. They're just shell scripts and pretty simple to write. |
19 |
> >> That lets you tweak something at some point during boot without having |
20 |
> >> to build the entire thing yourself. |
21 |
> > |
22 |
> > This actually had (or has, not bothered to check current status) a |
23 |
> > distinct |
24 |
> > lack of usable documentation. Looking for clear howto's on creating my own |
25 |
> > (embedded into the kernel) initramfs was a lot quicker. |
26 |
> |
27 |
> Yeah, I found this frustrating as well. |
28 |
> |
29 |
> This may or may not be helpful: |
30 |
> https://rich0gentoo.wordpress.com/2012/01/21/a-quick-dracut-module/ |
31 |
|
32 |
It shows where to find it and add custom steps. |
33 |
For my scenario, I'd need to first find where the code is that currently handles |
34 |
it. Disable that and insert my own in its place. |
35 |
The majority works, except for it asking for my passphrase multiple times, |
36 |
which, in Dracut, might actually be handled by "cryptsetup" itself. In which |
37 |
case I'm stuck. |
38 |
|
39 |
In my script it's handled via: |
40 |
---- |
41 |
# Obtain key through loop device |
42 |
/sbin/losetup /dev/loop0 /key.iso || rescue_shell |
43 |
/sbin/cryptsetup -T 5 luksOpen /dev/loop0 key || rescue_shell |
44 |
|
45 |
# Unlock the root partition |
46 |
/sbin/cryptsetup --key-file /dev/mapper/key luksOpen --allow-discards /dev/sda2 |
47 |
sda2 || rescue_shell |
48 |
/sbin/cryptsetup --key-file /dev/mapper/key luksOpen --allow-discards /dev/sdb2 |
49 |
sdb2 || rescue_shell |
50 |
|
51 |
# Clean up the loop device |
52 |
/sbin/cryptsetup luksClose key |
53 |
/sbin/losetup -d /dev/loop0 |
54 |
---- |
55 |
|
56 |
> In general the benefits of using dracut are the benefits of using |
57 |
> anything that somebody else maintains. You could replace openrc with |
58 |
> a single shell script as well, or a fair bit of systemd. That doesn't |
59 |
> mean that this is really the optimal approach. |
60 |
|
61 |
If I'd need the level of complexity Dracut allows, I'd look into it. But all I |
62 |
need to do is maintain a few small and simple files and the kernel-build |
63 |
handles all the heavy lifting. |
64 |
|
65 |
> >> And since it uses udev it is fairly robust against things like adding |
66 |
> >> a drive and now the kernel re-letters everything. |
67 |
> > |
68 |
> > If I were using normal partitioning, I wouldn't need an initramfs. |
69 |
> |
70 |
> An initramfs is beneficial even if you don't "need" one. To start |
71 |
> with it allows you to build a more modular kernel, which is especially |
72 |
> beneficial if you aren't customizing your kernel for every host. It |
73 |
> also tends to be more robust when something goes wrong. You end up |
74 |
> having a rescue shell even if root doesn't mount, more robust fsck/etc |
75 |
> during early boot, and it is going to be a lot smarter when you |
76 |
> add/remove a drive (since root can be identified by UUID or label). |
77 |
> |
78 |
> Dracut is becoming common enough that I think it is worth learning... |
79 |
|
80 |
For binary distributions, I tend to stick with the supplied kernel and |
81 |
initramfs. Those are usually for running software from big vendors like Oracle |
82 |
or IBM. |
83 |
|
84 |
For the rest, it's quicker to make the few changes needed to the init-script. |
85 |
I don't have a large serverfarm requiring that level of standardisation. |
86 |
|
87 |
-- |
88 |
Joost |