But to compare the outputs in a clear way I need to access files written on both machines.
In 86Box, I can perform a terrible, terrible hack and send data (at 115200 baud; might take a while) using 86Box's serial passthrough feature. Doing the whole rootfs is fine; I can do something like tar -c / | base64 > /dev/ttyS0
and receive the base64'd tar file in one of the /dev/pts/*
on the host. I wouldn't know about Bochs, but a quick search tells me it should have a similar feature. (I couldn't bring up eth0
within the shell, else I'd have suggested using nc
or similar, which would've been much faster)
@bbonev commented 13 minutes ago
3.2.9 is quite old version with many things already fixed. Please confirm if the problem can be reproduced with the latest one.
So this leaves Adelie with updating to https://github.com/eudev-project/eudev/releases/tag/v3.2.14, I guess.
OK, filed an upstream issue: https://github.com/eudev-project/eudev/issues/270
OK, seems like udevadm test $(udevadm info --query=path --name=/dev/sr0)
tells us more specifics:
Eg. about /lib/udev/rules.d/60-persistent-storage.rules:94
.
But to compare the outputs in a clear way I need to access files written on both machines. I guess it will be hard in case of interrupted dracut.
@awilfox wrote:
There is never a
/dev/disk/by-label
directory created, even in the successful boot.
Continuing the story. Seems to be an udev
-related thing, on Beta5 it's eudev-3.2.9
:
So on Bochs 2.7 PMMX-Adelie-beta5.bxrc boots fine.
udevadm
produces following output for sr0
here:
While on 86Box it says a little less about sr0
:
At least two lines are missing:
S: disk/by-label/Adelie-pmmx
S: disk/by-uuid/2023-10-28-05-04-43-00
No ideas on how to dig further yet.
Seems like it's area of udev
:
https://unix.stackexchange.com/questions/56291/what-causes-dev-disk-by-label-to-be-populated/56309#56309
@awilfox wrote:
There is never a
/dev/disk/by-label
directory created, even in the successful boot.
At least on a Bochs 2.7 emulated MMX machine it gets created:
I wonder which mechanism is responsible for populating /dev/disk
: kernel or something else?
I gave adelie-live-mate-ppc-1.0-beta5-20230829 a test ride on my PowerMac G4 3,6 DP. The Adelie kernel gets loaded and the machine starts to boot but always gets stuck at detecting my PCI SATA SiI 3112 card. (see screenshot).
Don't think it's a general kernel issue as the SiI 3112 works fine on Gentoo Linux on the same machine.
# uname -a
Linux T600 6.4.13-gentoo-PMacG4 #1 SMP Thu Aug 31 15:24:16 CEST 2023 ppc 7455, altivec supported PowerMac3,6 GNU/Linux
# lspci
0000:00:0b.0 Host bridge: Apple Inc. UniNorth 2 AGP
0000:00:10.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV350 [Radeon 9550/9600/X1050 Series]
0001:00:0b.0 Host bridge: Apple Inc. UniNorth 2 PCI
0001:00:12.0 USB controller: NEC Corporation OHCI USB Controller (rev 43)
0001:00:12.1 USB controller: NEC Corporation OHCI USB Controller (rev 43)
0001:00:12.2 USB controller: NEC Corporation uPD72010x USB 2.0 Controller (rev 04)
0001:00:13.0 Mass storage controller: Silicon Image, Inc. SiI 3112 [SATALink/SATARaid] Serial ATA Controller (rev 02)
0001:00:15.0 Serial controller: MosChip Semiconductor Technology Ltd. PCI 9865 Multi-I/O Controller
0001:00:15.1 Serial controller: MosChip Semiconductor Technology Ltd. PCI 9865 Multi-I/O Controller
0001:00:15.2 Parallel controller: Illegal Vendor ID Device 9865
0001:00:16.0 Network controller: Broadcom Inc. and subsidiaries BCM4306 802.11b/g Wireless LAN Controller (rev 02)
0001:00:17.0 Unassigned class [ff00]: Apple Inc. KeyLargo Mac I/O (rev 03)
0001:00:18.0 USB controller: Apple Inc. KeyLargo USB
0001:00:19.0 USB controller: Apple Inc. KeyLargo USB
0001:00:1b.0 USB controller: NEC Corporation OHCI USB Controller (rev 43)
0001:00:1b.1 USB controller: NEC Corporation OHCI USB Controller (rev 43)
0001:00:1b.2 USB controller: NEC Corporation uPD72010x USB 2.0 Controller (rev 04)
0002:00:0b.0 Host bridge: Apple Inc. UniNorth 2 Internal PCI
0002:00:0d.0 Unassigned class [ff00]: Apple Inc. UniNorth 2 ATA/100
0002:00:0e.0 FireWire (IEEE 1394): Apple Inc. UniNorth 2 FireWire (rev 01)
0002:00:0f.0 Ethernet controller: Apple Inc. UniNorth 2 GMAC (Sun GEM)
# lspci -vv -s 0001:00:13.0
0001:00:13.0 Mass storage controller: Silicon Image, Inc. SiI 3112 [SATALink/SATARaid] Serial ATA Controller (rev 02)
Subsystem: Silicon Image, Inc. SiI 3112 SATALink Controller
Device tree node: /sys/firmware/devicetree/base/pci@f2000000/pci1095,3112@13
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 16, Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 53
Region 0: I/O ports at 0460 [size=8]
Region 1: I/O ports at 0450 [size=4]
Region 2: I/O ports at 0440 [size=8]
Region 3: I/O ports at 0430 [size=4]
Region 4: I/O ports at 0420 [size=16]
Region 5: Memory at 80082000 (32-bit, non-prefetchable) [size=512]
Expansion ROM at 80100000 [disabled] [size=512K]
Capabilities: [60] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=2 PME-
Kernel driver in use: sata_sil
Posting the issue here in Image Creation as I did not find a specific tracker for install media. Hope that's ok.
Just booted G4 3,6 DP with latest XFCE Adelie ppc iso which worked flawlessly. So case solved I would say. Thanks for having a look into the issue!
Sorry for my late feedback, was rather occupied the last weeks...
Tried to boot beta5 lxqt image. Boot process stalled after printing "EFI STUB: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path". I was able to use ctrl-option-delete to reboot.
iMac model: iMac12,2 GPU: AMD Radeon HD 6770M 512 Mb
UPD: it doesn't boot also on my home PC. I don't know what info could be useful, so please ask me to post needed data.
It does know what the label should be, but no by-label is ever created:
adelie-live ~ # blkid
/dev/sr0: BLOCK_SIZE="2048" UUID="2023-12-10-17-07-56-00" LABEL="Adelie-pmmx" TYPE="iso9660" PTTYPE="PMBR"
/dev/loop0: TYPE="squashfs"
adelie-live ~ # ls /dev/disk
by-id
adelie-live ~ #
I can reproduce this with a similar VM configuration (but made in MacBox) here. Manually changing the boot parameter to be root=live:/dev/sr0
instead of root=live:LABEL=Adelie-pmmx
fixes it.
There is never a /dev/disk/by-label
directory created, even in the successful boot. If you can call it successful, since the Cirrus Logic doesn't have DRM support…
I ran adelie-inst-pmmx-1.0-beta5-20231210.iso
on 86Box, it failed to boot and dropped to a debug shell.
rdsosreport.txt: https://pastebin.com/Z1LKrQXr
86Box.cfg: https://pastebin.com/rhUKNg7p
(The disk image adelie-pmmx.vhd
will almost certainly not exist on your machine: just create an IDE hard drive on channel 0:0, any size, or else the emulated board will fail to boot off the CD-ROM at all. I don't know why.)
A. Wilcox (7aa97473) at 09 Dec 04:48
Base configuration: Only use live user in live CDs
A. Wilcox (df456089) at 05 Dec 07:17
Base configuration: MATE: Remove some docs
A. Wilcox (c6aba0ab) at 04 Dec 12:31
Base configuration: Use /bin/zsh as root's shell
... and 1 more commit
Can you please try to test this with the latest media? There were some kernel configuration improvements around PCI Power Macs (notably packages@21a50bc2) and I'm hoping this will fix it.
Zach van Rijn (f712ce80) at 01 Dec 04:17
Per horizon#320, we need to install docs
on the KDE DVD image.
MATE is already pushing the boundaries of a 700 MB CD, so I don't think it will fit there. We may want to do an overview of whether everything included on there is necessary. That should be a separate issue.
LXQt has about 50 MB of room left, and the doc spread there should be about 400 MB uncompressed, so we should be able to fit it on there. We'll have to investigate this, though.
docs
to KDE