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 F24EB1580E0 for ; Thu, 30 Jan 2025 22:56:59 +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 D5C3234316A for ; Thu, 30 Jan 2025 22:56:59 +0000 (UTC) Received: from bobolink.gentoo.org (localhost [127.0.0.1]) by bobolink.gentoo.org (Postfix) with ESMTP id 0774111047D; Thu, 30 Jan 2025 22:55:54 +0000 (UTC) Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) (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 EDF2E1103B6 for ; Thu, 30 Jan 2025 22:55:52 +0000 (UTC) Received: by mail-pj1-x1030.google.com with SMTP id 98e67ed59e1d1-2f13acbe29bso3916913a91.1 for ; Thu, 30 Jan 2025 14:55:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1738277752; x=1738882552; darn=lists.gentoo.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=PVFsZU55LYxZD8kymBMS1xl8J15XoSW6LvzXRGqbPow=; b=bEYDfMeqCmg+hiDbVDLmSZ/pqxofmuud0a3BnrroOZgSF+px5raVPhszfqRZvPSbvi /0jtWj3AAYflsmHAR+5zQHrQGdybT/o0blPNDJBuh0BZ6wl6eLSk36ygSfim0egPtSsc 3D2LCocPqKVJcJbSW/67HX3HGXUJCbXPsIcJl2OKfsbsz7Pk57KVJlxS/jMg5Fxir86J K5EXIwJv1W0aST4gwg+RbEFXUmxFhV3JqrO+nFCl/Ph3LuaCWLDtUmjQHYHNjcrCsZMd rxVEhnUgd2ybC3We9x3SQEeAFvFAzetv9hTndLQybDrldI2iGzI9OT4GQOmIVbUpfkE1 vvzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738277752; x=1738882552; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=PVFsZU55LYxZD8kymBMS1xl8J15XoSW6LvzXRGqbPow=; b=dFrkz2Ib4Td2O5BW4g346O1kQuXj9nQ6Q4AxYji05W+cvT1icK6vJiEd8FwYjDZo2q XXFAzkPaiIfSrm4DfeAbt+8jveJicU9SK6tBaG45g5qbivNF35uZ11cnvt+rK6uzIh5/ /XxZ0oi1O/OY5tmLzddyShDZRzK0MkYXGG7Aw0GS8R9ZcCk/pkGei3S1iB/sJG3xbCek dtrykSCMg3xrzB97Z+d6rQNcNOqwcdlWRx8o3PZs900+NCeo98LB8kyfeevmBDSw/MDl 4GWCj/dOYdo/eWCwGp40Q5/jVEA5haT0hrEBs9P8Iz7xTlKYIlSE3VLvZUWFw9JeDC1k YOxg== X-Gm-Message-State: AOJu0YwOMm/M9dkZt3ysODvBKrD+2v972d9sgh37nXctDnpu/k7GGmgS /KDizInglKVjxKpM9KjR4As8NdOHzerz9KksskLG03YeSt0oTSymDbRj3Wq3rbQ7vWnaBc6f6/J FsLQqTuuK+G39Bhl79vdsjZTqkOiYwxJU X-Gm-Gg: ASbGncvdHqboIC8nFHAaEDUj9S0dJKyklDQEg4JM9FtGPD7IaA7SyR9p2Y+LApfaS2d MLJp8Cvsdw9YZ7UngY+AJQHCP8f6wIW7cGokAt6SnBKbtCfMvRm1aChmB/LQpGiEaZXDjoKzuq9 U= X-Google-Smtp-Source: AGHT+IEQtGiPRLBM5M/zMfrZ4LhkFc5UWkNd+LCaIlzT8aeehaQ83BwnKpwVdAjf0FmWX5I1i22DgyC2749Udo9nwOs= X-Received: by 2002:a05:6a00:114c:b0:728:f21b:ce4c with SMTP id d2e1a72fcca58-72fe2d21274mr8391654b3a.5.1738277751774; Thu, 30 Jan 2025 14:55:51 -0800 (PST) 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 References: <1f5877ed-a700-70d5-415a-3516cedee895@gentoo.tnetconsulting.net> In-Reply-To: From: gevisz Date: Fri, 31 Jan 2025 00:55:39 +0200 X-Gm-Features: AWEUYZmjWJCGnjkd4xn95zJgt5mlolv9bqqOMFJTMz-lnQRZFamjLqcy77XRyM8 Message-ID: Subject: Re: [gentoo-user] Zombie Linux kernel To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Archives-Salt: b1e579a6-2ad5-4d60-8837-effed40b69e2 X-Archives-Hash: 415ea542d61514a7b1868be3ea60e785 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 kern= el immediately after compiling the new one." =D0=BF=D1=82, 31 =D1=8F=D0=BD=D0=B2. 2025=E2=80=AF=D0=B3. =D0=B2 00:49, gev= isz : > > =D1=87=D1=82, 30 =D1=8F=D0=BD=D0=B2. 2025=E2=80=AF=D0=B3. =D0=B2 23:31, G= rant Taylor : > > > > On 1/30/25 11:49=E2=80=AFAM, 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 jump= s > > 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 ha= d > > 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 o= f > > 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 zf= s > > 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-kmo= d > 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 director= y. > > > 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 thei= r > > own modules and other things in them. They are usually based off of th= e > > 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 attache= d > > > 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 kern= el > > > 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 speculatio= n > > 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. /boo= t > > 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 i= t. > > 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.