From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 9F32B1580E0 for ; Thu, 30 Jan 2025 21:31:12 +0000 (UTC) Received: from lists.gentoo.org (bobolink.gentoo.org [140.211.166.189]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) (Authenticated sender: relay-lists.gentoo.org@gentoo.org) by smtp.gentoo.org (Postfix) with ESMTPSA id 8B731343157 for ; Thu, 30 Jan 2025 21:31:12 +0000 (UTC) Received: from bobolink.gentoo.org (localhost [127.0.0.1]) by bobolink.gentoo.org (Postfix) with ESMTP id 9800B11047D; Thu, 30 Jan 2025 21:29:47 +0000 (UTC) Received: from tncsrv06.tnetconsulting.net (tncsrv06.tnetconsulting.net [IPv6:2600:3c00:e000:1e9::8849]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by bobolink.gentoo.org (Postfix) with ESMTPS id 467751103B6 for ; Thu, 30 Jan 2025 21:29:46 +0000 (UTC) Received: from [IPV6:198:18:1:0:20c:29ff:fe4b:cb3e] ([IPv6:198:18:1:0:20c:29ff:fe4b:cb3e]) (authenticated bits=0) by tncsrv06.tnetconsulting.net (8.17.1.9/8.17.1.9) with ESMTPSA id 50ULThoV003736 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Thu, 30 Jan 2025 15:29:44 -0600 Message-ID: <1f5877ed-a700-70d5-415a-3516cedee895@gentoo.tnetconsulting.net> Date: Thu, 30 Jan 2025 15:29:43 -0600 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [gentoo-user] Zombie Linux kernel Content-Language: en-US To: gentoo-user@lists.gentoo.org References: From: Grant Taylor In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: Pass (sender authenticated); receiver=tncsrv06.tnetconsulting.net; client-ip=IPv6:198:18:1::20c:29ff:fe4b:cb3e; envelope-from= Received-SPF: Pass (sender authenticated); receiver=tncsrv06.tnetconsulting.net; client-ip=IPv6:198:18:1::20c:29ff:fe4b:cb3e; helo=[IPV6:198:18:1:0:20c:29ff:fe4b:cb3e] X-Scanned-By: milter-spamc/1.17.1 (tncsrv06.tnetconsulting.net [IPv6:2600:3c00:e000:1e9:0:0:0:8849]); Thu, 30 Jan 2025 15:29:44 -0600 X-Spam-Status: NO, hits=0.30 required=5.00 X-Spam-Level: X-Spam-Report: Spam detection software, running on the system "tncsrv06.tnetconsulting.net", | has NOT identified this incoming email as spam. The original | message has been attached to this so you can view it or label | similar future email. If you have any questions, see | the administrator of that system for details. | | Content preview: 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. | | Content analysis details: (0.3 points, 5.0 required) | | pts rule name description | ---- ---------------------- -------------------------------------------------- | 0.0 HELO_NO_DOMAIN Relay reports its domain incorrectly | 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS | -2.9 NICE_REPLY_A Looks like a legit reply (A) | 1.0 MAY_BE_FORGED Relay IP's reverse DNS does not resolve to IP | 0.9 DMARC_NONE DMARC none policy | X-Archives-Salt: f4f6a1a4-b3fb-4aed-8e64-d5753660a26c X-Archives-Hash: 1b4d82e1b31296da8bde33114e5a310b 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. . . .