Just saw that there were some
new updates to these not working packages,
https://archlinuxarm.org/packages/armv7 ... -armv7/loghttps://github.com/archlinuxarm/PKGBUIL ... inux-armv7The updates were from version linux-armv7 5.11.0-1, to, version linux-armv7 5.11.0-2.
It seems it was only this little change in file "config"
$this->bbcode_second_pass_code('', '
-CONFIG_VIRTIO_PCI=m
+CONFIG_VIRTIO_PCI=y')
I already tested them. On the rescue USB stick of course, not on the main chromebook.
No change in the situation.
The same boot problem continues.
PS: The above commit seems to be totally unrelated to this problem, but still interesting.
I am not very knowlegdeable about "who" and "how" these kernel packages updates work.
Could someone who knows, describe these proceses better, to us end users ?
This might be one of those, "this is obvious". Well it might be "obvious" to you if you are a maintainer, developer working daily on this stuff.I cant seem to form a picture of how the "system" works just by reading what is available on the main site, archlinuxarm.org
I am really curious about how all these important big kernel changes, in the end affect my laptop and my raspberry pi running arch arm. Where do those updates come from ? "Upstream" linux? The Raspberry Foundation linux kernel fork ? Individual Arch arm developer changes ? Who is a "commiter" and who is an "author" ? Why do these changes break the system sometimes ? Arent they automatically tested ?
In this case, let me have a go trying to understand it with this example.
Alexandru Stan seems to be a google employee,
https://hypertriangle.com/~alex/resume/With a personal fork of the PKGBUILDS,
https://github.com/amstan/PKGBUILDs .
His changes ,
https://github.com/amstan/PKGBUILDs/commits/master , seem to be regularly merged into the official PKGBUILDS
He had this interesting pull request,
https://github.com/archlinuxarm/PKGBUILDs/pull/1856$this->bbcode_second_pass_quote('', '.')..I was finally able to get my qemu going for linux-armv7
that was accepted . And so now it is apparently possible to boot a arm qemu image an x86 with with other qemu options:
$this->bbcode_second_pass_code('', '[code]qemu-system-arm -machine virt -m 4G -drive if=none,file=image_file,format=raw,id=hd0 -device virtio-blk-device,drive=hd0 -kernel boot/zImage -nographic -append "root=/dev/vda1 rw" -initrd boot/initramfs-linux.img[/code]')