Bug #3555

Bug #3539: [linux-libre]: 6.3.3 fails to load modules with kmod 31

armv7h kernels fails to install properly

ryry - 4 months ago - . Updated 13 days ago.

% Done:



After the issue regarding kmod 31 and the latest linux-libre kernel, it seems any devices which don't have extlinux support and thus ability to use the lts kernel have become unbootable. Would it be possible to have Linux-libre (as 6.5.8-1.vanilla1) as has been done for x86 and i686?

My apologies for raising an issue, if this is being worked on already.

Many thanks



Updated by bill-auger 4 months ago

  • Parent task set to #3539
  • Assignee set to bill-auger
  • Status changed from unconfirmed to in progress

yes i closed #3539 too hastily - it was not forgotten though - the first arm package did not work properly - i had to build it a second time - i only need to test it again now - hopefully it will be ready tomorrow


Updated by ryry 4 months ago

Thanks bill-auger for working on this, I will keep an look out for it in the repos.


Updated by bill-auger 3 months ago

  • Subject changed from Linux-libre as 6.5.8-1.vanilla1 needed for armv7h to armv7h kernels fails to install properly

Updated by ryry 24 days ago

I think the issue I am having, is actually a duplicate of .I noticed that no kernels where working after the recent update to the lts and no updated vmlinuz was being put in the /boot directory, so on the systems uboot with extlinux support I installed the vanilla kernel, which has the fix/workaround in the install which seems to solve this and was able to boot the latest vanilla kernel in the parabola repos. Sorry to be a pain but is there any update on when that might be included with all the other kernels (linux-libre, linux-libre-lts etc)?


Updated by bill-auger 13 days ago

yea sry i got side-tracked on this - i think this 'kmod' problem was fixed though; and i forgot to close this ticket - i could not reproduce this problem myself; so im not sure

so your problem is probably #3520 - you would know simply by looking in /boot to see if the kernel is present - but megver just upgraded linux-libre - i reminded him of the #3520 problem and assumed it was fixed now too

if your problem is #3520, and if you want a quick fix, all you need to do is move the kernel to /boot with the correct filename


Updated by ryry 13 days ago

Thats ok, I had until recently no success copying them over, The U-boots on all 3 different devices seemed to not find the copied vmlinuz or initramfs, reverting to the last but one lts kernel seemed to fix it, however I noticed this when I saw this or something like it in the serial console output so I changed the compression to gzip as suggested and it seems to be I get consistent booting of the most recent linux-libre kernel. So I am not at all sure what was the cause, but either way I am able to boot again. It was only really problematic on the Cubox as its singular Uboot seems to refuse to boot any other kernels so no backup, extlinux uboot allowed me to use the vanilla kernel.

Anyhow thanks once again as always


Updated by bill-auger 13 days ago

  • Status changed from in progress to fixed


Also available in: Atom PDF