Migration to V11: failed because of /boot/ has less than 70MB available

colletda · August 21, 2022, 3:53pm

Hi folks

My YunoHost server

Hardware: HP-Mini-Server at home
YunoHost version: 4.4.2.8 (stable).
I have access to my server : through the webadmin and direct access via keyboard / screen
Are you in a special context or did you perform some particular tweaking on your YunoHost instance ? : no

Description of my issue

I startet the last update and it offers the migration to V11. As I started the migration it raises a error: “/boot/ has less than 70MB available.”

https://paste.yunohost.org/raw/ikigudixah

How I can handle that?
Kind reagards

Daniel

Cellophile · August 22, 2022, 11:25am

Hello,
Same issue here.
Can we suppress some kernels of /boot folder ?
I have that :

root@serveur:/boot# ls -l
total 174936
-rw-r--r-- 1 root root   206267 sept. 29  2021 config-4.19.0-18-amd64
-rw-r--r-- 1 root root   206331 mars   7 22:13 config-4.19.0-19-amd64
-rw-r--r-- 1 root root   206331 mars  17 20:48 config-4.19.0-20-amd64
-rw-r--r-- 1 root root   206378 juin  30 14:52 config-4.19.0-21-amd64
drwxr-xr-x 5 root root     1024 août  22 12:32 grub
-rw-r--r-- 1 root root 35843971 déc.   9  2021 initrd.img-4.19.0-18-amd64
-rw-r--r-- 1 root root 35850237 mars  22 09:19 initrd.img-4.19.0-19-amd64
-rw-r--r-- 1 root root 35855573 mai    6 11:55 initrd.img-4.19.0-20-amd64
-rw-r--r-- 1 root root 35855210 août  22 10:58 initrd.img-4.19.0-21-amd64
drwx------ 2 root root    12288 mai   29  2021 lost+found
-rw-r--r-- 1 root root  3423029 sept. 29  2021 System.map-4.19.0-18-amd64
-rw-r--r-- 1 root root  3425681 mars   7 22:13 System.map-4.19.0-19-amd64
-rw-r--r-- 1 root root  3425737 mars  17 20:48 System.map-4.19.0-20-amd64
-rw-r--r-- 1 root root  3417138 juin  30 14:52 System.map-4.19.0-21-amd64
-rw-r--r-- 1 root root  5291264 sept. 29  2021 vmlinuz-4.19.0-18-amd64
-rw-r--r-- 1 root root  5299456 mars   7 22:13 vmlinuz-4.19.0-19-amd64
-rw-r--r-- 1 root root  5299456 mars  17 20:48 vmlinuz-4.19.0-20-amd64
-rw-r--r-- 1 root root  5299456 juin  30 14:52 vmlinuz-4.19.0-21-amd64

nounix · August 22, 2022, 12:08pm

hi,

apt-get autoremove does something ?

Mamie · August 22, 2022, 1:04pm

That’s what I do on my personal computer to remove old kernels, but I’ll soon expand the /boot partition to avoid this reccurent problem. (Only on my PC, I never had it on my server)

Cellophile · August 22, 2022, 2:09pm

Hi,
This command remove this packages for me : bind9-utils bind9utils dnsutils libicu63 libllvm7 libreadline7 php-gettext postgresql-11 postgresql-client-11 python3-ply python3-publicsuffix

It’s always cool, but not what we want

I’ve tried to move some things of my boot folder : I’ve moved all files with 4.19.0-18 and 4.19.0-19.
On the safe side, I’ve only moved that in another folder rather than delete it. After that, I could do the migration !

I’ve read on the net that it’s better to keep one version before the current version. So all the others can be deleted.

After migration, I’ve that in /boot folder : (as you ca see, the migration deletes automatically the 4.19.0-20 files)

root@serveur:/boot# ls -l
total 87535
-rw-r--r-- 1 root root   206378 30 juin  14:52 config-4.19.0-21-amd64
-rw-r--r-- 1 root root   236286 13 août  15:25 config-5.10.0-17-amd64
drwxr-xr-x 5 root root     1024 22 août  15:04 grub
-rw-r--r-- 1 root root 35855210 22 août  10:58 initrd.img-4.19.0-21-amd64
-rw-r--r-- 1 root root 37640602 22 août  15:02 initrd.img-5.10.0-17-amd64
drwx------ 2 root root    12288 29 mai    2021 lost+found
-rw-r--r-- 1 root root  3417138 30 juin  14:52 System.map-4.19.0-21-amd64
-rw-r--r-- 1 root root       83 13 août  15:25 System.map-5.10.0-17-amd64
-rw-r--r-- 1 root root  5299456 30 juin  14:52 vmlinuz-4.19.0-21-amd64
-rw-r--r-- 1 root root  6962816 13 août  15:25 vmlinuz-5.10.0-17-amd64

