Created attachment 11526 [details]
dmesg

Attach dmesg

Thanks for the dmesg attachment. It might help also to attach the O/P of:
 $ journalctl -ab
since that has timestamps (possibly too late).
Also, with a camera ready, get the boot process shown on-screen (Esc), and if it really does stick at a certain point, take the screenshot. That should show exactly where it is happening.

CC: (none) => lewyssmith

@Jybz, can you provide more details regarding your configuration, fstab?

Can you eventually try to regenerate current booting initrd by issuing command below (root's password required):

$ su -c 'dracut --force'

Keywords: (none) => NEEDINFO

Closing as OLD since none of the requested information was given.

Feel free to reopen this report if this issue is still present, while providing the information requested in comment 3 and comment 4

Status: NEW => RESOLVED
Resolution: (none) => OLD
CC: (none) => marja11

Created attachment 12197 [details]
Dracut --force

dracut

Created attachment 12198 [details]
journal -ab

journal

Status: RESOLVED => REOPENED
Resolution: OLD => (none)
Assignee: bugsquad => j.biernacki+mga

You want to resolve this by yourself as assignee? ;-)

BTW, attachment 12198 [details] doesn't give details on what's going on.
I do see:
janv. 08 15:42:44 jabztop kernel: microcode: microcode updated early to revision 0x27, date = 2019-02-26
janv. 08 15:42:44 jabztop kernel: Linux version 5.7.19-desktop-3.mga7 (iurt@ec2x1.mageia.org) (gcc version 8.4.0 (Mageia 8.4.0-1.mga7), GNU ld (GNU Binutils) 2.33.1) #1 SMP Sun Oct 18 15:46:00 UTC 2020
janv. 08 15:42:44 jabztop kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-5.7.19-desktop-3.mga7 root=UUID=2cbc79ae-8fa3-4a9d-a30d-1971e35a51fc ro splash audit=0

A boot starts at janv. 08 15:42:44
Root is mounted at janv. 08 15:42:44
you log on at janv. 08 15:43:23

This is superfast
But this line gives us a clue:
janv. 08 15:42:58 jabztop systemd[1]: Startup finished in 1.854s (firmware) + 3.624s (loader) + 2min 12.474s (kernel) + 14.769s (userspace) = 2min 32.723s.

Log timestamps are inaccurate.

See lot of errors/missing devices in your log.
Best things that can be done is to unplug all unnecessary devices, usb,...
Restart and see.

I don't see any one problem causing a long delay, but a lot of small things
that are adding up.

I'd start by fixing
janv. 08 15:42:46 jabztop mount[2941]: The disk contains an unclean file system (0, 0).
janv. 08 15:42:46 jabztop mount[2941]: Metadata kept in Windows cache, refused to mount.
janv. 08 15:42:46 jabztop mount[2941]: Falling back to read-only mount because the NTFS partition is in an
janv. 08 15:42:46 jabztop mount[2941]: unsafe state. Please resume and shutdown Windows fully (no hibernation
janv. 08 15:42:46 jabztop mount[2941]: or fast restarting.)

To fix ERROR     : [/etc/sysconfig/network-scripts/ifup-eth] Device enp0s29u1u1 does not seem to be present,
remove /etc/sysconfig/network-scripts/ifcfg-enp0s29u1u1

To fix ipmievd[3125]: Could not open device at /dev/ipmi0 or /dev/ipmi/0 or /dev/ipmidev/0: No such file or directory
remove the package ipmitool.

Run fsck as per FAT-fs (sda2): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.

Check the usb connections as per usb 1-1-port3: Cannot enable. Maybe the USB cable is bad?
You may need to replace the cable, and/or clean the port used to plug in the
cable.

After the above are done, fully shutdown, then after a new boot attach a new
copy of the journal output from "journalctl -ab --no-hostname".

CC: (none) => davidwhodgins

Also, to fix "Device vboxnet0 does not seem to be present", uninstall the
package virtualbox-guest-additions.

