1 |
On Wed, Jul 18, 2012 at 3:05 PM, Rich Freeman <rich0@g.o> wrote: |
2 |
> On Wed, Jul 18, 2012 at 2:53 PM, Michael Mol <mikemol@×××××.com> wrote: |
3 |
>> AFAIK, neither genkernel nor dracut were expected to get tied to the |
4 |
>> Gentoo update process. Has that changed? |
5 |
> |
6 |
> We don't even update kernels as part of the regular update process, |
7 |
> let alone initramfs systems. |
8 |
> |
9 |
> In general you update them together. |
10 |
> |
11 |
> The only issue I could see is if problems arise if you have a |
12 |
> different version of udev in your initramfs than on your system. I |
13 |
> don't know if that actually causes problems. For the most part after |
14 |
> the system is booted the initramfs is done its job. |
15 |
|
16 |
The most widely touted benefit I've heard for initramfs is its |
17 |
capability to ease system recovery in case, e.g. a critical filesystem |
18 |
refuses to mount. With recovery roles come recovery tools, which |
19 |
quickly extends network-aware tools and a security attack surface. |
20 |
|
21 |
Hence why I tend to feel that if an initramfs is going to become the |
22 |
go-to solution for bootstrapping userland, it's important to consider |
23 |
the difficulties of keeping the packed tools up-to-date; it's not just |
24 |
a bootstrap tool, it's also the first recovery option a sysadmin |
25 |
faces. |
26 |
|
27 |
> |
28 |
> If some package did need a kernel/initramfs/etc to be updated it |
29 |
> should be the subject of news or an ewarn unless it becomes routine |
30 |
> practice. I don't think we want the system to start touching these |
31 |
> things without operator intervention unless we make it really |
32 |
> bulletproof like they do on big distros (the only reason they can is |
33 |
> they have one-size-fits-all kernels and initramfs designs). |
34 |
|
35 |
Absolutely. |
36 |
|
37 |
-- |
38 |
:wq |