I’ve reboot my server (systemctl reboot), all is fine !
And to finish, I’ve deleted the folder with moved files.

nounix · August 22, 2022, 2:23pm

You should delete old kernels with apt remove instead rm.

to list all installed kernels : dpkg -l |grep linux-image and remove the ones you want with apt remove.
to see which one is in use : uname -a

Cellophile · August 22, 2022, 4:10pm

the command dpkg -l |grep linux-image gives this :

rc  linux-image-4.19.0-17-amd64           4.19.194-3                                         amd64        Linux 4.19 for 64-bit PCs (signed)
rc  linux-image-4.19.0-19-amd64           4.19.232-1                                         amd64        Linux 4.19 for 64-bit PCs (signed)
rc  linux-image-4.19.0-20-amd64           4.19.235-1                                         amd64        Linux 4.19 for 64-bit PCs (signed)
ii  linux-image-4.19.0-21-amd64           4.19.249-2                                         amd64        Linux 4.19 for 64-bit PCs (signed)
ii  linux-image-5.10.0-17-amd64           5.10.136-1                                         amd64        Linux 5.10 for 64-bit PCs (signed)
ii  linux-image-amd64                     5.10.136-1                                         amd64        Linux for 64-bit PCs (meta-package)

But if I do apt remove linux-image-4.19.0-17-amd64, I’ve that :

Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
E: Unable to locate package linux-image-4.19.0-17-amd64
E: Couldn't find any package by glob 'linux-image-4.19.0-17-amd64'

Maybe I make a mistake in my command ?

poupz13 · August 22, 2022, 4:15pm

hi
are you root ? or use sudo ?

Cellophile · August 22, 2022, 4:16pm

Yes I’m root when I do that

Cellophile · August 22, 2022, 4:19pm

Maybe it’s beacause I’ve already deleted images by a wrong way…
On another server, I have the same problem, but I hadn’t suppress something before, so It’s not because of a wrong practice :

First, see all images :

root@server:/# dpkg -l |grep linux-image
ii  linux-image-4.19.0-18-cloud-amd64     4.19.208-1                                         amd64        Linux 4.19 for x86-64 cloud (signed)
rc  linux-image-4.19.0-19-cloud-amd64     4.19.232-1                                         amd64        Linux 4.19 for x86-64 cloud (signed)
rc  linux-image-4.19.0-20-cloud-amd64     4.19.235-1                                         amd64        Linux 4.19 for x86-64 cloud (signed)
ii  linux-image-4.19.0-21-cloud-amd64     4.19.249-2                                         amd64        Linux 4.19 for x86-64 cloud (signed)
ii  linux-image-5.10.0-17-cloud-amd64     5.10.136-1                                         amd64        Linux 5.10 for x86-64 cloud (signed)
ii  linux-image-cloud-amd64               5.10.136-1                                         amd64        Linux for x86-64 cloud (meta-package)

And the one currently used :

root@server:/#  uname -a
Linux vps-serveur01.captp.fr 5.10.0-17-cloud-amd64 #1 SMP Debian 5.10.136-1 (2022-08-13) x86_64 GNU/Linux

Deletion of the older :

root@server:/# sudo apt remove linux-image-4.19.0-18-cloud-amd64
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages will be REMOVED:
  linux-image-4.19.0-18-cloud-amd64
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
After this operation, 73.9 MB disk space will be freed.
Do you want to continue? [Y/n] y
(Reading database ... 97297 files and directories currently installed.)
Removing linux-image-4.19.0-18-cloud-amd64 (4.19.208-1) ...
/etc/kernel/postrm.d/initramfs-tools:
update-initramfs: Deleting /boot/initrd.img-4.19.0-18-cloud-amd64
/etc/kernel/postrm.d/zz-update-grub:
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.10.0-17-cloud-amd64
Found initrd image: /boot/initrd.img-5.10.0-17-cloud-amd64
Found linux image: /boot/vmlinuz-4.19.0-21-cloud-amd64
Found initrd image: /boot/initrd.img-4.19.0-21-cloud-amd64
done

