Path: csiph.com!news.samoylyk.net!gothmog.csi.it!bofh.it!news.nic.it!robomod From: Ben Hutchings Newsgroups: linux.debian.bugs.dist,linux.debian.kernel Subject: Bug#1084232: initramfs-tools: fails with "No space left on device" due to 2 temporary initrd copies in /boot Date: Tue, 08 Oct 2024 20:20:01 +0200 Message-ID: References:

X-Original-To: Vincent Lefevre X-Mailbox-Line: From debian-bugs-dist-request@lists.debian.org Tue Oct 8 18:15:09 2024 Old-Return-Path: X-Spam-Flag: NO X-Spam-Score: 0.249 Reply-To: Ben Hutchings , 1084232@bugs.debian.org Resent-To: debian-bugs-dist@lists.debian.org Resent-Cc: Debian kernel team X-Debian-Pr-Message: followup 1084232 X-Debian-Pr-Package: initramfs-tools X-Debian-Pr-Keywords: moreinfo X-Debian-Pr-Source: initramfs-tools Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-65zF+qJz0YO1vqxA/XbN" User-Agent: Evolution 3.53.3-1 MIME-Version: 1.0 X-Sa-Exim-Connect-IP: 2a02:578:851f:1502:391e:c5f5:10e2:b9a3 X-Sa-Exim-Mail-From: ben@decadent.org.uk X-Sa-Exim-Scanned: No (on maynard); SAEximRunCond expanded to false X-Debian-Message: from BTS X-Mailing-List: archive/latest/1862245 List-ID: List-URL: Approved: robomod@news.nic.it Lines: 110 Organization: linux.* mail to news gateway Sender: robomod@news.nic.it X-Original-Cc: 1084232@bugs.debian.org X-Original-Date: Tue, 08 Oct 2024 20:12:11 +0200 X-Original-Message-ID: <9043e882b2d39b53850848c76d4cb9558291e61e.camel@decadent.org.uk> X-Original-References: <20241006223923.GA768321@qaa.vinc17.org> <56a40fba4b3c6b7e9d7cf1d1463c7140a42136ac.camel@decadent.org.uk> <20241008014132.GU7569@qaa.vinc17.org> <20241006223923.GA768321@qaa.vinc17.org> <20241008014132.GU7569@qaa.vinc17.org> Xref: csiph.com linux.debian.bugs.dist:1215752 linux.debian.kernel:84247 --=-65zF+qJz0YO1vqxA/XbN Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2024-10-08 at 03:41 +0200, Vincent Lefevre wrote: > On 2024-10-07 21:23:40 +0200, Ben Hutchings wrote: > > Control: tag -1 moreinfo > >=20 > > On Mon, 2024-10-07 at 00:39 +0200, Vincent Lefevre wrote: > > > Package: initramfs-tools > > > Version: 0.145 > > > Severity: normal > > >=20 > > > When updating an initrd file, update-initramfs keeps 2 temporary > > > copies in /boot, > >=20 > > I don't believe this is the case. A successful run of > > "update-initramfs -u" will do: > >=20 > > 1. Hard-link initrd.img- to initrd.img-.dpkg-bak > > 2. Create new initramfs as initrd.img-.new > > 3. Move initrd.img-.new to initrd.img- > > 4. Remove initrd.img-.dpkg-bak (unless backup_initramfs is > > enabled) > >=20 > > There is 1 temporary copy created in step 2, and after step 4 there are > > 0 temporary copies. > >=20 > > Step 1 does have a fallback to copying if hard-linking fails. That > > could happen if your /boot uses VFAT or some other un-Unix-like > > filesystem, but that's not supported by Debian. But maybe there's some > > other reason it can fail? >=20 > Indeed, with 3 installed kernels: >=20 > Filesystem Size Used Avail Use% Mounted on > /dev/nvme0n1p2 456M 295M 137M 69% /boot >=20 > So there isn't enough space for a 4th kernel + a temporary copy > (90 MB each at maximum compression + 9 MB for the vmlinuz file). OK. But 'apt autoremove' should normally remove one of the old kernels. And I don't see how this answers my question about the claim of 2 temporary copies. >=20 > > > though its space is typically *very* limited > > > (456 MB by default). This means that one can keep a limited number > > > of kernels. With the 456 MB default size and maximum compression > > > (COMPRESS=3Dlzma and COMPRESSLEVEL=3D9), only 3 kernels are possible. > > >=20 > > > The temporary copies should be stored on the main file system, > > > which is not space limited. > > [...] > >=20 > > The initramfs must be replaced atomically, otherwise we can end up with > > a previously working image being deleted or replaced with a truncated > > image. So there has to be 1 temporary copy. >=20 > The temporary copy could be on the main file system. The goal is > anyway to keep *at least* an additional working kernel in /boot > in case the rebuild of the kernel gets broken (which cannot be > detected until booting on this kernel). So, if anything goes wrong > (either at install time or when booting on the rebuilt kernel), it > is possible to boot on the working kernel to fix things. Unfortunately there is currently nothing with that global view of which kernel and initramfs images are known good. Also, if we delete an initramfs before rebuilding it, we should remove that kernel/initramfs from the boot menu until it's been rebuilt, but there's currently no mechanism to do that. I do see a need here for a proper re-think of the way we manage kernel and initramfs images in /boot, but this is not something that can be done through a quick fix in initramfs-tools. Ben. --=20 Ben Hutchings It is easier to write an incorrect program than to understand a correct one. --=-65zF+qJz0YO1vqxA/XbN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEErCspvTSmr92z9o8157/I7JWGEQkFAmcFdfsACgkQ57/I7JWG EQlxnRAAqYWjYY5c9BRy/F69OXEalEydYdyJHU+wZRfBmyvsOd6QGc5Qxi0/zlod Q9QgbBHTtBYxjpd0NCCrICsbZFCb9eFCdDOCsVORvTHX2nsS+xCiw9rBRApLWqfp 2tj103OJGX7LgtXdsuiJGWM8ZLqCqkqVLK4MJxLFeztCd4AyHXe1HRBDkb1XReuU RalMZbSTMh1tzu/4mFlPttQ/23eObAdL5p34VOnJWBJWGtB5G0PSrMG4o5lG+xn5 c9FM3bBd7sp/u0TjPEoF9cXEQlGcKFZ6sO2IJHyrmPi7n1ShWggGRnJxKMiggElK z8WzDK58J/m9oNxAKolmOGHvjr4KqnCbWi21P7cDuK21kE+YmXVZDTZPm+d1Zgzv qSZY5Wx7gr2Rca5f/B7NXCm+Uq3KERvT5KgC2/4tBpsi7OdIoRLchkP96iswAcpA AL5wJKTZ0+7i3Y2GqepKySY5hbED25d7phpWnn6PKBR/9WZAPJPXWERBlKU/MO0e HdhM352gesEsigS0fwYEOu8zxwsFYtR6Bzqktesa8C1DUnXCpaa3r+wzBW7ITLrk lreBUFkK12/wXHEHxhWzL+qilKg/vU4iy77WLq/E1h2c1w69KVnppuJsmp60sZZ+ rmzD3F89luZRlYWzRO/PP1lmY5FhRSSKKEvHeMmdzGavFKMPWrI= =zTa3 -----END PGP SIGNATURE----- --=-65zF+qJz0YO1vqxA/XbN--