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)

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 <enrico@enricozini.org>

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEJJAhGtA2CH5tHZqS0P9Jy+P0+2gFAmM+pHcACgkQ0P9Jy+P0 +2jwRxAAojJ4a8pEpqHJwDdmMcecQuE6X996s7PO9hC5UBDVwDgRcVhhp/SlYBqt V8rut96m4YES8wHdGzLtnGt5G9QyXJpuaaWP/SkYo/oiMiU5UKBJmOeGe9A20JDO ky/FffG+yd+49cO+nIxYvBsEtUNeF2JHlLfrWIns6vnMnVWFDnoUA70V+rtII/0l mL6aAFYUw9FZR1KKcsA44zn6zIZYJhSCC+gmOGS5BH8d/d7qgThsz3zPHBReYbIS a6c/cfwq82iFtYYL2046F7miLatUSZoHi+ZKqaiE5/v3JzWaCpAtxoSaWpUMv1/x EemRoZbX0P2OpbMlIou+YRO3RZWFEMZM8QwebLc3t/dt4RgmCMEEPHN6cNWnpBTY IKz/Ed1PgcJXXeBarhyHXEnCL/2cgNdEhgYET60+BZoyn1BUNMFj/SOJ80SCzGOQ Tss0yDKTNYQrI5XEYokY3UdhqzP4mfpRlE3ofxNnuFd5+WRSKxQkw/G5Dxr0lF9t 4JUdEmiwtE0ZsYsqjTD/ydPMXVxpeTxoYrddAgwgEnpNN/DeKiKV1VfwpJMmVpD7 WgqmlA5DR6auRieoD0qJd3+QuZEfgD0kuWGiMSFCw9GWGnUK8ZOTbIAe9Bj4uazX iT3mRAoe4yE+UEMJVF4pnuMSQ6310muZUeDvM9AN/FKtJfFqLuY=
=aK12
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

T24gVGh1LCAyMDIyLTEwLTA2IGF0IDExOjQ4ICswMjAwLCBFbnJpY28gWmluaSB3cm90ZToKPiBE ZXZpY2XCoMKgwqDCoMKgwqDCoMKgwqDCoCBTdGFydMKgwqDCoMKgwqDCoMKgIEVuZMKgwqAgU2Vj dG9yc8KgwqAgU2l6ZSBUeXBlCj4gL2Rldi9udm1lMG4xcDHCoMKgwqAgMjA0OMKgwqDCoCAxMDUw NjIzwqDCoCAxMDQ4NTc2wqDCoCA1MTJNIEVGSSBTeXN0ZW0KPiAvZGV2L252bWUwbjFwMiAxMDUw NjI0wqDCoMKgIDE1NTAzMzXCoMKgwqAgNDk5NzEywqDCoCAyNDRNIExpbnV4IGZpbGVzeXN0ZW0K PiAvZGV2L252bWUwbjFwMyAxNTUwMzM2IDEwMDAyMTQ1MjcgOTk4NjY0MTkyIDQ3Ni4yRyBMaW51 eCBmaWxlc3lzdGVtCgpDb3VsZCB5b3UgYWRkIHRoZSBtb3VudCBwb2ludCBpbmZvcm1hdGlvbj8g 4oCcZGYgLWjigJ0gd291bGQgYmUgZ3JlYXQuCgpSZWdhcmRzCg==

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.kernel

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 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)

