II just tried to install debian on a ultra sparc III based Sun Ultra
45 workstation with the newest netinst image I could find, but the
resulting install is not able to mount the root filesystem to complete
the boot process.

The UltraSparc IIIi cpu in this machine lacks the crc32 opcodes and
needs to use the crc32c_generic driver instead. Is this expected
behavior because the machine is too old, or is this a bug?

Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
Begin: Running /scripts/local-premount ... done.
Begin: Will now check root file system ... fsck from util-linux 2.41 [/sbin/fsck.ext4 (1) -- /dev/sdb2] fsck.ext4 -a -C0 /dev/sdb2
/dev/sdb2: clean, 33434/133169152 files, 9133747/532645976 blocks
done.
[ 75.478521] crc32c_sparc64: sparc64 crc32c opcode not available.
[ 75.652621] EXT4-fs (sdb2): Cannot load crc32c driver.
mount: mounting /dev/sdb2 on /root failed: No such file or directory
Failed to mount /dev/sdb2 as root file system.


BusyBox v1.37.0 (Debian 1:1.37.0-4) built-in shell (ash)
Enter 'help' for a list of built-in commands.

(initramfs) cat /proc/cpuinfo
cpu : TI UltraSparc IIIi (Jalapeno)
fpu : UltraSparc IIIi integrated FPU
pmu : ultra3i
prom : OBP 4.30.4 2009/08/19 07:14
type : sun4u
ncpus probed : 2
ncpus active : 2
D$ parity tl1 : 0
I$ parity tl1 : 0
cpucaps : flush,stbar,swap,muldiv,v9,ultra3,mul32,div32,v8plus,vis,vis2 Cpu0ClkTck : 000000005f5e1000
Cpu1ClkTck : 000000005f5e1000
MMU Type : Cheetah+
MMU PGSZs : 8K,64K,512K,4MB
State:
CPU0: online
CPU1: online
(initramfs) uname -a
Linux (none) 6.12.29-sparc64-smp #1 SMP Debian 6.12.29-1 (2025-05-18)
sparc64 GNU/Linux

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello Marcelo,

On Mon, 2025-05-19 at 16:24 +0200, Marcelo Bezerra wrote:

II just tried to install debian on a ultra sparc III based Sun Ultra
45 workstation with the newest netinst image I could find, but the
resulting install is not able to mount the root filesystem to complete
the boot process.

Which image did you use (please provide the URL) and what partition layout
did you use? I'm surprised that the root filesystem is referenced with the device node name (/dev/sdb2) and not the UUID of the partition which has
been standard on Debian for a long time.

Also, why does it try to mount the filesystem on /root and not /? Did you modify the partition layout and /etc/fstab yourself by any chance? Can you
post your /etc/fstab?

The UltraSparc IIIi cpu in this machine lacks the crc32 opcodes and
needs to use the crc32c_generic driver instead. Is this expected
behavior because the machine is too old, or is this a bug?

Those instructions were introduced with the SPARC T4 CPU, as far as I know:

https://blogs.oracle.com/solaris/post/sparc-t4-openssl-engine

Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
Begin: Running /scripts/local-premount ... done.
Begin: Will now check root file system ... fsck from util-linux 2.41 [/sbin/fsck.ext4 (1) -- /dev/sdb2] fsck.ext4 -a -C0 /dev/sdb2
/dev/sdb2: clean, 33434/133169152 files, 9133747/532645976 blocks
done.
[ 75.478521] crc32c_sparc64: sparc64 crc32c opcode not available.
[ 75.652621] EXT4-fs (sdb2): Cannot load crc32c driver.
mount: mounting /dev/sdb2 on /root failed: No such file or directory
Failed to mount /dev/sdb2 as root file system.

Mounting /dev/sdb2 on /root sounds very strange and not something that I would expect when automatic partitioning is used in debian-installer.

Adrian

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

(Please keep the list CC'ed)

Hello Marcelo,

On Mon, 2025-05-19 at 17:41 +0200, Marcelo Bezerra wrote:

I used this image: https://cdimage.debian.org/cdimage/ports/current/debian-12.0.0-sparc64-NETINST-1.iso

OK, thanks. FWIW, it's better to use the explicit links to avoid ambiguity:

https://cdimage.debian.org/cdimage/ports/snapshots/2025-04-01/debian-12.0.0-sparc64-NETINST-1.iso

sdb2 may sound strange, but it is the correct partition for /, as the
machine has solaris installed on what it thinks is sda :)

