Discussion:
GRUB testers on SPARC needed
(too old to reply)
John Paul Adrian Glaubitz
2017-12-08 12:30:01 UTC
Permalink
Hi!

We're in the process of migrating Debian for sparc64 from SILO to GRUB
as GRUB upstream is adding support for modern SPARC machines thanks to
the work of Eric Snowberg from Oracle.

In order to make sure GRUB works on all machines supported by the sparc64
port, we need your help to test GRUB on your particular hardware, the older
your machine, the better.

So, in order to help us, please follow the guide below to install GRUB to
replace SILO as your boot loader.

NOTE: If your system doesn't boot after installing GRUB, don't panic. Use
the current Debian sparc64 installation image and boot into rescue
mode by typing "rescue". Then chroot into your installed system and
just run "silo -t -f" to restore SILO on your machine.

1. Install the grub2 package:

***@andi:~# apt install grub2
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
grub-common grub-ieee1275 grub-ieee1275-bin grub2-common libfreetype6 libfuse2 libpng16-16 os-prober
Suggested packages:
multiboot-doc xorriso desktop-base console-setup fuse
The following NEW packages will be installed:
grub-common grub-ieee1275 grub-ieee1275-bin grub2 grub2-common libfreetype6 libfuse2 libpng16-16 os-prober
0 upgraded, 9 newly installed, 0 to remove and 0 not upgraded.
Need to get 4,556 kB of archives.
After this operation, 23.6 MB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://ftp.ports.debian.org/debian-ports unstable/main sparc64 libpng16-16 sparc64 1.6.34-1 [271 kB]
(...)

Creating config file /etc/default/grub with new version
Setting up grub2 (2.02-2+sparc64.3) ...
***@andi:~#

2. Make sure you have version 2.02-2+sparc64.3

***@andi:~# apt-cache show grub2 |grep Version
Version: 2.02-2+sparc64.3
***@andi:~#

3. Find your boot partition:

***@andi:~# mount |grep /boot
/dev/sda1 on /boot type ext3 (rw,relatime,data=ordered)
***@andi:~#

If you don't have one but just one root file system, grep for " / " instead

4. Install grub into your boot partition:

***@andi:~# grub-install --force --skip-fs-probe /dev/sda1
Installing for sparc64-ieee1275 platform.
grub-install: warning: Discarding improperly nested partition (hostdisk//dev/sda,sun1,sun2).
grub-install: warning: Discarding improperly nested partition (hostdisk//dev/sda,sun1,sun4).
grub-install: warning: Attempting to install GRUB to a disk with multiple partition labels. This is not supported yet..
grub-install: warning: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged..
Installation finished. No error reported.
***@andi:~#

Note: If you are using GPT partition tables instead of Sun partition
tables, you need to install GRUB into /dev/sda
(see: https://github.com/esnowberg/grub2-sparc/wiki)

5. Run update-grub:

***@andi:~# update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.14.0-1-sparc64-smp
Found initrd image: /boot/initrd.img-4.14.0-1-sparc64-smp
Found linux image: /boot/vmlinuz-4.14.0-trunk-sparc64-smp
Found initrd image: /boot/initrd.img-4.14.0-trunk-sparc64-smp
Found linux image: /boot/vmlinuz-4.14.0-rc7-sparc64-smp
Found initrd image: /boot/initrd.img-4.14.0-rc7-sparc64-smp
Found linux image: /boot/vmlinuz-4.14.0-rc5-sparc64-smp
Found initrd image: /boot/initrd.img-4.14.0-rc5-sparc64-smp
Found linux image: /boot/vmlinuz-4.12.0-rc1-sparc64-smp
Found initrd image: /boot/initrd.img-4.12.0-rc1-sparc64-smp
Found linux image: /boot/vmlinuz-4.11.0-trunk-sparc64-smp
Found initrd image: /boot/initrd.img-4.11.0-trunk-sparc64-smp
Found linux image: /boot/vmlinuz-4.10.0-trunk-sparc64-smp
Found initrd image: /boot/initrd.img-4.10.0-trunk-sparc64-smp
Found Debian GNU/Linux buster/sid on /dev/md0p1
done
***@andi:~#

6. Reboot:

***@andi:~#

7. Report back to the list and include your hardware and partition setup

Thanks,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Frans van Berckel
2017-12-08 13:30:01 UTC
Permalink
Hi Adrian,
Post by John Paul Adrian Glaubitz
Hi!
We're in the process of migrating Debian for sparc64 from SILO to
GRUB as GRUB upstream is adding support for modern SPARC machines
thanks to the work of Eric Snowberg from Oracle.
In order to make sure GRUB works on all machines supported by the
sparc64 port, we need your help to test GRUB on your particular
hardware, the older your machine, the better.
7. Report back to the list and include your hardware and partition setup
Probing system devices
Probing memory
Probing I/O buses
screen not found.
keyboard not found.
Keyboard not present. Using ttya for input and output.
Probing system devices
Probing memory
Probing I/O buses

Sun Fire V440, No Keyboard
Copyright 2010 Sun Microsystems, Inc. All rights reserved.
OpenBoot 4.30.4.a, 20480 MB memory installed, Serial #57654521.
Ethernet address 0:3:ba:6f:bc:f9, Host ID: 836fbcf9.

booting with command: boot
Boot device: disk File and args:

GRUB Loading kernel...
screen not found.
error: out of memory.
error: no suitable video mode found.

GNU GRUB version 2.02-2+sparc64.3

Loading Linux 4.13.0-1-sparc64-smp ...

# lsblk

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 136.7G 0 disk
├─sda1 8:1 0 902.1M 0 part /boot
├─sda2 8:2 0 135.9G 0 part
│ └─md0 9:0 0 135.7G 0 raid1 /
└─sda3 8:3 0 136.7G 0 part
sdb 8:16 0 136.7G 0 disk
├─sdb1 8:17 0 902.1M 0 part
├─sdb2 8:18 0 135.9G 0 part
│ └─md0 9:0 0 135.7G 0 raid1 /
└─sdb3 8:19 0 136.7G 0 part
sdc 8:32 0 33.9G 0 disk
├─sdc1 8:33 0 30G 0 part
│ └─md1 9:1 0 30G 0 raid1 /home
└─sdc2 8:34 0 3.9G 0 part [SWAP]
sdd 8:48 0 33.9G 0 disk
├─sdd1 8:49 0 30G 0 part
│ └─md1 9:1 0 30G 0 raid1 /home
└─sdd2 8:50 0 3.9G 0 part [SWAP]
sr0 11:0 1 197.2M 0 rom

The sda and sdb are Sun, sdc and sdd are GTP.

# uname -a

Linux deblnxsrv211 4.13.0-1-sparc64-smp #1 SMP Debian 4.13.4-2 (2017-
10-15) sparc64 GNU/Linux

Thanks,


Frans van Berckel
John Paul Adrian Glaubitz
2017-12-08 13:30:01 UTC
Permalink
Post by Frans van Berckel
Sun Fire V440, No Keyboard
Copyright 2010 Sun Microsystems, Inc. All rights reserved.
OpenBoot 4.30.4.a, 20480 MB memory installed, Serial #57654521.
Ethernet address 0:3:ba:6f:bc:f9, Host ID: 836fbcf9.
booting with command: boot
GRUB Loading kernel...
screen not found.
error: out of memory.
error: no suitable video mode found.
GNU GRUB version 2.02-2+sparc64.3
Loading Linux 4.13.0-1-sparc64-smp ...
So, I assume this means GRUB works as expected?

Do you get the normal boot menu? Does everything work?

Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Frans van Berckel
2017-12-08 13:40:01 UTC
Permalink
Post by John Paul Adrian Glaubitz
Post by Frans van Berckel
Sun Fire V440, No Keyboard
Copyright 2010 Sun Microsystems, Inc. All rights reserved.
OpenBoot 4.30.4.a, 20480 MB memory installed, Serial #57654521.
Ethernet address 0:3:ba:6f:bc:f9, Host ID: 836fbcf9.
booting with command: boot
GRUB Loading kernel...
screen not found.
error: out of memory.
error: no suitable video mode found.
GNU GRUB version 2.02-2+sparc64.3
Loading Linux 4.13.0-1-sparc64-smp ...
So, I assume this means GRUB works as expected?
Do you get the normal boot menu? Does everything work?
Yes, yes and yes.

Thanks,


Frans van Berckel
Frans van Berckel
2017-12-09 09:50:02 UTC
Permalink
Post by Frans van Berckel
Post by John Paul Adrian Glaubitz
So, I assume this means GRUB works as expected?
Do you get the normal boot menu? Does everything work?
Yes, yes and yes.
About grub.conf the header section ...

### BEGIN /etc/grub.d/00_header ###

at

if [ x$feature_default_font_path = xy ] ; then
font=unicode
else
insmod part_sun
insmod part_sun
insmod diskfilter
insmod mdraid1x
insmod ext2

The part_sun module is called twice.

Thanks,

Frans van Berckel
Tony Rodriguez
2017-12-08 15:30:01 UTC
Permalink
Please provide a link to the latest ISO with grub support for sparc64. I
will happy to test if it works on my t5120, t5140, and T4-2 systems.

Tony
Post by Frans van Berckel
Hi Adrian,
Post by John Paul Adrian Glaubitz
Hi!
We're in the process of migrating Debian for sparc64 from SILO to
GRUB as GRUB upstream is adding support for modern SPARC machines
thanks to the work of Eric Snowberg from Oracle.
In order to make sure GRUB works on all machines supported by the
sparc64 port, we need your help to test GRUB on your particular
hardware, the older your machine, the better.
7. Report back to the list and include your hardware and partition setup
Probing system devices
Probing memory
Probing I/O buses
screen not found.
keyboard not found.
Keyboard not present. Using ttya for input and output.
Probing system devices
Probing memory
Probing I/O buses
Sun Fire V440, No Keyboard
Copyright 2010 Sun Microsystems, Inc. All rights reserved.
OpenBoot 4.30.4.a, 20480 MB memory installed, Serial #57654521.
Ethernet address 0:3:ba:6f:bc:f9, Host ID: 836fbcf9.
booting with command: boot
GRUB Loading kernel...
screen not found.
error: out of memory.
error: no suitable video mode found.
GNU GRUB version 2.02-2+sparc64.3
Loading Linux 4.13.0-1-sparc64-smp ...
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 136.7G 0 disk
├─sda1 8:1 0 902.1M 0 part /boot
├─sda2 8:2 0 135.9G 0 part
│ └─md0 9:0 0 135.7G 0 raid1 /
└─sda3 8:3 0 136.7G 0 part
sdb 8:16 0 136.7G 0 disk
├─sdb1 8:17 0 902.1M 0 part
├─sdb2 8:18 0 135.9G 0 part
│ └─md0 9:0 0 135.7G 0 raid1 /
└─sdb3 8:19 0 136.7G 0 part
sdc 8:32 0 33.9G 0 disk
├─sdc1 8:33 0 30G 0 part
│ └─md1 9:1 0 30G 0 raid1 /home
└─sdc2 8:34 0 3.9G 0 part [SWAP]
sdd 8:48 0 33.9G 0 disk
├─sdd1 8:49 0 30G 0 part
│ └─md1 9:1 0 30G 0 raid1 /home
└─sdd2 8:50 0 3.9G 0 part [SWAP]
sr0 11:0 1 197.2M 0 rom
The sda and sdb are Sun, sdc and sdd are GTP.
# uname -a
Linux deblnxsrv211 4.13.0-1-sparc64-smp #1 SMP Debian 4.13.4-2 (2017-
10-15) sparc64 GNU/Linux
Thanks,
Frans van Berckel
John Paul Adrian Glaubitz
2017-12-08 15:50:01 UTC
Permalink
There is no separate ISO. You can just choose to install GRUB instead of SILO when you install your machine with the current ISO.

Just go back to the main menu instead of finishing the installation at the last installation step. Then choose „Install GRUB boot loader“, ignore the two errors about missing packages and install into /dev/BOOTDISK1 where BOOTDISK is your boot disk (e.g. sda or vdiska).

Adrian
Please provide a link to the latest ISO with grub support for sparc64. I will happy to test if it works on my t5120, t5140, and T4-2 systems.
Tony
Post by Frans van Berckel
Hi Adrian,
Post by John Paul Adrian Glaubitz
Hi!
We're in the process of migrating Debian for sparc64 from SILO to
GRUB as GRUB upstream is adding support for modern SPARC machines
thanks to the work of Eric Snowberg from Oracle.
In order to make sure GRUB works on all machines supported by the
sparc64 port, we need your help to test GRUB on your particular
hardware, the older your machine, the better.
7. Report back to the list and include your hardware and partition setup
Probing system devices
Probing memory
Probing I/O buses
screen not found.
keyboard not found.
Keyboard not present. Using ttya for input and output.
Probing system devices
Probing memory
Probing I/O buses
Sun Fire V440, No Keyboard
Copyright 2010 Sun Microsystems, Inc. All rights reserved.
OpenBoot 4.30.4.a, 20480 MB memory installed, Serial #57654521.
Ethernet address 0:3:ba:6f:bc:f9, Host ID: 836fbcf9.
booting with command: boot
GRUB Loading kernel...
screen not found.
error: out of memory.
error: no suitable video mode found.
GNU GRUB version 2.02-2+sparc64.3
Loading Linux 4.13.0-1-sparc64-smp ...
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 136.7G 0 disk
├─sda1 8:1 0 902.1M 0 part /boot
├─sda2 8:2 0 135.9G 0 part
│ └─md0 9:0 0 135.7G 0 raid1 /
└─sda3 8:3 0 136.7G 0 part
sdb 8:16 0 136.7G 0 disk
├─sdb1 8:17 0 902.1M 0 part
├─sdb2 8:18 0 135.9G 0 part
│ └─md0 9:0 0 135.7G 0 raid1 /
└─sdb3 8:19 0 136.7G 0 part
sdc 8:32 0 33.9G 0 disk
├─sdc1 8:33 0 30G 0 part
│ └─md1 9:1 0 30G 0 raid1 /home
└─sdc2 8:34 0 3.9G 0 part [SWAP]
sdd 8:48 0 33.9G 0 disk
├─sdd1 8:49 0 30G 0 part
│ └─md1 9:1 0 30G 0 raid1 /home
└─sdd2 8:50 0 3.9G 0 part [SWAP]
sr0 11:0 1 197.2M 0 rom
The sda and sdb are Sun, sdc and sdd are GTP.
# uname -a
Linux deblnxsrv211 4.13.0-1-sparc64-smp #1 SMP Debian 4.13.4-2 (2017-
10-15) sparc64 GNU/Linux
Thanks,
Frans van Berckel
Mark Morgan Lloyd
2017-12-11 21:50:01 UTC
Permalink
Post by John Paul Adrian Glaubitz
So, in order to help us, please follow the guide below to install GRUB to
replace SILO as your boot loader.
NOTE: If your system doesn't boot after installing GRUB, don't panic. Use
the current Debian sparc64 installation image
From where? The "Regularly updated" link on
https://wiki.debian.org/Sparc64 doesn't have any SPARC stuff.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
Frans van Berckel
2017-12-11 22:00:02 UTC
Permalink
Hi Mark,
Post by Mark Morgan Lloyd
Post by John Paul Adrian Glaubitz
So, in order to help us, please follow the guide below to install GRUB to
replace SILO as your boot loader.
NOTE: If your system doesn't boot after installing GRUB, don't panic. Use
the current Debian sparc64 installation image
From where? The "Regularly updated" link on
https://wiki.debian.org/Sparc64 doesn't have any SPARC stuff.
You're right. Please checkout, where all ports are saved now.

