## /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
Hello,[...]
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
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)
# Temporary mitigations[...]
## /etc/initramfs-tools/initramfs.conf
# makes somewhat smaller initrd files and buys some time
COMPRESS=zstd
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
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.
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.)
<div dir="auto">Maybe can be useful for Simeone</div><div dir="auto"><br></div><div dir="auto">Thank you</div><div dir="auto">Pd: sorry is a spanish blog</div><div dir="auto"><br></div><div dir="auto">[1] <a href="http://i5513.blogspot.com/2022/03/apt-key-obsoleto-y-como-mantener-solo.html?m=1">http://i5513.blogspot.com/2022/03/apt-key-obsoleto-y-como-mantener-solo.html?m=1</a><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:
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.
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
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.
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?
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.
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.
my laptop runs with a default partition layout created by Debian[snip]
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
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 339 |
Nodes: | 16 (2 / 14) |
Uptime: | 00:21:42 |
Calls: | 7,466 |
Calls today: | 2 |
Files: | 12,691 |
Messages: | 5,627,864 |