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)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id B23EC1580E0 for ; Fri, 31 Jan 2025 00:27:24 +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 9774834318F for ; Fri, 31 Jan 2025 00:27:24 +0000 (UTC) Received: from bobolink.gentoo.org (localhost [127.0.0.1]) by bobolink.gentoo.org (Postfix) with ESMTP id 7380811047D; Fri, 31 Jan 2025 00:26:18 +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 26E161103B6 for ; Fri, 31 Jan 2025 00:26:17 +0000 (UTC) Received: from REDACTED (omega.home.tnetconsulting.net [IPv6:198:18:1:0:0:0:0:11]) (authenticated bits=0) by tncsrv06.tnetconsulting.net (8.17.1.9/8.17.1.9) with ESMTPSA id 50V0QEIi027744 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Thu, 30 Jan 2025 18:26:15 -0600 Message-ID: <7f3ff79d-fe77-448f-8302-cc11c1a0e7cb@spamtrap.tnetconsulting.net> Date: Thu, 30 Jan 2025 18:26:14 -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 Thunderbird Subject: Re: [gentoo-user] Zombie Linux kernel To: gentoo-user@lists.gentoo.org References: <1f5877ed-a700-70d5-415a-3516cedee895@gentoo.tnetconsulting.net> From: Grant Taylor Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: Pass (sender authenticated); receiver=tncsrv06.tnetconsulting.net; client-ip=IPv6:198:18:1::11; envelope-from= Received-SPF: Pass (sender authenticated); receiver=tncsrv06.tnetconsulting.net; client-ip=IPv6:198:18:1::11; helo=REDACTED X-Scanned-By: milter-spamc/1.17.1 (tncsrv06.tnetconsulting.net [IPv6:2600:3c00:e000:1e9:1:1:1:8849]); Thu, 30 Jan 2025 18:26:15 -0600 X-Spam-Status: NO, hits=1.30 required=5.00 X-Spam-Level: x 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 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. | | Content analysis details: (1.3 points, 5.0 required) | | pts rule name description | ---- ---------------------- -------------------------------------------------- | 0.0 FSL_HELO_NON_FQDN_1 No description available. | 0.0 HELO_NO_DOMAIN Relay reports its domain incorrectly | 0.4 KHOP_HELO_FCRDNS Relay HELO differs from its IP's reverse DNS | 0.9 DMARC_NONE DMARC none policy | X-Archives-Salt: b068ed1c-d7f2-4fa3-9105-3ea79a54551e X-Archives-Hash: 5c3da6f7178fbbddbcd2f18f15b6c51b 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. . .