https://cdimage.debian.org/cdimage/ports/

Thanks,


Frans van Berckel
Mark Morgan Lloyd
2017-12-11 23:10:01 UTC
Permalink
Post by Frans van Berckel
Hi Mark,
Post by Mark Morgan Lloyd
Post by John Paul Adrian Glaubitz
So, in order to help us, please follow the guide below to install GRUB to
replace SILO as your boot loader.
NOTE: If your system doesn't boot after installing GRUB, don't panic. Use
the current Debian sparc64 installation image
From where? The "Regularly updated" link on
https://wiki.debian.org/Sparc64 doesn't have any SPARC stuff.
You're right. Please checkout, where all ports are saved now.
https://cdimage.debian.org/cdimage/ports/
Thanks Frans, using it to test a new router and will try installing over
the next day or so.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
Tony Rodriguez
2017-12-16 08:50:01 UTC
Permalink
FYI, as requested, successfully installed Debian 9 using grub2 on my sun
T5120 and T4-2.

Tony Rodriguez
Post by John Paul Adrian Glaubitz
Hi!
We're in the process of migrating Debian for sparc64 from SILO to GRUB
as GRUB upstream is adding support for modern SPARC machines thanks to
the work of Eric Snowberg from Oracle.
In order to make sure GRUB works on all machines supported by the sparc64
port, we need your help to test GRUB on your particular hardware, the older
your machine, the better.
So, in order to help us, please follow the guide below to install GRUB to
replace SILO as your boot loader.
NOTE: If your system doesn't boot after installing GRUB, don't panic. Use
the current Debian sparc64 installation image and boot into rescue
mode by typing "rescue". Then chroot into your installed system and
just run "silo -t -f" to restore SILO on your machine.
Reading package lists... Done
Building dependency tree
Reading state information... Done
grub-common grub-ieee1275 grub-ieee1275-bin grub2-common libfreetype6 libfuse2 libpng16-16 os-prober
multiboot-doc xorriso desktop-base console-setup fuse
grub-common grub-ieee1275 grub-ieee1275-bin grub2 grub2-common libfreetype6 libfuse2 libpng16-16 os-prober
0 upgraded, 9 newly installed, 0 to remove and 0 not upgraded.
Need to get 4,556 kB of archives.
After this operation, 23.6 MB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://ftp.ports.debian.org/debian-ports unstable/main sparc64 libpng16-16 sparc64 1.6.34-1 [271 kB]
(...)
Creating config file /etc/default/grub with new version
Setting up grub2 (2.02-2+sparc64.3) ...
2. Make sure you have version 2.02-2+sparc64.3
Version: 2.02-2+sparc64.3
/dev/sda1 on /boot type ext3 (rw,relatime,data=ordered)
If you don't have one but just one root file system, grep for " / " instead
Installing for sparc64-ieee1275 platform.
grub-install: warning: Discarding improperly nested partition (hostdisk//dev/sda,sun1,sun2).
grub-install: warning: Discarding improperly nested partition (hostdisk//dev/sda,sun1,sun4).
grub-install: warning: Attempting to install GRUB to a disk with multiple partition labels. This is not supported yet..
grub-install: warning: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged..
Installation finished. No error reported.
Note: If you are using GPT partition tables instead of Sun partition
tables, you need to install GRUB into /dev/sda
(see: https://github.com/esnowberg/grub2-sparc/wiki)
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.14.0-1-sparc64-smp
Found initrd image: /boot/initrd.img-4.14.0-1-sparc64-smp
Found linux image: /boot/vmlinuz-4.14.0-trunk-sparc64-smp
Found initrd image: /boot/initrd.img-4.14.0-trunk-sparc64-smp
Found linux image: /boot/vmlinuz-4.14.0-rc7-sparc64-smp
Found initrd image: /boot/initrd.img-4.14.0-rc7-sparc64-smp
Found linux image: /boot/vmlinuz-4.14.0-rc5-sparc64-smp
Found initrd image: /boot/initrd.img-4.14.0-rc5-sparc64-smp
Found linux image: /boot/vmlinuz-4.12.0-rc1-sparc64-smp
Found initrd image: /boot/initrd.img-4.12.0-rc1-sparc64-smp
Found linux image: /boot/vmlinuz-4.11.0-trunk-sparc64-smp
Found initrd image: /boot/initrd.img-4.11.0-trunk-sparc64-smp
Found linux image: /boot/vmlinuz-4.10.0-trunk-sparc64-smp
Found initrd image: /boot/initrd.img-4.10.0-trunk-sparc64-smp
Found Debian GNU/Linux buster/sid on /dev/md0p1
done
7. Report back to the list and include your hardware and partition setup
Thanks,
Adrian
John Paul Adrian Glaubitz
2017-12-16 09:00:01 UTC
Permalink
Hi Tony!
FYI, as requested, successfully installed Debian 9 using grub2 on my sun T5120 and T4-2.
Thanks! I'm starting to get confident now that we will be able to completely
replace SILO with GRUB on sparc and sparc64 :).

Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
txt.file
2017-12-18 04:10:01 UTC
Permalink
I tested it on a SunFire V440 and it is booting. I plan to test it also
on a Sun Netra T1.

***@txt-sunfire-v440:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 67.9G 0 disk
├─sda1 8:1 0 94.1M 0 part /boot
├─sda2 8:2 0 67.8G 0 part
│ ├─txt--sunfire--v440--vg-root 254:0 0 11.7G 0 lvm /
│ ├─txt--sunfire--v440--vg-swap_1 254:1 0 7.7G 0 lvm [SWAP]
│ ├─txt--sunfire--v440--vg-var 254:2 0 4.2G 0 lvm /var
│ ├─txt--sunfire--v440--vg-tmp 254:3 0 800M 0 lvm /tmp
│ └─txt--sunfire--v440--vg-home 254:4 0 43.5G 0 lvm /home
└─sda3 8:3 0 67.9G 0 part
sr0 11:0 1 1024M 0 rom
***@txt-sunfire-v440:~#

kind regards
txt.file
Post by John Paul Adrian Glaubitz
Hi!
We're in the process of migrating Debian for sparc64 from SILO to GRUB
as GRUB upstream is adding support for modern SPARC machines thanks to
the work of Eric Snowberg from Oracle.
In order to make sure GRUB works on all machines supported by the sparc64
port, we need your help to test GRUB on your particular hardware, the older
your machine, the better.
So, in order to help us, please follow the guide below to install GRUB to
replace SILO as your boot loader.
NOTE: If your system doesn't boot after installing GRUB, don't panic. Use
the current Debian sparc64 installation image and boot into rescue
mode by typing "rescue". Then chroot into your installed system and
just run "silo -t -f" to restore SILO on your machine.
Reading package lists... Done
Building dependency tree
Reading state information... Done
grub-common grub-ieee1275 grub-ieee1275-bin grub2-common libfreetype6 libfuse2 libpng16-16 os-prober
multiboot-doc xorriso desktop-base console-setup fuse
grub-common grub-ieee1275 grub-ieee1275-bin grub2 grub2-common libfreetype6 libfuse2 libpng16-16 os-prober
0 upgraded, 9 newly installed, 0 to remove and 0 not upgraded.
Need to get 4,556 kB of archives.
After this operation, 23.6 MB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://ftp.ports.debian.org/debian-ports unstable/main sparc64 libpng16-16 sparc64 1.6.34-1 [271 kB]
(...)
Creating config file /etc/default/grub with new version
Setting up grub2 (2.02-2+sparc64.3) ...
2. Make sure you have version 2.02-2+sparc64.3
Version: 2.02-2+sparc64.3
/dev/sda1 on /boot type ext3 (rw,relatime,data=ordered)
If you don't have one but just one root file system, grep for " / " instead
Installing for sparc64-ieee1275 platform.
grub-install: warning: Discarding improperly nested partition (hostdisk//dev/sda,sun1,sun2).
grub-install: warning: Discarding improperly nested partition (hostdisk//dev/sda,sun1,sun4).
grub-install: warning: Attempting to install GRUB to a disk with multiple partition labels. This is not supported yet..
grub-install: warning: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged..
Installation finished. No error reported.
Note: If you are using GPT partition tables instead of Sun partition
tables, you need to install GRUB into /dev/sda
(see: https://github.com/esnowberg/grub2-sparc/wiki)
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.14.0-1-sparc64-smp
Found initrd image: /boot/initrd.img-4.14.0-1-sparc64-smp
Found linux image: /boot/vmlinuz-4.14.0-trunk-sparc64-smp
Found initrd image: /boot/initrd.img-4.14.0-trunk-sparc64-smp
Found linux image: /boot/vmlinuz-4.14.0-rc7-sparc64-smp
Found initrd image: /boot/initrd.img-4.14.0-rc7-sparc64-smp
Found linux image: /boot/vmlinuz-4.14.0-rc5-sparc64-smp
Found initrd image: /boot/initrd.img-4.14.0-rc5-sparc64-smp
Found linux image: /boot/vmlinuz-4.12.0-rc1-sparc64-smp
Found initrd image: /boot/initrd.img-4.12.0-rc1-sparc64-smp
Found linux image: /boot/vmlinuz-4.11.0-trunk-sparc64-smp
Found initrd image: /boot/initrd.img-4.11.0-trunk-sparc64-smp
Found linux image: /boot/vmlinuz-4.10.0-trunk-sparc64-smp
Found initrd image: /boot/initrd.img-4.10.0-trunk-sparc64-smp
Found Debian GNU/Linux buster/sid on /dev/md0p1
done
7. Report back to the list and include your hardware and partition setup
Thanks,
Adrian
Frank Scheiner
2017-12-31 20:30:02 UTC
Permalink
Hi Adrian, hi Eric,

thanks for getting GRUB2 with support for sparc64 into Debian Ports.
Looks very good so far. :-D
Post by John Paul Adrian Glaubitz
7. Report back to the list and include your hardware and partition setup
I had some spare time these days and tested on the following machines:

## Machines tested ##

* Sun Enterprise 250
* Sun Ultra 80
* Sun Enterprise 4500
* Sun Fire V240
* Sun Fire V445
* Sun SPARC Enterprise T1000

## General information ##

I started with my Ultra 80 but wasn't able to successfully install
Debian Sid (from the sparc64 ISO from 2017-12-04 created by Adrian) -
the installation process always blocks during partman startup (always at
33%) but sadly for no obvious reason (nothing specific in syslog). Later
I sucessfully installed Debian Sid with the mentioned ISO on a V240 and
moved its disk to the other machines with parallel SCSI SCA ports (Ultra
80, E250).

When running `update-grub` GRUB2 configures the "root" device by using a
"search hint" with the OF path for the partition containing `/boot` on
the currently used machine:

e.g. from `/boot/grub/grub.cfg` on E250:
```
[...]
set root='hd0,sun1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root
--hint-ieee1275='ieee1275//***@1f\,4000/***@3/***@0\,0,sun1'
--hint-bios=hd0,sun1 --hint-efi=hd0,sun1 --hint-baremetal=ahci0,sun1
df9a392d-2dc5-4981-b6f9-57476351d51b
else
search --no-floppy --fs-uuid --set=root
df9a392d-2dc5-4981-b6f9-57476351d51b
fi
[...]
```

...but when moving the disk to a different machine with different bus
structure and different devices this OF path usually does not exist
there, so GRUB2 won't be able to find the correct "root" device.
Fortunately it's possible to use available OF device aliases in GRUB2 by
e.g. `set root='ieee1275/disk,1'`, where "disk" is a device alias which
usually translates to the very first disk and ",1" selects the partition
which contains `/boot`. So to boot successfully the easiest way for me
was to modify the device setting for the "root" device of GRUB2 (`set
root=[...]`) and remove the whole if clause below it. This can be done
directly from the GRUB2 menu on startup (select the desired entry and
hit the "e" key). When booted, a call to `update-grub` should configure
the correct search hint and this change won't be needed any longer
(works on E250, V240 and V445, not tested on Ultra 80 and not working on
E4500).

## Specific information ##

UPDATE: V445 and V240 tested with Linux kernel v4.14.2. E250, E4500,
Ultra 80 and T1000 tested with both v4.14.2 and v4.14.7.

### Enterprise 250 ###

* 2 x UltraSPARC II @ 400 MHz
* partition layout => same as on the V240
* booting via GRUB2 works
* installation from ISO not tested, used SCSI SCA disk from V240

### Ultra 80 ###

* 4 x UltraSPARC II @ 450 MHz
* partition layout => same as on the V240
* booting via GRUB2 works
* installation does not succeed (see above), used SCSI SCA disk from V240

### Enterprise 4500 ###

* 14 x UltraSPARC II @ 400 MHz
* partition layout => similar to the one on the V240
* booting via GRUB2 works, but problems with console (handover - I
assume) during kernel boot (at least with the MP kernel, the SP kernel
from the installer and the Debian Sid repo work without issues but leave
me with 13 unused CPUs, which is a pity :-/)
* installation from ISO worked somehow: the GRUB2 installer suggests to
install into MBR although the disk has a Sun disk label on it. I
selected /dev/sda1 manually (assuming an installation in the MBR would
overwrite the Sun disk label) and it looks like it worked. On reboot
though I noticed, that there was no ieee1275 search hint in the grub.cfg
entry (see above for an entry for E250), hence booting didn't work
without manual intervention (i.e. setting "root" to "ieee1275/disk,1").

### Fire V240 ###

* 2 x UltraSPARC IIIi @ 1 GHz
* partition layout:
```
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
[...]
sda 8:0 0 33.9G 0 disk
├─sda1 8:1 0 94.1M 0 part /boot
├─sda2 8:2 0 22.3G 0 part /
├─sda3 8:3 0 33.9G 0 part
└─sda4 8:4 0 11.6G 0 part [SWAP]
[...]
```
* booting via GRUB2 works
* installation from ISO worked, but I only installed SILO from ISO
first, GRUB2 was installed manually later (as per Adrian's howto).

### Fire V445 ###

* 4 x UltraSPARC IIIi @ 1.59 GHz
* partition layout similar to layout on V240, but as the machine since
the latest package upgrades no longer successfully boots I cannot get
the lsblk output :-(
* booting via GRUB2 works
* initially used an updated SATA disk from a V245 with Debian Sid and
installed GRUB2 manually but a later installation from ISO and a SAS
disk also worked (but similar situation as for E4500, i.e. GRUB2
proposed installation to MBR although the disk has a Sun disk label on
it, but at least a correct ieee1275 search hint made it to grub.cfg)

### SPARC Enterprise T1000 ###

* 1 x UltraSPARC T1 @ 1 GHz (8 cores)
* partition layout => same as on V445, as the same disk was used
* booting via GRUB2 works, but segfaults already with Linux kernel v4.14.2

Cheers,
Frank
Frank Scheiner
2018-02-19 09:30:01 UTC
Permalink
Post by John Paul Adrian Glaubitz
We're in the process of migrating Debian for sparc64 from SILO to GRUB
as GRUB upstream is adding support for modern SPARC machines thanks to
the work of Eric Snowberg from Oracle.
In order to make sure GRUB works on all machines supported by the sparc64
port, we need your help to test GRUB on your particular hardware, the older
your machine, the better.
So, in order to help us, please follow the guide below to install GRUB to
replace SILO as your boot loader.
[...]
2. Make sure you have version 2.02-2+sparc64.3
Version: 2.02-2+sparc64.3
There's a new package version (2.02+dfsg1-1) available since a few days
([1]).

[1]:
http://metadata.ftp-master.debian.org/changelogs/main/g/grub2/grub2_2.02+dfsg1-1_changelog

Installing it **and** using the mentioned `grub-install` command to
install it on the `/boot` partition over the previous version
(2.02-2+sparc64.3) breaks booting with GRUB2:

```
Sun Ultra 5/10 UPA/PCI (UltraSPARC-IIi 440MHz), No Keyboard
OpenBoot 3.31, 512 MB (60 ns) memory installed, Serial #12345678.
Ethernet address 8:0:20:12:34:56, Host ID: 80c6bc6f.



Rebooting with command: boot
Boot device: disk File and args:
GRUB Loading kernel..
Fast Data Access MMU Miss
ok
```

@Adrian:
Could or will you provide a new package with Eric's patches included -
assuming those are missing in 2.02+dfsg1-1?

Cheers,
Frank
John Paul Adrian Glaubitz
2018-02-19 13:40:01 UTC
Permalink
Hello!
There's a new package version (2.02+dfsg1-1) available since a few days ([1]).
[1]: http://metadata.ftp-master.debian.org/changelogs/main/g/grub2/grub2_2.02+dfsg1-1_changelog
Yes, this is something I don't have any control over. The grub2 package will
break every time on sparc64 until GRUB 2.04 has been released with hopefully
all of Eric's patches merged.

Alternatively, you can try to convince Debian's GRUB maintainers (CC'ed) that
they will merge my patch from #854568 [1].

Additionally, you will have to add the following in debian/rules for sparc/sparc64:

ifneq (,$(filter sparc sparc64,$(DEB_HOST_ARCH_CPU)))
export TARGET_LDFLAGS := -no-pie
endif
Could or will you provide a new package with Eric's patches included - assuming those are missing in 2.02+dfsg1-1?
Well, this will break over and over again, so I rather prefer getting the
patch merged into the Debian package officially.

Adrian
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854568
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Frank Scheiner
2018-02-19 14:40:02 UTC
Permalink
Hi,
Post by John Paul Adrian Glaubitz
Post by Frank Scheiner
Installing it **and** using the mentioned `grub-install` command to
install it on the `/boot` partition over the previous version
Yes, this is something I don't have any control over. The grub2 package will
break every time on sparc64 until GRUB 2.04 has been released with hopefully
all of Eric's patches merged.
I see.
Post by John Paul Adrian Glaubitz
Alternatively, you can try to convince Debian's GRUB maintainers (CC'ed) that
they will merge my patch from #854568 [1].
If they couldn't be convinced by you despite all your hard work on
Debian Ports, not even for the experimental suite, why should they
bother about me? :-)

But if someone cares: GRUB2 (w/those patches) allows network booting for
sparc64 w/modern (aka huge) kernels and initram file systems - something
that wasn't working properly (if at all) for a long time on sparc64.

Though the selection of per MAC/IP address configuration files during
startup as of now is in fact not on par with other network capable boot
loaders like pxelinux or yaboot, one can still script together a
somewhat similar method (see [1]).

[1]: https://bugzilla.redhat.com/show_bug.cgi?id=873406#c1

In addition it works on every sparc64 (Sun-4u, Sun-4v) machine I've
tested so far.

Hence I consider it a must have for sparc64. And my machines see things
the same way. :-)

Cheers,
Frank
txt.file
2018-02-19 15:00:02 UTC
Permalink
I finally found time to test GRUB on my Netra T1. But then I saw this
message and am demotivated.

Please add a grub build with Erics patches to experimental.

kind regards
txt.file
Post by John Paul Adrian Glaubitz
Hello!
There's a new package version (2.02+dfsg1-1) available since a few days ([1]).
http://metadata.ftp-master.debian.org/changelogs/main/g/grub2/grub2_2.02+dfsg1-1_changelog
Installing it **and** using the mentioned `grub-install` command to
install it on the `/boot` partition over the previous version
Yes, this is something I don't have any control over. The grub2 package will
break every time on sparc64 until GRUB 2.04 has been released with hopefully
all of Eric's patches merged.
Alternatively, you can try to convince Debian's GRUB maintainers (CC'ed) that
they will merge my patch from #854568 [1].
ifneq (,$(filter sparc sparc64,$(DEB_HOST_ARCH_CPU)))
export TARGET_LDFLAGS := -no-pie
endif
Could or will you provide a new package with Eric's patches included -
assuming those are missing in 2.02+dfsg1-1?
Well, this will break over and over again, so I rather prefer getting the
patch merged into the Debian package officially.
Adrian
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854568
John Paul Adrian Glaubitz
2018-02-23 22:40:01 UTC
Permalink
I just uploaded "2.02+dfsg1-1+sparc64.1" which fixes the problem.
Just wait some hours until it shows up on the regular FTP servers or
fetch it from https://incoming.debian.org/debian-buildd/pool/main/g/.
Wrong link. Should be: http://incoming.ports.debian.org/
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Frank Scheiner
2018-02-26 17:00:01 UTC
Permalink
Post by John Paul Adrian Glaubitz
I just uploaded "2.02+dfsg1-1+sparc64.1" which fixes the problem.
Just wait some hours until it shows up on the regular FTP servers or
fetch it from https://incoming.debian.org/debian-buildd/pool/main/g/.
Wrong link. Should be: http://incoming.ports.debian.org/
Thanks for the upload. The new version works like version
2.02-2+sparc64.3 for me.

Although not that useful currently:

I just tested this also with a PRIMEPOWER 250 with two SPARC64 V+
(sun4us) CPUs and guess what, GRUB(2) also works on this machine:

```
Fujitsu Siemens PRIMEPOWER250 2x SPARC64 V, No Keyboard
OpenBoot 3.18.1-1, 16384 MB memory installed
Ethernet address 0:b:5d:12:34:56, Host ID: 80123456.
XSCF Version: 4.12.1



{0} ok boot net:dhcp
Boot device: /***@83,4000/***@1,1:dhcp File and args:
44800 screen:r1024x768x75 not found.
Will use config file "(tftp)/etc/01-00-0b-5d-12-34-56"
Network status of pp250-3:
ofnet_gnet 00:0b:5d:12:34:56
ofnet_net0 00:0b:5d:12:34:56
ofnet_net0 00:0b:5d:12:34:56 172.16.2.109
ofnet_net0:local 172.16.0.0/16 ofnet_net0
ofnet_net0:default 0.0.0.0/0 gw 172.16.0.1


Loading Linux kernel ...
Loading initial ramdisk ...

[ 0.000058] PROMLIB: Sun IEEE Boot Prom 'OBP 3.18.1 2006/01/23 17:06'
[ 0.000067] PROMLIB: Root node compatible: sun4us
[ 0.000259] Linux version 4.15.0-1-sparc64-smp
(debian-***@lists.debian.org) (gcc version 7.3.0 (Debian 7.3.0-3)) #1
SMP Debian 4.15.4-1 (2018-02-18)
[ 0.295767] bootconsole [earlyprom0] enabled
[ 0.346696] ARCH: SUN4U
[ 0.375829] Ethernet address: 00:0b:5d:12:34:56
[ 0.429880] MM: PAGE_OFFSET is 0xfffff80000000000 (max_phys_bits == 40)
[ 0.508875] MM: VMALLOC [0x0000000100000000 --> 0x0000060000000000]
[ 0.583726] MM: VMEMMAP [0x0000060000000000 --> 0x00000c0000000000]
[ 0.659608] Kernel: Using 3 locked TLB entries for main kernel image.
[ 0.735624] Remapping the kernel...
[ 0.735682] done.
RED State Exception ( CPU#0 )
{0} ok
```

Though downloading kernel and initramfs via TFTP is slow on this machine
and the kernel crashes the machine, GRUB already works well.

Nice!

Cheers,
Frank
John Paul Adrian Glaubitz
2018-02-27 10:50:01 UTC
Permalink
Thanks for the upload. The new version works like version 2.02-2+sparc64.3 for me.
Frank, if you like, you can help improving grub-installer for sparc64.

We have extended the hardware detection in debian-installer on sparc and
sparc64 now, so that the installer can detect whether the hardware supports
GPT partition tables or not.

On a sparc64 with GPT support, you get something like:

sparc64/sun4v_gpt as the hardware type.

A sparc with GPT gives:

sparc/sun4v_gpt

And a sparc64 which is a sun4u without GPT, gives:

sparc64/sun4u_sun
https://anonscm.debian.org/git/d-i/grub-installer.git/tree/grub-installer#n628
https://anonscm.debian.org/git/d-i/grub-installer.git/tree/grub-installer#n853
https://anonscm.debian.org/git/d-i/grub-installer.git/tree/grub-installer#n867
https://github.com/esnowberg/grub2-sparc/wiki
I am building a new installer image necessary to work on this.

Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
John Paul Adrian Glaubitz
2018-02-27 11:00:01 UTC
Permalink
Post by John Paul Adrian Glaubitz
I am building a new installer image necessary to work on this.
https://people.debian.org/~glaubitz/debian-cd/debian-9.0-sparc64-NETINST-1.iso
Note: This image might have issues, it's solely intended for working
on grub-installer in case anyone else wants to use it.

Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Frank Scheiner
2018-03-02 21:00:02 UTC
Permalink
Hi Adrian,
Post by John Paul Adrian Glaubitz
Post by Frank Scheiner
Thanks for the upload. The new version works like version
2.02-2+sparc64.3 for me.
Frank, if you like, you can help improving grub-installer for sparc64.
Sure! :-) I had a first look and also did some testing.

I did use the image from 2018-02-16 for my testing though, as the newer
one from 2018-02-27 didn't work for me. When selecting the menu option
to load additional installer components I get a red screen
("Installation step failed") and looking into the log I see the following:

```
[...]
Mar 2 20:34:21 cdrom-retriever: warning: File
/cdrom/dists/sid/main/debian-installer/binary-sparc64/Packages does not
exist.
Mar 2 20:34:21 main-menu[220]: (process:836): Segmentation fault

Mar 2 20:34:21 kernel: [ 151.303940] anna[838]: segfault at 0 ip
ffff800100497648 (rpc ffff800100308f74) sp 000007feff91a961 error 1 in
libc.so.6[ffff800100410000+15e000]

Mar 2 20:34:21 main-menu[220]: WARNING **: Configuring 'load-cdrom'
failed with error code 139
Mar 2 20:34:21 main-menu[220]: WARNING **: Menu item 'load-cdrom' failed.
```

As I don't have a T4 (=minimum requirement for GPT support according to
Eric's wiki page) I cannot test booting from a GPT partitioned disk. But
I assume I can still test GRUB installations to GPT partitioned disks.
So I rewrote `/lib/partman/lib/disk-label.sh` to propose a default
partitioning scheme depending on the existence of a properly named file
in `/tmp`:

```
[...]
sparc|sparc64)
if [ -e /tmp/gpt ]; then
echo gpt
elif [ -e /tmp/sun ]; then
echo sun
else
echo UNKNOWN
fi;;
[...]
```

...which also works around the missing new subarch hardware detection on
the older image I had to use.

## Results ##

Up until now I got GRUB2 installations working automatically for disks
with Sun disklabel and GPT partitioned disks. For GPT I had to manually
partition the disk to get that required BIOS_GRUB partition. In the end
it worked with the following layout:

```
# parted /dev/sda print
Model: ATA Samsung SSD 850 (scsi)
Disk /dev/sda: 250GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number Start End Size File system Name Flags
1 1049kB 7340kB 6291kB bios_grub
2 7340kB 263MB 256MB ext2
3 263MB 240GB 240GB ext4
4 240GB 250GB 9796MB linux-swap(v1)
```

So we should also have a look into the recipe for GPT partitioning on
sparc(64).

The modifications I made autoselect (1) the partition for `/boot` as
target if a Sun disklabel is used and (2) the whole disk containing the
partition for `/boot` as target if the disk is GPT partitioned. A user
is never asked to select a target device.

Is that what we want?
Post by John Paul Adrian Glaubitz
We have extended the hardware detection in debian-installer on sparc and
sparc64 now, so that the installer can detect whether the hardware supports
GPT partition tables or not.
Nice. I have to say I never noticed that the subarch was always
"generic" for sparc(64) up until your changes ([1]).

[1]:
https://anonscm.debian.org/cgit/d-i/libdebian-installer.git/commit/src/system/subarch-sparc-linux.c?id=aa1ce486176b0cb24f5783d67eb28f80128aafb3
Post by John Paul Adrian Glaubitz
Post by Frank Scheiner
https://anonscm.debian.org/git/d-i/grub-installer.git/tree/grub-installer#n628
https://anonscm.debian.org/git/d-i/grub-installer.git/tree/grub-installer#n853
https://anonscm.debian.org/git/d-i/grub-installer.git/tree/grub-installer#n867
I don't think we can rely on the subarch value in this case, but have to
determine the actual partitioning scheme (available in `bootfslabel`
when running `grub-installer` or via `partmap <DISK>`) to select the
correct installation method. This because at least for sun4v with GPT
support users could also manually select to use a Sun disklabel. I used
the `bootfslabel` variable in my modifcations.

Up until now I tested with a single disk installed, but I'll also test
with multiple disks installed in my T5220 to see if this will make any
difference.

I can come up with a patch the next days perhaps. This should be much
smaller than the patchset for NewWorld Power Macs.

Cheers,
Frank
John Paul Adrian Glaubitz
2018-03-02 21:20:02 UTC
Permalink
I don't think we can rely on the subarch value in this case, but have to determine the actual partitioning scheme (available in `bootfslabel` when running `grub-installer` or via `partmap <DISK>`) to select the correct installation method. This because at least for sun4v with GPT support users could also manually select to use a Sun disklabel. I used the `bootfslabel` variable in my modifcations.
Well, debian-installer normally does not allow you to choose the partition table type.

On x86, it will automatically use GPT if the machine is booted in EFI mode. On sparc64, we would normally just switch to GPT if the machine supports GPT.

I don’t know how debian-installer behaves if you boot an x86 machine in EFI mode which has an MFT partition table, but I think that’s not supported by debian-installer.

For now it should be reasonable to assume GPT partioning on a machine that supports it and defaulting to Sun otherwise.

Please don’t let‘s us over-engineer this just to be able the rare case that someone used Sun partition tables from a previous installation on a machine that supports GPT.

I know you try to make the most compatible design to fit all use cases, but I don’t think we should support such edge cases when debian-installer doesn’t support it on other platforms.

Adrian
Frank Scheiner
2018-03-02 21:30:01 UTC
Permalink
Post by John Paul Adrian Glaubitz
Well, debian-installer normally does not allow you to choose the partition table type.
I remember I had a problem - which must be due to that behaviour in
hindsight - when I used a GPT partitioned disk from an rx2620 in a
rp3440. Although the installer created a different partition layout it
continued to use the GPT partitioning scheme and whan palo should be
installed it failed miserably.
Post by John Paul Adrian Glaubitz
On x86, it will automatically use GPT if the machine is booted in EFI mode. On sparc64, we would normally just switch to GPT if the machine supports GPT.
I understand. Then it's safe to just use the subarch to select how GRUB2
should be installed, although it's really not less complex than using
the variable.
Post by John Paul Adrian Glaubitz
I don’t know how debian-installer behaves if you boot an x86 machine in EFI mode which has an MFT partition table, but I think that’s not supported by debian-installer.
For now it should be reasonable to assume GPT partioning on a machine that supports it and defaulting to Sun otherwise.
Please don’t let‘s us over-engineer this just to be able the rare case that someone used Sun partition tables from a previous installation on a machine that supports GPT.
I know you try to make the most compatible design to fit all use cases, but I don’t think we should support such edge cases when debian-installer doesn’t support it on other platforms.
Ok, makes sense.
John Paul Adrian Glaubitz
2018-03-03 00:20:01 UTC
Permalink
Post by John Paul Adrian Glaubitz
On x86, it will automatically use GPT if the machine is booted in EFI mode. On sparc64, we would normally just switch to GPT if the machine supports GPT.
I understand. Then it's safe to just use the subarch to select how GRUB2 should be installed, although it's really not less complex than using the variable.
The thing is - I don't want to deviate the code too much from what's doing
on the other architectures. I don't necessarily disagree with you, but I just
want to go along with the other architectures for the time being.

However, if you're really concerned about the issue, I think we should discuss
this in a separate thread and also involve the debian-boot mailing list so
that we can find a common solution for all architectures.
Post by John Paul Adrian Glaubitz
I know you try to make the most compatible design to fit all use cases, but I don’t think we should support such edge cases when debian-installer doesn’t
support it on other platforms.
Ok, makes sense.
We can still address this once the other stuff works. You definitely have a
point though that there can be cases where the current code will most likely
fail.

Maybe it's a good idea to perform some tests with such setups on x86 (e.g.
having MBR partitioning and then booting the machine in EFI mode and keeping
the MBR setup) and observe what debian-installer does.

