1 |
On Tue, May 28, 2019 at 4:35 AM Neil Bothwick <neil@××××××××××.uk> wrote: |
2 |
> |
3 |
> On Tue, 28 May 2019 04:04:23 -0400, John Covici wrote: |
4 |
> |
5 |
> > In my latest update, there is a hard block sys-kernel/spl-0.7.13 is |
6 |
> > blocking 0.8.0. Can I unmerge the old one and still have access to my |
7 |
> > pools while the new one is compiled. My whole system except /boot is |
8 |
> > on zfs, this is wny I am asking, or should I do this one emerge from a |
9 |
> > rescue disk? |
10 |
> |
11 |
> spl is now part of the zfs package, so you will still have it after |
12 |
> updating. During the update, the module will still be in memory. If you |
13 |
> reboot during the update, you will have a problem, I kept a backup copy |
14 |
> of the spl modules just in case, or you could quickpkg spl. |
15 |
|
16 |
The one file you really need is: |
17 |
/lib/modules/4.19.46/extra/spl/spl.ko.gz |
18 |
(or whatever version you're using). |
19 |
|
20 |
I would personally do the switch during a kernel update, so that you |
21 |
can leave your old modules around and boot the old kernel. |
22 |
|
23 |
I'm honestly not sure if portage will leave the old kernel module in |
24 |
place when doing the switch. Looking at my kernel directory I see old |
25 |
spl modules so when re-emerging spl it isn't removing the old modules. |
26 |
However, I also can't see any documented mechanism that would protect |
27 |
kernel modules from unmerging. It could be an undocumented portage |
28 |
feature (it does make sense to leave the old kernel modules around). |
29 |
|
30 |
If you update an existing kernel in-place none of this will help as |
31 |
the zfs bundled spl would overwrite the spl-bundled version. And of |
32 |
course it wouldn't make sense to mix the two in a kernel anyway. |
33 |
|
34 |
I'll see how it goes in a few months when I try out 0.8. As much as |
35 |
I'm looking forward to a few of its features I'm really in no rush to |
36 |
go trying new versions of filesystems... |
37 |
|
38 |
-- |
39 |
Rich |