| Summary: | Rpi images are not working | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Jybz <j.biernacki+mga> |
| Component: | RPM Packages | Assignee: | Jybz <j.biernacki+mga> |
| Status: | NEW --- | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | davidwhodgins, ezequiel_partida, filip.komar, zen25000 |
| Version: | Cauldron | ||
| Target Milestone: | --- | ||
| Hardware: | aarch64 | ||
| OS: | Linux | ||
| URL: | https://wiki.mageia.org/en/Installing_Mageia_on_ARM_(Raspberry_PI) | ||
| Whiteboard: | |||
| Source RPM: | CVE: | ||
| Status comment: | |||
| Bug Depends on: | 24084, 26277, 28572, 28818, 30243, 32160, 29560, 32159, 32526 | ||
| Bug Blocks: | |||
|
Description
Jybz
2023-08-11 15:20:10 CEST
Jybz
2023-08-11 15:31:02 CEST
Depends on:
(none) =>
32159
Jybz
2023-08-11 15:31:27 CEST
Depends on:
(none) =>
32160
Jybz
2023-08-11 15:38:19 CEST
Depends on:
(none) =>
30243
Jybz
2023-08-11 15:38:57 CEST
Depends on:
(none) =>
28572
Jybz
2023-08-11 15:46:34 CEST
Depends on:
(none) =>
26277, 29560 On Rpi4, wpa_supplicant could not connect to wifi : - bug https://bugs.mageia.org/show_bug.cgi?id=32160 On Rpi4, there is a long boot : - bug https://bugs.mageia.org/show_bug.cgi?id=26277 - https://bugs.mageia.org/show_bug.cgi?id=29560 The rpi devices do not use an iso. They use images that must be copied to the sd card, such as http://mirror.math.princeton.edu/pub/mageia/distrib/9/aarch64/install/images/ from last April. What have you been testing with? The best way to test them for now is to use an mga8 image and then upgrade it to m9. One way to upgrade is to use "killall mgaapplet" followed by "mgaapplet --testing". CC:
(none) =>
davidwhodgins I've requested updated images be produced, on the sysadmin discuss ml. So where do we assign this? Hardware:
All =>
aarch64 Assigning to iso builders group, though aarch64 uses dd images, not iso images. It that's wrong, please reassign appropriately. Assignee:
bugsquad =>
isobuild Just repeated my upgrade test on an rpi 4b. Copied a working m8 plasma install to a new sd card, booted that and used urpmi to upgrade. Zero bugs noticed. On reboot it's working perfectly so far. OK but what are you supposed to do if you don't have a working Mga8 image? The one in the repo from Feb 2021 does not boot in a RPi4b. Error message says: ----snip start4.elf is not compatible This board requires newer software ----snip Is copying a newer start4.elf etc. from e.g. a working raspbian system likely to work any better than it does with the Mga9 image? CC:
(none) =>
zen25000 Short answer: no. I copied across 8 files: fixup4* start4*.elf Only output was: Net:eth0: ethernet@7d580000 PCIe BRCM: link up, 5Gbps x1 (SSC) starting USB... Bus xhci_pci: probe failed, error -110 No working controllers found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device ERROR: memory not allocated The Mga9 version did get to a login albeit without keyboard.
Barry Jackson
2023-08-12 15:16:08 CEST
Summary:
Rpi ISO are not working =>
Rpi images are not working Yes... Working on it. It is useless to generate new images right now as long as I did not solve the major issues. I assign it to me instead of isobuild team.
Jybz
2023-08-12 15:20:42 CEST
Assignee:
isobuild =>
j.biernacki+mga From lshw on my working rpi 4b, currently back to running m8.
*-firmware
description: BIOS
vendor: U-Boot
physical id: 0
version: 2020.10
date: 02/02/2021
I guess newer versions of the 4b are different enough not to work. The only part
that doesn't work on mine in Mageia is sound via hdmi. It works in raspberian,
but not in Mageia 8. I haven't tested the sound in m9 yet.
The monitor I normally use for it doesn't have speakers, so have to hook it up
to my tv to test sound.
Lewis Smith
2023-08-13 21:20:44 CEST
CC:
lewyssmith =>
(none)
Filip Komar
2023-08-20 18:15:27 CEST
CC:
(none) =>
filip.komar \o/
Il n'y a plus qu'à.
I was able to boot Mageia with USB support, I was able to mount a USB key.
When using proprietary DTB (B for blob, not open source), our u-boot refuses to load the efi as it will overwrite reserved sections.
From u-boot, one can solve the issue by:
> env save
> env set kernel_addr_r 0x00001000
> env save
loading from address 1000h instead of 80000h provide enough space to load the efi and boot grub, then grub the initrd and kernel...
What needs to be done:
On mageia4arm project; copy the bananapro lines which extract and save the default environment of uboot into the root of the FAT boot partition, set the path to the environment file in /etc then use the uboot tools to overwrite set kernel_addr_r with 0x00001000. (If I remember correctly)
I will not do it tonight; good night
As we modify the environment variable, we might set the grub efi file to mageia's one as in x86_64 /efi/mageia/grubx64.efi instead of /efi/BOOT/bootaa64.efi By the way; I don't know what I did wrong at the first time, I got this output, I'm not yet able to debug/understand. Loading Linux 6.4.8-desktop-4.mga9 ... Loading initial ramdisk ... EFI stub: Booting Linux Kernel... "Synchronous Abort" handler, esr 0x96000005 elr: 00000000000b5734 lr : 00000000000b564c (reloc) elr: 000000003df87734 lr : 000000003df8764c x0 : 0000000300905a4d x1 : 000000003db40124 x2 : 0000000000000004 x3 : 000000003df8761c x4 : 000000003db56430 x5 : 000000003db56430 x6 : 000000000000005f x7 : 000000003db40130 x8 : 000000000000003f x9 : 000000003804aa88 x10: 0000000000000004 x11: 000000000000dc00 x12: 0000000000001450 x13: 000000003c918e34 x14: 0000000000000001 x15: 000000003ca445c1 x16: 000000003df8761c x17: 0000000000000000 x18: 000000003db4dd70 x19: 0000000000000004 x20: 0000000000000000 x21: 0000000000000004 x22: 000000003db40124 x23: 0000000080000020 x24: 00000000ffffffff x25: 0000000000000000 x26: 0000000000000007 x27: 0000000000010000 x28: 0000000000000000 x29: 000000003db3ffd0 Code: 1400000a d2803e80 9400a696 f9400280 (b9401800) UEFI image [0x0000000036660000:0x0000000036688fff] '/\efi\BOOT\bootaa64.efi' Resetting CPU ... resetting ... Back on this topic: Finally; the grub generates the efi file at the u-boot's default path. I only modify the preboot avoiding to spend time scanning usb devices and the kernel load address for uboot's environment variable. Current state: The boards loads and execute correctly the firmware (bootcode.bin + start*.elf) The firmware loads correctly the dtb and the u-boot.bin and executes it correctly u-boot.bin loads and executes correctly the first stage of grub (bootaa64.efi) grub loads and execute correctly grub second stage (printing the menu of the different mageia and edition of the kernel command line) grub loads correclty the kernel and the initrd and executes the initrd... The initrd fails to mount /proc and kernel-panic. The given hint : > mount: error while loading shared libraries: libmount.so.1: cannot open shared object file: No such file or directory > Cannot mount proc on /proc! Compile the kernel with CONFIG_PROC_FS! is misleading I think because : > grep CONFIG_PROC_FS /run/media/[...]/boot/config-6.4.9-desktop-4.mga9 > CONFIG_PROC_FS=y But I tried to regenerate an mga8 image and I've the same error, so I'm thinking about an error in the generation of the initrd on my machine and a bug in the mageia4arm project.
Filip Komar
2023-09-01 00:07:32 CEST
Depends on:
(none) =>
24084
Filip Komar
2023-09-01 00:16:18 CEST
Depends on:
(none) =>
28818
Filip Komar
2023-09-01 00:20:04 CEST
URL:
(none) =>
https://wiki.mageia.org/en/Installing_Mageia_on_ARM_(Raspberry_PI) Back after many trials. It seems that the generation of the initrd on a x86_64 machine with chroot+qemu fails. I took an old image with handmade workarround, git clone mageia4arm and generate an rpi-aarch64 image, burn the image on the sd card from the laptop. It boots ! When booted, first steps : - define a root password - regenerate an initrd (avoid 3minutes timeout) : dracut -f - fix wpa_supplicant (comment the line setting wrong frequency) - define wifi configuration : wpa_passphrase - connect to wifi: wpa_supplicant -Dnl80211 -iwlan0 -c/etc/wpa_supplicant.conf & - get an ip address : dhclient - enlarge the root partition: -- install cloud-utils-growpart -- growpart /dev/mmcblk0 2 -- resize2fs /dev/mmcblk0p2 - install drakconf - set the network with drakconf, because it works better at reboot : mmc - define the firewall (on mmc, section firewall) - add a user (adduser) - add your ssh key to your user user friendly :D So currently, for arm images, isobuild team needs to ensure the generation on aarch64 machine. Sorry
Filip Komar
2023-11-20 16:46:49 CET
Depends on:
(none) =>
32526 (In reply to Jybz from comment #15) > Back after many trials. Sounds familiar. > It seems that the generation of the initrd on a x86_64 machine with > chroot+qemu fails. > > I took an old image with handmade workarround, git clone mageia4arm and > generate an rpi-aarch64 image, burn the image on the sd card from the laptop. > > It boots ! Nice! Can you be more specific: 1. on which board it works? 2. are any images somewhere online? is it on our mirrors like: http://mirrors.kernel.org/mageia/distrib/9/aarch64/install/images/ 3. did you fix mageia4arm or did you use another "handmade workarround"? What was it? I would like to test it ;). I have 3B, 4B and 5. Hi, i've a 4B and 5B (waiting for uboot). No need for 3B, i can buy one on wednesday if required. I worked on mageia4arm. https://gitweb.mageia.org/software/mageia4arm/commit/?id=a3b81566b3b730e0a3bc3e768a40498b230bf524 I'm not sysadm, i can not re-generate the images from arm servers. Jybz Hello, any success on rpi 3b? mine boots fine but the keyboard doesn´t work so I can´t do anything. Does somebody knows if openssh-server is activated? This would be great, CC:
(none) =>
ezequiel_partida I pushed on master a fix, tested with Rpi3. There is still one thing to fix: the dracut generation of initrd that takes the build machine drives, thus there is a delay when the rpi start; not finding build machine drives... |