Closed markshank closed 2 years ago
This time the startup logged a bunch of ldconfig garbage and then locked up. In this case, holding down the power button resulted in the screen going black when it finally powered off.
NOTE Sometimes it logs the ldconfig garbage and presses on to the login screen. And sometimes the ldconfig garbage looks like it might come from a copyright text file.
Did we ever figure this out? :)
No
I just booted the most recent nightly (2022-Aug-21 15:18 ravynOS_0.4.0pre5_f14_5654957775912960_amd64.iso) in a libvirt virtual machine on Ubuntu and the ldconfig: lines scrolled continuously on the serial console for minutes before finally stopping. It filled the screen buffer so I can't show all of it.
This doesn't make sense. ldconfig
here would be /etc/rc.d/ldconfig
during the rc boot sequence. A broken ISO should affect everyone. Why are you the only one seeing this?
It looks like the system does eventually boot. Can you log in?
What does grep ldconfig /etc/rc.conf
show?
If you run sudo /etc/rc.d/ldconfig start
does it spew garbage again?
Why are you the only one seeing this?
The original issue was on my Chromebook. It has no serial console, so it roars through the ldconfig: garbage much quicker than the emulated 115200 bps serial console.
It looks like the system does eventually boot. Can you log in?
Not this time, neither the graphic console nor the serial console respond to an Enter key press. Ctrl+Alt+F2 does switch to alternate console, but Enter provokes nothing. Virtual Machine Manager shows the single processor chugging along at approx 50%.
If I tried enough times, I might get lucky based on my original experience with the Chromebook. But it takes so long and the CPU is pegged while it is spewing the ldconfig: stuff.
The mediated passthrough of the Intel GPU may be introducing a special case. Especially since i915kms.ko thinks it has a physical GPU which causes it to throw all kinds of errors when the mediated passthrough GPU doesn't cooperate with it.
Still doesn't explain the original Chromebook issue though.
Have you verified the image MD5 sum? It feels like something is corrupted but I can't think what it could be. ldconfig appears to be reading the contents of /raminit (a binary file) and version.txt among other things. It should only do that if those files are listed either in rc.conf or are in a directory listed in rc.conf or where it normally looks.
I used the Proxmox iso download utility which checked the MD5 sum I specified after it downloaded the iso. Then I used scp to copy it to the standalone Ubuntu box.
Unless the "Illegal byte sequence" below means something:
I am 99% sure, I had the exact same issues SOMETIMES (weirdly, not with every boot nor with any recognisable trigger). It eventually disappeared (after maybe 20 fails) without me having changed anything proactively.
edit: by "the exact same" I mean the initial screenshots and errors listed in the serial console buffer
I noticed that "illegal byte sequence" on my new install as well. It seems harmless - not sure where it's coming from yet.
What were your other settings using Proxmox? Mine seems to hang at "launchd 1"...
What were your other settings using Proxmox?
root@epyc3000:\~# qm config 132 balloon: 0 bios: ovmf boot: order=ide2;scsi0 cores: 4 efidisk0: CephPool:vm-132-disk-1,efitype=4m,size=528K ide2: cephfs:iso/ravynOS_0.4.0pre5_f14_5654957775912960_amd64.iso,media=cdrom,size=1457042K machine: q35 memory: 4096 name: airyxlivecd net0: virtio=16:7D:D7:B3:1A:D9,bridge=vmbr0 numa: 0 ostype: other scsi0: CephPool:vm-132-disk-0,size=15G scsihw: virtio-scsi-pci smbios1: uuid=5c7e79be-0cbc-4a9f-8bd0-76af5949322d sockets: 1 vga: std vmgenid: 716daf0f-a9bb-485f-9097-1136b38717b1 root@epyc3000:~#
Mine seems to hang at "launchd 1"
Graphics are not supported on VMs yet. Work in progress on drivers for that. This is what I see:
I chanced into reproducing the 'ldconfig' issue and was able to capture the top of the output. This is it:
kldload: can't load utouch: No such file or directory
/etc/rc: WARNING: Unable to load kernel module utouch
^Blo0: link state changed to UP
ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/lib/compat/pkg /usr/lib/perl5/5.32/mach/CORE /usr/lib/qt5 /usr/llvm13/lib Applications Library System Users Volumes bin boot cdrom compat dev etc init.sh lib libexec media mnt private proc raminit rescue root sbin sysroot tmp usr var version . version version version version version version version version version version version version version version version version version version version version version Applications Library System Users Volumes bin boot cdrom compat dev etc init.sh lib libexec media mnt private proc raminit rescue root sbin sysroot tmp usr var version version version version version version Applications Library System Users Volumes bin boot cdrom compat dev etc init.sh lib libexec media mnt private proc raminit rescue root sbin sysroot tmp usr var version // // Applications Library System Users Volumes bin boot cdrom compat dev etc init.sh lib libexec media mnt private proc raminit rescue root sbin sysroot tmp usr var version version version version version version . . . . . . . . .
So the actual behavior we're seeing makes sense - ldconfig is iterating that list of directories. What doesn't make sense is WHY it has that list.
I think it is caused by the presence of /usr/lib/qt5
in the ldconfig_paths
entry in /etc/rc.conf
. That has been there for a while so I'm not sure why it suddenly causes problems, but removing it seems to fix this - and it makes sense that reading those shared objects as text files containing paths would blow up.
Kernel Panic after boot from SSD
The startup after boot is a hit or miss situation. It might make it to the login screen, and I can logon to the desktop. Or not.
This kernel panic happened after the startup had frozen. Could not ctrl+alt+F2 (or F3). So I held down the power button until it responded with this kernel panic.