On 02/27/2018 11:42 AM, John Paul Adrian Glaubitz wrote:
On 02/26/2018 05:55 PM, Frank Scheiner wrote:
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
Mar 2 20:34:21 main-menu: (process:836): Segmentation fault
Mar 2 20:34:21 kernel: [ 151.303940] anna: segfault at 0 ip
ffff800100497648 (rpc ffff800100308f74) sp 000007feff91a961 error 1 in
Mar 2 20:34:21 main-menu: WARNING **: Configuring 'load-cdrom'
failed with error code 139
Mar 2 20:34:21 main-menu: 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
if [ -e /tmp/gpt ]; then
elif [ -e /tmp/sun ]; then
...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
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
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?
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 ().
This information should be used here:
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
I can come up with a patch the next days perhaps. This should be much
smaller than the patchset for NewWorld Power Macs.