Hi,
I failed miserably during my first attempt to upgrade from Una to Vanessa. Although I had enough remaining free disk space as per the recommendations given by mintupgrade (something like 5.5 gig or so), I ran out of diskspace towards the end of the upgrade, when the new (additional) kernel 5.15.0-67 is compiled, and was left with a broken and unbootable system. Also, mintupgrade went into an endless loop, retrying ever again to compile the kernel (maybe some source code to fix?).
So I recommend to add some 1 or better 2 gig of free disk space to the figure recommended by mintupgrade.
Best,
T.
For the upgrade to Vanessa, reserve more disk space
Forum rules
Before you post read how to get help. Topics in this forum are automatically closed 6 months after creation.
Before you post read how to get help. Topics in this forum are automatically closed 6 months after creation.
For the upgrade to Vanessa, reserve more disk space
Last edited by LockBot on Wed Sep 20, 2023 10:00 pm, edited 1 time in total.
Reason: Topic automatically closed 6 months after creation. New replies are no longer allowed.
Reason: Topic automatically closed 6 months after creation. New replies are no longer allowed.
Re: For the upgrade to Vanessa, reserve more disk space
A kernel only takes up approximately 125MiB, the functioning part of it anyway(in /boot). Initial installation of it is about another 500MiB(in /system space) with the files an headers and modules required to build it out. So all in all not even much in the scheme of things. So space is probably not an issue overall.
a 5.4 kernel and many prior only took close to 100MiB, in /boot.
the 5.15 and later are more like the 125MiB mark now, in /boot.
HOWEVER, if you have a separated /boot partition, which some users have done on purpose(it used to be popular many years ago when disk space was not what it is today), OR if you have a default full disk encryption scheme setup, then there is a definite notable space constraint with the separated partition(which is typically pretty small in comparison to disk size, maybe a few hundred M or even 5 or 600M or even 1 or 1.5Kib). And you have to personally manage that partition, because it will fill up, and keeps tabs on what's going on space-wise.
If you have a /boot partition of, say, 500MiB, then you might just barely get 4 kernels stored there(before you have to use space management and remove one or more), but you can definitely have 3 without any space concern at all.
You can use the Kernel Manager from within the Mint Update Manager and check the "View" menu -> Linux kernels. There is also a feature for mass removal of unused kernels, -in case you have a whole list of them spread across all the different minor version series(many of who are EOL and you should not be using anyway).
A typical user will always keep at least 2, because in a drastic situation, perhaps the lastest Nvidia driver update, -then having the previous kernel still there gives an easy way to boot to that one while you can correct the driver, or whatever other kernel booting problem that might have come. 3 seems to be the defacto number(although there's no exact rule), but by the fact that if you are always keeping 2, to install the newer one you end up with 3. anyway...
Another point is that when you do a kernel upgrade(just get the next latest version), or change a variety of drivers or certain programs that are kernel dependent, maybe VirtualBox, then EACH old kernel left on the system will be required to be rebuilt against the newer package(s). And it seems typical that this is the biggest time consuming thing during an update, rebuilding those initramfs files. And if you are doing it against 8 or 9 kernels that's a big deal, time-wise.
So, check out your situation, just revert that snapshot, do some kernel management, and then go again, you'll be fine.
a 5.4 kernel and many prior only took close to 100MiB, in /boot.
the 5.15 and later are more like the 125MiB mark now, in /boot.
HOWEVER, if you have a separated /boot partition, which some users have done on purpose(it used to be popular many years ago when disk space was not what it is today), OR if you have a default full disk encryption scheme setup, then there is a definite notable space constraint with the separated partition(which is typically pretty small in comparison to disk size, maybe a few hundred M or even 5 or 600M or even 1 or 1.5Kib). And you have to personally manage that partition, because it will fill up, and keeps tabs on what's going on space-wise.
If you have a /boot partition of, say, 500MiB, then you might just barely get 4 kernels stored there(before you have to use space management and remove one or more), but you can definitely have 3 without any space concern at all.
You can use the Kernel Manager from within the Mint Update Manager and check the "View" menu -> Linux kernels. There is also a feature for mass removal of unused kernels, -in case you have a whole list of them spread across all the different minor version series(many of who are EOL and you should not be using anyway).
A typical user will always keep at least 2, because in a drastic situation, perhaps the lastest Nvidia driver update, -then having the previous kernel still there gives an easy way to boot to that one while you can correct the driver, or whatever other kernel booting problem that might have come. 3 seems to be the defacto number(although there's no exact rule), but by the fact that if you are always keeping 2, to install the newer one you end up with 3. anyway...
Another point is that when you do a kernel upgrade(just get the next latest version), or change a variety of drivers or certain programs that are kernel dependent, maybe VirtualBox, then EACH old kernel left on the system will be required to be rebuilt against the newer package(s). And it seems typical that this is the biggest time consuming thing during an update, rebuilding those initramfs files. And if you are doing it against 8 or 9 kernels that's a big deal, time-wise.
So, check out your situation, just revert that snapshot, do some kernel management, and then go again, you'll be fine.
Re: For the upgrade to Vanessa, reserve more disk space
How much free space was available in your system as a percentage? The operating system needs at least 5% free space just to boot. For your system to run well, the root partition should be less than 75% full.
I would recommend checking, and cleaning if necessary, one's system based on the percent full prior to an upgrade rather than just checking absolute values.
A woman typing on a laptop with LM20.3 Cinnamon.
Re: For the upgrade to Vanessa, reserve more disk space
All my linux partitions are 20 GiB, which is fairly small I admit. They all have all their files (/root, /boot/, /home etc.) in their own partitions (except /boot/efi/ of course).
My LM partition was about 75% full, and I had to do some little cleaning (in ~/Downloads) to satisfy the disk free check built into mintupgrade. When I had 5.5 gig free, I got past the check and the upgrade started.
I was on kernel 5.4.0-144 when the upgrade was initiated. I don't know why mintupgrade decided to change to 5.15. Anyway, that was the case, and ran me into the said troubles (out of diskspace in combination with a loop on kernel compile).
After the recovery with timeshift, I then decided to offload more stuff from my home directory, eg. ~/Videos and ~/Music, until I got 7 gigs free. I restarted the upgrade and it went through w/o issues.
T.
My LM partition was about 75% full, and I had to do some little cleaning (in ~/Downloads) to satisfy the disk free check built into mintupgrade. When I had 5.5 gig free, I got past the check and the upgrade started.
I was on kernel 5.4.0-144 when the upgrade was initiated. I don't know why mintupgrade decided to change to 5.15. Anyway, that was the case, and ran me into the said troubles (out of diskspace in combination with a loop on kernel compile).
After the recovery with timeshift, I then decided to offload more stuff from my home directory, eg. ~/Videos and ~/Music, until I got 7 gigs free. I restarted the upgrade and it went through w/o issues.
T.
Re: For the upgrade to Vanessa, reserve more disk space
The minimum kernel requirement for LM21 is the 5.15 LTS kernel. That is why you were upgraded.
A woman typing on a laptop with LM20.3 Cinnamon.
Re: For the upgrade to Vanessa, reserve more disk space
Great news!
Alternately, just saying this for the info, you could go to the snapshot, and then the same kernel 5.15 is available from the 20.x line, install that, clean any old ones, that might free up 100's of MiB or maybe up to almost 1KiB.
(not that this will do anything useful) But then go with the upgrade and the kernel transition would not be a necessity. 
good job though! Glad it worked out.
Alternately, just saying this for the info, you could go to the snapshot, and then the same kernel 5.15 is available from the 20.x line, install that, clean any old ones, that might free up 100's of MiB or maybe up to almost 1KiB.
(not that this will do anything useful) But then go with the upgrade and the kernel transition would not be a necessity. good job though! Glad it worked out.
Re: For the upgrade to Vanessa, reserve more disk space
Great post zcot!
I have several installations with separate /boot and /var that are (very) tight for space. I find that as well as /boot, /var can fill up when replacing a kernel, during the building of initramfs. So making sure you have enough space on both if you operate with them as separate drives, partitions, or LVM volumes is wise.
I have several installations with separate /boot and /var that are (very) tight for space. I find that as well as /boot, /var can fill up when replacing a kernel, during the building of initramfs. So making sure you have enough space on both if you operate with them as separate drives, partitions, or LVM volumes is wise.
-
toomanycharacter
- Level 1
- Posts: 5
- Joined: Thu Aug 04, 2022 2:42 pm
Re: For the upgrade to Vanessa, reserve more disk space
I just had almost exactly the same problem.
Disk space ran out during the upgrade and mintupgrade went into a (quasi) infinite loop. After about 30 mins of that loop, it gave some error about "needing to keep 0 more packages". Pressing any of the buttons did basically nothing, so I quit mintupgrade and shut down the system. I added 20 more gigs to root and reverted to the snapshot I made right before upgrading using Timeshift on the live installation.
Wouldn't it be really easy to put a warning into mintupgrade that pops up if root has less than 10-15% free space? That would have saved me (and, probably, hundreds other people) a few hours.
Disk space ran out during the upgrade and mintupgrade went into a (quasi) infinite loop. After about 30 mins of that loop, it gave some error about "needing to keep 0 more packages". Pressing any of the buttons did basically nothing, so I quit mintupgrade and shut down the system. I added 20 more gigs to root and reverted to the snapshot I made right before upgrading using Timeshift on the live installation.
Wouldn't it be really easy to put a warning into mintupgrade that pops up if root has less than 10-15% free space? That would have saved me (and, probably, hundreds other people) a few hours.