Debian Sparc64 port

Rationale for such a port

Installing the Debian SPARC64 Port

Installation is performed much like any other Debian release architecture. The best way to get started is to download the latest Debian SPARC64 Network Installer ISO image, burn the image to a CD/DVD, and boot the machine from the internal CD/DVD drive. Both Sun and Oracle branded machines are classified under the sun4 architecture. As mentioned earlier, the Debian SPARC64 port only supports 64 bit SPARC processors which correspond to the following sun4 architectures / processors.

The Debian SPARC64 port is stable on most machines using these architectures / processors, but not all of them. Kernel support for the hardware found in these machines is the biggest factor in whether a particular machine is supported or not.

NOTICE: Currently the Linux kernel is not working on at least two systems with SPARC64 CPUs from Fujitsu. And a thread on the linux-sparc mailing list - although already from 2015 - also speaks of "adding support for SPARC64 machines". It is hence assumed that systems with SPARC64 CPUs are not yet supported by Linux. If you can proof otherwise please let us know.

Debian SPARC64 ISO Images

Current installer ISO images for SPARC64 are available on Debian's official cdimage mirror:

Known Working System Configurations

sun4u

Specifics

Ultra 10

Install only works on serial console. You have to explicitly set input and output devices at the OPB prompt with

Unplugging the keyboard is not sufficient, since GRUB switches back to the OPB output device after startup.

The debian package for the Creator 3D UPA card has to be compiled from source

and works without an xorg.conf file after installation.

Sun Fire 280R

The qla2xxx module (for the builtin Fibre Channel (FC) controller) should be blacklisted (with e.g. modprobe.blacklist=qla2xxx in the kernel command line) as otherwise the Linux kernel will panic soon after loading it (tested with 4.16.5, see this post on the linux-scsi mailing list and this post on the debian-sparc mailing list for details). This means that FC disks cannot be used with the builtin FC controller of the 280R. This might also apply to the similar systems Blade 1000 and 2000.

Sun Fire V210/V240

Debian installs normally on these machines, however when selecting a built in network interface they do show up in the correct order. Listed below is the order they show up in the installer corresponding to their port number on the chassis.

enP3p0s2f0 = Port 2
enP3p0s2f1 = Port 3
enp0s2f0 = Port 0
enp0s2f1 = Port 1

Sun Ultra Enterprise 3/4/5/6000 & Enterprise 3/4/5/6500

These machines can be tricky to install on as currently the driver modules they rely upon do not support uevents. This prevents the Debian installer and initramfs from loading them automatically. The steps needed to successfully install Debian on these machines is as follows.

  1. These machines use a Sun ESP SCSI controller for their CD/DVD drives. After booting into the installer it will fail to find the CD/DVD drive. At this point you need to execute a shell in the installer environment and issue a modprobe sun_esp command. Afterwards you can exit the shell and start the CD/DVD drive detection step of the installer again.

  2. The 10/100Mbit Ethernet controller built into the I/O boards are Sun HME controllers. The installer will fail to detect these and will prompt you to choose a driver for the network card. The correct driver to choose is sunhme.

  3. There are a few different SCSI controllers that are typically used for accessing hard disks. The installation notes for each are below.
    • Sun ESP (Built In): These drivers were loaded in step one. The partitioner should start normally.

    • Differential Sun ESP (SBUS): These drivers were loaded in step one, but this card is known to cause a kernel panic during the partitioning process.

    • Differential QLogic ISP (SBUS): You'll need to obtain a copy of the isp1000.bin firmware. This is free firmware, but is not included in any Debian package at the moment. In this case the partitioner will fail to find any hard disks and you will need to execute a shell in the installation environment. If you have a PCI I/O board with a USB controller you can mount a USB flash drive to /media and copy isp1000.bin to /lib/firmware/qlogic. If you do not have a way to attach a USB flash drive you can connect a second SCSI CD/DVD drive to one of the built in Sun ESP controller ports. If you're machine has a slot for a tape drive you can install a second CD/DVD drive in that slot. You can burn the isp1000.bin file to a CD/DVD and mount it to /media using the second CD/DVD drive. Afterwards issue a modprobe qlogicpti command and exit the shell. You can then restart the hard disk detection step of the installer.

  4. The installation will proceed normally from this point forward. After you have completed the installation DO NOT reboot or else you will have a non-bootable system! You need to execute one more shell in the installation environment and issue the following commands.

mount -t proc proc /target/proc && \
mount --rbind /sys /target/sys && \
mount --make-rslave /target/sys && \
mount --rbind /dev /target/dev && \
mount --make-rslave /target/dev
chroot /target /bin/bash
source /etc/profile
  1. At this point you will be chrooted into your new Debian installation. At this point you need to add the necessary kernel modules into /etc/initramfs-tools/modules. For example if your CD/DVD drive is attached to the built in Sun ESP SCSI controller and your hard disk is attached to a QLogic ISP SBUS controller, then the following command would add the necessary modules to /etc/initramfs-tools/modules

