Re: Unbootable system after fresh install on Sun Ultra 45 workstation
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
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.
isofs 49152 1
usb_storage 81920 0
sd_mod 65536 2
evdev 32768 0
hid_generic 24576 0
usbhid 65536 0
hid 253952 2 usbhid,hid_generic
sr_mod 32768 1
cdrom 73728 2 isofs,sr_mod
ata_generic 24576 0
pata_ali 24576 1
libata 303104 2 pata_ali,ata_generic
mptsas 49152 2
ohci_pci 32768 0
mptscsih 32768 1 mptsas
ehci_pci 32768 0
ehci_hcd 90112 1 ehci_pci
mptbase 65536 2 mptsas,mptscsih
ohci_hcd 57344 1 ohci_pci
tg3 196608 0
scsi_transport_sas 32768 1 mptsas
usbcore 262144 6
ohci_hcd,ehci_pci,usbhid,usb_storage,ehci_hcd,ohci_pci
scsi_mod 229376 7
mptsas,scsi_transport_sas,sd_mod,usb_storage,mptscsih,libata,sr_mod
libphy 122880 1 tg3
usb_common 24576 3 ohci_hcd,usbcore,ehci_hcd
scsi_common 24576 7
mptsas,scsi_mod,sd_mod,usb_storage,mptscsih,libata,sr_mod
On Mon, May 19, 2025 at 5:41 PM Marcelo Bezerra <marcelo@bezerra.org> wrote:
>
> John,
>
> I used this image:
> https://cdimage.debian.org/cdimage/ports/current/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 :)
>
> 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.
>
> 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.
>
> 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.
>
>
>
> On Mon, May 19, 2025 at 4:32 PM John Paul Adrian Glaubitz
> <glaubitz@physik.fu-berlin.de> wrote:
> >
> > 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
Reply to: