boot partition expansion
Hi folks Well all is well after the previous mess apart from one thing that i must admit i forgot to tackle on the reinstall a few days ago my "/boot" partition is too small 300mb ran into a problem last night pacman installing kernel 6.7.0 The main kernel built installed fine but the fall back errored out with no room on . I have a spare empty partition sda2 of 40Gb sat doing nothing can i grow the boot partition to take some of that spare space without risking another reinstall Sorry to be a pain right now but i got enough medical issues right now and this is just bugging me beyond sanity Any help would be greatfully received Thanks Pete .
Hello, it's not possible to expand a partition if you don't have free space directly after it. It might however be possible to move it. Boot partition is not necessarily that difficult to reconstruct, even from scratch. W dniu 15.01.2024 o 16:48, pete pisze:
Hi folks
Well all is well after the previous mess apart from one thing that i must admit i forgot to tackle on the reinstall a few days ago
my "/boot" partition is too small 300mb ran into a problem last night pacman installing kernel 6.7.0
The main kernel built installed fine but the fall back errored out with no room on .
I have a spare empty partition sda2 of 40Gb sat doing nothing can i grow the boot partition to take some of that spare space without risking another reinstall
Sorry to be a pain right now but i got enough medical issues right now and this is just bugging me beyond sanity
Any help would be greatfully received
Thanks Pete .
On 1/15/24 16:48, pete wrote:
Hi folks Hi,
Well all is well after the previous mess apart from one thing that i must admit i forgot to tackle on the reinstall a few days ago
my "/boot" partition is too small 300mb ran into a problem last night pacman installing kernel 6.7.0 While 300 MiB is not huge, it should be enough in most cases.
The issue you faced with kernel 6.7.0 is actually a mkinitcpio issue [1] that made initramfs files grow up in size significantly. Fortunately, this issue already has a patch already tested and merged. [2] :)
The main kernel built installed fine but the fall back errored out with no room on .
I have a spare empty partition sda2 of 40Gb sat doing nothing can i grow the boot partition to take some of that spare space without risking another reinstall
While you can look into increasing your /boot partition size to avoid eventual situations like this in the future, the next mkinitcpio release should reduce the initramfs files to a more reasonable size, fixing your issue at the same time :)
Sorry to be a pain right now but i got enough medical issues right now and this is just bugging me beyond sanity
Any help would be greatfully received
Thanks Pete .
[1] https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio/-/issues/238 [2] https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio/-/merge_request... -- Regards, Robin Candau / Antiz
On Mon, 15 Jan 2024 17:03:33 +0100 Robin Candau <antiz@archlinux.org> wrote:
On 1/15/24 16:48, pete wrote:
Hi folks Hi,
Well all is well after the previous mess apart from one thing that i must admit i forgot to tackle on the reinstall a few days ago
my "/boot" partition is too small 300mb ran into a problem last night pacman installing kernel 6.7.0 While 300 MiB is not huge, it should be enough in most cases.
The issue you faced with kernel 6.7.0 is actually a mkinitcpio issue [1] that made initramfs files grow up in size significantly. Fortunately, this issue already has a patch already tested and merged. [2] :)
The main kernel built installed fine but the fall back errored out with no room on .
I have a spare empty partition sda2 of 40Gb sat doing nothing can i grow the boot partition to take some of that spare space without risking another reinstall
While you can look into increasing your /boot partition size to avoid eventual situations like this in the future, the next mkinitcpio release should reduce the initramfs files to a more reasonable size, fixing your issue at the same time :)
Sorry to be a pain right now but i got enough medical issues right now and this is just bugging me beyond sanity
Any help would be greatfully received
Thanks Pete .
[1] https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio/-/issues/238 [2] https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio/-/merge_request...
Ahh right Thanks for that i had a feeling it was an issue from the update lastnight i will bide my time in that case Pete
While 300 MiB is not huge, it should be enough in most cases. And note that 300 MB is recommended, while in reality you could go even below that. I have a BIOS system with 128 MB “/boot”, with 45 MB occupied by the images. So that’s certainly not you doing something wrong or having a partition “simply too small”.
The issue you faced with kernel 6.7.0 is actually a mkinitcpio issue [1] that made initramfs files grow up in size significantly. Fortunately, this issue already has a patch already tested and merged. [2] :) As detected a moment ago, the current git mkinitcpio version still does not resolve the issue. I am ending up with 5× inflation of the image between linux 6.6.8 and 6.7.0. So the problem remains open.
From the current conversations, but please don’t take this as an official statement or proper evaluation of the situation, it seems that nouveau is not pulling in nVidia’s firmware blobs. A combination of that and some issue with mkinitcpio leads to the problem.
On Mon, 15 Jan 2024 18:03:02 +0100 mpan <archml-y1vf3axu@mpan.pl> wrote:
While 300 MiB is not huge, it should be enough in most cases. And note that 300 MB is recommended, while in reality you could go even below that. I have a BIOS system with 128 MB “/boot”, with 45 MB occupied by the images. So that’s certainly not you doing something wrong or having a partition “simply too small”.
The issue you faced with kernel 6.7.0 is actually a mkinitcpio issue [1] that made initramfs files grow up in size significantly. Fortunately, this issue already has a patch already tested and merged. [2] :) As detected a moment ago, the current git mkinitcpio version still does not resolve the issue. I am ending up with 5× inflation of the image between linux 6.6.8 and 6.7.0. So the problem remains open.
From the current conversations, but please don’t take this as an official statement or proper evaluation of the situation, it seems that nouveau is not pulling in nVidia’s firmware blobs. A combination of that and some issue with mkinitcpio leads to the problem.
yes this is what i have from the fall back image 228519936 Jan 15 01:11 initramfs-linux-fallback.img. note the size this is the normal . 35949163 Jan 15 01:10 initramfs-linux.img Crazy . Pete
sizes of img files with latest mkinitcpio 37.2-1 110M initramfs-linux-ck-generic-v3-fallback.img 51M initramfs-linux-ck-generic-v3.img 110M initramfs-linux-fallback.img 51M initramfs-linux.img Sent with Proton Mail secure email. On Monday, January 15th, 2024 at 2:24 PM, pete <petegn@mail.com> wrote:
On Mon, 15 Jan 2024 18:03:02 +0100 mpan archml-y1vf3axu@mpan.pl wrote:
While 300 MiB is not huge, it should be enough in most cases. And note that 300 MB is recommended, while in reality you could go even below that. I have a BIOS system with 128 MB “/boot”, with 45 MB occupied by the images. So that’s certainly not you doing something wrong or having a partition “simply too small”.
The issue you faced with kernel 6.7.0 is actually a mkinitcpio issue [1] that made initramfs files grow up in size significantly. Fortunately, this issue already has a patch already tested and merged. [2] :) As detected a moment ago, the current git mkinitcpio version still does not resolve the issue. I am ending up with 5× inflation of the image between linux 6.6.8 and 6.7.0. So the problem remains open.
From the current conversations, but please don’t take this as an official statement or proper evaluation of the situation, it seems that nouveau is not pulling in nVidia’s firmware blobs. A combination of that and some issue with mkinitcpio leads to the problem.
yes this is what i have from the fall back image
228519936 Jan 15 01:11 initramfs-linux-fallback.img.
note the size
this is the normal . 35949163 Jan 15 01:10 initramfs-linux.img
Crazy .
Pete
On Mon, 2024-01-15 at 19:30 +0000, Serge Korol wrote:
sizes of img files with latest mkinitcpio 37.2-1
* Things seem quite reasonable again with the latest release of mkinitcpio * I stopped keeping fallback images for both dracut and mkinitcpio. You may or may not choose to do this too. * -If- you choose to do this and ever need a driver in the initrd for changed hardware (e.g. root drive disk controller) then for that somewhat rare case one should keep a handy usb drive with arch installer so you can boot that and regen the initrd. Benefits of no fallback: * smaller space usage and much faster regeneration of initrd [1] * If you choose to no longer keep fallback image then the following is one way to do it: 1) edit /etc/mkinitcpio.d/linux.preset Change preset line to be PRESETS=('default') 2) rm /boot/initramfs-linux-fallback.img 3) Confirm regen initrd: mkinitcpio -P (or -p linux) gene [1] Its initramfs but initrd, while not the same, is sometimes used in place of initramfs and its shorter to type 🙂
On Mon, 2024-01-15 at 16:39 -0500, Genes Lists wrote:
Benefits of no fallback: * smaller space usage and much faster regeneration of initrd
Hi, no doubt there are some use cases where an installation should be kept as small as possible, but on an average desktop laptop computer or server a GiB more or less doesn't matter these days. I use a 4 GiB ESP partition and my Arch Linux /boot, which contains the kernels, is part of the root directory instead of being its own partition. IOW hundreds of unused GiB are available. When I compare /boot/ with e.g. /usr/lib/firefox/ and similar paths, I come to the conclusion that it is irrelevant if you oversize one or the other partition and in return you never have to move and enlarge partitions and after that to reinstall the bootloader or to waste thoughts on the fact that you can save fallback.imgs. In my opinion, this saves resources at the wrong end. Yes, "regeneration of initrd" takes a while, but when this happens you can still use the computer, you don't need to live watch the messages, you can read them later, when the upgrade has finished, after maybe 5 minutes on a very slow machine with many kernels installed. Regards, Ralf
Hi On 1/16/24 05:22, Ralf Mardorf wrote:
On Mon, 2024-01-15 at 16:39 -0500, Genes Lists wrote:
Benefits of no fallback: * smaller space usage and much faster regeneration of initrd
Hi,
You can modify COMPRESSION_OPTIONS in mkinitcpio.conf to add more compression level. Best regards, Severus -- Trên con đường lấy lửa thử vàng anh phát hiện con tim mình chỉ là đá.
no doubt there are some use cases where an installation should be kept as small as possible, but on an average desktop laptop computer or server a GiB more or less doesn't matter these days. (…) Note: I’m aware you are answering to Genes Lists’s post specifically, making a statement about benefits.I want to make a general note here, so this is not extended to all cases.
Many people din’t choose the boot partition to be small. We created it in the past and, over time, initramfs grown to the point of filling the space. My 128M partition was claimed to be an order of magnitude too big at its birth. :)
Hi Ralf,
...my Arch Linux /boot, which contains the kernels, is part of the root directory instead of being its own partition. IOW hundreds of unused GiB are available.
I thought I was old-fashioned for not using LVM and encrypting disk data, e.g. https://wiki.archlinux.org/title/Dm-crypt/Encrypting_an_entire_system#LUKS_o..., but perhaps not. I keep thinking I should do it at the next install. Back to OP Pete's original perennial question of whether a partition can grow, LVM ‘fixed’ that if put in place in advance. -- Cheers, Ralph.
On 2024-01-15 22:39, Genes Lists wrote:
Benefits of no fallback: * smaller space usage and much faster regeneration of initrd [1]
I just disabled the fallback image and the systemd-boot timeout (as I never used them, I always have an Archiso USB stick on hand). # time mkinitcpio -P With fallback ------------- real 0m6.606s user 0m4.546s sys 0m3.489s Without fallback ---------------- real 0m1.122s user 0m0.732s sys 0m0.618s -- tippfehlr
On Tue, 16 Jan 2024 10:08:43 +0100 tippfehlr <tippfehlr@tippfehlr.eu> wrote:
On 2024-01-15 22:39, Genes Lists wrote:
Benefits of no fallback: * smaller space usage and much faster regeneration of initrd [1]
I just disabled the fallback image and the systemd-boot timeout (as I never used them, I always have an Archiso USB stick on hand).
# time mkinitcpio -P
With fallback ------------- real 0m6.606s user 0m4.546s sys 0m3.489s
Without fallback ---------------- real 0m1.122s user 0m0.732s sys 0m0.618s
I might be interested in the no fall back setup i have never booted the fall back kernel i always have an up to date live cd to hand Pete
On Mon, 15 Jan 2024 16:39:17 -0500 Genes Lists <lists@sapience.com> wrote:
On Mon, 2024-01-15 at 19:30 +0000, Serge Korol wrote:
sizes of img files with latest mkinitcpio 37.2-1
* Things seem quite reasonable again with the latest release of mkinitcpio
* I stopped keeping fallback images for both dracut and mkinitcpio. You may or may not choose to do this too.
* -If- you choose to do this and ever need a driver in the initrd for changed hardware (e.g. root drive disk controller) then for that somewhat rare case one should keep a handy usb drive with arch installer so you can boot that and regen the initrd.
Benefits of no fallback: * smaller space usage and much faster regeneration of initrd [1]
* If you choose to no longer keep fallback image then the following is one way to do it:
1) edit /etc/mkinitcpio.d/linux.preset Change preset line to be PRESETS=('default')
2) rm /boot/initramfs-linux-fallback.img
3) Confirm regen initrd:
mkinitcpio -P (or -p linux)
gene
[1] Its initramfs but initrd, while not the same, is sometimes used in place of initramfs and its shorter to type 🙂
Yes got to report all seems back to sanity again updated late last night and back to rights now i got 1 to tackle but i will post another mail for that regarding Firefox Cheers Pete
The issue you faced with kernel 6.7.0 is actually a mkinitcpio issue [1] that made initramfs files grow up in size significantly. Fortunately, this issue already has a patch already tested and merged. [2] :) As detected a moment ago, the current git mkinitcpio version still does not resolve the issue. I am ending up with 5× inflation of the image between linux 6.6.8 and 6.7.0. So the problem remains open. A correction/clarification on the current situation.
There are two factors at hand. One is 6.7.0 introducing nouveau with GSP.⁽¹⁾ The other is an issue in mkinitcpio. They both contribute to image inflation and, independently, the latter is triggered by the former. The commit mentioned by Robin Candau fixes the latter. Upgrading to mkinitcpio 37.2-1 *does* reduce image size for people, who experienced its increase due to the symlinks issue.⁽²⁾ Separately, regardless of the mkinitcpio fix, pulling in nouveau in 6.7.0 still causes the image to be bigger. But this is not something mkinitcpio may address at this point. ____ ⁽¹⁾ https://www.phoronix.com/news/Nouveau-GSP-Merged-Linux-6.7 ⁽²⁾ Not all do, which led to the mkinitcpio fix to appear ineffective.
On Wed, 17 Jan 2024 21:32:04 +0100 mpan <archml-y1vf3axu@mpan.pl> wrote:
The issue you faced with kernel 6.7.0 is actually a mkinitcpio issue [1] that made initramfs files grow up in size significantly. Fortunately, this issue already has a patch already tested and merged. [2] :) As detected a moment ago, the current git mkinitcpio version still does not resolve the issue. I am ending up with 5× inflation of the image between linux 6.6.8 and 6.7.0. So the problem remains open. A correction/clarification on the current situation.
There are two factors at hand. One is 6.7.0 introducing nouveau with GSP.⁽¹⁾ The other is an issue in mkinitcpio. They both contribute to image inflation and, independently, the latter is triggered by the former.
The commit mentioned by Robin Candau fixes the latter. Upgrading to mkinitcpio 37.2-1 *does* reduce image size for people, who experienced its increase due to the symlinks issue.⁽²⁾
Separately, regardless of the mkinitcpio fix, pulling in nouveau in 6.7.0 still causes the image to be bigger. But this is not something mkinitcpio may address at this point. ____ ⁽¹⁾ https://www.phoronix.com/news/Nouveau-GSP-Merged-Linux-6.7 ⁽²⁾ Not all do, which led to the mkinitcpio fix to appear ineffective.
Ok i use ATI Radeon gave up on nouveau Pete
On Wed, 17 Jan 2024 21:58:59 +0000 pete <petegn@mail.com> wrote:
Ok
i use ATI Radeon gave up on nouveau
Pete
But if you're using the kms hook, you still get nouveau in the fallback initramfs.
participants (11)
-
Doug Newgard
-
Genes Lists
-
Michał Zegan
-
mpan
-
pete
-
Ralf Mardorf
-
Ralph Corderoy
-
Robin Candau
-
Serge Korol
-
Severus
-
tippfehlr