echo sun_esp >> /etc/initramfs-tools/modules && \
echo qlogicpti >> /etc/initramfs-tools/modules
  1. Finally, all that is left to do is execute a update-initramfs -u -k $(uname -r) command. Afterwards you can exit the shell, finalize the installation, and reboot the system. After the reboot you should be welcomed by a Debian login prompt!

sun4v

Specifics

SPARC Enterprise T5120/T5220

Debian installs normally on these machines, however you will have to append the console kernel argument to the kernel at boot time or else you will not get a login prompt. After finishing the installation you need to execute a shell in the installation environment. Add The following to /target/boot/silo.conf as seen below.

image=/vmlinuz
    append="console=ttyS0"
    label=Linux
    initrd=/initrd.img

Afterwards you can exit the shell, finish the installation, and reboot. If you accidentally reboot before adding the above changes you can still boot into your new installation by appending the following to the SILO boot prompt.

boot: Linux console=ttyS0

After booting into the system you can make the necessary changes to /boot/silo.conf

Creating an LDOM to install Debian in

This is a quick guide which details the necessary commands to create a new LDOM (Oracle VM for SPARC) to install Debian (or any other compatible operating system FWIW).

1. Create LDOM

root@tokyo:~# ldm add-domain testvm
root@tokyo:~# ldm add-vcpu 8 testvm
root@tokyo:~# ldm add-memory 2G testvm
root@tokyo:~# zfs create tank/ldoms/testvm
root@tokyo:~# zfs create -V 20G tank/ldoms/testvm/disk0
root@tokyo:~# ldm add-vdsdev /dev/zvol/dsk/tank/ldoms/testvm/disk0 testvm-disk0@primary-vds0
root@tokyo:~# ldm add-vdisk disk testvm-disk0@primary-vds0 testvm
root@tokyo:~# ldm add-vnet vnet0 primary-vsw0 testvm
root@tokyo:~#

2. Add CD image

root@tokyo:~# ldm add-vdsdev /tank/iso/debian-10.0-sparc64-NETINST-3.iso sparc64-3.iso@primary-vds0
root@tokyo:~# ldm add-vdisk cdrom sparc64-3.iso@primary-vds0 testvm
root@tokyo:~#

3. Disable autoboot

root@tokyo:~# ldm set-var auto-boot\?=false testvm                     │
Variables or keys have been set and those settings will be lost over a──────┘
powercycle.  To persist variables or keys over a powercycle, a configuration
must be saved to the SP after updates.
root@tokyo:~#

4. Booting the LDOM

root@tokyo:~# ldm list
NAME             STATE      FLAGS   CONS    VCPU  MEMORY   UTIL  UPTIME
primary          active     -n-cv-  SP      16    7900M    1.3%  130d 3h
kyoto            active     -n----  5001    32    16G      0.4%  68d 4h 51m
osaka            active     -n----  5000    48    32G      2.1%  12d 18h 31m
testvm           bound      ------  5002    8     2G
root@tokyo:~# ldm start testvm ; telnet localhost 5002

sparc64 buildd status

Bootstrapping sparc64

If you are currently on Debian sparc, you cannot point to sparc64 packages directly. In the meanwhile, you might be able to run it on a chroot.

debootstrap

The usual tool for putting together a root filesystem in Debian is debootstrap. In the past this was limited to bootstraps from a single suite only (e.g. from "unstable" but not from "unstable" and "unreleased"), but with a handy tool provided by JH Chatenet in a message to the debian-alpha/debian-68k/debian-hppa mailing lists in 2014]], bootstraps from both "unstable" and "unreleased" are also possible for debootstrap.

Download this tool with e.g. the following command and check its SHA256 hash value before unpacking and using it:

$ wget -c https://lists.debian.org/debian-alpha/2014/06/binpcKlVK5jS1.bin -O debian-ports.gz

$ sha256sum debian-ports.gz
0418a8e2f3f0b530508da0a4a0afafd32a8344105bcc24a3aa01aff350fa5772  debian-ports.gz

$ gunzip debian-ports.gz

Afterwards you can use it as follows with debootstrap:

# debootstrap [--arch=sparc64] unstable sparc64-port http://ftp.ports.debian.org/debian-ports/ ./debian-ports

--arch=sparc64 should be only needed when bootstrapping from a Debian sparc architecture installation.

multistrap

multistrap can also be used to pull from the debian-ports mirror and can cope with multiple suites by itself alone. You can select the mirror nearest to you via Debian Ports page.

