From MAILER-DAEMON Wed Nov 30 00:48:54 2022 Received: from list by lists.fsf.org with archive (Exim 4.90_1) id 1p0Fxl-0002md-EW for mharc-tech-volunteer-meeting@fsf.org; Wed, 30 Nov 2022 00:48:54 -0500 Received: from mail.fsf.org ([2001:470:142::13]) by lists.fsf.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p0Fxj-0002mU-Lb for tech-volunteer-meeting@fsf.org; Wed, 30 Nov 2022 00:48:51 -0500 Received: from havoc.proulx.com ([96.88.95.61]) by mail.fsf.org with esmtps (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.93) (envelope-from ) id 1p0Fxh-005Lpa-VC for tech-volunteer-meeting@fsf.org; Wed, 30 Nov 2022 00:48:51 -0500 Received: from joseki.proulx.com (localhost [127.0.0.1]) by havoc.proulx.com (Postfix) with ESMTP id A6365121 for ; Tue, 29 Nov 2022 22:48:44 -0700 (MST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proulx.com; s=dkim2048; t=1669787324; bh=e0kpOaPLJa0dHK9sp+UK7WqpbdMtOrr16t6CEKiolto=; h=Date:From:To:Subject:From; b=n42WHBpWt9+LSBk5qUlHuQ21rcJJTK4gyiUMVnOopAj2kwMQC4uv9uwZToMx2+z1z 3w4Cghx6zayWQnOHY1cIIsuhkc0CBaqWzhVSwj1jeDmz3p2uS3ZfIRB3On/hCvsPSX IvgS1R4a7azRb6lgQKTCEIKRHCcC6eTKjCa/S5ZGIqeIWwUYqBNecWQTpBDXO0xHr0 QYU9bq/yiysn0YldST1SV89gKMXY2Lp/Gv3BJlBtx5vUdd5ldHJl8MWnmcjyk12ZNZ m6BH+7K2AHjRrNedwgsOfn8wkIevIQ3dwMlL4ouIvutGlWBeMbCqbvsx6SjiMq5spw elqq4MON1+C8w== Received: from hysteria.proulx.com (hysteria.proulx.com [192.168.230.119]) by joseki.proulx.com (Postfix) with ESMTP id 842727A018 for ; Tue, 29 Nov 2022 22:48:44 -0700 (MST) Received: by hysteria.proulx.com (Postfix, from userid 1000) id 7DF34693C9AA; Tue, 29 Nov 2022 22:48:44 -0700 (MST) Date: Tue, 29 Nov 2022 22:48:44 -0700 From: Bob Proulx To: tech-volunteer-meeting@fsf.org Subject: Ubuntu upgrade snag, full /boot partition Message-ID: <20221129223244945113767@bob.proulx.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Received-SPF: pass client-ip=96.88.95.61; envelope-from=bob@proulx.com; helo=havoc.proulx.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: tech-volunteer-meeting@fsf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2022 05:48:52 -0000 I recently upgraded a few Ubuntu systems. I have been hearing other people report that their /boot filled up and failed the upgrade but I had not seen it. Not until now. I looked into what was happening and thought I would send a hint around. The Ubuntu installer makes it very difficult to use a different partitioning than what the installer provides. And what the installer provides is a 500MB /boot partition. And that is becoming problematic because the Ubuntu kernel upgrade uses significant *temporary* space in the partition. Filesystem Size Used Avail Use% Mounted on /dev/md0 459M 259M 177M 60% /boot -rw------- 1 root root 6250186 Oct 17 14:36 System.map-5.15.0-53-generic -rw------- 1 root root 4748126 Oct 17 11:19 System.map-5.4.0-132-generic -rw-r--r-- 1 root root 261837 Oct 17 14:36 config-5.15.0-53-generic -rw-r--r-- 1 root root 237852 Oct 17 11:19 config-5.4.0-132-generic drwx------ 3 root root 4096 Dec 31 1969 efi drwxr-xr-x 5 root root 1024 Nov 28 17:17 grub -rw-r--r-- 1 root root 113780621 Nov 28 17:18 initrd.img-5.15.0-53-generic -rw-r--r-- 1 root root 110402334 Nov 28 17:03 initrd.img-5.4.0-132-generic drwx------ 2 root root 12288 Mar 10 2019 lost+found -rw-r--r-- 1 root root 182800 Feb 6 2022 memtest86+.bin -rw-r--r-- 1 root root 184476 Feb 6 2022 memtest86+.elf -rw-r--r-- 1 root root 184980 Feb 6 2022 memtest86+_multiboot.bin -rw------- 1 root root 11548224 Oct 17 14:41 vmlinuz-5.15.0-53-generic -rw------- 1 root root 13668608 Oct 17 11:42 vmlinuz-5.4.0-132-generic That looks pretty normal. Nothing extreme. Just the defaults. But that partition ran out of space for me on an upgrade. Up through Ubuntu 18.04 they used Linux 4.x kernels. Upon upgrade from 18.04 to 20.04 one Linux 4.13 kernel is left behind in /boot and forgotten. Then 20.04 leaves one Linux 5.4 kernel behind also forgotten. 22.04 brings in a Linux 5.15 kernel. The forgotten Linux 4 kernel (not shown, I purged it for space) was too much. This caused the do-release-upgrade script that I ran to fail out. And afterward the do-release-upgrade script didn't want to restart. So of course I just manually worked through the upgrade. But I can see where that would leave some people stuck. So here is the hint. Prior to an upgrade it would be good to purge off all Linux kernels behind the one that is currently booting. Since we know the current kernel boots and it will become the new backup it is okay to purge all but the currently running kernel. And then in the future I will probably purge off the memtest86+ boot environment too. It's sometimes useful but only rarely used. Removing it would save 545KB which is miniscule but perhaps every byte counts. Bob