On 1/30/25 11:49 AM, gevisz wrote:
I have not updated my Gentoo system since May 31, 2024, so in the
middle of October 2024 I had to install it anew.
Why did you have to install it anew?
I've pulled Gentoo systems more than three years forward. I've talked
about how to do it on this mailing list in the past, including the
scripts that I was using at the time.
I posted about pulling a system last updated in March '21 to current
last November.
https://oldbytes.space/@drscriptt/113460218243172979
In short, switch to a git based Gentoo repo and do a bunch of tiny jumps
from the last update you did through current. It takes time and does a
LOT of compilation. But it works.
Just to remind you: during that time we all had to switch to the new
Gentoo profile scheme, which made an update from my old system more
difficult than a new install.
I'm not able to log in and check the profile the system is on. But I
feel like I could have handled the profile change in December '24 just
like I could have when the profile change came out. The repo just
needed to have the branch checked out that was shortly after when the
profile came out.
On October 26, I compiled a new Linux kernel. It had version 6.6.52
and worked quite well.
However, with time it disappeared from the Gentoo portage tree. So,
11 days ago I compiled kernel version 6.6.62 and successfully booted
my Gentoo system with it over the next 9 days.
The old kernel of version 6.6.52 was deleted from the /boot directory
just after compilation of kernel version 6.6.62 just because it could
not support my home ZFS disks any more (because zfs-kmod should be
compiled against the specific kernel version and would not work with
another one).
Um ... kernel modules are kernel version dependent. You should have had
two different kernel modules, one for each kernel.
/lib/modules/6.6.52.../zfs.ko
/lib/modules/6.6.62.../zfs.ko
But yesterday, after booting my Gentoo system, the uname -a command
reported that I have been booted with the deleted old kernel version
6.6.52 compiled on October 26, 2024! And, of course, it did not
mount my ZFS /home.
So the kernel is still there.
Did you manually delete the zfs / spl kernel modules?
I've had various other types of things break zfs / spl kernel module
compatibility even in the same version. I'd have to look at my motes of
what I do to get the module to work again. I think it usually involves
a round of make bzImage modules modules_prepare, and re-emerging the zfs
kmodule. But I may be mis-remembering.
I have double checked everything: the old kernel of version 6.6.52
together with its initramfs have been deleted from the /boot directory.
Moreover, just a day before I deleted /usr/lib/modules/6.6.52-gentoo/
directory.
initramfs complicate things and I tend to not use them. They have their
own modules and other things in them. They are usually based off of the
current system but can get out of sync relatively easily. So you could
have modules coming from the initramfs and not the root file system.
I tried to reboot and found out that GRUB menu had only an option of
loading the old kernel of version 6.6.52.
Did you try going to the GRUB command line and modifying it to match
what should have been on the system?
I've found that contemporary GRUB has tab completion and is generally
nicer to work with than older Korn shells.
However, I soon understood that the latter was because I have attached
additional HDD before booting my Gentoo system, and as a result of
this the system decided to boot from another HDD where I have not
installed a new GRUB file. So, I fixed it and my Gentoo system was
finally able to boot with the new kernel of version 6.6.62.
Ya, device ordering can be a problem. That's one of the main reasons
that I like UUIDs to identify file systems et al. If you can get the
boot loader to start off of the correct disk, you're usually in place
that you can pull yourself up by your boot straps.
But the mystery of loading my Gentoo system with deleted kernel and
deleted modules remains. How could that happen at all?
The kernel and modules are somewhere that GRUB found them lest it
wouldn't have booted them.
My only explanation is that XFS actually had not deleted the old kernel
and the modules directory but only marked them as such. So, the old
GRUB file could load them even when they had been marked as deleted.
But is this explanation actually correct?
I don't know that it's not correct, but I am very suspicious of it. I
would expect that GRUB's support for XFS would look at files that aren't
marked for deletion.
There are a number of things that come to mind that are pure speculation
if you're no longer in that configuration to be able to look. Not the
least of which is files in file systems on different devices; e.g. /boot
vs /. Have a file in the /boot directory on the / (root) file system
and it will be covered up when the /boot file system is mounted. Or
something like that.
--
Grant. . . .