PS: I wrote "MFT" in my previous mail. I meant MBR, of course. MFT is part of NTFS.

Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
John Paul Adrian Glaubitz
2018-03-05 10:50:02 UTC
Permalink
At least with the stretch installer there is no problem with using a MBR partitioning
on the am64 arch. You maybe can't select it, but if you generate a MBR partitioning using
the shell inside the installer this will work.
Ok, after a quick look it seems that this particular configuration is actually
https://anonscm.debian.org/git/d-i/grub-installer.git/tree/grub-installer#n338
On EFI systems, it will test whether /var/lib/partman/ignore_uefi exists which I
assume is written by partman if it finds an MBR partition table on an EFI system.

We can most certainly add support for that later on sparc*. I just want to
get a simple GRUB installation on a clean system working and we're almost
there regarding that.
Also IMHO this (EFI partition on MBR) is usefull to work, as the server BIOSses here are all able
to boot from an USB stick which usually have MBR partitioning.
This is for installed systems, not for installer images.
As the servers used here all have an internal USB slot thats my favorite setup at the moments.
Why not use a remote KVM? ;)

Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Hermann Lauer
2018-03-05 12:30:02 UTC
Permalink
Post by John Paul Adrian Glaubitz
At least with the stretch installer there is no problem with using a MBR partitioning
on the am64 arch. You maybe can't select it, but if you generate a MBR partitioning using
the shell inside the installer this will work.
Ok, after a quick look it seems that this particular configuration is actually
https://anonscm.debian.org/git/d-i/grub-installer.git/tree/grub-installer#n338
On EFI systems, it will test whether /var/lib/partman/ignore_uefi exists which I
assume is written by partman if it finds an MBR partition table on an EFI system.
Thanks for this information.
Post by John Paul Adrian Glaubitz
Also IMHO this (EFI partition on MBR) is usefull to work, as the server BIOSses here are all able
to boot from an USB stick which usually have MBR partitioning.
This is for installed systems, not for installer images.
Yes, exactly: Booting the installed system via UEFI from usb stick. The netboot installer
has no partitioning - so no issue with installer images, at least not in my case.
Post by John Paul Adrian Glaubitz
As the servers used here all have an internal USB slot thats my favorite setup at the moments.
Why not use a remote KVM? ;)
Because netbooting rocks - or what are I'm missing ? ;-)