$ cat >> sparc64.conf <<"EOF"
# Example multistrap configuration file for a sid build chroot
# Need to use cascading to select the toolchain for a cross arch.

[General]
arch=sparc64
directory=sparc64-port
# same as --tidy-up option if set to true
cleanup=true
# same as --no-auth option if set to true
# keyring packages listed in each debootstrap will
# still be installed.
noauth=true
# extract all downloaded archives (default is true)
unpack=true
# the order of sections is not important.
# the debootstrap option determines which repository
# is used to calculate the list of Priority: required packages.
debootstrap=Base Base-unreleased
aptsources=Base

[Base]
packages=apt dpkg-dev apt-utils whiptail locales
source=http://ftp.ports.debian.org/debian-ports/
keyring=debian-ports-archive-keyring
suite=unstable
omitdebsrc=true

[Base-unreleased]
packages=
source=http://ftp.ports.debian.org/debian-ports/
suite=unreleased
omitdebsrc=true
EOF

$ /usr/sbin/multistrap -f sparc64.conf
$ sudo mount --bind /dev sparc64-port/dev
$ sudo mount --bind /sys sparc64-port/sys
$ sudo mount --bind /proc sparc64-port/proc
$ sudo chroot sparc64-port dpkg --configure -a

When asked if you want to use dash as the default system /bin/sh to improve performance, say "n" or the setup will fail.

$ echo "export debian_chroot=chroot1" >> sparc64-port/root/.bashrc
$ sudo chroot sparc64-port

(Test and Enjoy)

Apt-line

deb http://deb.debian.org/debian-ports unstable main
deb-src http://deb.debian.org/debian unstable main
deb http://deb.debian.org/debian-ports unreleased main
deb-src http://deb.debian.org/debian-ports unreleased main

Network booting

OBP boot methods

RARP

Traditionally Sun machines determined their own IP address by using RARP. As this does not provide information about the TFTP service to use, it is just assumed that the TFTP service is also located on the same host that provided the RARP answer. But this is not always the case, i.e. think about dedicated hosts for address resolution (DHCP, DNS) - where RARP would fit in - and for file services (NFS) - where TFTP would fit in. Such a distinction makes a problem then. But it can be worked around: rarpd as used in Debian GNU/Linux checks if a file named like the boot image expected by the client (usually a file named after the IP address in hex, e.g. A1B2C3D4) is existing in the assumed directory served by the TFTP service and only answers RARP requests if that is the case. So one can either split or duplicate RARP related information over multiple hosts (this requires multiple RARP services) or move the RARP service to the same host that also hosts the TFTP service in the described situation.

OBP command to use this method:

{0} ok boot net

NOTICE: net in this case is only an alias that could have been (re)configured with the nvalias command. So first check what net really expands to with e.g. the output of the devalias command.

DHCP

More recent Sun machines - and according to this documentation this includes all Sun machines with at least OBP revision 3.25, so likely all machines with UltraSPARC and later CPUs - can also use DHCP to determine its IP address and also other network boot related information. This method avoids the above mentioned shortcoming of RARP.

OBP command to use this method:

{0} ok boot net:dhcp

NOTICE: net in this case is only an alias that could have been (re)configured with the nvalias command, e.g. so it already includes the :dhcp part. So first check what net really expands to with e.g. the output of the devalias command.

Netbooting with GRUB2

Required services (on servers)

It worked for me with the services mentioned in the brackets.

Preparing GRUB2 files for TFTP service

If you already have a working installation of Debian GNU/Linux Sid for sparc64, first upgrade all packages, then install the grub-ieee1275-bin package and last run grub-mknetdir.

There remains a chicken-and-egg problem if you do not already have a working GRUB2 installation that provides the grub-mknetdir command and the needed files for sparc64. A solution is to install the package on e.g. an amd64 host running Debian GNU/Linux Sid. Please follow the instructions on Multiarch/HOWTO and install with apt install grub-ieee1275-bin:sparc64. Afterwards the GRUB2 boot directory for sparc64 can be created with:

# grub-mknetdir -d /usr/lib/grub/sparc64-ieee1275
Netboot directory for sparc64-ieee1275 created. Configure your DHCP server to point to /srv/tftp/boot/grub/sparc64-ieee1275/core.img

Now copy the resulting directory structure (starting with the boot directory) to your TFTP service's root directory (keep the structure as is, as this structure is expected by GRUB2 by default later on!). In the root directory of the TFTP service create a symlink named like e.g. AC10026D (=the IP address of the client in hexadecimal and my recommendation) - or whatever you intend to configure as filename for this netboot client for your DHCP service - and pointing to the GRUB2 image mentioned in the grub-mknetdir output above (relative to the TFTP service's root directory!).