[...]

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/msg00000.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.

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEErCspvTSmr92z9o8157/I7JWGEQkFAmM+2yAACgkQ57/I7JWG EQlpYg/+JyBp6XzZ7ayA2vepp+lxCsF7d+4wUjNXu5p/z6nEUsTKsLP/jOfy6AVx aIi+Brb3s/fmqaQ/+M3QSKtlnMKwzn7cAQYr0LYeJkxuu2uvZBponZU9ep2rmAQh 3Lgmx8iwvGdDY4hKuaOfdyPF2wAe++67jJ9l/LmD2xH/JyPhrADDRIDNecTAHiIZ 2EFNSqortk3lgyzVLKZwbwD5WX7OXIazBV5j4xiS4vRe6bG4pL43mzdpeTK03Oo5 Bu/cIbT1KdKfIiErJTl5Ii8n0aqZu2KZkzGGDEQSXDnJzuJ/hsVns6bmoeXTeCZV r2ikSWm5HvI9sCmLhDn16D7xXSKA3kGTX/YEjrH1AH/9iwzCeeM2JGJtcvHp1ofR wKbnOpWegJ9pV+KhEwXZXtpQJTCqGfEuYx05s28V6iJeqFltp9TXrUiZrTEjPU6a GnQbuV6uuI2VRS0b2o9LWkUg4xa8s8gZygTjwqcfQ9/g54Y6MKyj2AyhNaI8vGjv aTWir2GAKQXz7opICQKy6m8GMBxBppVEb9LR0Zt6GVNKS8FikGAsDw40CLAGOwNT F3C/BaoDNxKLrywpS9SfIrrvKq92sdT7JT825ej1gUPKG6mug4fYHM578Lrq2B+V 2QMtAdA6zfLsknokkTPDiygRdjyKCQTuYRvr56PQjKl4ii3q7XQ=
=VgK4
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

The vmlinuz is usually small. The initrd can be quite big.

Regards

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.kernel
Copy: ben@decadent.org.uk (Ben Hutchings)

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 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.

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.
-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCYz7k3wAKCRDXblvOeH7b bgwUAQDlR1jMHcnDKq6epEoNl0lU7Yxw2P8a6h4czugUaIcPTgEAonBdoh6uBFLK 9AFMGRe/hP/je71BZE+EFGNYuZobawA=
=OpVm
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello,

El jue., 6 oct. 2022 12:03, gregor herrmann <gregoa@debian.org> 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



<div dir="auto"><div>Hello,<br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El jue., 6 oct. 2022 12:03, gregor herrmann &lt;<a href="mailto:gregoa@debian.org">gregoa@debian.org</a>&gt; escribió:<br></div><blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, 06 Oct 2022 11:48:42 +0200, Enrico Zini wrote:<br>

&gt; ## /etc/initramfs-tools/initramfs.conf<br>
&gt; <br>
&gt;     # makes somewhat smaller initrd files and buys some time<br>
&gt;     COMPRESS=zstd<br>
&gt; <br>
&gt;     # makes definitely smaller initrd files, but breaks boot if<br> &gt;     # dependencies are not computed correctly: risky! And it needs<br> &gt;     # regenerating the initrd if running on different hardware<br> &gt;     MODULES=dep <br>

also:<br>

## /etc/initramfs-tools/update-initramfs.conf<br>

    #<br>
    # backup_initramfs [ yes | no ]<br>
    #<br>
    # Default is no<br>
    # If set to no leaves no .bak backup files.<br>

    backup_initramfs=no<br>

(ISTR that the default was &quot;yes&quot;, and avoiding those backups has<br> helped my in a smilar situation in the past.)<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I had to workaround too, I posted [1] about a possible solution, which is running succesfully on my laptop </div><div dir="auto"><br></

<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:
1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.kernel

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). -----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCYz7tswAKCRDXblvOeH7b bojvAP0dD82dxehEfyCfzK3tHWR3wm8tG1sw4bCqFQHkqWsp8QEApG9jPxhWedW0 EsmggYZmLXJtY6Hctw/R0oGiHr7h2QE=
=17MK
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------1ziZOZtPtR0pmP3eCNmDlJ0h
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

DQpBbSAwNi4xMC4yMiB1bSAxNjoyMyBzY2hyaWViIERpZWRlcmlrIGRlIEhhYXM6DQo+IFRo YXQgZG9lc24ndCBjaGFuZ2UgbXkgcGVyc3BlY3RpdmUgdGhhdCB0aGUgZnVuZGFtZW50YWwg YXNwZWN0IG9mIC9ib290IGJlaW5nDQo+IHRvbyBzbWFsbCBzaG91bGQgYmUgYWRkcmVzc2Vk IChkaXJlY3RseSkgYW5kIG5vdCB0cnkgdG8gd29ya2Fyb3VuZCBpdC4NCg0KQWdyZWVkLiBC dXQgYXV0b21hdGljYWxseSByZXNpemluZyBleGlzdGluZyBwYXJ0aXRpb25zIG9uIGEgcnVu bmluZyANCnN5c3RlbSB3aWxsIHByb2JhYmx5IG5vdCBiZSBwb3NzaWJsZSB0byBkbyBpbiBh IHNhZmUgd2F5Lg0KDQpBdCBsZWFzdCBJIGNhbid0IHRoaW5rIG9mIGEgd2F5IGhvdyB0aGlz IGNvdWxkIGJlIGRvbmUgYXV0b21hdGljYWxseSBieSANCmEgcGFja2FnZSBkdXJpbmcgYSBk aXN0LXVwZ3JhZGUuDQo=