Probably we are getting to OT now...
Greetings
Hermann
--
Netzwerkadministration/Zentrale Dienste, Interdiziplinaeres
Zentrum fuer wissenschaftliches Rechnen der Universitaet Heidelberg
IWR; INF 205; 69120 Heidelberg; Tel: (06221)54-14405 Fax: -14427
Email: ***@iwr.uni-heidelberg.de
Hermann Lauer
2018-03-05 11:20:01 UTC
Permalink
Post by John Paul Adrian Glaubitz
On x86, it will automatically use GPT if the machine is booted in EFI mode. ...
...
Post by John Paul Adrian Glaubitz
I know you try to make the most compatible design to fit all use cases, but I don’t think we should support such edge cases when debian-installer doesn’t
support it on other platforms.
...
Post by John Paul Adrian Glaubitz
Maybe it's a good idea to perform some tests with such setups on x86 (e.g.
having MBR partitioning and then booting the machine in EFI mode and keeping
the MBR setup) and observe what debian-installer does.
At least with the stretch installer there is no problem with using a MBR partitioning
on the am64 arch. You maybe can't select it, but if you generate a MBR partitioning using
the shell inside the installer this will work.

Also IMHO this (EFI partition on MBR) is usefull to work, as the server BIOSses here are all able
to boot from an USB stick which usually have MBR partitioning.

