/dev not populated on sparc64

[immolo]

Describe the bug
When using dracut on sparc64 hardware it seems /dev doesn't get populated correctly and the system fails to boot.

Using qemu-system-sparc64 to boot:

[    5.627919] Run /init as init process
[    6.178188] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100
[    6.179025] CPU: 0 UID: 0 PID: 1 Comm: init Not tainted 7.0.13-gentoo-dist #1 VOLUNTARY
[    6.179774] Call Trace:
[    6.180253] [<0000000000432bec>] dump_stack+0x8/0x18
[    6.181015] [<0000000000428f3c>] vpanic+0xf8/0x328
[    6.181488] [<0000000000429190>] panic+0x24/0x30
[    6.181974] [<000000000046995c>] do_exit+0xafc/0xb20
[    6.182476] [<0000000000469b44>] do_group_exit+0x24/0xa0
[    6.182987] [<0000000000469bdc>] sys_exit_group+0x1c/0x40
[    6.183498] [<00000000004061b4>] linux_sparc_syscall+0x34/0x44
[    6.184427] Press Stop-A (L1-A) from sun keyboard or send break
[    6.184427] twice on console to return to the boot prom
[    6.185259] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100 ]---

Do note all the correct modules are built in so the proc message is a red herring.

I see no errors or warnings while creating the initramfs with dracut.

Unpacking the image though shows:

# ls -la /tmp/initrd-check/dev/
total 0
drwxr-xr-x 1 root root   0 Jun 21 16:42 .
drwxr-xr-x 1 root root 110 Jun 21 17:49 ..

If I then create the following nodes with these commands:

mknod -m 666 dev/null c 1 3
mknod -m 600 dev/console c 5 1
mknod -m 666 dev/zero c 1 5

Manually repacking the initramfs will then boot correctly.

Distribution used
Gentoo using the both gentoo-kernel and directly calling dracut during testing.

Dracut version
111

Init system
OpenRC

To Reproduce

qcow2 images can be provided. but the command being used for qemu is:

# qemu-system-sparc64 -M sun4u -m 2048     -kernel vmlinux-7.0.13-gentoo-dist     -initrd initramfs-7.0.13-gentoo-dist.img     -cdrom /var/tmp/catalyst/builds/23.0-default/install-sparc64-minimal-dist.iso     -drive file=/home/immolo/QEMU/gentoo-sparc.qcow2,if=ide,bus=0,unit=0,format=qcow2,cache=writeback,discard=unmap     -append "root=/dev/sda1 console=ttyS0,115200"    -nographic

Expected behavior
/dev to be populated.

Additional context
Add any other context you like about the problem here.

[immolo]

I can't be 100% sure I've completely ruled out user error.

So I'm happy provide the output of test required to narrow this issue down.

[immolo]

Additional logs that may be of use:

lsinitrd output:
lsinitrd-7.0.13.txt

runtime output:
runtime-build.txt

[bdrung]

I see /dev devices in your lsinitrd log:

crw-r--r--   1 root     root       0, 1343225856 Jun 25 17:35 dev/console
crw-r--r--   1 root     root       0, 279969792 Jun 25 17:35 dev/kmsg
crw-r--r--   1 root     root       0, 271581184 Jun 25 17:35 dev/null
crw-r--r--   1 root     root       0, 276824064 Jun 25 17:35 dev/random
crw-r--r--   1 root     root       0, 277872640 Jun 25 17:35 dev/urandom
lrwxrwxrwx   1 root     root            7 Jun 25 17:35 bin -> usr/bin
drwxr-xr-x   2 root     root            0 Jun 25 17:35 dev

The unusual part is that they have huge device number.

[immolo]

The unusual part is that they have huge device number.

Yeah, I can't for the life of me understand why this happening.

I have since found Gentoo has a SPARC machine using dracut which boots fine, which just adds to the strangest rather than helps us narrow it down.

[bdrung]

dev/console is listed before dev which is wrong, but my system has it as well. So this is probably not the cause.

[bdrung]

dev/console is listed before dev which is wrong, but my system has it as well. So this is probably not the cause.

That is just caused by lsinitrd sorting the entries. 3cpio shows the correct order and there it is correct.

[immolo]

Sorry for mega link, but my host is having issues so at least can share the kernel and qcow2 files I have:

https://mega.nz/file/3sYBQYwQ#AdRA7FCHEA-CfBmAytqTfyHr66gGJdtYdJm5y54vlZ0

# sha256sum Gentoo-SPARC-7.0.13.tar.xz
07bc5ef556ab1f0a21303272a455897cc10dcf5ff4fd2291ddba0f77b7a2e84b  Gentoo-SPARC-7.0.13.tar.xz

As an out the box idea, do you think there is any chance trying 6.18 could provide us with something helpful?