Where is the best place to report this - I've lodged a ticket with ASRock, but given Win 10 boot image on the same USB flash drives (I've tried two different brands) successfully boots every time, this seems to me to be a Linux issue (or a BIOS incompatibility?)
]]>Do all of these have actually distinct kernels? Which kernel is the working iso using? If it's a 5.15 variant you could opt to try to install and boot the LTS kernel instead of the main linux package which would be on 5.16
I've not checked kernel version on all the distros I tried. Neither last month's Arch or current Ubuntu Server flash drive would boot successfully. The ISO that did (archlinux-2020.12.01-x86_64.iso) has Kernel Version: 5.9.11. When weekend rolls around again I'll retry with the today's ISO and if that fails revert to the last 5.15 and work backwards from there to try find the last install that works.
]]>Disklabel type: dos
I'd not generally expect a DOS type partition table to be supported by EFI boots, you should change that to GPT.
Good catch , don't know how I missed that.
It doesn't explain why this PC is seemingly incapable of consistently booting from the latest Arch ISO written to any number of USB drives though. As a test I downloaded an ancient Arch ISO archlinux-2020.12.01-x86_64.iso, wrote that to USB and it boots every time. A gremlin / compatibility issue has crept in somehere where booting recent Linux builds and this board is concerned.
]]>Disklabel type: dos
I'd not generally expect a DOS type partition table to be supported by EFI boots, you should change that to GPT.
]]>FWIW here's the data relevant to the configuration...
Output of lsblk:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
loop0 7:0 0 673.7M 1 loop /run/archiso/airootfs
sda 8:0 1 14.5G 0 disk
├─sda1 8:1 1 760M 0 part /run/archiso/bootmnt
└─sda2 8:2 1 86M 0 part
nvme0n1 259:0 0 232.9G 0 disk
├─nvme0n1p1 259:1 0 512M 0 part /mnt/boot
└─nvme0n1p2 259:2 0 232.4G 0 part /mnt
Output of fdisk -l /dev/nvme0n1:
Disk /dev/nvme0n1: 232.89 GiB, 250059350016 bytes, 488397168 sectors
Disk model: Samsung SSD 970 EVO Plus 250GB
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x183ae04a
Device Boot Start End Sectors Size Id Type
/dev/nvme0n1p1 2048 1050623 1048576 512M ef EFI (FAT-12/16/32)
/dev/nvme0n1p2 1050624 488397167 487346544 232.4G 83 Linux
Output from blkid:
/dev/nvme0n1p1: UUID="936A-D7E7" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="183ae04a-01"
/dev/nvme0n1p2: UUID="b3370e5d-1f14-4824-aa5d-0e785b45b6df" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="183ae04a-02"
/dev/loop0: TYPE="squashfs"
/dev/sda2: SEC_TYPE="msdos" LABEL_FATBOOT="ARCHISO_EFI" LABEL="ARCHISO_EFI" UUID="D326-2B49" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="0862fc4e-02"
/dev/sda1: BLOCK_SIZE="2048" UUID="2021-11-01-07-53-41-00" LABEL="ARCH_202111" TYPE="iso9660" PARTUUID="0862fc4e-01"
Command I used to write EFI bootstub:
efibootmgr -d /dev/nvme0n1p2 -p 1 -c -L "Arch" -l \vmlinuz-linux -u "root=UUID=b3370e5d-1f14-4824-aa5d-0e785b45b6df rw initrd=\amd-ucode.img initrd=\initramfs-linux.img"
Output from efibootmgr:
BootCurrent: 0001
Timeout: 1 seconds
BootOrder: 0000,0001,0002
Boot0000* Arch
Boot0001* UEFI: KingstonDataTraveler 3.0PMAP
Boot0002* UEFI: KingstonDataTraveler 3.0PMAP, Partition 2
Have I missed something?
]]>I tried both nomodeset and debug. nomodeset made no difference, debug makes the boot output more verbose but it disappears from screen too quickly to be useful.
I tried a second USB flash drive and by some miracle the Arch install booted and I was able to then install Arch on the 970 EVO Plus SSD.
I did not install a boot loader but instead configured the EFI bootstub directly to load Arch (my preferred method), including AMD microcode updates . On issuing a reboot the PC proceeded to boot Arch from the SSD but then at some point before the login prompt was reached the screen went blank and I ended up in the perpetual reboot cycle.
Adding the same damn USB flash media back to the mix and trying to boot it from the BIOS' boot menu generates the same outcome - the endless reboot cycle.
Should I somehow try installing a bootloader?
FWIW, this is what I see dropping into the UEFI shell:
If I issue a reboot -C (i.e. cold reboot from the shell the display loses signal and that's the end of it till I power cycle.
]]>If the nomodeset turns out to be insufficient, try adding debug or so to get some more messages.
]]>For the "stick preparation" whatever's on /dev/sdd should already not be mounted in the first place when you run the cat, but I somewhat doubt that to be the underlying issue.
KDE Plasma automounts all media on insertion, so I umount, wipe, write and then as soon as the write is finished Plasma automounts it again, hence my issuing the umount.
ACPI errors are normally harmless. Can you boot if you press e and add nomodeset to the kernel params?
Thanks, I'll give this a try this morning.
]]>ACPI errors are normally harmless. Can you boot if you press e and add nomodeset to the kernel params?
]]>wipefs --all /dev/sdd
cat archlinux-2022.01.01-x86_64.iso > /dev/sdd
sync
umount /run/media/x/*
I'm wanting to install Arch on an Asrock DeskMini X300 with Ryzen 4750G CPU installed. I've cleared CMOS, turned secure boot off and booted from USB. After getting the usual Arch installation menu and selecting install I get an ACPI BIOS error message, following which the screen goes blank and the display loses signal and shortly afterward the Arch boot menu reappears. Left alone it would do that all day. I had exactly the same experience when out of desperation I tested a n Ubuntu server install. However, Ubuntu Desktop booted into a full desktop environment. BIOS is latest available for the motherboard in question.
Any thoughts on what else to try would be greatly appreciated - this is to be my headless med ia server, just need to get the Arch installation boot process going.
]]>