Display of all images :

root@server:/# dpkg -l |grep linux-image
rc  linux-image-4.19.0-18-cloud-amd64     4.19.208-1                                         amd64        Linux 4.19 for x86-64 cloud (signed)
rc  linux-image-4.19.0-19-cloud-amd64     4.19.232-1                                         amd64        Linux 4.19 for x86-64 cloud (signed)
rc  linux-image-4.19.0-20-cloud-amd64     4.19.235-1                                         amd64        Linux 4.19 for x86-64 cloud (signed)
ii  linux-image-4.19.0-21-cloud-amd64     4.19.249-2                                         amd64        Linux 4.19 for x86-64 cloud (signed)
ii  linux-image-5.10.0-17-cloud-amd64     5.10.136-1                                         amd64        Linux 5.10 for x86-64 cloud (signed)
ii  linux-image-cloud-amd64               5.10.136-1                                         amd64        Linux for x86-64 cloud (meta-package)

There is always the one I just delete ! I attempt to delete it one more time :

root@server:/# sudo apt remove linux-image-4.19.0-18-cloud-amd64
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Package 'linux-image-4.19.0-18-cloud-amd64' is not installed, so not removed
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Without success. I attempt to delete another old kernel :

root@server:/# sudo apt remove linux-image-4.19.0-19-cloud-amd64
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Package 'linux-image-4.19.0-19-cloud-amd64' is not installed, so not removed
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

No more success. I don’t understand…

nounix · August 22, 2022, 4:38pm

rc flag mean that the package is removed and the config-files are present

So everything’s fine. If you want, you can purge them by dpkg -P linux-image... but it’s not needed

colletda · August 24, 2022, 1:40pm

This was in my case the solution:

Thank you for the hints. With this I can delete a older image (270MB) and I could start the migration. I’m now on YunoHost 11.

zzthom · August 27, 2022, 5:00pm

Same error here on my RPi-3 - my /boot is 44M in total, so I cannot reach the 75M requirement.

$ df -h
[...]
/dev/mmcblk0p1   44M   25M   19M  58% /boot

I did my install a few years ago, following the official instructions (of that time)

Is there a solution ? Or should I install the v11 from scratch ?

Aleks · August 27, 2022, 5:17pm

Zblerg I guess you can edit the code directly …

Should be something like

sudo nano /usr/lib/moulinette/yunohost/data_migrations/0021_migrate_to_bullseye.py

Then find this line :

github.com

YunoHost/yunohost/blob/buster/src/yunohost/data_migrations/0021_migrate_to_bullseye.py#L387


      
                  pass
          
          

          
    raise YunohostError("migration_0021_not_buster2")
          
          
# Have > 1 Go free space on /var/ ?
          if free_space_in_directory("/var/") / (1024**3) < 1.0:
              raise YunohostError("migration_0021_not_enough_free_space")
          
          
# Have > 70 MB free space on /var/ ?
          if free_space_in_directory("/boot/") / (1024**2) < 70.0:
              raise YunohostError("/boot/ has less than 70MB available. This will probably trigger a crash during the upgrade because a new kernel needs to be installed. Please look for advice on the forum on how to remove old, unused kernels to free up some space in /boot/.", raw_msg=True)
          
          
# Check system is up to date
          # (but we don't if 'bullseye' is already in the sources.list ...
          # which means maybe a previous upgrade crashed and we're re-running it)
          if os.path.exists("/etc/apt/sources.list") and " bullseye " not in read_file(
              "/etc/apt/sources.list"
          ):
              tools_update(target="system")
              upgradable_system_packages = list(_list_upgradable_apt_packages())

and replace the < 70.0 criteria with whatever … i guess 18 in your case … which sounds uncomfortably low …

zzthom · August 27, 2022, 8:10pm

thanks a lot aleks, it worked like a charm, 18M was enough in my case

inizi · September 1, 2022, 10:12pm

Same Pi, same problem.
Aleks solution worked also for me to.
Thanks a lot Aleks

system · October 1, 2022, 10:12pm

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.