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

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

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

hi,

apt-get autoremove does something ?

1 Like

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)

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 :slight_smile:

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.

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

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 ?

hi
are you root ? or use sudo ?

Yes I’m root when I do that :slight_smile:

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…

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

1 Like

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.

3 Likes

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 ?

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 :

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

1 Like

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

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

1 Like