--------------1ziZOZtPtR0pmP3eCNmDlJ0h--

-----BEGIN PGP SIGNATURE-----

wsF5BAABCAAjFiEECbOsLssWnJBDRcxUauHfDWCPItwFAmM+8PAFAwAAAAAACgkQauHfDWCPItzl yQ//ZHyWxw+Y2I74rcv3uxtNh6yHkhGFy6xWCXRJa8njcaL6D/fQkL0TPBCLe6M9sliPC0LIYVIA iL519vEA41acQ+zwAAzQuVFZUGJ/ZDheKbH76/HB+hj3mztYDpkGbaa32vBJLWMQkwn8p0HlNqOm 9dmrvQHeTA4h5YVQnZ3wpif1ZTyBtgxuBcmc8ZXh6UIPdnPlwtwCPb97RRHZdO31f/vebIDB+vL7 s7SvNhf+0WWhT6zw1jEo1Nspd7FFv0weP26qc0d//9IY5uMmghoDYoRfnyf3H3e00bBe+4mg3MeG rNIg1TdVmYaPK3+sACFt4gpPH6arHy73mTd/2sYN3imYbMxwgL1opYrwocg/kVJhqaZaGFuk0YkZ 4liz6icu0Rs3tTuG5YTB9gJ0l4auGQVIeo0iQI6A+CS8tE1Ajzo9ZVgqLrSpPUu1cpRndUwaJV2+ dp6F9q51LKJOK4SWO8l8u59SxEKbGnSmf/3Nw8JGoCte1Hems4PfingBLTEDpxkOetEBET0v38k3 HHpEObRPaHSS6GAGnxpETzzlmM9AsFqmHfoE+ueob52Eyt+VCA6okINP2G0QFhjvHrDaWLb7LZbF UVYOHlwkfNnvi/nyVg/prG+IfXqaBtQ7Y7HggqoU6LBONal2syWuEYrrpTpa/Bv7NmY2JeOo5Ar6 PVk=
=CK/K
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------kIWxc5SF0nKEAlk3TIsQ2dyN
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

QW0gMDYuMTAuMjIgdW0gMTE6NDggc2NocmllYiBFbnJpY28gWmluaToNCj4gKHNvbWVob3cg YSBiaXQgbW9yZSBzcGFjZSBpcyBuZWVkZWQgZHVyaW5nIGluc3RhbGwgdGhhbiBpcyB1c2Vk IGF0IHRoZQ0KPiBlbmQpDQoNCkNhbiB5b3UgY2xhcmlmeT8gSXMgdGhlIG5ldyBpbnRyYW1m cyBnZW5lcmF0ZWQgaW4gL2Jvb3Qgb3IgZ2VuZXJhdGVkIA0Kb3V0c2lkZSBvZiAvYm9vdCBi dXQgY29waWVkIHRvIC9ib290IHVuZGVyIGEgZGlmZmVyZW50IG5hbWUgc28gaXQgY2FuIGJl IA0KcmVwbGFjZWQgYXRvbWljYWxseT8NCkkgYXNzdW1lIHRoaXMgaXMgZG9uZSBmb3Igcm9i dXN0bmVzcyByZWFzb25zLiBNYXliZSwgaWYgc3BhY2UgaXMgYXMgDQp0aWdodCBhcyBpbiBz dWNoIHNpdHVhdGlvbnMsIG9uZSBjb3VsZCBjb21wcm9taXNlIGhlcmU/DQoNCg==

--------------kIWxc5SF0nKEAlk3TIsQ2dyN--

