You are not logged in.
Pages: 1
This is an old desktop (HPE-341f circa 2010, AMD) To try sorting this out, I have successfully installed syslinux to one other older BIOS machine VAIO circa 2007 and to two VB VMs so I am fairly confident of the procedure.
GRUB boots fine, but I'm interested in syslinux here so ...
For linux and linux-lts the system swings back to the menu without error or warning.
The fallback system starts up as expected ------------------- UNLESS I include the amd_ucode in the kernel parameters.
The fallback differs from the others in that the fallback does not run autodetect for modules. It instead loads all drivers and modules installed to the system -- correct?
If so then is it the autodetect that's crashing the boot or is it one of the modules it is detecting?
I have reinstalled linux and linux-lts.
:>uname -a
Linux hlas 5.14.2-arch1-2 #1 SMP PREEMPT Thu, 09 Sep 2021 09:42:35 +0000 x86_64 GNU/Linux
:> pacman -Q linux
linux 5.14.2.arch1-2
:> pacman -Q linux-lts
linux-lts 5.10.64-1
Disk /dev/sdc: 223.57 GiB, 240057409536 bytes, 468862128 sectors
Disk model: KINGSTON SA400S3
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: 0x2a4a4aa1
Device Boot Start End Sectors Size Id Type
/dev/sdc1 * 2048 1050623 1048576 512M 83 Linux
/dev/sdc2 1050624 468862127 467811504 223.1G 83 Linux
blkid -s UUID /dev/sdc2
/dev/sdc2: UUID="e0615142-0476-41a2-9c40-299f23dfcf5c"
UI menu.c32
PROMPT 0
MENU TITLE Boot Menu
TIMEOUT 50
DEFAULT arch
LABEL arch
MENU LABEL Arch Linux
LINUX ../vmlinuz-linux
APPEND root=UUID="e0615142-0476-41a2-9c40-299f23dfcf5c" rw
INITRD ../initramfs-linux.img
LABEL arch-lts
MENU LABEL Arch Linux LTS
LINUX ../vmlinuz-linux
APPEND root=UUID="e0615142-0476-41a2-9c40-299f23dfcf5c" rw
INITRD ../initramfs-linux-lts.img
LABEL archfallback
MENU LABEL Arch Linux Fallback
LINUX ../vmlinuz-linux
APPEND root=UUID="e0615142-0476-41a2-9c40-299f23dfcf5c" rw
INITRD ../initramfs-linux-fallback.img
Note that with the ucode configured then the falllback fails in the same way as the other two entries.
LABEL archfallback
MENU LABEL Arch Linux Fallback
LINUX ../vmlinuz-linux
APPEND root=UUID="e0615142-0476-41a2-9c40-299f23dfcf5c" rw
INITRD ../amd-ucode.img,../initramfs-linux-fallback.img
Last edited by hwallace (2021-09-18 18:28:45)
Offline
Autodetect tries to minimize the number of modules included, usually (or always ?) everything found through autodetect is present in the fallback image .
Your system may need some kernel module autodetect fails to ad .
https://wiki.archlinux.org/title/Mkinit … _the_image has info how to extract an initcpio image .
I suggest you extract both images and compare the include modules.
as for the microcode issue :
Early microcode loading is a recent addition to the kernel.
Amd processors with Zen core do support it, but the K10 family (produced from 2007 - 2013) didn't .
It does seem likely your processor only supports late microcode loading .
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
So the mission is to decide which of the 653 modules autodetect passes over that I need to add to the config of mkinitcpio. If I understand you correctly.
Last edited by hwallace (2021-09-14 13:27:56)
Offline
Fortunately most of those modules are part of a chain/tree or provide functionality not needed in initramfs
hypothetical example : unless you login with facial recognition a webcam kernel module is not needed in initram stage .
real example :
$ lsmod | grep snd
snd_hda_codec_realtek 159744 1
snd_hda_codec_generic 98304 1 snd_hda_codec_realtek
ledtrig_audio 16384 1 snd_hda_codec_generic
snd_hda_codec_hdmi 73728 1
snd_hda_intel 57344 2
snd_intel_dspcfg 28672 1 snd_hda_intel
snd_intel_sdw_acpi 20480 1 snd_intel_dspcfg
snd_hda_codec 176128 4 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec_realtek
snd_hda_core 110592 5 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek
snd_hwdep 16384 1 snd_hda_codec
snd_pcm 151552 4 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_hda_core
snd_timer 45056 1 snd_pcm
snd 114688 12 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hwdep,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek,snd_timer,snd_pcm
soundcore 16384 1 snd
$
All those modules work together, telling the kernel to load snd_hda_intel will pull in the rest .
boot with the fallback kernel , run lspci -k and compare the modules it lists as in use with those in the 2 extracted images .
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
...
boot with the fallback kernel , run lspci -k and compare the modules it lists as in use with those in the 2 extracted images .
The linux image had no entries for /var/lib/*. So I re-ran mkinitcpio hoping for a different image but -- no.
I put it aside for a couple days then today I ran an update that included a new kernel and so a refresh of the linux boot image.
Now the linux boot works.
I'm a bit disappointed because I was looking forward to some poking around and experimenting so I'll have to find something else to do now.
So because I don't feel this problem is 'solved' but rather fixed by chance I will tag this topic as CLOSED rather than SOLVED. I'll change that if in violation of policy.
Last edited by hwallace (2021-09-18 18:09:59)
Offline
I'll change that if in violation of policy.
Yes, it is...
CoC - How to post
Offline
hwallace wrote:I'll change that if in violation of policy.
Yes, it is...
CoC - How to post
Fixed
Offline
Pages: 1