When bootscripts do not match the expected kernel of the disk image, the kernel modules are not mapped or are mapped incorrectly

[athena255]

It appears that if a disk image is loaded on a VC server with the incorrect bootscript, then the modules for the running VM kernel will not be mapped or are mapped to the wrong kernel version. The fix for this is to run "depmod -a", but the issue remains that for rolling distributions, it does not seem possible to upgrade the kernel.

---

My specific issue was with the Archlinux image: (https://www.scaleway.com/imagehub/archlinux/) The version I have was using the latest ARM kernel bootscript at the time I first got it which was version ARMv7l 4.4.0. When I shut that server down to boot with the Rescue script and then tried to boot normally after, I could not find the 4.4.0 bootscript in the bootscript options. Any script for kernels higher than 4.4.0 would not boot, so I had to use 3.18.27, which was the only one available that was lower than 4.4.0.

The problem is that kernel modules for the bootscript specified kernel are not loaded on restart. When manually trying to load those modules with modprobe, the modules are not found because there is no mapping in /lib/modules/3.18.27-ARCH. The mappings are in /lib/modules/4.4.0-ARCH, so then running "depmod -a" recreates the mappings and allows the modules to be loaded.

[QuentinPerez]

Hi @athena255,

You can patch the server to recover your bootscript with our CLI

$ scw _patch your_server bootscript=71018833-6c91-43c3-a405-492a6c34f745 # 4.4 std
$ scw restart your_server
$ scw exec -w roman "uname -a"
Linux romantic-ride 4.4.0-std-1 #1 SMP Wed Jan 20 13:27:11 UTC 2016 armv7l GNU/Linux