As the servers used here all have an internal USB slot thats my favorite setup at the moments.

Just 2cents and thank for all your work,
greetings
Hermann
--
Netzwerkadministration/Zentrale Dienste, Interdiziplinaeres
Zentrum fuer wissenschaftliches Rechnen der Universitaet Heidelberg
IWR; INF 205; 69120 Heidelberg; Tel: (06221)54-14405 Fax: -14427
Email: ***@iwr.uni-heidelberg.de
John Paul Adrian Glaubitz
2018-02-23 22:40:02 UTC
Permalink
There's a new package version (2.02+dfsg1-1) available since a few days ([1]).
[1]: http://metadata.ftp-master.debian.org/changelogs/main/g/grub2/grub2_2.02+dfsg1-1_changelog
Installing it **and** using the mentioned `grub-install` command to install it on the `/boot` partition over the previous version (2.02-2+sparc64.3) breaks
I just uploaded "2.02+dfsg1-1+sparc64.1" which fixes the problem.
Just wait some hours until it shows up on the regular FTP servers or
fetch it from https://incoming.debian.org/debian-buildd/pool/main/g/.

Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Robin Cremer
2021-05-15 17:40:01 UTC
Permalink
Hi,
Post by John Paul Adrian Glaubitz
We're in the process of migrating Debian for sparc64 from SILO to GRUB
as GRUB upstream is adding support for modern SPARC machines thanks to
the work of Eric Snowberg from Oracle.
In order to make sure GRUB works on all machines supported by the sparc64
port, we need your help to test GRUB on your particular hardware, the older
your machine, the better.
[...]
7. Report back to the list and include your hardware and partition setup
A bit late to the party, as SILO already appears to be gone (including
the repos) and all install images use GRUB now, but I'm having trouble
and wanted to report this - and maybe get some ideas, in case this is
the best address to do so:

