On 1/30/25 16:49, gevisz wrote:
Because, as I wrote it, it was easier than to try to change a profile
with the procedure described in the corresponding news.
I take that as you chose to do the fresh install, not that something
forced you to do the fresh install. It's perfectly fine if that's the
choice you made.
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.
Each chooses their own. ;-)
Well, maybe you are right. I did (NOT) know this and so deleted the old
kernel immediately after compiling the new one.
Now you know for the next time. :-)
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 tend to keep my current and previous kernel source tree and module
tree around for these very types of reasons. At least if I'm not tight
on disk space.
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.
Usually, the incompatibility is when I've made a big change in the
kernel that can fundamentally alter things. E.g. enabled / disabled an
entire sub-system or made changes to any security related settings.
That is usually the size of the change that needs to be made in the
kernel config to render the existing ZFS / SPL module incompatible for
me. Smaller changes usually don't impact ZFS / SPL.
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.
I don't use initramfs so I can't say. I try to keep what I need to boot
and come up into single user mode in the kernel. But I've run into this
type of discrepancy on other people's systems.
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.
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.
Unexpectedly getting dropped at a grub prompt when booting is never fun.
Some consider it a right of passage, sort of like accidentally
rebooting the wrong system, or causing data loss in production.
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.
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.
Correct.
BIOS based booting is ... or can be annoyingly complicated.
My alternative explanation was that the uname -a command was actually
accessing not the current kernel but the GRUB logs.
My understanding is that the kernel part of the uname command's output
comes from the running kernel, not something on disk.
Currently, with my new kernel loaded, lsmod does not report XFS kernel
module being loaded into the memory.
I would expect that XFS wouldn't show in the lsmod output if XFS is
complied into the kernel.
Remember, lsmod shows modules dynamically loaded into the running
kernel, not things complied in.
--
Grant. . .
