Re: [gentoo-user] Zombie Linux kernel

[gevisz <gevisz@gmail.com>]

Correction: My second paragraph in the last email should read:
"Well, maybe you are right. I did NOT know this and so deleted the old kernel
immediately after compiling the new one."

пт, 31 янв. 2025 г. в 00:49, gevisz <gevisz@gmail.com>:
>
> чт, 30 янв. 2025 г. в 23:31, Grant Taylor <gtaylor@gentoo.tnetconsulting.net>:
> >
> > 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?
>
> Because, as I wrote it, it was easier than to try to change a profile
> with the procedure described in the corresponding news. Moreover,
> it was written in the same news that the result is not guaranteed.
> So, why to do a lot of compilation just to try if it will work, while
> I did knew that starting from scratch I will get the guaranteed
> result with less compilation.
>
> > 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
>
> Well, maybe you are right. I did know this and so deleted the old kernel
> immediately after compiling the new one.
>
> > > 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?
>
> Yes, I manually deleted the /usr/lib/modules/6.6.52-gentoo/
> directory just before the last shutdown before this happened.
> Moreover, at the same time I manually deleted everything from
> directory /usr/src/linux-6.6.52-gentoo/ except for the .config file.
>
> > 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.
>
> So far, I had no problems with incompatibility of the kernel and the ZFS
> kernel module. But I always followed the instruction to recompile zfs-kmod
> after compiling the kernel.
>
> > > 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 do not know if I needed it taking into account that I have compiled
> the XFS module into the kernel. But I have created
> initramfs-6.6.62-gentoo.img
> file with the command
> genkernel --install initramfs
> and I hope that the genkernel was wise enough to create it based
> on the /usr/lib/modules/6.6.62-gentoo/ directory and not the
> /usr/lib/modules/6.6.52-gentoo/ directory that still was present at that time.
>
> Maybe, the file /boot/vmlinuz-6.6.52-gentoo also was present at the time
> of creating initramfs-6.6.62-gentoo.img but I definitely deleted
> /boot/vmlinuz-6.6.52-gentoo just after that.
>
> > > 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?
>
> No, I never did it in my life even with online documentation present,
> so I even have not tried to do it with just a GRUB command line before me.
>
> All that I managed to do is just to recall the commands
> grub-mkconfig -o /boot/grub/grub.cfg
> and
> grub-install /dev/sdc
> and executed them.
>
> > 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, as far as I know, the UUID does not help to identify the disk,
> from which the system starts as it is managed by BIOS.
>
> > > 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.
>
> But they have not been present in the /boot/ directory,
> nor in /usr/lib/ directory, nor in the /usr/src/ directory.
>
> > > 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.
>
> I do agree with you that such an explanation is at least strange.
> However, I do not have any other.
>
> My alternative explanation was that the uname -a command was actually
> accessing not the current kernel but the GRUB logs. However, it would be
> extremely strange and was refuted by the fact that XFS kernel module
> was loaded into memory according to lsmod.
>
> Currently, with my new kernel loaded, lsmod does not report XFS kernel
> module being loaded into the memory.
>
> > 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.
>
> I have not created a separate partition for the /boot directory.
> It is located in the / (root) partition. So, there is nothing to shadow it.
>
> I have also checked the other disk partitions. Some of them do have
> the /boot directory but neither of them contains the kernel 6.6.52.
> They do contain much older kernel versions.