I'm in the process of migrating most of our SPARC servers running
Solaris 10 & the old Debian with 32bit SPARC userland to the SPARC64
debport.
Some servers running Solaris 11 will follow.

Installing on two SunFire v215 went reasonably well

/- (apart from recurring Kernel Panics with "Unable to handle kernel
paging request in mna handler", most often triggered on boot immediately
after the systemd binfmt service tries to start. This seems to have been
mentioned in /2020/04/msg00020.html but never pinpointed and fixed?) -/

but I can't seem to be able to configure GRUB on these servers as I did
in the past with SILO (a 2-disk mdraid with mirrored /boot, / and swap).
I'm currently stuck with /boot on only one disk and the rest of the
system mirrored as I can't figure out how to install grub for a mirrored
/boot partition:

1) Installing to the mirror device always yields a Segmentation Fault. I
was unable to get any clue with my limited gdb experience as to why -
(with loaded debug symbols etc.: "Backtrace stopped: previous frame
Post by John Paul Adrian Glaubitz
# grub-install --skip-fs-probe --force --debug /dev/md0
[...]
grub-install: info: setting the root device to
`mduuid/1ae243c1e2445aef777f4d32b671f41c'.
grub-install: warning: File system `ext2' doesn't support embedding.
grub-install: warning: Embedding is not possible.  GRUB can only be
installed in this setup by using blocklists.  However, blocklists are
UNRELIABLE and their use is discouraged..
grub-install: info: will leave the core image on the filesystem.
Segmentation fault
2) Trying to install to the individual disk partitions or the raw disk
Post by John Paul Adrian Glaubitz
grub-install: warning: File system `ext2' doesn't support embedding.
grub-install: error: embedding is not possible, but this is required
for RAID and LVM install.
[...]
Post by John Paul Adrian Glaubitz
grub-install: warning: Partition style `sun' doesn't support embedding.
grub-install: error: embedding is not possible, but this is required
for RAID and LVM install.
Neither different filesystems (ext2, xfs, ...) nor different mdraid
metadata formats made any difference.
I can't test other disk labels, as the old OBP doesn't handle GPT AFAIR.
Also, GRUB built from the most recent official sources from their git
segfaults as well.

Any pointers how to achieve this setup? What can I test or does someone
else have a similar setup working? Am I doing something horribly wrong?
I don't think mdraid-mirrored bootdisks should be too uncommon on this
hardware.

Thanks and cheers to the community keeping SPARC alive :-)
Robin
Robin Cremer
2021-05-16 00:10:02 UTC
Permalink
Responding to myself:

Some progress:
I put additional informational output between all commands in the
#ifdef GRUB_SETUP_SPARC64
  {
    grub_partition_t container = root_dev->disk->partition;
    if (grub_strstr (container->partmap->name, "gpt"))
      bl.gpt_offset = grub_partition_get_start (container);
  }
#endif
When installing on an md-device - or other special devices - it will
never have a partition table, thus "container" is null.
After that, access to struct members is tried without checking if it
even exists, leading to the segfault.
if (container && grub_strstr (container->partmap->name, "gpt"))
actually works & installs on LVM if I put a hint for GRUB into the
device.map pointing to the UUID of the MDRAID.

I'll try to get a patch for that submitted or discussed (I'm new to this
and not exactly sure if the change has other implications).


It still won't boot, though. The first "stage" in the 2nd partition
block is executed by OBP and something along the lines of "GRUB FAIL -
trap: Illegal Instruction" and on a second attempt "Unaligned Memory
Access" was encountered...


I'll post back,

Greetings,
Robin
John Paul Adrian Glaubitz
2021-05-17 08:50:01 UTC
Permalink
#ifdef GRUB_SETUP_SPARC64
  {
    grub_partition_t container = root_dev->disk->partition;
    if (grub_strstr (container->partmap->name, "gpt"))
      bl.gpt_offset = grub_partition_get_start (container);
  }
#endif
When installing on an md-device - or other special devices - it will never have a partition table, thus "container" is null.
It might be trying to read the partition table from a fixed position where it wouldn't be when using
a software RAID, not sure. In any case, this definitely needs to be moved upstream and you should
put Eric Snowberg from Oracle in the loop as he is the expert on GRUB for SPARC.
After that, access to struct members is tried without checking if it even exists, leading to the segfault.
if (container && grub_strstr (container->partmap->name, "gpt"))
actually works & installs on LVM if I put a hint for GRUB into the device.map pointing to the UUID of the MDRAID.
I'll try to get a patch for that submitted or discussed (I'm new to this and not exactly sure if the change has other implications).
It still won't boot, though. The first "stage" in the 2nd partition block is executed by OBP and something along the lines
of "GRUB FAIL - trap: Illegal Instruction" and on a second attempt "Unaligned Memory Access" was encountered...
Most likely because the block numbers reported back by the software RAID don't map to the block numbers on the
physical device which is why the first stage is just loading random garbage and executing it which leads to
SIGILL.

Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
John Paul Adrian Glaubitz
2021-05-17 08:30:01 UTC
Permalink
Hi Robin!
Post by John Paul Adrian Glaubitz
7. Report back to the list and include your hardware and partition setup
A bit late to the party, as SILO already appears to be gone (including the repos) and
all install images use GRUB now, but I'm having trouble and wanted to report this - and
You can still install SILO from snapshot.debian.org. However, I would recommend building
the latest version from source as there have been some bugfixes in the meantime.
I'm in the process of migrating most of our SPARC servers running Solaris 10 & the old Debian
with 32bit SPARC userland to the SPARC64 debport. Some servers running Solaris 11 will follow.
Good to hear.
Installing on two SunFire v215 went reasonably well
/- (apart from recurring Kernel Panics with "Unable to handle kernel paging request in mna handler",
most often triggered on boot immediately after the systemd binfmt service tries to start. This seems
to have been mentioned in /2020/04/msg00020.html but never pinpointed and fixed?) -/
What kernel version are you running. There have actually been some fixes in this regard, in particular
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/sparc?id=e5e8b80d352ec999d2bba3ea584f541c83f4ca3f
but I can't seem to be able to configure GRUB on these servers as I did in the past with SILO (a 2-disk
mdraid with mirrored /boot, / and swap). I'm currently stuck with /boot on only one disk and the rest of
Please keep in mind that GRUB is installed using blocklists on these older machines which means it's not
aware of the filesystem being used. The bootloader will just remember the location of the data blocks
and the physical disk. So it has no means to deal with something sophisticated as a software RAID.

Not sure how it worked with SILO which didn't use anything else than blocklists either (which is why
the /boot partition couldn't be too large and the filesystem used couldn't be too fancy).
1) Installing to the mirror device always yields a Segmentation Fault. I was unable to get any clue with
my limited gdb experience as to why - (with loaded debug symbols etc.: "Backtrace stopped: previous frame
Post by John Paul Adrian Glaubitz
# grub-install --skip-fs-probe --force --debug /dev/md0
[...]
grub-install: info: setting the root device to `mduuid/1ae243c1e2445aef777f4d32b671f41c'.
grub-install: warning: File system `ext2' doesn't support embedding.
grub-install: warning: Embedding is not possible.  GRUB can only be installed in this setup by using blocklists.  However, blocklists are UNRELIABLE and their use is discouraged..
grub-install: info: will leave the core image on the filesystem.
Segmentation fault
As I said above, I don't expect this to work, really. That doesn't mean that grub-install should crash
here. I will try to reproduce the issue when I find some time. Ideally, grub-install should just abort
the installation in this case.

But we could also find out how SILO worked in this case.
Post by John Paul Adrian Glaubitz
grub-install: warning: File system `ext2' doesn't support embedding.
grub-install: error: embedding is not possible, but this is required for RAID and LVM install.
[...]
Post by John Paul Adrian Glaubitz
grub-install: warning: Partition style `sun' doesn't support embedding.
grub-install: error: embedding is not possible, but this is required for RAID and LVM install.
Neither different filesystems (ext2, xfs, ...) nor different mdraid metadata formats made any difference.
I can't test other disk labels, as the old OBP doesn't handle GPT AFAIR.
Also, GRUB built from the most recent official sources from their git segfaults as well.
Thanks for testing the git version, I was about to ask that.
Any pointers how to achieve this setup? What can I test or does someone else have a similar setup
working? Am I doing something horribly wrong? I don't think mdraid-mirrored bootdisks should be too
uncommon on this hardware.
From my statements above, I wouldn't expect GRUB with blocklists to work on a software RAID, so I
think you probably have no choice but to use a single disk for booting. In any case, I think the
the GRUB-specific discussion should be moved to the GRUB mailing list as this really concerns the
low-level functionality of GRUB.
Thanks and cheers to the community keeping SPARC alive :-)
Sure. Glad it's being useful.

Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Robin Cremer
2021-05-17 09:40:01 UTC
Permalink
Hi Adrian,