Preparing GRUB2 configuration files

For network booting a convenient solution is to use distinct configuration files for hosts or groups of hosts. GRUB2 does not support this by default - i.e. there is no search algorithm implemented that selects and loads configuration files on a MAC or IP address basis (like pxelinux or yaboot can do). GRUB2 only loads a file named grub.cfg from a hard-coded location (/boot/grub).

To support per-host configuration files - at least to some degree - the following code part can be used (derived from help-grub mailing list) for boot/grub/grub.cfg:

insmod gzio
insmod net
insmod tftp

regexp --set=1:m1 --set=2:m2 --set=3:m3 --set=4:m4 --set=5:m5 --set=6:m6 '^([0-9a-f]{1,2})\:([0-9a-f]{1,2})\:([0-9a-f]{1,2})\:([0-9a-f]{1,2})\:([0-9a-f]{1,2})\:([0-9a-f]{1,2})' "$net_default_mac"

set mac=${m1}-${m2}-${m3}-${m4}-${m5}-${m6}

set configfile=(tftp)/etc/01-$mac
echo "Will use config file \"$configfile\""

echo "Network status:"
echo "cards:"
net_ls_cards
echo "addr:"
net_ls_addr
echo "routes:"
net_ls_routes

sleep 5
clear

source "$configfile"

This allows to host per MAC address configurations in /etc (similar to yaboot when used on IBM POWER machines). If multiple hosts should use the same configuration, one can symlink the group configuration file with the names of the host configuration files. The 01 part is the ARP type for Ethernet and is currently hard-coded as GRUB2 doesn't provide this information in a variable. It is mainly added to mimic the naming of other network boot loaders.

A host configuration file can then look like this:

set timeout=0
menuentry 'Debian GNU/Linux Sid (diskless)' --class os {

        # t5240-2
        # primary network interface on Debian GNU/Linux Sid
        set boot_iface="enP1p4s0f0"

        set ip_address_hex="AC10026D"
        set gateway="172.16.0.1"
        set subnet_mask="255.255.0.0"

        echo 'Loading Linux kernel ...'
        # DHCP method gives bus errors
        # linux (tftp)/${ip_address_hex}.vmlinuz root=/dev/nfs ip=:::::${boot_iface}:dhcp rw
        # BOOTP doesn't get the gateway and DNS server address
        # linux (tftp)/${ip_address_hex}.vmlinuz root=/dev/nfs ip=:::::${boot_iface}:bootp rw
        linux (tftp)/${ip_address_hex}.vmlinuz root=/dev/nfs ip=${net_ofnet_net0_ip}:${net_ofnet_net0_next_server}:${gateway}:${subnet_mask}:${net_ofnet_net0_hostname}:${boot_iface}:off nfsroot=${net_ofnet_net0_next_server}:/srv/nfs/${net_ofnet_net0_hostname}/root nfsrootdebug rw

        echo 'Loading initial ramdisk ...'
        initrd (tftp)/${ip_address_hex}.initrd.img
}

...and should be placed in /etc in the TFTP service's root directory with a name corresponding to the MAC address of the used interface on the netboot client, e.g. 01-00-21-28-11-22-33.

As the IP autoconfiguration performed with ipconfig (from klibc-utils) from the initramfs currently doesn't work as expected for sparc64 when BOOTP or DHCP methods are used (see this thread for details), all needed IP and NFS information is configured manually using several variables provided by GRUB2 (with loaded net module) and some additional manually configured variables. Please check the Network part of the GRUB2 manual for an explanation of the contents.

For this configuration one needs to know:

Please also copy the used Linux kernel and initramfs to your TFTP service's root directory and symlink them accordingly.

NOTICE: GRUB2 uses different network interface names on different architectures (e.g. ofnet_net0 for the first network interface on a SPARC Enterprise T5240 or ofnet_/ht\@0,f2000000/pci\@2/bcom5714\@4 on a type 11,2 Power Macintosh G5). In addition the numbering on SPARC hardware only happens if multiple network interfaces are present. If a machine has only a single interface like an Ultra 10, the network interface is named just ofnet_net. This makes it difficult to choose the correct variable names for the configuration file. But on the other hand this is currently also only required for sparc64 because ipconfig doesn't work as expected there. It is not needed for e.g. powerpc or ppc64.

Please keep in mind that the used net_[...] variables above are for a machine with multiple network interfaces, so are numbered. If your machine only has a single network interface don't use a number in the respective variables.

Qemu-system-sparc64

Running Debian under qemu-system-sparc64 Sparc64Qemu

Mailing List

debian-sparc@lists.debian.org

Other links on the wiki

Bugs


CategoryPorts CategoryDebianInstaller CategoryDebianInstaller CategoryDebianInstaller