But the naming of devices is not guaranteed at all on Linux. Whether your Solaris disk becomes sda or sdb is pure accident which is why it shouldn't
rely on device names.

Fstab has not been modified and does indeed refer to the paritions by
UUID. This is the first boot after a fresh install. The error message
of can't mount /root probably is probably a side effect of the
initramfs process or someone trying to make it more user friendly.

I just checked the LDOM on one of our SPARC T4 and the partition is mounted with the following message:

EXT4-fs (vdiska2): mounted filesystem <redacted UUID> ro with ordered data mode. Quota mode: none.

Installation was done in guided partition mode, using the full (sdb)
disk. sdb1 is /boot, sbd2 is / and sbd3 is swap in this particular installation.

Can you post the /etc/fstab? You can obtain it by booting into rescue mode using the installation CD. While at it, please also provide the files "partman" and "syslog" from /var/log/installer.

The system clearly tried to load the wrong crc32c module, instead of crc32c_generic, which triggered the following kernel messages:
[ 75.478521] crc32c_sparc64: sparc64 crc32c opcode not available.
[ 75.652621] EXT4-fs (sdb2): Cannot load crc32c driver.

I'm not sure how this is supposed to be related to your root filesystem problem.

Adrian

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

The system clearly tried to load the wrong crc32c module, instead of crc32c_generic, which triggered the following kernel messages:
[ 75.478521] crc32c_sparc64: sparc64 crc32c opcode not available.
[ 75.652621] EXT4-fs (sdb2): Cannot load crc32c driver.

I'm not sure how this is supposed to be related to your root filesystem problem.

Adrian

This is the ext4 driver complaining about it not finding a crc32c
driver, and it won't mount any ext4 filesystems.

I sent the fstab and lsmod from the installation cd on a separate
message. I will try blacklisting the crc32c_sparc module to see if
that forces it to try the _generic version frist.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello Marcelo,

On Mon, 2025-05-19 at 17:50 +0200, Marcelo Bezerra wrote:

As follow up:

Just booted the installation cd and mounted the disk, chrooted and
started ssh so I could more easily copy and paste :)

mosca@ultra45:~$ cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# systemd generates mount units based on this file, see systemd.mount(5).
# Please run 'systemctl daemon-reload' after making changes here.
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/sdb2 during installation UUID=25f72af7-ea5d-484b-859c-6724ed3382bc / ext4 errors=remount-ro 0 1
# /boot was on /dev/sdb1 during installation UUID=40e43524-0383-4da1-bb08-ae3a10a6114e /boot ext2
defaults 0 2
# swap was on /dev/sdb4 during installation UUID=de638666-5dc6-4869-bcdc-014907d38a8b none swap sw
0 0
/dev/sr0 /media/cdrom0 udf,iso9660 user,noauto 0 0

OK, this looks good. What does the kernel command line say?

mosca@ultra45:~$ lsmod
Module Size Used by
ext4 794624 2
crc16 24576 1 ext4
mbcache 24576 1 ext4
jbd2 122880 1 ext4
crc32c_generic 24576 3 <== this is the correct module that
should be used, fresh install tries to use crc32c which fails, due to
lack of crc32c opcodes in this older cpu.

The question is whether this is related to the failure you are seeing and
I am not sure about this. It seems that there were some changes to ext4
with regards to crc32c [1].

If this is actually the problem, we need to figure out why the wrong module
is loaded on your machine. I don't have an answer to that from the top of
my head.

You can try blacklisting the crc32c_sparc64 module from the kernel command line.

Adrian

[1] https://patchwork.kernel.org/project/linux-mips/patch/20241103223154.136127-16-ebiggers@kernel.org/

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Marcelo,

On Mon, 2025-05-19 at 18:07 +0200, Marcelo Bezerra wrote:

The system clearly tried to load the wrong crc32c module, instead of crc32c_generic, which triggered the following kernel messages:
 [ 75.478521] crc32c_sparc64: sparc64 crc32c opcode not available.
 [ 75.652621] EXT4-fs (sdb2): Cannot load crc32c driver.

This is the ext4 driver complaining about it not finding a crc32c
driver, and it won't mount any ext4 filesystems.

Yeah, as I said in my other mail, there seem to have been some recent changes to the ext4 driver with regards to crc32 which I wasn't aware of. Thus, your analysis could actually be correct.

