Re: What's the purpose of initrd.img{,.old} and vmlinuz{,.old} symlinks in the root dir?
On Sun 01 Mar 2020 at 18:11:07 (+0100), Mikhail Morfikov wrote: > On 01/03/2020 17:15, mick crane wrote: > > On 2020-02-29 18:17, Mikhail Morfikov wrote > > > >> vmlinuz -> boot/vmlinuz-5.4.0-4-amd64 > >> lrwxrwxrwx 1 root root 24 2020-02-24 00:37:53 > >> vmlinuz.old -> boot/vmlinuz-5.5.4-amd64 > >> > > > > .old is pointing to a newer kernel ? > > > > mick > > > > Yes, it is because I updated recently the debian kernel. So I think it thinks > the older is newer now. But after moving the links to the /boot/ dir, I get: > > $ ls -al /boot/ | egrep "vmlinuz|initrd" > lrwxrwxrwx 1 root root 22 2020-03-01 15:18:21 initrd.img -> > initrd.img-5.5.4-amd64 > -rw-r--r-- 1 root root 39127233 2020-02-14 17:23:07 initrd.img-5.4.0-4-amd64 > -rw-r--r-- 1 root root 16005450 2020-03-01 14:41:38 initrd.img-5.5.4-amd64 > lrwxrwxrwx 1 root root 24 2020-03-01 15:18:21 initrd.img.old -> > initrd.img-5.4.0-4-amd64 > lrwxrwxrwx 1 root root 19 2020-03-01 15:18:21 vmlinuz -> > vmlinuz-5.5.4-amd64 > -rw-r--r-- 1 root root 5627632 2020-02-13 06:14:49 vmlinuz-5.4.0-4-amd64 > -rw-r--r-- 1 root root 9331760 2020-02-26 09:38:52 vmlinuz-5.5.4-amd64 > lrwxrwxrwx 1 root root 21 2020-03-01 15:18:21 vmlinuz.old -> > vmlinuz-5.4.0-4-amd64 > > So the .old points now to the older one. But I don't need the debian kernel > anyway since I build it on my own. I haven't removed it just in case. :] But > I think I will remove it when I set everything up to avoid such situations. I haven't had to compile a linux kernel for probably 15 years, but I always used an epoch so that my kernel-image package could have the correct version number but would always be viewed as newer by the APT programs. It was just a matter of adding 5: between the underscore and the upstream version. (5 is a random choice, you could choose 202003051130: if you wanted to timestamp it.) Cheers, David.
Re: What's the purpose of initrd.img{,.old} and vmlinuz{,.old} symlinks in the root dir?
Mikhail Morfikov wrote: ... > Also, I'm trying to configure refind EFI boot manager, and basically I do= > n't > want to change its config file with each kernel update (the numbers in th= > e file > names change). that's exactly what i've been doing. they work fine no matter where they end up as long as you adjust your refind config to work with them. songbird
Re: What's the purpose of initrd.img{,.old} and vmlinuz{,.old} symlinks in the root dir?
Brian composed on 2020-03-01 16:10 (UTC): > On Sun 01 Mar 2020 at 08:41:09 -0500, Felix Miata wrote: >> Grub does not like symlinks to un-versioned kernel and initrd in /boot/. > I am probably missing your point but I have just booted successfully > with: > root='hd1,msdos5' > linux /vmlinuz.old root=/dev/sdb5 > initrd /initrd.img.old "Grub" was the wrong word. It looks like dpkg might have been appropriate. Here's where I see the dislike: Canceled hold on linux-image-amd64. # apt dist-upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages were automatically installed and are no longer required: ... Use 'apt autoremove' to remove them. The following NEW packages will be installed: linux-image-4.19.0-8-amd64 The following packages have been kept back: grub-legacy The following packages will be upgraded: linux-image-amd64 1 upgraded, 1 newly installed, 0 to remove and 1 not upgraded. Need to get 48.1 MB of archives. After this operation, 269 MB of additional disk space will be used. Do you want to continue? [Y/n] y Get:1 http://ftp.debian.org/debian buster/main amd64 linux-image-4.19.0-8-amd64 amd64 4.19.98-1 [48.1 MB] Get:2 http://ftp.debian.org/debian buster/main amd64 linux-image-amd64 amd64 4.19+105+deb10u3 [8,120 B] Fetched 48.1 MB in 38s (1,275 kB/s) Reading changelogs... Done Selecting previously unselected package linux-image-4.19.0-8-amd64. (Reading database ... 107064 files and directories currently installed.) Preparing to unpack .../linux-image-4.19.0-8-amd64_4.19.98-1_amd64.deb ... Unpacking linux-image-4.19.0-8-amd64 (4.19.98-1) ... Preparing to unpack .../linux-image-amd64_4.19+105+deb10u3_amd64.deb ... Unpacking linux-image-amd64 (4.19+105+deb10u3) over (4.19+105+deb10u1) ... Setting up linux-image-4.19.0-8-amd64 (4.19.98-1) ... I: /vmlinuz.old is now a symlink to boot/vmlinuz-4.19.0-6-amd64 I: /initrd.img.old is now a symlink to boot/initrd.img-4.19.0-6-amd64 I: /vmlinuz is now a symlink to boot/vmlinuz-4.19.0-8-amd64 I: /initrd.img is now a symlink to boot/initrd.img-4.19.0-8-amd64 /etc/kernel/postinst.d/initramfs-tools: update-initramfs: Generating /boot/initrd.img-4.19.0-8-amd64 I: The initramfs will attempt to resume from /dev/sda5 I: (UUID=1e43d736-b4a1-4144-8f2f-81f873192d61) I: Set the RESUME variable to override this. /etc/kernel/postinst.d/zz-update-grub: Searching for GRUB installation directory ... found: /boot/grub Searching for default file ... found: /boot/grub/default Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst Searching for splash image ... none found, skipping ... dpkg: warning: version 'prv3' has bad syntax: version number does not start with digit dpkg: warning: version 'prv4' has bad syntax: version number does not start with digit dpkg: warning: version 'prv2' has bad syntax: version number does not start with digit dpkg: warning: version 'prv4' has bad syntax: version number does not start with digit dpkg: warning: version 'prv2' has bad syntax: version number does not start with digit dpkg: warning: version 'prv3' has bad syntax: version number does not start with digit dpkg: warning: version 'prv' has bad syntax: version number does not start with digit dpkg: warning: version 'prv4' has bad syntax: version number does not start with digit dpkg: warning: version 'prv' has bad syntax: version number does not start with digit dpkg: warning: version 'prv3' has bad syntax: version number does not start with digit dpkg: warning: version 'prv' has bad syntax: version number does not start with digit dpkg: warning: version 'prv2' has bad syntax: version number does not start with digit dpkg: warning: version 'prv4' has bad syntax: version number does not start with digit dpkg: warning: version 'prv3' has bad syntax: version number does not start with digit dpkg: warning: version 'prv2' has bad syntax: version number does not start with digit dpkg: warning: version 'prv' has bad syntax: version number does not start with digit dpkg: warning: version 'prv4' has bad syntax: version number does not start with digit dpkg: warning: version 'prv3' has bad syntax: version number does not start with digit dpkg: warning: version 'prv2' has bad syntax: version number does not start with digit dpkg: warning: version 'prv' has bad syntax: version number does not start with digit dpkg: warning: version 'prv4' has bad syntax: version number does not start with digit dpkg: warning: version 'prv3' has bad syntax: version number does not start with digit dpkg: warning: version 'prv2' has bad syntax: version number does not start with digit dpkg: warning: version 'prv' has bad syntax: version number does not start with digit dpkg: warning: version 'prv4' has bad syntax: version number does not start with digit dpkg: warning: version 'prv3' has bad syntax: version number does not start with digit dpkg: warning: version 'prv2' has b
Re: What's the purpose of initrd.img{,.old} and vmlinuz{,.old} symlinks in the root dir?
On 01/03/2020 17:15, mick crane wrote: > On 2020-02-29 18:17, Mikhail Morfikov wrote > >> vmlinuz -> boot/vmlinuz-5.4.0-4-amd64 >> lrwxrwxrwx 1 root root 24 2020-02-24 00:37:53 >> vmlinuz.old -> boot/vmlinuz-5.5.4-amd64 >> > > .old is pointing to a newer kernel ? > > mick > Yes, it is because I updated recently the debian kernel. So I think it thinks the older is newer now. But after moving the links to the /boot/ dir, I get: $ ls -al /boot/ | egrep "vmlinuz|initrd" lrwxrwxrwx 1 root root 22 2020-03-01 15:18:21 initrd.img -> initrd.img-5.5.4-amd64 -rw-r--r-- 1 root root 39127233 2020-02-14 17:23:07 initrd.img-5.4.0-4-amd64 -rw-r--r-- 1 root root 16005450 2020-03-01 14:41:38 initrd.img-5.5.4-amd64 lrwxrwxrwx 1 root root 24 2020-03-01 15:18:21 initrd.img.old -> initrd.img-5.4.0-4-amd64 lrwxrwxrwx 1 root root 19 2020-03-01 15:18:21 vmlinuz -> vmlinuz-5.5.4-amd64 -rw-r--r-- 1 root root 5627632 2020-02-13 06:14:49 vmlinuz-5.4.0-4-amd64 -rw-r--r-- 1 root root 9331760 2020-02-26 09:38:52 vmlinuz-5.5.4-amd64 lrwxrwxrwx 1 root root 21 2020-03-01 15:18:21 vmlinuz.old -> vmlinuz-5.4.0-4-amd64 So the .old points now to the older one. But I don't need the debian kernel anyway since I build it on my own. I haven't removed it just in case. :] But I think I will remove it when I set everything up to avoid such situations. signature.asc Description: OpenPGP digital signature
Re: What's the purpose of initrd.img{,.old} and vmlinuz{,.old} symlinks in the root dir?
On 01/03/2020 16:53, David Wright wrote: > I've read here that Grub can decrypt LUKS, but currently only v1, > at least in buster, so no help to you. Actually grub supports LUKSv2[1], but I haven't tried it yet. [1]: https://git.savannah.gnu.org/cgit/grub.git/commit/?id=365e0cc3e7e44151c14dd29514c2f870b49f9755 signature.asc Description: OpenPGP digital signature
Re: What's the purpose of initrd.img{,.old} and vmlinuz{,.old} symlinks in the root dir?
On 3/1/20, Brian wrote: > On Sun 01 Mar 2020 at 08:41:09 -0500, Felix Miata wrote: > >> >> Grub does not like symlinks to un-versioned kernel and initrd in /boot/. > > I am probably missing your point but I have just booted successfully > with: > > root='hd1,msdos5' > linux /vmlinuz.old root=/dev/sdb5 > initrd /initrd.img.old My brain interpreted it to mean something like /boot/vmlinuz -> boot/vmlinuz-x.x.x-x-amd64 Having said that AND it written out to explain where MY brain went: Maybe any reported fail is somehow tied to the missing slash (or when it's in place, instead)... *IF* this is even the scenario that was originally referenced. When it's under "/" root/, I like the missing slash. I think I wrote a while back that I've had symlinks that point to "/boot/vmlinuz-x.x.x-x-amd64" take me to the [HOST] computer's /boot directory, NOT the [guest] in chroot. I only discovered that accidentally one time when I had to run "ls -ld" on vmlinuz and initrd.img for some long forgotten reason... or another. DISCLAIMER It's possible it had something to do with how I was mounting chroot's fstab when I first started doing debootstrap installs.. Cindy :) -- Cindy-Sue Causey Talking Rock, Pickens County, Georgia, USA * runs with birdseed *
Re: What's the purpose of initrd.img{,.old} and vmlinuz{,.old} symlinks in the root dir?
On 2020-02-29 18:17, Mikhail Morfikov wrote vmlinuz -> boot/vmlinuz-5.4.0-4-amd64 lrwxrwxrwx 1 root root 24 2020-02-24 00:37:53 vmlinuz.old -> boot/vmlinuz-5.5.4-amd64 .old is pointing to a newer kernel ? mick -- Key ID4BFEBB31
Re: What's the purpose of initrd.img{,.old} and vmlinuz{,.old} symlinks in the root dir?
On Sun 01 Mar 2020 at 08:41:09 -0500, Felix Miata wrote: > Brian composed on 2020-03-01 13:26 (UTC): > > > On Sat 29 Feb 2020 at 19:15:12 -0600, David Wright wrote: > > >> On Sat 29 Feb 2020 at 19:17:39 (+0100), Mikhail Morfikov wrote: > > >>> # ls -al / > >>> ... > >>> lrwxrwxrwx 1 root root 29 2020-02-14 17:22:18 initrd.img -> > >>> boot/initrd.img-5.4.0-4-amd64 > >>> lrwxrwxrwx 1 root root 27 2020-02-24 00:37:53 initrd.img.old -> > >>> boot/initrd.img-5.5.4-amd64 > >>> ... > >>> lrwxrwxrwx 1 root root 26 2020-02-14 17:22:18 vmlinuz -> > >>> boot/vmlinuz-5.4.0-4-amd64 > >>> lrwxrwxrwx 1 root root 24 2020-02-24 00:37:53 vmlinuz.old -> > >>> boot/vmlinuz-5.5.4-amd64 > > >>> So I have a question here: what's the purpose of the links? > > >> They're a convenience. If you want them kept in /boot, then edit > >> /etc/kernel-img.conf and linux-update-symlinks will recreate them > >> there when the kernel is updated. Ditto if you want them removed. > > > They are also useful to reference on the linux and initrd lines when > > booting with GRUB to rescue a system. I'd leave them there. > > + + + :-) > > Grub does not like symlinks to un-versioned kernel and initrd in /boot/. I am probably missing your point but I have just booted successfully with: root='hd1,msdos5' linux /vmlinuz.old root=/dev/sdb5 initrd /initrd.img.old -- Brian.
Re: What's the purpose of initrd.img{,.old} and vmlinuz{,.old} symlinks in the root dir?
On Sun 01 Mar 2020 at 15:09:34 (+0100), Mikhail Morfikov wrote: > On 01/03/2020 02:15, David Wright wrote: > > They're a convenience. If you want them kept in /boot, then edit > > /etc/kernel-img.conf and linux-update-symlinks will recreate them > > there when the kernel is updated. Ditto if you want them removed. > I didn't know there's even such an option. But yes, it creates links > in /boot/ now. Excellent. > >> Also, I'm trying to configure refind EFI boot manager, and > >> basically I don't want to change its config file with each kernel > >> update (the numbers in the file names change). > > > > I'm not familiar with that, but one of the reasons there are links > > in root is for that very reason: their names don't change. > That's why I need those links in /boot/ , so refind would easily pick > them up. > > > You don't say why *you* think it's better to create links in /boot, > > so I'm not sure why we're expected to think so too. But if you want > > them in both places, I think you have to maintain them in the other > > location yourself. > I thought it was obvious, but I write it again to be clear. I'm using > LUKSv2+LVM setup and (so far) syslinux/extlinux as a bootloader in > MBR/MS-DOS partition layout (this will change to refind + EFI soon). Yes, as I said, I don't know anything about their capabilities. I've read here that Grub can decrypt LUKS, but currently only v1, at least in buster, so no help to you. > So my machine is encrypted entirely, and only the /boot/ (and future > ESP) partition remains unencrypted. When my system creates the links > to the initrd and kernel in / , they're useless since you have to > decrypt the root partition in order to get to those links, and in > order to decrypt the partition, you have to load the kernel first, > but when you load the kernel, you don't need the links anymore... So > as you can see the better place for the links is in /boot/ and not > in / , at least in the case of fully encrypted installation setups. In your case, that sounds sensible. Hence the option I described, I guess. Cheers, David.
Re: What's the purpose of initrd.img{,.old} and vmlinuz{,.old} symlinks in the root dir?
On 01/03/2020 02:15, David Wright wrote: > They're a convenience. If you want them kept in /boot, then edit > /etc/kernel-img.conf and linux-update-symlinks will recreate them > there when the kernel is updated. Ditto if you want them removed. I didn't know there's even such an option. But yes, it creates links in /boot/ now. >> Also, I'm trying to configure refind EFI boot manager, and >> basically I don't want to change its config file with each kernel >> update (the numbers in the file names change). > > I'm not familiar with that, but one of the reasons there are links > in root is for that very reason: their names don't change. That's why I need those links in /boot/ , so refind would easily pick them up. > You don't say why *you* think it's better to create links in /boot, > so I'm not sure why we're expected to think so too. But if you want > them in both places, I think you have to maintain them in the other > location yourself. I thought it was obvious, but I write it again to be clear. I'm using LUKSv2+LVM setup and (so far) syslinux/extlinux as a bootloader in MBR/MS-DOS partition layout (this will change to refind + EFI soon). So my machine is encrypted entirely, and only the /boot/ (and future ESP) partition remains unencrypted. When my system creates the links to the initrd and kernel in / , they're useless since you have to decrypt the root partition in order to get to those links, and in order to decrypt the partition, you have to load the kernel first, but when you load the kernel, you don't need the links anymore... So as you can see the better place for the links is in /boot/ and not in / , at least in the case of fully encrypted installation setups. signature.asc Description: OpenPGP digital signature
Re: What's the purpose of initrd.img{,.old} and vmlinuz{,.old} symlinks in the root dir?
Brian composed on 2020-03-01 13:26 (UTC): > On Sat 29 Feb 2020 at 19:15:12 -0600, David Wright wrote: >> On Sat 29 Feb 2020 at 19:17:39 (+0100), Mikhail Morfikov wrote: >>> # ls -al / >>> ... >>> lrwxrwxrwx 1 root root 29 2020-02-14 17:22:18 initrd.img -> >>> boot/initrd.img-5.4.0-4-amd64 >>> lrwxrwxrwx 1 root root 27 2020-02-24 00:37:53 initrd.img.old -> >>> boot/initrd.img-5.5.4-amd64 >>> ... >>> lrwxrwxrwx 1 root root 26 2020-02-14 17:22:18 vmlinuz -> >>> boot/vmlinuz-5.4.0-4-amd64 >>> lrwxrwxrwx 1 root root 24 2020-02-24 00:37:53 vmlinuz.old -> >>> boot/vmlinuz-5.5.4-amd64 >>> So I have a question here: what's the purpose of the links? >> They're a convenience. If you want them kept in /boot, then edit >> /etc/kernel-img.conf and linux-update-symlinks will recreate them >> there when the kernel is updated. Ditto if you want them removed. > They are also useful to reference on the linux and initrd lines when > booting with GRUB to rescue a system. I'd leave them there. + + + :-) Grub does not like symlinks to un-versioned kernel and initrd in /boot/. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
Re: What's the purpose of initrd.img{,.old} and vmlinuz{,.old} symlinks in the root dir?
On Sat 29 Feb 2020 at 19:15:12 -0600, David Wright wrote: > On Sat 29 Feb 2020 at 19:17:39 (+0100), Mikhail Morfikov wrote: > > I have an encrypted (LUKSv2) LVM setup with a separate unencrypted /boot/ > > partition. When I install a new kenrel in the system, the following > > symlinks are > > created in the root directory (/): > > > > # ls -al / > > ... > > lrwxrwxrwx 1 root root 29 2020-02-14 17:22:18 initrd.img > > -> boot/initrd.img-5.4.0-4-amd64 > > lrwxrwxrwx 1 root root 27 2020-02-24 00:37:53 > > initrd.img.old -> boot/initrd.img-5.5.4-amd64 > > ... > > lrwxrwxrwx 1 root root 26 2020-02-14 17:22:18 vmlinuz -> > > boot/vmlinuz-5.4.0-4-amd64 > > lrwxrwxrwx 1 root root 24 2020-02-24 00:37:53 vmlinuz.old > > -> boot/vmlinuz-5.5.4-amd64 > > > > So I have a question here: what's the purpose of the links? > > They're a convenience. If you want them kept in /boot, then edit > /etc/kernel-img.conf and linux-update-symlinks will recreate them > there when the kernel is updated. Ditto if you want them removed. They are also useful to reference on the linux and initrd lines when booting with GRUB to rescue a system. I'd leave them there. -- Brian.
Re: What's the purpose of initrd.img{,.old} and vmlinuz{,.old} symlinks in the root dir?
On Sat 29 Feb 2020 at 19:17:39 (+0100), Mikhail Morfikov wrote: > I have an encrypted (LUKSv2) LVM setup with a separate unencrypted /boot/ > partition. When I install a new kenrel in the system, the following symlinks > are > created in the root directory (/): > > # ls -al / > ... > lrwxrwxrwx 1 root root 29 2020-02-14 17:22:18 initrd.img > -> boot/initrd.img-5.4.0-4-amd64 > lrwxrwxrwx 1 root root 27 2020-02-24 00:37:53 > initrd.img.old -> boot/initrd.img-5.5.4-amd64 > ... > lrwxrwxrwx 1 root root 26 2020-02-14 17:22:18 vmlinuz -> > boot/vmlinuz-5.4.0-4-amd64 > lrwxrwxrwx 1 root root 24 2020-02-24 00:37:53 vmlinuz.old > -> boot/vmlinuz-5.5.4-amd64 > > So I have a question here: what's the purpose of the links? They're a convenience. If you want them kept in /boot, then edit /etc/kernel-img.conf and linux-update-symlinks will recreate them there when the kernel is updated. Ditto if you want them removed. > Also, I'm trying to configure refind EFI boot manager, and basically I don't > want to change its config file with each kernel update (the numbers in the > file > names change). I'm not familiar with that, but one of the reasons there are links in root is for that very reason: their names don't change. The links are of no particular use to me, because I always boot linux with Grub, and /boot/grub/grub.cfg gets updated with the actual filenames (in /boot) whenever the kernel is upgraded. But if you boot using software that's *not* maintained by Debian and therefore isn't updated with the name of the new kernel, then the symlinks in root are more useful: any software can find them there, and with names that never change. > Wouldn't be better to create the links under /boot/ dir instead (or in > addition > to the already existing ones, if they serve any purpose)? It's up to you. Not having links at all means that you might, in the absence of filename completion, have to remember strings like boot/vmlinuz-4.19.0-8-amd64 if booting doesn't go smoothly. You don't say why *you* think it's better to create links in /boot, so I'm not sure why we're expected to think so too. But if you want them in both places, I think you have to maintain them in the other location yourself. Cheers, David.
What's the purpose of initrd.img{,.old} and vmlinuz{,.old} symlinks in the root dir?
I have an encrypted (LUKSv2) LVM setup with a separate unencrypted /boot/ partition. When I install a new kenrel in the system, the following symlinks are created in the root directory (/): # ls -al / ... lrwxrwxrwx 1 root root 29 2020-02-14 17:22:18 initrd.img -> boot/initrd.img-5.4.0-4-amd64 lrwxrwxrwx 1 root root 27 2020-02-24 00:37:53 initrd.img.old -> boot/initrd.img-5.5.4-amd64 ... lrwxrwxrwx 1 root root 26 2020-02-14 17:22:18 vmlinuz -> boot/vmlinuz-5.4.0-4-amd64 lrwxrwxrwx 1 root root 24 2020-02-24 00:37:53 vmlinuz.old -> boot/vmlinuz-5.5.4-amd64 So I have a question here: what's the purpose of the links? Also, I'm trying to configure refind EFI boot manager, and basically I don't want to change its config file with each kernel update (the numbers in the file names change). Wouldn't be better to create the links under /boot/ dir instead (or in addition to the already existing ones, if they serve any purpose)? signature.asc Description: OpenPGP digital signature
