Re: /boot partition too small
Am Donnerstag, dem 06.10.2022 um 11:48 +0200 schrieb Enrico Zini: > > my laptop runs with a default partition layout created by Debian > Installer 4 years or so ago: > > Device Start End Sectors Size Type > /dev/nvme0n1p1 2048 1050623 1048576 512M EFI System > /dev/nvme0n1p2 1050624 1550335 499712 244M Linux filesystem > /dev/nvme0n1p3 1550336 1000214527 998664192 476.2G Linux filesystem [snip] There is another possibility: Just shrink the filesystem and then the /dev/nvme0n1p3 partition and create a fourth partition from the free space. Move boot into the new partition. Then you can remove /dev/nvme0n1p2 and either add that space to your ESP or to the root partition. Regards, Daniel -- Daniel Leidert | https://www.wgdd.de/ GPG-Key RSA4096 / BEED4DED5544A4C03E283DC74BCD0567C296D05D GPG-Key ED25519 / BD3C132D8B3805D1808123AB7ACE00941E338C78 https://www.fiverr.com/dleidert https://www.patreon.com/join/dleidert signature.asc Description: This is a digitally signed message part
Re: /boot partition too small
On Fri, 2022-10-07 at 07:13 +0200, Enrico Zini wrote: > On Thu, Oct 06, 2022 at 06:16:56PM +0200, Michael Biebl wrote: > > > Can you clarify? Is the new intramfs generated in /boot or generated outside > > of /boot but copied to /boot under a different name so it can be replaced > > atomically? > > I assume this is done for robustness reasons. Maybe, if space is as tight as > > in such situations, one could compromise here? > > The situation went somewhat like this: > > 1. I have 2 kernels installed, a new one arrives > 2. Installation of the 3rd one fails as usual, /boot contains 2 and a >half kernels > 3. I remove the kernel I'm not using, /boot contains 1 and a half >kernels > 4. dpkg --configure -a keeps failing for lack of disk space > 5. I manually remove the initrd file of the new, not fully installed >kernel > 6. apt install --reinstall of the new kernel succeeds (dpkg --configure >-a didn't generate the missing initrd) > > I haven't had a chance to investigate why with a failed configure phase > an old initrd was left there, and why configure failed but a new > configure didn't regenerate the initd, so it may be that I hit a corner > case. > So it looks like there is more people with limited /boot space who need to take care during upgrades :-) I can only fit 2 kernels, and each rebuild of initramfs fails. In such a case: 1. rm /boot/initrd.img-* 2. dpkg --configure -a 3. apt-get clean 4. update-initramfs -v -c -k all 5. update-grub When I notice that there is new kernel, I remove one of old ones, and then upgrade/install succeeds. Best regards. -- Tomasz Rybak, Debian Developer GPG: A565 CE64 F866 A258 4DDC F9C7 ECB7 3E37 E887 AA8C signature.asc Description: This is a digitally signed message part
Re: /boot partition too small
Hi, Am Fri, Oct 07, 2022 at 07:13:12AM +0200 schrieb Enrico Zini: > On Thu, Oct 06, 2022 at 06:16:56PM +0200, Michael Biebl wrote: > > > Can you clarify? Is the new intramfs generated in /boot or generated outside > > of /boot but copied to /boot under a different name so it can be replaced > > atomically? > > I assume this is done for robustness reasons. Maybe, if space is as tight as > > in such situations, one could compromise here? > > The situation went somewhat like this: > > 1. I have 2 kernels installed, a new one arrives > 2. Installation of the 3rd one fails as usual, /boot contains 2 and a >half kernels > 3. I remove the kernel I'm not using, /boot contains 1 and a half >kernels > 4. dpkg --configure -a keeps failing for lack of disk space > 5. I manually remove the initrd file of the new, not fully installed >kernel > 6. apt install --reinstall of the new kernel succeeds (dpkg --configure >-a didn't generate the missing initrd) > > I haven't had a chance to investigate why with a failed configure phase > an old initrd was left there, and why configure failed but a new > configure didn't regenerate the initd, so it may be that I hit a corner > case. In case it helps: I have also a laptop featuring this problem which I also solve the very same way as Enrico (but shame on me was always to lazy to report). Just to confirm that Enrico is not the only one - probably there is quite a number of installations out there and some of the users will be scared to go steps 3.-6. Kind regards Andreas. -- http://fam-tille.de
Re: /boot partition too small
On Thu, Oct 06, 2022 at 06:16:56PM +0200, Michael Biebl wrote: > Can you clarify? Is the new intramfs generated in /boot or generated outside > of /boot but copied to /boot under a different name so it can be replaced > atomically? > I assume this is done for robustness reasons. Maybe, if space is as tight as > in such situations, one could compromise here? The situation went somewhat like this: 1. I have 2 kernels installed, a new one arrives 2. Installation of the 3rd one fails as usual, /boot contains 2 and a half kernels 3. I remove the kernel I'm not using, /boot contains 1 and a half kernels 4. dpkg --configure -a keeps failing for lack of disk space 5. I manually remove the initrd file of the new, not fully installed kernel 6. apt install --reinstall of the new kernel succeeds (dpkg --configure -a didn't generate the missing initrd) I haven't had a chance to investigate why with a failed configure phase an old initrd was left there, and why configure failed but a new configure didn't regenerate the initd, so it may be that I hit a corner case. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Re: /boot partition too small
On Thu, 6 Oct 2022 17:14:56 +0200 Michael Biebl wrote: > Am 06.10.22 um 16:23 schrieb Diederik de Haas: > > That doesn't change my perspective that the fundamental aspect of /boot > > being too small should be addressed (directly) and not try to workaround > > it. > > Agreed. But automatically resizing existing partitions on a running system > will probably not be possible to do in a safe way. > > At least I can't think of a way how this could be done automatically by a > package during a dist-upgrade. I don't think we should even try to fix it. Every affected problem is different and so is the desired solution for that person/device. In this case I think that recommending a fresh install, isn't a bad solution. signature.asc Description: This is a digitally signed message part.
Re: /boot partition too small
Am 06.10.22 um 11:48 schrieb Enrico Zini: (somehow a bit more space is needed during install than is used at the end) Can you clarify? Is the new intramfs generated in /boot or generated outside of /boot but copied to /boot under a different name so it can be replaced atomically? I assume this is done for robustness reasons. Maybe, if space is as tight as in such situations, one could compromise here? OpenPGP_signature Description: OpenPGP digital signature
Re: /boot partition too small
Am 06.10.22 um 16:23 schrieb Diederik de Haas: That doesn't change my perspective that the fundamental aspect of /boot being too small should be addressed (directly) and not try to workaround it. Agreed. But automatically resizing existing partitions on a running system will probably not be possible to do in a safe way. At least I can't think of a way how this could be done automatically by a package during a dist-upgrade. OpenPGP_signature Description: OpenPGP digital signature
Re: /boot partition too small
On Thursday, 6 October 2022 16:23:27 CEST Diederik de Haas wrote: > That doesn't change my perspective that the fundamental aspect of /boot > being too small should be addressed (directly) and not try to workaround > it. With workarounds I was thinking of using a better compression scheme (already done by switching to zstd) and such things to 'shave off' a 'few' bytes. On Thursday, 6 October 2022 15:41:52 CEST Ben Hutchings wrote: > The kernel team has had some discussion about changing linux-image > packages to not install vmlinuz directly in /boot: > https://lists.debian.org/debian-kernel/2021/11/msg00091.html I should've read those msgs (again) before replying, but the above linked alternative is not a workaround AFAIC (which ~ makes /boot/ irrelevant IIUC). signature.asc Description: This is a digitally signed message part.
Re: /boot partition too small
Hello, El jue., 6 oct. 2022 12:03, gregor herrmann escribió: > On Thu, 06 Oct 2022 11:48:42 +0200, Enrico Zini wrote: > > > ## /etc/initramfs-tools/initramfs.conf > > > > # makes somewhat smaller initrd files and buys some time > > COMPRESS=zstd > > > > # makes definitely smaller initrd files, but breaks boot if > > # dependencies are not computed correctly: risky! And it needs > > # regenerating the initrd if running on different hardware > > MODULES=dep > > also: > > ## /etc/initramfs-tools/update-initramfs.conf > > # > # backup_initramfs [ yes | no ] > # > # Default is no > # If set to no leaves no .bak backup files. > > backup_initramfs=no > > (ISTR that the default was "yes", and avoiding those backups has > helped my in a smilar situation in the past.) > I had to workaround too, I posted [1] about a possible solution, which is running succesfully on my laptop Maybe can be useful for Simeone Thank you Pd: sorry is a spanish blog [1] http://i5513.blogspot.com/2022/03/apt-key-obsoleto-y-como-mantener-solo.html?m=1 >
Re: /boot partition too small
On Thursday, 6 October 2022 15:41:52 CEST Ben Hutchings wrote: > > my laptop runs with a default partition layout created by Debian > > Installer 4 years or so ago: > > > > Device StartEnd Sectors Size Type > > /dev/nvme0n1p120481050623 1048576 512M EFI System > > /dev/nvme0n1p2 10506241550335499712 244M Linux filesystem > > /dev/nvme0n1p3 1550336 1000214527 998664192 476.2G Linux filesystem > > > > The boot partition is now big enough to contain 2 kernel version, too > > small to contain 3, and too small to purge one and install another > > (somehow a bit more space is needed during install than is used at the > > end) > > The kernel team has had some discussion about changing linux-image > packages to not install vmlinuz directly in /boot ... > > This would potentially allow for smarter management of the available > space in /boot. That sounds like fixing the wrong problem or in the wrong place to me. The EFI partition gets 512MB, while boot gets 244MB? ... On a ~500GB drive? With the RPi images we had a discussion to increase the partition size* from 300MB to 512MB to accommodate several kernels. And that's on a minimal image which is (normally) written to a SD card. And my hesitation came from that people may be using 4 or 8 GB SD cards. Personally I never use the standard partitioning layout as it didn't make sense to me ... and IIRC that was from ~10 years ago. I don't know, but I expect there is some algorithm which determines what sizes the various partitions should get. Maybe that needs a new look to determine whether it is still the most sensible today? EDIT: I just looked up the thread on debian-devel and saw that d-i already has better defaults. That doesn't change my perspective that the fundamental aspect of /boot being too small should be addressed (directly) and not try to workaround it. *) Technically it's a partition mounted on /boot/firmware, but the kernels get copied into that partition. signature.asc Description: This is a digitally signed message part.
Re: /boot partition too small
The vmlinuz is usually small. The initrd can be quite big. Regards
Re: /boot partition too small
On Thu, 2022-10-06 at 11:48 +0200, Enrico Zini wrote: > Hello, > > my laptop runs with a default partition layout created by Debian > Installer 4 years or so ago: > > Device StartEnd Sectors Size Type > /dev/nvme0n1p120481050623 1048576 512M EFI System > /dev/nvme0n1p2 10506241550335499712 244M Linux filesystem > /dev/nvme0n1p3 1550336 1000214527 998664192 476.2G Linux filesystem > > The boot partition is now big enough to contain 2 kernel version, too > small to contain 3, and too small to purge one and install another > (somehow a bit more space is needed during install than is used at the > end) [...] That doesn't sound right to me. But an upgrade (with same kernel ABI version) *will* temporarily require space for both old and versions of all files in the package. The kernel team has had some discussion about changing linux-image packages to not install vmlinuz directly in /boot: https://lists.debian.org/debian-kernel/2021/11/msg00091.html https://lists.debian.org/debian-kernel/2022/01/msg00236.html https://lists.debian.org/debian-kernel/2022/02/msg0.html https://lists.debian.org/debian-kernel/2022/02/msg00010.html This would potentially allow for smarter management of the available space in /boot. But I don't think there is any implementation available for this yet. [...] > # Temporary mitigations > > ## /etc/initramfs-tools/initramfs.conf > > # makes somewhat smaller initrd files and buys some time > COMPRESS=zstd [...] This is the default in bookworm. Ben. -- Ben Hutchings If the facts do not conform to your theory, they must be disposed of. signature.asc Description: This is a digitally signed message part
Re: /boot partition too small
On Thu, 2022-10-06 at 11:48 +0200, Enrico Zini wrote: > Device Start End Sectors Size Type > /dev/nvme0n1p1 2048 1050623 1048576 512M EFI System > /dev/nvme0n1p2 1050624 1550335 499712 244M Linux filesystem > /dev/nvme0n1p3 1550336 1000214527 998664192 476.2G Linux filesystem Could you add the mount point information? “df -h” would be great. Regards
Re: /boot partition too small
On Thu, 06 Oct 2022 11:48:42 +0200, Enrico Zini wrote: > ## /etc/initramfs-tools/initramfs.conf > > # makes somewhat smaller initrd files and buys some time > COMPRESS=zstd > > # makes definitely smaller initrd files, but breaks boot if > # dependencies are not computed correctly: risky! And it needs > # regenerating the initrd if running on different hardware > MODULES=dep also: ## /etc/initramfs-tools/update-initramfs.conf # # backup_initramfs [ yes | no ] # # Default is no # If set to no leaves no .bak backup files. backup_initramfs=no (ISTR that the default was "yes", and avoiding those backups has helped my in a smilar situation in the past.) Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- BOFH excuse #179: multicasts on broken packets
/boot partition too small
Hello, my laptop runs with a default partition layout created by Debian Installer 4 years or so ago: Device StartEnd Sectors Size Type /dev/nvme0n1p120481050623 1048576 512M EFI System /dev/nvme0n1p2 10506241550335499712 244M Linux filesystem /dev/nvme0n1p3 1550336 1000214527 998664192 476.2G Linux filesystem The boot partition is now big enough to contain 2 kernel version, too small to contain 3, and too small to purge one and install another (somehow a bit more space is needed during install than is used at the end) Boot happens via UEFI and grub, the root partition is a filesystem in a LV in an encrypted PV. d-i now has better defaults for partitioning, so this isn't a problem in newly installed systems, but it seems like a nontrivial issue in upgrades, which deserves a section in release notes. I'm not sure what could be good, default, official suggestions for this situation, thoguh. There's been some brainstorming on #debian-devel, I'll try to summarise what I've seen so far. I'm not sure any of this can be turned into a one-size-fits-all upgrade path, but a collection of tips and workarounds is at least a starting point. # Temporary mitigations ## /etc/initramfs-tools/initramfs.conf # makes somewhat smaller initrd files and buys some time COMPRESS=zstd # makes definitely smaller initrd files, but breaks boot if # dependencies are not computed correctly: risky! And it needs # regenerating the initrd if running on different hardware MODULES=dep ## using dracut Someone reported that dracut creates smaller initrd images ## Using /boot/efi to grow /boot My /boot/efi is 512M and mostly empty, and is contiguous with /boot. One can shrink /boot/efi and use the space to enlarge /boot ## /boot inside the PV grub can understand LVM, so one can move /boot inside the PV, if the PV is not encrypted. ## Encrypted /boot grub can also understand LUKS, so one can move /boot inside the encrypted PV. grub cannot however forward the LUKS key to Linux during boot, so one would have to enter the password twice. One can store LUKS keys inside the initrd (see /etc/cryptsetup-initramfs/conf-hook), which is then stored in the encrypted PV. This allows to boot entering the password only once, but then anyone who can read the initrd file on the filesystem after boot can recover the key, so one needs to at least manage the permissions of the initd file, which is world-readable by default. This will also give another path for extracting the LUKS keys, although I don't know how hard it is to extract the keys from a running system as it is now, so I don't know how worse this would get. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