-----BEGIN PGP SIGNATURE-----

wsF5BAABCAAjFiEECbOsLssWnJBDRcxUauHfDWCPItwFAmM+/3gFAwAAAAAACgkQauHfDWCPItzj XA//fuXcNhBdM/FAAuLQ2S8qz1UUTyovRXGFBC0Uvn8I5CW6fZSLUoEWRiQXlGtHnA+EN+hNsiYO 4rlo2kI5+FYWd4ZiZiMZdhMFk/Mjtwr+jRb3R6EnaVcwb4ugKQ6Xq0KLzO/X8Ss1MONSHb7C0Cs5 Xg3jS7oRsLHWxY79dXtDJmTtMIhDvl0vTKYTE0awUOph4/qWqMVoj1pPNEaJ4qPyPnGG6DdR0cRU Y7Xzzw9hph1uMcfGpMkwj9n5+xTyKvyI2Gc3b8p/K5U2+FmVfBkDrwgZHr/qBTyGiHer2u3Mlosi voZ3p2sLUvUk+Dzjmm/00EZQnE9yLz8APsHMjWj7Iomh9Jfa4fwHTHRDqJcGXOfndx4i62ZcBMs0 ylBQHXG/Z3U2qIAvdyQz341MJe/28XTrpjVQf/RGoFOy6fJgHD6dPE2nRfNykWDrjWryKp7vSZzh Kyu2KnxMDp7uhv8EKYIiAPafysLlf76jqbIJf6WDvTf/2+41b6iExARYfWeQVzmsKuGH9cKsbX6L H5W+XYOFzG0rfmi+ar1rlbTUbZtgG7oO7RGF3qUVLneqX91ghT3WZ1zdlos+fA44Ttid5K8jD9VW TDsrs0/ujmRXouCTaWrKm5SMNBg2GjD+81z/FMuRznKL/cPkmJnQFAWZoP6NxkT8SjC6XCz+GuZU KXk=
=HWEy
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 6 Oct 2022 17:14:56 +0200 Michael Biebl <biebl@debian.org> 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. -----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCYz9RsQAKCRDXblvOeH7b bv2lAP9FfVegofIPUjl54dDqj5s96UqgJA/H/3Nlp4p7vxiLogEAt2aBJtaU0BHA IkGdqhU8yq0NvxkSQ1sLuSNQ2DY6lw0=
=JwOR
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 <enrico@enricozini.org>

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEJJAhGtA2CH5tHZqS0P9Jy+P0+2gFAmM/tWgACgkQ0P9Jy+P0 +2jJZxAAgVqSXVk7JbDSTTRSMgQdzs9LehIrA2IA550XI5VNW7xLvSXYMBPpz7RE lv5AqG1YWSoXqgz47tfDBFwg/bwUWVCCuo6hAmSFL9M5c8RO+4ZbQ6cinZMA+8A7 bh+Xl1CgvnbityBxTUo0v4ehxXttjFQzA+8CIRXRh3KbiwoglxEYfqfBt2N6MJXk QVMN3dJxwwsbGri53MmQqHK0oWKSr6RLGI5UvLY/1+vuLiMTL+BSIOZOmExfiTsa RfcFDYnQ1Hn7WqZGmquuXUETJ7WbsyiWMcpMq2gjOkhNA3iGoZ7R8eqrGKGq+yLH KG7G13aUQGotiEDEg6SvqVQiH74GHsZGJ0g5OID6r5hURgxz2vnUH1FrAF94O4rE vjJLzmQpvbr6lSo1I0Qnp1esUR3B3DeLPZCMscU+DakWdm0IdTHTjJOyMamoDp26 3D0fO7yuheXI8/XJbPYAQHQGgy3peeeSccg7YZ1DDLcuUWHyNrB89LQ14CGyztwM Eg3PDUT/UOPmf/iwxltzWmxDlWfc/L4i0/XsYDswVOf6MlQbGgHLVqCcunTrUDGG 270lPbKjC9lfKhTlmw8clnFwkeG/PikbkoyzW6Mhjst9ImBe9L95SfN3disPvpKT W3pVFLgHFc9t9vg0yU1NldLnnA0lw45EzMuItJc1Y7wBx3DEHkQ=
=X0sw
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 <serpent@debian.org>
GPG: A565 CE64 F866 A258 4DDC F9C7 ECB7 3E37 E887 AA8C