I sent the fstab and lsmod from the installation cd on a separate
message. I will try blacklisting the crc32c_sparc module to see if
that forces it to try the _generic version frist.

Yes, please. I have not observed this issue myself yet, so I'm curios to
learn what the root cause is. I have recently booted Debian's 6.12.x kernel
on an UltraSPARC IIIi without problems, so this issue may affect fresh installations only.

Adrian

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Blacklisting that module did indeed fix the issue and the system booted.

Not sure what the ideal fix would be for this. I suspect this should
affect other machines lacking that instructions, and not only this
ultra45.

[]s,
Marcelo

On Mon, May 19, 2025 at 5:59 PM John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:

Hello Marcelo,

On Mon, 2025-05-19 at 17:50 +0200, Marcelo Bezerra wrote:

As follow up:

Just booted the installation cd and mounted the disk, chrooted and
started ssh so I could more easily copy and paste :)

mosca@ultra45:~$ cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5).
#
# systemd generates mount units based on this file, see systemd.mount(5).
# Please run 'systemctl daemon-reload' after making changes here.
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/sdb2 during installation UUID=25f72af7-ea5d-484b-859c-6724ed3382bc / ext4 errors=remount-ro 0 1
# /boot was on /dev/sdb1 during installation UUID=40e43524-0383-4da1-bb08-ae3a10a6114e /boot ext2
defaults 0 2
# swap was on /dev/sdb4 during installation UUID=de638666-5dc6-4869-bcdc-014907d38a8b none swap sw
0 0
/dev/sr0 /media/cdrom0 udf,iso9660 user,noauto 0 0

OK, this looks good. What does the kernel command line say?

mosca@ultra45:~$ lsmod
Module Size Used by
ext4 794624 2
crc16 24576 1 ext4
mbcache 24576 1 ext4
jbd2 122880 1 ext4
crc32c_generic 24576 3 <== this is the correct module that
should be used, fresh install tries to use crc32c which fails, due to
lack of crc32c opcodes in this older cpu.

The question is whether this is related to the failure you are seeing and
I am not sure about this. It seems that there were some changes to ext4
with regards to crc32c [1].

If this is actually the problem, we need to figure out why the wrong module is loaded on your machine. I don't have an answer to that from the top of
my head.

You can try blacklisting the crc32c_sparc64 module from the kernel command line.

Adrian

[1] https://patchwork.kernel.org/project/linux-mips/patch/20241103223154.136127-16-ebiggers@kernel.org/

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Marcelo,

On Mon, 2025-05-19 at 18:17 +0200, Marcelo Bezerra wrote:

Blacklisting that module did indeed fix the issue and the system booted.

Thanks a lot for confirming this!

Not sure what the ideal fix would be for this. I suspect this should
affect other machines lacking that instructions, and not only this
ultra45.

Good question. Ideally, the sparc64-specific variant of crc32 should
probably unload itself if it doesn't find any supported hardware.

Adrian

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

(Please keep the list CC'ed)

Hi Marcello,

On Mon, 2025-05-19 at 18:51 +0200, Marcelo Bezerra wrote:

I wonder if the code in https://github.com/torvalds/linux/blob/a5806cd506af5a7c19bcd596e4708b5c464bfd21/arch/sparc/lib/crc32_glue.c#L62
should be returning non 0 when it lacks HWCAP_SPARC_CRYPTO or fails
the CFR_CRC32C checks.

static int __init crc32_sparc_init(void)
{
unsigned long cfr;

if (!(sparc64_elf_hwcap & HWCAP_SPARC_CRYPTO))
return 0; <=== here

__asm__ __volatile__("rd %%asr26, %0" : "=r" (cfr));
if (!(cfr & CFR_CRC32C))
return 0; <=== and here

static_branch_enable(&have_crc32c_opcode);
pr_info("Using sparc64 crc32c opcode optimized CRC32C implementation\n");
return 0;
}
arch_initcall(crc32_sparc_init);

This is actually correct as the conditional checks only determine whether static_branch_enable() is called or not and as you can see from the code
above, that only happens when both the flags HWCAP_SPARC_CRYPTO and
CFR_CRC32C are present.

The code is similar to the one on powerpc which also returns zero even when
no hardware support for crc32 instructions was found [1].

Adrian

[1] https://elixir.bootlin.com/linux/v6.14.7/source/arch/powerpc/lib/crc32-glue.c#L73

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)