thanks for the response!

First things first: I got GRUB to work yesterday :-)
The last bit of magic missing in the picture was what you expected: The
blocklist was "shifted" because GRUB-install didn't correctly determine
the relation of physical disk vs. MDraid-Volume block positions.
Not sure if it does when installing on x86 with blocklists?
I found it hard to find usable documentation about the actual physical
on-disk-layout of MDraid RAID-1.
SuperBlocks are well documented, the "complex" RAID-levels reasonably
well also, but I found no mention that building the volume with
metadata-version 1.2
(metadata 4k from beginning of disk, which shouldn't be a problem, as
only the first 2 512-Byte sectors (->~1k) are in use for label & GRUB
boot.img) actually shifts the start of Data in the mdraid to the end of
the first 1MB block - so blocklist numbers are off by 1MB.
I noticed that by trial & error: I opened a "normally installed" disk
and the RAID member disk I tried to build in a hexeditor ;-)
metadata=0.9 does not do this. I thought the metadata-settings only
affected the position and "type" of the mdraid metadata blocks, not the
actual on-disk-layout of the mirror.

So, long story short:
My old setup with SILO was exactly like this: metadata=0.9 for the /boot
partition. With this, the ext3 blocks are on the same position on the
physical disk AND on the md-volume.
I might have set it up like this for the same reason back then, but
forgot... It's been quite a while.

The second (although minor) trouble was, that grub-mkconfig generates an
unusable grub.cfg for this setup. It refuses to set the "root=" variable
to (mduuid/UUID), which was in turn necessary to install the bootblocks,
instead using settings that lead to GRUB being unable to open the
partition label and failing back to OBP.

The best solution I found was to edit the
/usr/lib/grub/grub-mkconfig_lib shellscript to not set root at all.
In my case, that works flawlessly, as GRUB actually starts with "root="
already set to the disk that loaded it, so it even works with one disk
pulled from the server, simulating failure - which was exactly what I
wanted.


So, long story short:
- Patching util/setup.c to correctly handle (virtual) block devices
without partition tables.
- Use metadata=0.9 to build the mirror (!)
- Add device.map entry for MDraid-Device to work around the "diskfilter
(mduuid/66bf8873932144cf2d6a74e4a05e67d3) /dev/md0
- Strip the lines in /usr/lib/grub/grub-mkconfig_lib between
  # otherwise set root as per value in device.map.
and
  IFS="$old_ifs"
to make boot entries that do not try to re-set "root"


After this fight, I achieved my boot mirror setup on GRUB/SPARC :-)

I'll respond to the kernel-stuff separately.

Thanks!

- Robin
Hi Robin!
Post by John Paul Adrian Glaubitz
7. Report back to the list and include your hardware and partition setup
A bit late to the party, as SILO already appears to be gone (including the repos) and
all install images use GRUB now, but I'm having trouble and wanted to report this - and
You can still install SILO from snapshot.debian.org. However, I would recommend building
the latest version from source as there have been some bugfixes in the meantime.
I'm in the process of migrating most of our SPARC servers running Solaris 10 & the old Debian
with 32bit SPARC userland to the SPARC64 debport. Some servers running Solaris 11 will follow.
Good to hear.
Installing on two SunFire v215 went reasonably well
/- (apart from recurring Kernel Panics with "Unable to handle kernel paging request in mna handler",
most often triggered on boot immediately after the systemd binfmt service tries to start. This seems
to have been mentioned in /2020/04/msg00020.html but never pinpointed and fixed?) -/
What kernel version are you running. There have actually been some fixes in this regard, in particular
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/sparc?id=e5e8b80d352ec999d2bba3ea584f541c83f4ca3f
but I can't seem to be able to configure GRUB on these servers as I did in the past with SILO (a 2-disk
mdraid with mirrored /boot, / and swap). I'm currently stuck with /boot on only one disk and the rest of
Please keep in mind that GRUB is installed using blocklists on these older machines which means it's not
aware of the filesystem being used. The bootloader will just remember the location of the data blocks
and the physical disk. So it has no means to deal with something sophisticated as a software RAID.
Not sure how it worked with SILO which didn't use anything else than blocklists either (which is why
the /boot partition couldn't be too large and the filesystem used couldn't be too fancy).
1) Installing to the mirror device always yields a Segmentation Fault. I was unable to get any clue with
my limited gdb experience as to why - (with loaded debug symbols etc.: "Backtrace stopped: previous frame
Post by John Paul Adrian Glaubitz
# grub-install --skip-fs-probe --force --debug /dev/md0
[...]
grub-install: info: setting the root device to `mduuid/1ae243c1e2445aef777f4d32b671f41c'.
grub-install: warning: File system `ext2' doesn't support embedding.
grub-install: warning: Embedding is not possible.  GRUB can only be installed in this setup by using blocklists.  However, blocklists are UNRELIABLE and their use is discouraged..
grub-install: info: will leave the core image on the filesystem.
Segmentation fault
As I said above, I don't expect this to work, really. That doesn't mean that grub-install should crash
here. I will try to reproduce the issue when I find some time. Ideally, grub-install should just abort
the installation in this case.
But we could also find out how SILO worked in this case.
Post by John Paul Adrian Glaubitz
grub-install: warning: File system `ext2' doesn't support embedding.
grub-install: error: embedding is not possible, but this is required for RAID and LVM install.
[...]
Post by John Paul Adrian Glaubitz
grub-install: warning: Partition style `sun' doesn't support embedding.
grub-install: error: embedding is not possible, but this is required for RAID and LVM install.
Neither different filesystems (ext2, xfs, ...) nor different mdraid metadata formats made any difference.
I can't test other disk labels, as the old OBP doesn't handle GPT AFAIR.
Also, GRUB built from the most recent official sources from their git segfaults as well.
Thanks for testing the git version, I was about to ask that.
Any pointers how to achieve this setup? What can I test or does someone else have a similar setup
working? Am I doing something horribly wrong? I don't think mdraid-mirrored bootdisks should be too
uncommon on this hardware.
From my statements above, I wouldn't expect GRUB with blocklists to work on a software RAID, so I
think you probably have no choice but to use a single disk for booting. In any case, I think the
the GRUB-specific discussion should be moved to the GRUB mailing list as this really concerns the
low-level functionality of GRUB.
Thanks and cheers to the community keeping SPARC alive :-)
Sure. Glad it's being useful.
Adrian
Robin Cremer
2021-05-17 10:40:01 UTC
Permalink
Hi Adrian,
Post by John Paul Adrian Glaubitz
Post by Robin Cremer
Installing on two SunFire v215 went reasonably well
/- (apart from recurring Kernel Panics with "Unable to handle kernel paging request in mna handler",
most often triggered on boot immediately after the systemd binfmt service tries to start. This seems
to have been mentioned in /2020/04/msg00020.html but never pinpointed and fixed?) -/
What kernel version are you running. There have actually been some fixes in this regard, in particular
Post by Robin Cremer
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/sparc?id=e5e8b80d352ec999d2bba3ea584f541c83f4ca3f
5.10.0-6-sparc64-smp #1 SMP Debian 5.10.28-1 (2021-04-09) sparc64
GNU/Linux
The commit you mention seems to be in 5.12 and 5.13-rc2?
Is there a pre-built SMP-image for this or do I have to set up building
myself?


Running on the v215 was a real nightmare yesterday. They will be stable
for hours, but certain actions (in one occurence executing dmesg (!),
apt-get installing nfs-common, some mounts systemd tries) crashed both
of the boxes with various errors, most of them the dreaded line with "p
Retrying the dpkg-reconfigure as well. After the systemd-unit for - I
think - rpcbind was activated during package configuration, both boxes
crashed about 4-6 times, I had to reset from OBP.
After a few tries, installation went through, then. Now I can mount nfs...
The hours I spent in the rescue mode of the current installation CD
without any trouble made me suspect that non-SMP-kernels are "more
stable". I'm currently running the SMP variant with "maxcpus=1", that
seems stable so far... But as with any other sporadic issue, that's hard
to tell with a way to reliably trigger the errors...