-----BEGIN PGP SIGNATURE-----

iQJHBAABCgAxFiEE1bhtbqZEgXjcK9cyggqgxGY3jWkFAmNO/n0THHNlcnBlbnRA ZGViaWFuLm9yZwAKCRCCCqDEZjeNaWNXD/9uLy4MLIstMJbTUEQPnfXwaHIA3lDU lndmjmwUOMNqJW2Q28lnSGA9xUtkfsPg+frOEeqIogwh4ZqabICOQZq4gzzXVc+b Q+nY0RFZOqSLwGPb+z5OBcxj1Nv/MZAe7oXvMZkg/M1ahcDEp0Y6zoepoQQRYc9d zkm5X/ikIILLZdh47Z+v3dN2KVW4N+lQ2kyuljBfuPPU1/nOyzCERy37F7/mwIcx fmNDoRfpFa+aCTGgNWoJ3xPY3SC+DCVrAde+pBRitoHLZjhoxQTXB0HN9sgsRe5c YkLzAGzwbfBb8zonqGOBJQwgGXZDrvakEpYAOmDkAKeKcTLMeJriEpFr/uwrZZje 2uQTG5p4wkMHnd4kwm+EHoQNf7WgPvjL7Qb6DxRzvT6W+oyA5GSHhMyKav6DiUKh LzVP4nLaAXXyhE/FuChW2J3Fewca1gxYZOZTg4kOP9CPuRgz4guKVG3g34ikoXE/ 8sE/yKLdCXa39UNOuhl0tqVNg011b8mBr/L/Mku6pdmCqlVQO/u1IneZzV3Jm/ut kXPpKSy+TZgLaufU8giXi3UlzgfoNpP19H1vBQ+nS3pgTOFkaWbSzZLuSqcOdE2t yIvrWHcZkxFE7dDvDdocdwMCQ3gsUy7drl3SLWI3SR/8GWK76CnlcscJzB5S3X+F kraA95HyfvrzAA==
=5B04
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05

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 <dleidert@debian.org> | https://www.wgdd.de/
GPG-Key RSA4096 / BEED4DED5544A4C03E283DC74BCD0567C296D05D
GPG-Key ED25519 / BD3C132D8B3805D1808123AB7ACE00941E338C78

https://www.fiverr.com/dleidert
https://www.patreon.com/join/dleidert

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAmNR48UACgkQS80FZ8KW 0F14jg/8CX0DhxBeAhXjYUlppoC5NzDZhZsLemd/PfdtTuSrncuAWCVz/5d/fnrR xL9FZ0g+dIPcsBtD/mMG70ktXNC1fimyhtms/pHqnG5OQmhbyYlU/u1H7/yIeb+9 nt1Q9gz3hOYgRyTN7ZilHsBHfA6qzWb6flLzE+aA3RjKiW+LSOdceOOitjxD4pcO ecu4hMcMW3PzBQ2GEt7W6/h8dQv9Eat/kf62OJnIrmaZrXtTGTB91ujuTE14et6b P1so6Tn4lMLvy2eb41E/a8F/U7U1y+cOo2GtQGuqpDjfBihZpksdPsK1BvWdmZFN EjrvAv8E1botrVaOSkXDBflh2hBNW06Jfbx5OYGZUEwBOHq5XOsT+SCzlcoJyYZo nzAPk0367WOuZRvWbMv4DJQBmq+SGFVjKUq4okOr9drRdYzAi2hJd1LVo1Wsy9X5 dQzEoPqLutZZwvOXESU+gdg2h+0FlZS+NsUnfLHeWcaUa89rIaycu+g3ItYQUwvc wDV7gNDQAA2LrWBsRmTlufMR7Erqq7qtKKIYZvLUtv3b5ruzIoms4RU+yJVAFMxu il84Aw9BbUvY6S6NWRWjKFZzeHOMyhKIWShWAKVPfaas5RJx3ZTYWSPA6W52bMvf
gt7