Created attachment 12261 [details]
dmesg

Windows restarted (I forgot that I had win :-D)
fschk.fat /dev/sda2 run, dirty bit removed.
rm /etc/sysconfig/network-scripts/ifcfg-enp0s29u1u*
urpme ipmitool virtualbox-guest-additions
bad usb : we have to deal with, it is the broken builtin laptop camera. 
rebooted

btw : I had to force to reboot pressing on the power key, the system hang on "reached target reboot \n target reboot" (or something so). I could still switch over the splashscreen, ctrl+alt+f1, ctrl+alt+f12.

See the dmesg, next message with journalctl

Attachment 11526 is obsolete: 0 => 1

Created attachment 12262 [details]
journalctl

journalctl

Attachment 12198 is obsolete: 0 => 1

Except for the time sync making figuring out how long things actually took
difficult, the journal shows no problems up to the point autologin has completed
and akonadi has started indexing everything it can read, making the system
unresponsive until it completes it's initial indexing.

Using the power button to kill it just means that the next boot, it will have
to start from the beginning again. It also means that the file systems may
need fsck run against them again.

As to the camera, see if there is a bios option to disable it.

The root file system is on sda5, a ST500LM021-1KJ152 spinning rust drive with
an ssd cache. As it uses 4096-byte physical blocks with 512-byte logical blocks,
partition alignment is critical. If a partition does not start on a 4k boundary,
then every 4k write by the kernel is translated by the drive's firmware into
two 4k reads, merging the 4k write into the two 4k blocks it read, and then
two 4k writes. https://www.diskgenius.com/how-to/4k-alignment.php

For now, start it up again, and leave it running until akonadi can finish
indexing everything, or disable it's indexing. In systemsettings5, Workspace,
Search, under File Search, uncheck the option to Enable File Search, and under
Plasma Search uncheck every box that is checked. You may have little choice
but to wait for the indexing to finish before you can get systemsettings5 to
run.

I'd strongly recommend switching to a clean install using xfce4 rather then
plasma or gnome. Both plasma and gnome are designed for relatively new hardware,
and keep adding things that make them too resource hungry for older or slower
hardware. If the drive can be wiped and diskdrake is used to create the new
partitions, it will keep the partitions aligned ok. If using other partitioning
software, be very careful with partition alignment.