The worst offender so far seems to be xfs, though...
I initially installed both v215 with ext3 /boot and xfs for /.
I'm not sure if the problem is related, but xfs seems to frequently
encounter
Post by John Paul Adrian Glaubitz
[   35.325122] XFS (md1): Metadata corruption detected at
xfs_dinode_verify.part.0+0x358/0x6c0 [xfs], inode 0x402c4d0 dinode
[   35.469639] XFS (md1): Unmount and run xfs_repair
on both machines. xfs_repair doesn't do anything, though. Either, these
inodes were the last ones written during kernel panics, or the
underlying issue of the panics
leads to checksum-mismatches in-memory? The latter seems more likely,
Post by John Paul Adrian Glaubitz
[  195.360257] XFS (md1): Corruption of in-memory data detected. 
Shutting down filesystem
(after that, obviously, the system is unusable despite not panicking, as
root is missing entirely...)
Post by John Paul Adrian Glaubitz
[  281.304119] WARNING: CPU: 1 PID: 11 at kernel/smp.c:633
smp_call_function_many_cond+0x3bc/0x3e0
[  281.418696] Modules linked in: ext4(E) crc16(E) mbcache(E) jbd2(E)
sr_mod(E) cdrom(E) ata_generic(E) tg3(E) libphy(E) ptp(E) ohci_pci(E)
sg(E) pata_ali(E) ehci_pci(E) ohci_hcd(E) ehci_hcd(E) libata(E)
pps_core(E) usbcore(E) usb_common(E) flash(E) drm(E)
drm_panel_orientation_quirks(E) i2c_core(E) fuse(E) configfs(E)
ip_tables(E) x_tables(E) autofs4(E) xfs(E) raid10(E) raid456(E)
async_raid6_recov(E) async_memcpy(E) async_pq(E) raid6_pq(E)
async_xor(E) xor(E) async_tx(E) libcrc32c(E) crc32c_generic(E)
raid0(E) multipath(E) linear(E) raid1(E) md_mod(E) sd_mod(E) t10_pi(E)
crc_t10dif(E) crct10dif_generic(E) crct10dif_common(E) mptsas(E)
scsi_transport_sas(E) mptscsih(E) mptbase(E) scsi_mod(E)
[  282.224447] CPU: 1 PID: 11 Comm: ksoftirqd/1 Tainted: G D     E    
5.10.0-6-sparc64-smp #1 Debian 5.10.28-1
[  282.391788] [<000000000046c67c>] __warn+0xbc/0x120
[  282.454810] [<0000000000c450f8>] warn_slowpath_fmt+0x34/0x74
[  282.529285] [<0000000000517b5c>]
smp_call_function_many_cond+0x3bc/0x3e0
[  282.617512] [<0000000000517be4>] smp_call_function+0x24/0x40
[  282.691989] [<0000000000441828>] smp_send_stop+0x28/0x120
[  282.763028] [<0000000000c44e84>] panic+0x110/0x350
[  282.826047] [<0000000000472ad0>] do_exit+0xad0/0xb20
[  282.891357] [<0000000000c43ab0>] die_if_kernel+0x1f4/0x260
[  282.963543] [<0000000000c5501c>] unhandled_fault+0x88/0xac
[  283.035728] [<0000000000c553c8>] do_sparc64_fault+0x388/0xa80
[  283.111354] [<0000000000407714>] sparc64_realfault_common+0x10/0x20
[  283.193850] [<00000000005a1e64>] __bpf_prog_put_rcu+0x24/0x60
[  283.269470] [<00000000004f5c20>] rcu_core+0x240/0x620
[  283.335926] [<00000000004f600c>] rcu_core_si+0xc/0x20
[  283.402383] [<0000000000c5602c>] __do_softirq+0x10c/0x3a0
[  283.473423] [<0000000000473b14>] run_ksoftirqd+0x34/0x60
[  283.543315] ---[ end trace 9f0a29fcdf85be47 ]---
[  124.914048] CPU[1]: Cheetah+ D-cache parity error at
TPC[00000000005bc2b0]
[  125.004638] TPC<bpf_check+0x1cd0/0x32e0>
nfs-utils.service is a disabled or a static unit, not starting it.
[  125.528183] Kernel unaligned access at TPC[8ffba4]
atomic64_sub_return+0x4/0x54
[  125.624591] Unable to handle kernel paging request in mna handler
[  125.624595]  at virtual address 6f430c861b2ffaab
[  125.765686] current->{active_,}mm->context = 00000000000000c1
[  125.841410] current->{active_,}mm->pgd = fff0000001b94000
[  125.912544]               \|/ ____ \|/
[  125.912544]               /_| \__/ |_\
[  125.912544]                  \__U_/
[  126.106299] systemd(1): Oops [#1]
Especially the "Unable to handle kernel paging request in mna handler"
is interesting. It's nearly identical to the issue posted ~ a year ago,
seemingly introduced somewhere around the Kernel 5.0-time.
It's not always accompanied by the "Cheetah+ D-cache parity error at
TPC[00000000005bc2b0]"-error. And while CPU L1-Cache parity errors
"seem" like a hardware issue, I highly suspect it is not. Both machines
show these errors sporadically (often without panicking!) and I found
mention of these errors in other contexts...
Also, both systems were highly stable in the past, exceeding 2-3 years
of uptime, although on Solaris 10 :-(


On a not entirely unrelated note:
Are there any news on functioning netboot images? The last post I could
find points to images from April '17 on your webspace, which were,
according to the ML, not bootable because of the size.
At least I can't boot them either.
If there is no more recent version, I'll try to build something myself -
are there any pointers on how to go about this? Minimal OS or the
netinstaller in an .img would be preferred.

I think that would help in quick testing, as I have multiple other
systems with Cheetah (UltraSPARC III, III CU and IIIi) I'd like to try
provoking the panics on.
Also, some older (UltraSPARC IIi and IIe+) systems are waiting for
recent Debian :-)


Thanks,

- Robin
John Paul Adrian Glaubitz
2021-05-17 11:00:01 UTC
Permalink
Post by Robin Cremer
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/sparc?id=e5e8b80d352ec999d2bba3ea584f541c83f4ca3f
5.10.0-6-sparc64-smp #1 SMP Debian 5.10.28-1 (2021-04-09) sparc64 GNU/Linux
The commit you mention seems to be in 5.12 and 5.13-rc2?
Is there a pre-built SMP-image for this or do I have to set up building myself?
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/arch/sparc?h=linux-5.10.y&id=f2b38f03a3f71c30c77a4516b26c8bea13cc08ce
Running on the v215 was a real nightmare yesterday. They will be stable for hours, but
certain actions (in one occurence executing dmesg (!), apt-get installing nfs-common,
some mounts systemd tries) crashed both of the boxes with various errors, most of them the
dreaded line with "p
Try to use a 4.19 kernel from snapshot.debian.org, these are known to run more stable on the
older machines. Any machine older than T2 seem to have some issues with the more recent kernels.

If you have the possibility to bisect the issue, that would be great. I do have such older machines
myself but currently no possibility to set them up for bisecting.

On the newer CPUs (>= SPARC T2), the kernel runs stable. Dave Miller (the Linux SPARC maintainer)
uses a T5 himself for testing.
Post by Robin Cremer
Retrying the dpkg-reconfigure as well. After the systemd-unit for - I think - rpcbind was activated
during package configuration, both boxes crashed about 4-6 times, I had to reset from OBP.
After a few tries, installation went through, then. Now I can mount nfs...
The hours I spent in the rescue mode of the current installation CD without any trouble made me suspect
that non-SMP-kernels are "more stable". I'm currently running the SMP variant with "maxcpus=1", that
seems stable so far... But as with any other sporadic issue, that's hard to tell with a way to reliably
trigger the errors...
I think these issues have started to show up sometime after 4.19 but only on the older machines. So, chances
are you can bisect the issue.
Post by Robin Cremer
Are there any news on functioning netboot images? The last post I could find points to images from April '17
on your webspace, which were, according to the ML, not bootable because of the size.
I don't have the time and resources at the moment to work on netboot. I'm not just maintaining the sparc64
port in Debian but also many of the other unofficial ports such as 32-bit PowerPC. So far, netboot has not
been a top priority so I haven't worked on it yet.

Additional support is always welcome.
Post by Robin Cremer
At least I can't boot them either.
If there is no more recent version, I'll try to build something myself - are there any pointers on how to go
about this? Minimal OS or the netinstaller in an .img would be preferred.
You just have to build the debian-installer package on sparc64 using sbuild and as a result, you will get
the tarball containing the netboot and cdrom images.
Post by Robin Cremer
I think that would help in quick testing, as I have multiple other systems with Cheetah (UltraSPARC III, III CU
and IIIi) I'd like to try provoking the panics on. Also, some older (UltraSPARC IIi and IIe+) systems are waiting
for recent Debian :-)
For these machines, I would recommend installing a regular release, then downgrading the kernel to 4.19, then
bi-sect using a cross-compiled kernel if you have a working reproducer.

Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Robin Cremer
2021-05-25 23:20:02 UTC
Permalink
thanks for the information. I'm still battling a few issues, but the
most prominent problem on my way to netboot-install is that I can't seem
Post by John Paul Adrian Glaubitz
You just have to build the debian-installer package on sparc64 using sbuild and as a result, you will get
the tarball containing the netboot and cdrom images.
...trying to get the build-deps for debian-installer complains, that I
should at least specify one deb-src line in my sources.list...
I have the settings the installer configured ("deb-src
http://deb.debian.org/debian-ports/ sid main"), but sid doesn't have a
/main/source on debian-ports... "unreleased" does have a source folder,
but apt seems to ignore the "unreleased" distribution for sources (maybe
that's what the comment "unreleased does not support sources yet" means?)

Well... long story short: Can you point me in the right direction to get
the sources the debian-ports use? Or is the normal way to pull sources
from "normal" debian repositories?

Thanks,
Robin

Frank Scheiner
2021-05-17 11:30:01 UTC
Permalink
Hi Robin,
Post by Robin Cremer
[...]
Are there any news on functioning netboot images? The last post I could
find points to images from April '17 on your webspace, which were,
according to the ML, not bootable because of the size.
At least I can't boot them either.
Can't help you with any netboot images, though I assume the existing
ones in the archives ([1], images are in
`./installer-sparc64/20210415/images/netboot/netboot.tar.gz`) could
actually work if they are loaded from GRUB and not from the OBP.

[1]:
http://ftp.ports.debian.org/debian-ports/pool-sparc64/main/d/debian-installer/
Post by Robin Cremer
If there is no more recent version, I'll try to build something myself -
are there any pointers on how to go about this? Minimal OS or the
netinstaller in an .img would be preferred.
I described a possible setup to netboot with GRUB on [2]. My used
version of GRUB is old (`sparc64-ieee1275-2.02+dfsg1-18`) but works.
This setup works similarly to identically for most of my machinery
(ia64, amd64, powerpc, ppc64, sparc64) and for me GRUB is able to load
"large" images (> 100 MiB, tested during my investigation on [3]) over
network w/o an issue. With a working sparc64 Debian installation it's
even easier to setup. You can host everything needed (I recommend:
dnsmasq (only for DNS), tftpd-hpa, isc-dhcp-server and possibly rarpd)
on a Raspberry Pi for example. I assume you're already familiar with
these services but just ask if you need some help in configuration.

[2]: https://wiki.debian.org/Sparc64#Netbooting_with_GRUB2

[3]: https://lists.debian.org/debian-sparc/2021/03/msg00045.html
Post by Robin Cremer
I think that would help in quick testing, as I have multiple other
systems with Cheetah (UltraSPARC III, III CU and IIIi) I'd like to try
provoking the panics on.
Also, some older (UltraSPARC IIi and IIe+) systems are waiting for
recent Debian :-)
For testing multiple systems for anomalies I'd recommend to netboot with
a Debian root FS provided by NFS which saves you the time to install
Debian on every machine. There were two posts on the debian-sparc list
recently ([4]) by Anatoly that mentioned the `stress-ng` tool, which
might be helpful in provoking panics and possibly identifying the source
of a panic.

[4]:
https://lists.debian.org/cgi-bin/search?P=stress-ng&DEFAULTOP=or&B=Gdebian-sparc&SORT=&HITSPERPAGE=10

Cheers,
Frank
Continue reading on narkive:
Loading...