| 1 |
On Aug 22, 2013 1:28 PM, "J. Roeleveld" <joost@××××××××.org> wrote: |
| 2 |
> Correct, and here lies the cause for the "out of sync" scenario. |
| 3 |
> |
| 4 |
> > So the only "out of sync" scenario that should matter is with the |
| 5 |
> > kernel or kernel modules. Even if it were out of sync with your |
| 6 |
> > current toolset it should still be able |
| 7 |
> > to perform the pivot. Shouldn't any "userland stuff" that |
| 8 |
> > breaks initramfs BE in initramfs? |
| 9 |
> |
| 10 |
> Incorrect, there are userland tools, like LVM and MDADM (layout 1.2 does |
| 11 |
> NOT support auto-assembly by kernel), that are needed to access of the |
| 12 |
> filesystems. |
| 13 |
> |
| 14 |
> It is possible that an older version of one of these tools, after an |
| 15 |
> update, can no longer access the disks succesfully. When portage updates |
| 16 |
> this package, the initramfs is not automatically updated with the new |
| 17 |
> version. |
| 18 |
|
| 19 |
Ok. I don't use raid / lvm on my desktop so I missed the obvious case of a |
| 20 |
user tool that needs to be in initramfs. |
| 21 |
|
| 22 |
But it makes sense. Any tool that affects filesystem mounting at the very |
| 23 |
least of /usr, even if its cifs or nfs or whatev, should be included in |
| 24 |
initramfs. This is gentoo, not ubuntu. Blind updates are known to be |
| 25 |
irresponsible behavior. Is this a big deal? |
Archives