I'm still using an 8 year old 16GB ram quad core desktop system, but have
replaced it's spinning rust drives with ssd drives only. Except on testing
installs (where akonadi doesn't have much to index), I disable all of the
search indexing. Note that akonadi will index everything the user has read
access to, including mounted network file systems or other internal file
systems. If there are large file systems, it can easily take a few hours for
the initial indexing.

Forgot to add. Using the power button should only be done if the keyboard is
not responding at all. Use ...
https://en.wikipedia.org/wiki/Raising_Skinny_Elephants_Is_Utterly_Boring

Hold down the alt, ctrl and sysrq/print screen keys. While holding them down
press and release the following keys in order. r, s, e, i, s, u, b.

That way the file systems will be properly synced and unmounted before rebooting.

Perhaps "Raising_Skinny_Elephants_Is_So_Utterly_Boring" here!
An invaluable reference.
"The key combination consists of Alt+SysRq (for Linux Mint, the combination is Ctrl Alt+SysRq ) and another key".
How many hands do you need?
Ah: " SysRq may be released before pressing the command key, as long as Alt remains held down". Thank goodness!
---
On a more serious note, I recently came across a utility to monitor what takes the most time during system start. But my rpm system is en panne, and I cannot look for it. Perhaps Dave will know.

CC: lewyssmith => (none)

That would be "systemd-analyze blame". There's also ...
$ systemd-analyze plot>plot.svg
$ firefox plot.svg
to view the same information in a critical path gantt chart.

Created attachment 12347 [details]
systemd-analyse plot

Systemd-analyse plot,
unfortunately, nothing interesting.

Created attachment 12348 [details]
systemd-analyse plot

Systemd-analyse plot, nothing interesting.

Sorry for the double post, but uploading the svg crashed twice the server, saying me I have to redo, and finally kick me out to the home page.

Something interesting with blame, Almost 2minutes for dnf.

> [root@jabztop jibz]# systemd-analyze blame 
>     1min 52.838s dnf-makecache.service
>           6.039s adb.service
>           2.331s postfix.service
>           2.012s network.service
>           1.857s mandriva-everytime.service
>           1.497s plymouth-start.service
>            746ms systemd-udev-settle.service

> [root@jabztop ~]# systemctl mask dnf-makecache.service 
> Created symlink /etc/systemd/system/dnf-makecache.service → /dev/null.
> [root@jabztop ~]# systemctl mask dnf-makecache.timer 
> Created symlink /etc/systemd/system/dnf-makecache.timer → /dev/null.

I'm waiting for something before restarting. Suspense...

Fail... 

> [root@jabztop ~]# systemd-analyze blame 
>           6.038s adb.service
>           2.669s mandriva-everytime.service
>           2.398s postfix.service
>           2.109s network.service
>           1.454s plymouth-start.service

> [    4.133762] usb 1-1.3: new high-speed USB device number 4 using ehci-pci
> [    4.247276] usb 1-1.3: New USB device found, idVendor=04f2, idProduct=b3fd, bcdDevice=69.54
> [    4.248319] usb 1-1.3: New USB device strings: Mfr=3, Product=1, SerialNumber=2
> [    4.249336] usb 1-1.3: Product: USB2.0 HD UVC WebCam
> [    4.250343] usb 1-1.3: Manufacturer: Chicony Electronics Co.,Ltd.
> [    4.251353] usb 1-1.3: SerialNumber: 0x0001
> [  131.382607] dracut: Scanning for all btrfs devices
> [  131.900856] EXT4-fs (sda5): INFO: recovery required on readonly filesystem
> [  131.901857] EXT4-fs (sda5): write access will be enabled during recovery
> [  132.632845] EXT4-fs (sda5): orphan cleanup on readonly fs
> [  132.637356] EXT4-fs (sda5): 5 orphan inodes deleted
> [  132.638508] EXT4-fs (sda5): recovery complete
> [  132.662190] EXT4-fs (sda5): mounted filesystem with ordered data mode. Opts: (null)

I only use dnf when testing it, and not in my main install, so am not that
familiar with it.

I'm wondering if there is a big difference between a hard reset and a soft
reset.

Please fully shutdown and poweroff the system. Boot it, then attach the output
of "journalctl -b --no-hostname >journal.cold.txt" and then reboot the system
using "systemctl reboot" (use the magic sysrq keys if necessary to reboot),
and then attach the output of journalctl -b --no-hostname >journal.warm.txt"

@Jybz, you said that webcam is broken.
Can you disable it in BIOS or better try to disconnect it physically by opening your laptop?

This looong boot process in kernel space reminds me a timeout somewhere when Kernel try to initialize all peripherals.

This is strange there is not some warning here.

Also, this line: "dracut: Scanning for all btrfs devices"
Why?

On, my system with 0 (zero) btrfs partition:
$ journalctl -b --no-pager | grep btrfs

$ journalctl -b --no-pager | grep Btrfs
mars 12 09:00:23 mageia.local kernel: Btrfs loaded, crc32c=crc32c-generic

perhaps it is this? Do you have btrfs partitions?
(Seeing your comment 20)

Keywords: NEEDINFO => (none)

Also given the 6 second delay looking for android devices, do you need
# systemctl -a status adb.service
● adb.service - Android Debug Bridge (adb) service
   Loaded: loaded (/usr/lib/systemd/system/adb.service; disabled; vendor preset: disabled)
   Active: inactive (dead)

started at boot or could you start it manually only when needed.

Oh ?!

I didn't had time yet to continue.

BUT https://bugs.mageia.org/show_bug.cgi?id=28572#c9
> [   47.240409] hid-generic 0003:1A2C:0C21.0004: input,hidraw1: USB HID v1.10 Mouse [USB USB Keyboard] on usb-0000:01:00.0-1.3/input1
> [  156.300316] dracut: Scanning for all btrfs devices

I don't have btrfs partition. I will try to disable it in dracut.

I found my 120 seconds.
in :
/usr/lib/dracut/modules.d/99base/init.sh ~#L180
> RDRETRY=$(getarg rd.retry -d 'rd_retry=')
> RDRETRY=${RDRETRY:-180}
> RDRETRY=$(($RDRETRY*2))
> export RDRETRY
> main_loop=0
> export main_loop
> while :; do
> 
>     check_finished && break
> 
>     udevsettle
> 
>     check_finished && break
> 
>     if [ -f $hookdir/initqueue/work ]; then
>         rm -f -- $hookdir/initqueue/work
>     fi
> 
>     for job in $hookdir/initqueue/*.sh; do
>         [ -e "$job" ] || break
>         job=$job . $job
>         check_finished && break 2
>     done
> 
>     $UDEV_QUEUE_EMPTY >/dev/null 2>&1 || continue
> 
>     for job in $hookdir/initqueue/settled/*.sh; do
>         [ -e "$job" ] || break
>         job=$job . $job
>         check_finished && break 2
>     done
> 
>     $UDEV_QUEUE_EMPTY >/dev/null 2>&1 || continue
> 
>     # no more udev jobs and queues empty.
>     sleep 0.5
> 
> 
>     if [ $main_loop -gt $((2*$RDRETRY/3)) ]; then
>         for job in $hookdir/initqueue/timeout/*.sh; do
>             [ -e "$job" ] || break
>             job=$job . $job
>             udevadm settle --timeout=0 >/dev/null 2>&1 || main_loop=0
>             [ -f $hookdir/initqueue/work ] && main_loop=0
>         done
>     fi
> 
>     main_loop=$(($main_loop+1))
>     [ $main_loop -gt $RDRETRY ] \
>         && { flock -s 9 ; emergency_shell "Could not boot."; } 9>/.console_lock
> done

Thank to Pterjan for pointing the kernel command line `rd.debug` and gave me a possible file.

Here we see, RDRETRY is set to -180 by default (why minus ?), then, multiply by 2, then, compared with main_loop after being multiplied by 2 again, and devided by 3.
180*2*2/3=240.
The loop has an half second break (sleep 0.5), so 240*0.5=120 seconds.

(correction :
${var:-xxx} is not a negative value, but `:-` is the assignment, a different one from `:=`. So, All Correct.
http://www.gnu.org/software/bash/manual/html_node/Shell-Parameter-Expansion.html )

So a workaround would be to try adding rd.retry=5 or similar to the cmdline

CC: (none) => pterjan

Output section of dracut while booting with `rd.debug`
https://termbin.com/6eeb

In the logs, we can only see this repetition:
> mars 15 19:00:46 kernel: usb 1-1.3: SerialNumber: 0x0001
> 
> mars 15 19:00:46 dracut: /init@213(main): '[' 4 -gt 240 ']'
> mars 15 19:00:46 dracut: /init@222(main): main_loop=5
> mars 15 19:00:46 dracut: /init@223(main): '[' 5 -gt 360 ']'
> mars 15 19:00:46 dracut: /init@181(main): :
> mars 15 19:00:46 dracut: /init@183(main): check_finished
> mars 15 19:00:46 dracut: /lib/dracut-lib.sh@439(check_finished): local f
> mars 15 19:00:46 dracut: /lib/dracut-lib.sh@440(check_finished): for f in $hookdir/initqueue/finished/*.sh
> mars 15 19:00:46 dracut: /lib/dracut-lib.sh@441(check_finished): '[' '/lib/dracut/hooks/initqueue/finished/devexists-x2fdevx2fdiskx2fby-uuidx2f2cbc79ae-8fa3-4a9d-a30d-1971e35a51fc.sh' = '/lib/dracut/hooks/initqueue/finished/*.sh' ']'
> mars 15 19:00:46 dracut: /lib/dracut-lib.sh@442(check_finished): '[' -e '/lib/dracut/hooks/initqueue/finished/devexists-x2fdevx2fdiskx2fby-uuidx2f2cbc79ae-8fa3-4a9d-a30d-1971e35a51fc.sh' ']'
> mars 15 19:00:46 dracut: /lib/dracut-lib.sh@442(check_finished): . '/lib/dracut/hooks/initqueue/finished/devexists-x2fdevx2fdiskx2fby-uuidx2f2cbc79ae-8fa3-4a9d-a30d-1971e35a51fc.sh'
[...]
> mars 15 19:00:46 dracut: /init@213(main): '[' 234 -gt 240 ']'
> mars 15 19:00:46 dracut: /init@222(main): main_loop=235
> mars 15 19:00:46 dracut: /init@223(main): '[' 235 -gt 360 ']'
> mars 15 19:00:46 dracut: /init@181(main): :
> mars 15 19:00:46 dracut: /init@183(main): check_finished
> mars 15 19:00:46 dracut: /lib/dracut-lib.sh@439(check_finished): local f
> mars 15 19:00:46 dracut: /lib/dracut-lib.sh@440(check_finished): for f in $hookdir/initqueue/finished/*.sh
> mars 15 19:00:46 dracut: /lib/dracut-lib.sh@441(check_finished): '[' '/lib/dracut/hooks/initqueue/finished/devexists-x2fdevx2fdiskx2fby-uuidx2f2cbc79ae-8fa3-4a9d-a30d-1971e35a51fc.sh' = '/lib/dracut/hooks/initqueue/finished/*.sh' ']'
> mars 15 19:00:46 dracut: /lib/dracut-lib.sh@442(check_finished): '[' -e '/lib/dracut/hooks/initqueue/finished/devexists-x2fdevx2fdiskx2fby-uuidx2f2cbc79ae-8fa3-4a9d-a30d-1971e35a51fc.sh' ']'
> mars 15 19:00:46 dracut: /lib/dracut-lib.sh@442(check_finished): . '/lib/dracut/hooks/initqueue/finished/devexists-x2fdevx2fdiskx2fby-uuidx2f2cbc79ae-8fa3-4a9d-a30d-1971e35a51fc.sh'
> 
> mars 15 19:00:46 dracut: Scanning for all btrfs devices

But the most interresting thing is not on the log, but on the screen during the boot :
> /init@181(main): :
> /init@183(main): check_finished
> /lib/dracut-lib.sh@439(check_finished): local f
> /lib/dracut-lib.sh@440(check_finished): for f in $hookdir/initqueue/finished/*.sh
> /lib/dracut-lib.sh@441(check_finished): '[' '/lib/dracut/hooks/initqueue/finished/devexists-/dev/disk/by-uuid/$MyRootUUID.sh' = '/lib/dracut/hooks...
> /lib/dracut-lib.sh@442(check_finished): '[' -e '/lib/dracut/hooks/initqueue/finished/devexists-/dev/disk/by-uuid/$MyRootUUID.sh' ']'
> /lib/dracut-lib.sh@442(check_finished): . '/lib/dracut/hooks/initqueue/finished/devexists-/dev/disk/by-uuid/$MyRootUUID.sh'
> //lib/dracut/hooks/initqueue/finished/finished/devexists-/dev/disk/by-uuid/$MyRootUUID.sh@01(source): '[' -e /dev/disk/by-uuid/$MyRootUUID[...]
> /lib/dracut-lib.sh@440(check_finished): for f in $hookdir/initqueue/finished/*.sh
> /lib/dracut-lib.sh@441(check_finished): '[' '/lib/dracut/hooks/initqueue/finished/devexists-/dev/non-hostonly-lvm.sh' = '/lib/dracut/hooks/initqueue/finished/*.sh' ']'
> /lib/dracut-lib.sh@442(check_finished): '[' -e '/lib/dracut/hooks/initqueue/finished/devexists-/dev/non-hostonly-lvm.sh' ']'
> /lib/dracut-lib.sh@442(check_finished): . '/lib/dracut/hooks/initqueue/finished/devexists-/dev/non-hostonly-lvm.sh'
> //lib/dracut/hooks/initqueue/finished/finished/devexists-/dev/non-hostonly-lvm.sh@01(source): '[' -e /dev/non-hostonly-lvm ']'
> /lib/dracut-lib.sh@442(check_finished): return 1
> 
> /init@185(main): udevsettle
> /lib/dracut-lib.sh@529(udevsettle): '[' -z 241 ']'
> /lib/dracut-lib.sh@531(udevsettle): '[' 241 -ge 143 ']'
> /lib/dracut-lib.sh@532(udevsettle): udevadm settle --exit-if-exists=/lib/dracut/hooks/initqueue/work
> 
> /init@187(main): check_finished
> /lib/dracut-lib.sh@439(check_finished): local f
> /lib/dracut-lib.sh@440(check_finished): for f in $hookdir/initqueue/finished/*.sh
> /lib/dracut-lib.sh@441(check_finished): '[' '/lib/dracut/hooks/initqueue/finished/devexists-/dev/disk/by-uuid/$MyRootUUID.sh' = '/lib/dracut/hooks...
> /lib/dracut-lib.sh@442(check_finished): '[' -e '/lib/dracut/hooks/initqueue/finished/devexists-/dev/disk/by-uuid/$MyRootUUID.sh' ']'
> /lib/dracut-lib.sh@442(check_finished): . '/lib/dracut/hooks/initqueue/finished/devexists-/dev/disk/by-uuid/$MyRootUUID.sh'
> //lib/dracut/hooks/initqueue/finished/finished/devexists-/dev/disk/by-uuid/$MyRootUUID.sh@01(source): '[' -e /dev/disk/by-uuid/$MyRootUUID[...]
> /lib/dracut-lib.sh@440(check_finished): for f in $hookdir/initqueue/finished/*.sh
> /lib/dracut-lib.sh@441(check_finished): '[' '/lib/dracut/hooks/initqueue/finished/devexists-/dev/non-hostonly-lvm.sh' = '/lib/dracut/hooks/initqueue/finished/*.sh' ']'
> /lib/dracut-lib.sh@442(check_finished): '[' -e '/lib/dracut/hooks/initqueue/finished/devexists-/dev/non-hostonly-lvm.sh' ']'
> /lib/dracut-lib.sh@442(check_finished): . '/lib/dracut/hooks/initqueue/finished/devexists-/dev/non-hostonly-lvm.sh'
> //lib/dracut/hooks/initqueue/finished/finished/devexists-/dev/non-hostonly-lvm.sh@01(source): '[' -e /dev/non-hostonly-lvm ']'
> /lib/dracut-lib.sh@442(check_finished): return 1
> 
> /init@189(main): '[' -f /lib/dracut/hooks/initqueue/work ']'
> /init@193(main): for job in $hookdir/initqueue/*.sh
> /init@194(main): '[' -e '/lib/dracut/hooks/initqueue/*.sh' ']'
> /init@194(main): break
> /init@199(main): udevadm settle --timeout=0
> /init@201(main): for job in $hookdir/initqueue/settled/*.sh
> /init@202(main): '[' -e '/lib/dracut/hooks/initqueue/settled/*.sh' ']'
> /init@202(main): break
> /init@207(main): udevadm settle --timeout=0
> /init@207(main): sleep 0.5
> /init@213(main): '[' 104 -gt 240 ']'
> /init@213(main): main_loop=105
> /init@213(main): '[' 105 -gt 360 ']'


So I suspect something wrong with /dev/non-hostonly-lvm.sh and/or /dev/disk/by-uuid/$MyRootUUID.sh

Yes, rd.retry will reduce the boot delay, but won't solve the problem.
I applied this workarround, works great, but I continue to track the bug.

Does /etc/dracut.conf.d/50-mageia.conf have a line with
hostonly="yes"

If not, then trying to create an initrd that will boot on any system, like we
have for the live iso images, would explain the initrd looking for hardware
that is not present such as btrfs file systems.

(In reply to Dave Hodgins from comment #30)
> Does /etc/dracut.conf.d/50-mageia.conf have a line with
> hostonly="yes"
> 
> If not, then trying to create an initrd that will boot on any system, like we
> have for the live iso images, would explain the initrd looking for hardware
> that is not present such as btrfs file systems.

Jybz, could you please reply to the previous question? If you don't reply within two weeks from now, I will have to close this bug as OLD. Thank you.


Note: the timeout seems to have an origin on kernel waiting for a device...
When you'll have time, can you do this:
 - remove the harddrive physically
 - install an empty harddrive physically
 - install on new harddrive Mageia 8.
 - See if boot is still long...

In the case 1: still long boot => not Mageia related. You should consider a faulty hardware.
In the case 2: shorter boot process => wrong configuration somewhere in existing conf files on the old harddrive... In this case, you must reinstall.

Keywords: (none) => NEEDINFO
Status: REOPENED => ASSIGNED

\o/

Bravo Dave ! hostonly was set to "no". I'm not sure but did I set it to "no" on purpose for the Mageia4arm project, building initrd for arm... But it should be on the chroot, not on my system. If I did it, that was a bug on my side.

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED

Hi,
i'm playing with qemu and Mageia-8-rpi-aarch64-noDE.img to be abble to install on my RPI.
this way demonstrate clearly the bug.

to reproduce:
- download Mageia-8-rpi-aarch64-noDE.img.gz, extract Mageia-8-rpi-aarch64-noDE.img

- losetup -fP ./Mageia-8-rpi-aarch64-noDE.img
   sudo mkdir /mnt/virtual
   lsblk /dev/loop0
   sudo mount --rw /dev/loop0p2 /mnt/virtual/
   sudo mount --rw /dev/loop0p1 /mnt/virtual/boot/EFI/

- cat /mnt/virtual/etc/dracut.conf.d/50-mageia.conf|grep -i host
- add rd.debug
  nano /mnt/virtual/boot/grub2/grub.cfg

- ready to start a qemu EFI generic machine 
  qemu-system-aarch64 -machine virt -smp 8 -m 4G -cpu cortex-a72 -serial stdio -bios /usr/share/edk2/aarch64/QEMU_EFI.fd -drive if=none,file=./Mageia-8-rpi-aarch64-noDE.img,format=raw,id=hd -device qemu-xhci -device usb-storage,drive=hd -boot menu=on -device qxl -display gtk,gl=on

we got a command prompt and log as root, but saw before the monster loop


in another way, we can do an rpi3 machine, but never got the command promp or keyboard isn't managed/loaded :

qemu-system-aarch64 \
   -machine raspi3b \
   -cpu cortex-a72 \
   -dtb /mnt/virtual/boot/EFI/bcm2710-rpi-cm3.dtb \
   -m 1G -smp 4 -k fr -serial vc \
-display sdl,gl=on -vga std\
   -kernel /mnt/virtual/boot/EFI/u-boot.bin \
   -drive if=sd,file=./Mageia-8-rpi-aarch64-noDE.img,format=raw,id=hd -boot menu=on \
   -append "rw earlyprintk loglevel=8 console=ttyAMA0,115200 dwc_otg.lpm_enable=0 root=/dev/mmcblk0p2 rootdelay=1 rd.debug"

Resolution: FIXED => (none)
Status: RESOLVED => UNCONFIRMED
Ever confirmed: 1 => 0
CC: (none) => surfzoid

strangely inconsistent.
i say me, let's try an urpmi --auto --auto-update
so first, i resized the image file :
qemu-img resize ./Mageia-8-rpi-aarch64-noDE.img 6g
then i attached to the loop:
losetup -fP ./Mageia-8-rpi-aarch64-noDE.img

in nautillus i saw the 2 partitions, double click on the second one mount it, then property->open in gnome-disk and resize from 3 to 6 giga.

start generic qemu and no monster loop anymore, i did update, more than 500 rpm and restart, mo monster loop.

i forgot, the default media, ftp.free is broken, need to remove and add add $MIRROIRLIST

Hi
all aarch64 mga8 and 9 have hostonly="yes" but all have this long dracut loop, on phisycal PI and qemu-system-aarch64

It works on a rpi 4b, not older pi models.

(In reply to Dave Hodgins from comment #37)
> It works on a rpi 4b, not older pi models.

ho, yu spoke about dracut? because, i spent hours and with the workaround, i have now a nice XFCE desktop on a RPI3, i'm compressing a custom and working img to share it

(In reply to Eric Petit from comment #38)
> (In reply to Dave Hodgins from comment #37)
> > It works on a rpi 4b, not older pi models.
> 
> ho, yu spoke about dracut? because, i spent hours and with the workaround, i
> have now a nice XFCE desktop on a RPI3, i'm compressing a custom and working
> img to share it

Eric, can you please share your knowledge on https://wiki.mageia.org/en/Installing_Mageia_on_ARM_(Raspberry_PI)

Hi

Does someone has a working img file that boots correctly on RPI3?

I used the scripts to make one for the RPI3+64 but it did´nt boot, and the ones one the mirror do not accept any of my keyboards once it asks for the password.

Regards
ZekeMX

CC: (none) => ezequiel_partida

(In reply to Ezequiel Partida from comment #40)
> Hi
> 
> Does someone has a working img file that boots correctly on RPI3?
> 
> I used the scripts to make one for the RPI3+64 but it did´nt boot, and the
> ones one the mirror do not accept any of my keyboards once it asks for the
> password.
> 
> Regards
> ZekeMX

yu can try my soup :
magnet:?xt=urn:btih:620d0b56499f7a13fd133ae52f7396bd20a23e22&dn=Mageia-cauldron-rpi-aarch64-XFCE.tar.xz

(In reply to Eric Petit from comment #41)
> (In reply to Ezequiel Partida from comment #40)
> > Hi
> > 
> > Does someone has a working img file that boots correctly on RPI3?
> > 
> > I used the scripts to make one for the RPI3+64 but it did´nt boot, and the
> > ones one the mirror do not accept any of my keyboards once it asks for the
> > password.
> > 
> > Regards
> > ZekeMX
> 
> yu can try my soup :
> magnet:?xt=urn:btih:620d0b56499f7a13fd133ae52f7396bd20a23e22&dn=Mageia-
> cauldron-rpi-aarch64-XFCE.tar.xz

Hello,

Sorry Ijust saw your reply, it seeams you mageia-cauldron-rpi-aarch64-XFCE.tar.xz is not valid anymore

regards

(In reply to Ezequiel Partida from comment #42)
> (In reply to Eric Petit from comment #41)
> > (In reply to Ezequiel Partida from comment #40)
> > > Hi
> > > 
> > > Does someone has a working img file that boots correctly on RPI3?
> > > 
> > > I used the scripts to make one for the RPI3+64 but it did´nt boot, and the
> > > ones one the mirror do not accept any of my keyboards once it asks for the
> > > password.
> > > 
> > > Regards
> > > ZekeMX
> > 
> > yu can try my soup :
> > magnet:?xt=urn:btih:620d0b56499f7a13fd133ae52f7396bd20a23e22&dn=Mageia-
> > cauldron-rpi-aarch64-XFCE.tar.xz
> 
> Hello,
> 
> Sorry Ijust saw your reply, it seeams you
> mageia-cauldron-rpi-aarch64-XFCE.tar.xz is not valid anymore
> 
> regards

Hi,
yes i stopped BitTorrent client.
If you have an url to give i cold upload the 5 gig image.