Re: Kernel Panics / Re: GRUB testers on SPARC needed

[Robin Cremer]

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 
to get the apt/sources.list right for fetching sources (?):

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

Re: Kernel Panics / Re: GRUB testers on SPARC needed

[Frank Scheiner]

Hi Robin,

On 17.05.21 12:36, Robin Cremer wrote:

[...]
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.


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/


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


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=or=Gdebian-sparc==10

Cheers,
Frank

Re: Kernel Panics / Re: GRUB testers on SPARC needed

[John Paul Adrian Glaubitz]

On 5/17/21 12:36 PM, Robin Cremer wrote:
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/sparc?id=e5e8b80d352ec999d2bba3ea584f541c83f4ca3f
> I'm using the latest version from the repositories:
>> 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?

The commit has been backported to the 5.10.x series which is an LTS kernel:

> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/arch/sparc?h=linux-5.10.y=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.

> 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.

> 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.

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.

> 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.

> 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 - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Kernel Panics / Re: GRUB testers on SPARC needed

[Robin Cremer]

Hi Adrian,
for the sake of visibility, here the response to the kernel-trouble:

Am 17.05.2021 um 10:23 schrieb John Paul Adrian Glaubitz:

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
this fix:


https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/sparc?id=e5e8b80d352ec999d2bba3ea584f541c83f4ca3f

I'm using the latest version from the repositories:
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
[   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, 
because during dpkg-installs the following popped up a few times as well:
[  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...)


Some faults:
[  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.359710] Call Trace:
[  282.391788] [<0046c67c>] __warn+0xbc/0x120
[  282.454810] [<00c450f8>] warn_slowpath_fmt+0x34/0x74
[  282.529285] [<00517b5c>] 
smp_call_function_many_cond+0x3bc/0x3e0

[  282.617512] [<00517be4>] smp_call_function+0x24/0x40
[  282.691989] [<00441828>] smp_send_stop+0x28/0x120
[  282.763028] [<00c44e84>] panic+0x110/0x350
[  282.826047] [<00472ad0>] do_exit+0xad0/0xb20
[  282.891357] [<00c43ab0>] die_if_kernel+0x1f4/0x260
[  282.963543] [<00c5501c>] unhandled_fault+0x88/0xac
[  283.035728] [<00c553c8>] do_sparc64_fault+0x388/0xa80
[  283.111354] [<00407714>] sparc64_realfault_common+0x10/0x20
[  283.193850] [<005a1e64>] __bpf_prog_put_rcu+0x24/0x60
[  283.269470] [<004f5c20>] rcu_core+0x240/0x620
[  283.335926] [<004f600c>] rcu_core_si+0xc/0x20
[  283.402383] [<00c5602c>] __do_softirq+0x10c/0x3a0
[  283.473423] [<00473b14>] run_ksoftirqd+0x34/0x60
[  283.543315] ---[ end trace 9f0a29fcdf85be47 ]---


[  124.914048] CPU[1]: Cheetah+ D-cache parity error at 
TPC[005bc2b0]

[  125.004638] TPC
nfs-utils.service is a disabled or a static unit, not starting it.
[  125.528183] Kernel unaligned access 

Re: GRUB testers on SPARC needed

[Robin Cremer]

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 
writes not supported"-issue (from grub-probe -t ieee1275_hints -d /dev/md0):

(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


Am 17.05.2021 um 10:23 schrieb John Paul Adrian Glaubitz:

Hi Robin!

On 5/15/21 7:25 PM, Robin Cremer wrote:

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:

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
this fix:


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
the system mirrored as I can't figure out how to install grub for a mirrored 
/boot partition:

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

Re: GRUB testers on SPARC needed

[John Paul Adrian Glaubitz]

On 5/16/21 2:03 AM, Robin Cremer wrote:
> Responding to myself:
> 
> Some progress:
> I put additional informational output between all commands in the suspect 
> area in GRUBs util/setup.c and pinpointed the bug:
> 
>> #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 - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: GRUB testers on SPARC needed

[John Paul Adrian Glaubitz]

Hi Robin!

On 5/15/21 7:25 PM, Robin Cremer wrote:
>> 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:

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
this fix:

> 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
> the system mirrored as I can't figure out how to install grub for a mirrored 
> /boot partition:

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
> identical to this frame (corrupt stack?)"):
>> # 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.

> 2) Trying to install to the individual disk partitions or the raw disk itself:
>> 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.
> [...]
>> 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 - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: GRUB testers on SPARC needed

[Robin Cremer]

Responding to myself:

Some progress:
I put additional informational output between all commands in the 
suspect area in GRUBs util/setup.c and pinpointed the bug:



#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

Re: GRUB testers on SPARC needed

[Robin Cremer]

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


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 
identical to this frame (corrupt stack?)"):

# 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 
itself:

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.

[...]

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

Re: grub-installer: info: Calling 'apt-install grub-ieee1275' failed

[John Paul Adrian Glaubitz]

Hello!

On 1/11/21 2:53 PM, Dennis Clarke wrote:
> I am doing a re-install with the "default" installer and I choose the
> most trivial config options. Which is to say the partition options were
> whatever seems most trivial. Full disk. New partition table. Everything
> in one partition.  The default seems to be 512MB ext2 bootable /boot and
> then a large slice and 1G of swap.
> 
> Eventually I see a big red box :
> 
> [!!] Configure the package manager
> apt configuration problem
> An attempt to configure apt to install additional packages from the
> media failed.
> 
> Here I select "continue" and things seem to move along.

You should have checked what's in the log in the other terminal so you know
the actual problem was.

> I guess there is something oddball in the expert level menu option but
> we don't really test for that. OKay, this works in the easy mode option.

I alone simply don't have the capacity to test (and fix!) all possible
paths in the installer.

If you run into such problem, try to reproduce it with a daily snapshot
of the installer on one of the officially supported architectures and
then file a bug against debian-installer.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: grub-installer: info: Calling 'apt-install grub-ieee1275' failed

[Dennis Clarke]

On 1/9/21 1:12 AM, John Paul Adrian Glaubitz wrote:
> On 1/9/21 1:53 AM, Dennis Clarke wrote:
>>
>> I think this is pretty much well known but I will report it here
>> regardless. From the latest sparc64 installer images I eventually
>> see grub-ieee1275 fails.
>> (...)
>> Jan  4 19:00:02 in-target: Get:1 http://deb.debian.org/debian-ports
>> sid/main sparc64 grub2-common sparc64 2.04-11 [719 kB]
>> Jan  4 19:00:04 in-target: Err:2 http://deb.debian.org/debian-ports
>> sid/main sparc64 grub-ieee1275-bin sparc64 2.04-11
>> Jan  4 19:00:04 in-target:   503  Backend unavailable, connection
>> timeout [IP: 2a04:4e42:58::644 80]
>> Jan  4 19:00:04 in-target: Get:3 http://deb.debian.org/debian-ports
>> sid/main sparc64 grub-ieee1275 sparc64 2.04-11 [542 kB]
>> Jan  4 19:00:05 in-target: Fetched 1261 kB in 4s (316 kB/s)
>> Jan  4 19:00:05 in-target: E
>> Jan  4 19:00:05 in-target: :
>> Jan  4 19:00:05 in-target: Failed to fetch
>> http://deb.debian.org/debian-ports/pool-sparc64/main/g/grub2/grub-ieee1275-bin_2.04-11_sparc64.deb
>>  503  Backend unavailable, connection timeout [IP: 2a04:4e42:58::644 80]
>> Jan  4 19:00:05 in-target:
>> Jan  4 19:00:05 in-target: E
>> Jan  4 19:00:05 in-target: :
>> Jan  4 19:00:05 in-target: Unable to fetch some archives, maybe run
>> apt-get update or try with --fix-missing?
>> Jan  4 19:00:05 in-target:
>> Jan  4 19:00:05 grub-installer: info: Calling 'apt-install
>> grub-ieee1275' failed
> 
> I have no clue which image you used and I'm not sure what you did to end up 
> in a situation
> where the installer would try to download the grub2 packages over the net 
> which are actually
> on the installation ISO, so they don't have to be downloaded.
> 
> I also just verified that by installing the latest sparc64 ISO inside an LDOM 
> in offline mode
> and grub2 was installed without any issues with no package mirror being set 
> up.


I am doing a re-install with the "default" installer and I choose the
most trivial config options. Which is to say the partition options were
whatever seems most trivial. Full disk. New partition table. Everything
in one partition.  The default seems to be 512MB ext2 bootable /boot and
then a large slice and 1G of swap.

Eventually I see a big red box :

[!!] Configure the package manager
apt configuration problem
An attempt to configure apt to install additional packages from the
media failed.

Here I select "continue" and things seem to move along.

Then, after a little while everything seems to just work neatly.

I guess there is something oddball in the expert level menu option but
we don't really test for that. OKay, this works in the easy mode option.


-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

Re: grub-installer: info: Calling 'apt-install grub-ieee1275' failed

[John Paul Adrian Glaubitz]

On 1/9/21 2:33 PM, Dennis Clarke wrote:
> May be possibly because I always use the "expert mode" option in the
> installer. That allows me to setup the network without DHCP.

Manual networking setup also works in normal mode. It will try DHCP first,
then fail and then offer manual configuration.

> I will try again with the default trivial installer.

Yes, please try to avoid the expert installer. It's an untested code path.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: grub-installer: info: Calling 'apt-install grub-ieee1275' failed

[Dennis Clarke]

On 1/9/21 1:12 AM, John Paul Adrian Glaubitz wrote:
> On 1/9/21 1:53 AM, Dennis Clarke wrote:
>>
>> I think this is pretty much well known but I will report it here
>> regardless. From the latest sparc64 installer images I eventually
>> see grub-ieee1275 fails.
>> (...)
>> Jan  4 19:00:02 in-target: Get:1 http://deb.debian.org/debian-ports
>> sid/main sparc64 grub2-common sparc64 2.04-11 [719 kB]
>> Jan  4 19:00:04 in-target: Err:2 http://deb.debian.org/debian-ports
>> sid/main sparc64 grub-ieee1275-bin sparc64 2.04-11
>> Jan  4 19:00:04 in-target:   503  Backend unavailable, connection
>> timeout [IP: 2a04:4e42:58::644 80]
>> Jan  4 19:00:04 in-target: Get:3 http://deb.debian.org/debian-ports
>> sid/main sparc64 grub-ieee1275 sparc64 2.04-11 [542 kB]
>> Jan  4 19:00:05 in-target: Fetched 1261 kB in 4s (316 kB/s)
>> Jan  4 19:00:05 in-target: E
>> Jan  4 19:00:05 in-target: :
>> Jan  4 19:00:05 in-target: Failed to fetch
>> http://deb.debian.org/debian-ports/pool-sparc64/main/g/grub2/grub-ieee1275-bin_2.04-11_sparc64.deb
>>  503  Backend unavailable, connection timeout [IP: 2a04:4e42:58::644 80]
>> Jan  4 19:00:05 in-target:
>> Jan  4 19:00:05 in-target: E
>> Jan  4 19:00:05 in-target: :
>> Jan  4 19:00:05 in-target: Unable to fetch some archives, maybe run
>> apt-get update or try with --fix-missing?
>> Jan  4 19:00:05 in-target:
>> Jan  4 19:00:05 grub-installer: info: Calling 'apt-install
>> grub-ieee1275' failed
> 
> I have no clue which image you used and I'm not sure what you did to end up 
> in a situation
> where the installer would try to download the grub2 packages over the net 
> which are actually
> on the installation ISO, so they don't have to be downloaded.
> 

I used the sparc64 netinst from
https://cdimage.debian.org/cdimage/ports/snapshots/2021-01-03/ and did
veridy the SHA512 hash.

> I also just verified that by installing the latest sparc64 ISO inside an LDOM 
> in offline mode
> and grub2 was installed without any issues with no package mirror being set 
> up.
>


May be possibly because I always use the "expert mode" option in the
installer. That allows me to setup the network without DHCP.

I will try again with the default trivial installer.

Dennis

Re: grub-installer: info: Calling 'apt-install grub-ieee1275' failed

[John Paul Adrian Glaubitz]

On 1/9/21 2:03 PM, Gregor Riepl wrote:
> The only situation where I can imagine this would happen is when the
> repositories have a newer version of the package than the installer
> image, and update to the latest version during installation is enabled
> (probably the default).

I have never run into this situation but I know that a lot of users choose
the weirdest configuration settings in debian-installer without understanding
the ramifications and then wonder why it doesn't work.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: grub-installer: info: Calling 'apt-install grub-ieee1275' failed

[Gregor Riepl]

> I have no clue which image you used and I'm not sure what you did to end up 
> in a situation
> where the installer would try to download the grub2 packages over the net 
> which are actually
> on the installation ISO, so they don't have to be downloaded.

The only situation where I can imagine this would happen is when the
repositories have a newer version of the package than the installer
image, and update to the latest version during installation is enabled
(probably the default).

Maybe try again, or with a different mirror?
This sounds very much like a temporary issue with the repo, not the
installer:

Jan  4 19:00:04 in-target:   503  Backend unavailable, connection
timeout [IP: 2a04:4e42:58::644 80]

Re: grub-installer: info: Calling 'apt-install grub-ieee1275' failed

[John Paul Adrian Glaubitz]

On 1/9/21 1:53 AM, Dennis Clarke wrote:
> 
> I think this is pretty much well known but I will report it here
> regardless. From the latest sparc64 installer images I eventually
> see grub-ieee1275 fails.
> (...)
> Jan  4 19:00:02 in-target: Get:1 http://deb.debian.org/debian-ports
> sid/main sparc64 grub2-common sparc64 2.04-11 [719 kB]
> Jan  4 19:00:04 in-target: Err:2 http://deb.debian.org/debian-ports
> sid/main sparc64 grub-ieee1275-bin sparc64 2.04-11
> Jan  4 19:00:04 in-target:   503  Backend unavailable, connection
> timeout [IP: 2a04:4e42:58::644 80]
> Jan  4 19:00:04 in-target: Get:3 http://deb.debian.org/debian-ports
> sid/main sparc64 grub-ieee1275 sparc64 2.04-11 [542 kB]
> Jan  4 19:00:05 in-target: Fetched 1261 kB in 4s (316 kB/s)
> Jan  4 19:00:05 in-target: E
> Jan  4 19:00:05 in-target: :
> Jan  4 19:00:05 in-target: Failed to fetch
> http://deb.debian.org/debian-ports/pool-sparc64/main/g/grub2/grub-ieee1275-bin_2.04-11_sparc64.deb
>  503  Backend unavailable, connection timeout [IP: 2a04:4e42:58::644 80]
> Jan  4 19:00:05 in-target:
> Jan  4 19:00:05 in-target: E
> Jan  4 19:00:05 in-target: :
> Jan  4 19:00:05 in-target: Unable to fetch some archives, maybe run
> apt-get update or try with --fix-missing?
> Jan  4 19:00:05 in-target:
> Jan  4 19:00:05 grub-installer: info: Calling 'apt-install
> grub-ieee1275' failed

I have no clue which image you used and I'm not sure what you did to end up in 
a situation
where the installer would try to download the grub2 packages over the net which 
are actually
on the installation ISO, so they don't have to be downloaded.

I also just verified that by installing the latest sparc64 ISO inside an LDOM 
in offline mode
and grub2 was installed without any issues with no package mirror being set up.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: grub-ieee1275 fails to install bootblock

[John Paul Adrian Glaubitz]

Hi Alexander!

Could you please retest with the latest ISO image for sparc64 [1] and
check whether this issue has been resolved for you now?

We have fixed a lot of issues around GRUB on sparc64, both upstream and
in Debian and I'm confident that GRUB should work now out of the box
on your UltraSPARC 45.

FWIW, there are currently some issues with 5.x on older UltraSPARC machines
but these should not affect this bug report.

If GRUB works for you on sparc64 after testing the image, please consider
closing this bug report.

Adrian

> [1] 
> https://cdimage.debian.org/cdimage/ports/2020-04-19/debian-10.0-sparc64-NETINST-1.iso

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Grub, sparc64, and compressed kernels

[Chris Ross]

On Tue, Jul 03, 2018 at 04:43:32PM -0400, Chris Ross wrote:
> [- tried to grub-install onto /dev/sda1 and /dev/sda2, won't boot, Illegal
>Instruction. -]

> So, I fear some of this is based on the fact that I'm running grub-install
> into raid filesystems that are mounted as a RAID1, but I'm sticking things
> into them at the same time.  Or maybe it's more complicated, but the fact
> that I'm writing into the raw partitions under an md RAID certainly seems
> of concern.  :-/

So I'm even more confused now.  I was unable to boot disk0 or disk1, but
also got errors booting off of disk3, which had been working.  So I booted
into rescue cd, re-ran the grub-install onto /dev/sdd1, then rebooted.
Came up fine, as before.  When it did, I did nothing but log in, then 
re-run "grub-install --force --skip-fs-probe" onto each of /dev/sda1 and
/dev/sda2, while /dev/md0 wasn't mounted.  Nothing on the first three
disks had been accessed since boot.

Sadly, this did not make those disks bootable either.  But, surprisingly,
I now can't boot off of disk3 again.  Even after a "reset-all", I see:

Boot device: disk3  File and args: 
GRUB ERROR: Last Trap: Illegal Instruction

So, I've no idea how merely running grub-install onto /dev/sda1 and
/dev/sdb1 could possibly have messed up the grub on /dev/sdd1?  I am booting
into rescue cd again now to repair that, but I'm starting to feel that
grub is acting for some evil spirit and I am failing to meet whatever
it's needs are....

- Chris

ps, re-grub-install'ing to /dev/sdd1 allowed the system to boot again.
I rebooted a few times, seems to have remained functional.  I also after
a few successful boots to sdd (aka disk3), tried booting from PROM to
disk0 again, got the Illegal Instruction, but was then still able to 
boot disk3.

Re: Grub, sparc64, and compressed kernels

[Chris Ross]

Sorry for the chatter on the list, all...

On Tue, Jul 03, 2018 at 04:14:18PM -0400, Chris Ross wrote:
> Adrian answered some of this before I asked the above questions:
> 
> t5120# grub-install /dev/sda1
> Installing for sparc64-ieee1275 platform.
> 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.
> t5120# grub-install --force --skip-fs-probe /dev/sda1
> Installing for sparc64-ieee1275 platform.
> 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.
> t5120# 

Okay.  So, I see the above error from grub-install, when running in the
chroot, for both /dev/sda1, _and_ for /dev/sdd1 which worked fine for the
real disks I'm running on, and booted from.  From the full machine, I can
also successfully grub-install onto /dev/sda1 (and /dev/sdb1).  I don't
know why that is different when running in the chroot onto the target area.

Rebooting now, to see if I can load a working grub from disk0, and what
it can load.  Hmm.  Okay, clearly some problems there...

Boot device: disk3  File and args: 
[halt sent]

{0} ok boot disk0
Boot device: /pci@0/pci@0/pci@2/scsi@0/disk@0  File and args: 
GRUB Loading kernel...
ERROR: /pci@0/pci@0/pci@2/scsi@0: Last Trap: Illegal Instruction

{0} ok boot disk1

Boot device: /pci@0/pci@0/pci@2/scsi@0/disk@1  File and args: 
GRUB Loading kernel
error: unable to open /pci@0/pci@0/pci@1/pci@0/pci@1/pci@0/usb@0,2/hub@4/device@
4/st.
error: unable to open /pci@0/pci@0/pci@1/pci@0/pci@1/pci@0/usb@0,2/hub@4/device@
4/st.
error: unable to open /pci@0/pci@0/pci@1/pci@0/pci@1/pci@0/usb@0,2/hub@4/device@
4/st.
error: unable to open /pci@0/pci@0/pci@1/pci@0/pci@1/pci@0/usb@0,2/hub@4/device@
4/st.
UNKNOWN DEVICE: ieee1275//pci@0/pci@0/pci@2/scsi@0/disk@3\,0:a
error: unable to open /pci@0/pci@0/pci@1/pci@0/pci@1/pci@0/usb@0,2/hub@4/device@
4/st.
error: unable to open /pci@0/pci@0/pci@1/pci@0/pci@1/pci@0/usb@0,2/hub@4/device@
4/st.
ERROR: /pci@0: Last Trap: Fast Data Access MMU Miss

{0} ok boot disk0

Boot device: /pci@0/pci@0/pci@2/scsi@0/disk@0  File and args: 
GRUB Loading kernel...
ERROR: Last Trap: Illegal Instruction

{0} ok 

So, I fear some of this is based on the fact that I'm running grub-install
into raid filesystems that are mounted as a RAID1, but I'm sticking things
into them at the same time.  Or maybe it's more complicated, but the fact
that I'm writing into the raw partitions under an md RAID certainly seems
of concern.  :-/

Again, let me know any thoughts.  Thanks.

- Chris

Re: Grub, sparc64, and compressed kernels

[Chris Ross]

On Tue, Jul 03, 2018 at 03:37:24PM -0400, Chris Ross wrote:
> Sorry, stupid user trick.  I had mdadm and friends in the disk I was running
> on, but had _not_ installed those packages into the environment in md/ZFS
> that I chrooted into.  After installing mdadm (and the collection it brought),
> I am able to update-grub.  And grub-probe gives me the answer I'd expect:
> 
> But, I'm seeing the following if I try to grub-install:
> 
> (chroot) root@t5120# grub-install --force --skip-fs-probe /dev/md0
> Installing for sparc64-ieee1275 platform.
> 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..
> zsh: segmentation fault  grub-install --force --skip-fs-probe /dev/md0
> 
> (1) Is this supposed to work?
> (2) Assuming it's not actually installed correctly yet, booting will fail.
> Should I grub-install onto /dev/sda1 or /dev/sda2?  Whether one or both,
> won't that mess up the RAID of those devices?

Adrian answered some of this before I asked the above questions:

On Tue, Jul 03, 2018 at 09:39:56PM +0200, John Paul Adrian Glaubitz wrote:
> Well, you need to tell GRUB to install on the individual disks
> and not on the RAID (md0), this won't work - with any boot loader.
> [...]
> Don't use /dev/md0, use /dev/sd* and install on any of the disks that
> are part of the RAID. You cannot boot from /dev/md0 as the kernel needs
> to be running to be able to access the software RAID device.

Okay.  That all makes sense, thank you.  Two problems at this point
(1) The segv above.  I'm doing something wrong, but it shouldn't SEGV
(2) Installing onto /dev/sda1 doesn't work.

t5120# grub-install /dev/sda1
Installing for sparc64-ieee1275 platform.
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.
t5120# grub-install --force --skip-fs-probe /dev/sda1
Installing for sparc64-ieee1275 platform.
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.
t5120# 

Is there some other options for grub-install I'm missing?  Embedding
(grub-install /dev/sda) isn't possible with sun partition labels, but the
above message suggests that embedding is required for RAID install.

Thanks...

 - Chris

Re: Grub, sparc64, and compressed kernels

[John Paul Adrian Glaubitz]

On 07/03/2018 09:24 PM, Chris Ross wrote:
> Okay.  So, in prepping a chroot'd md/zfs environemnt on this machine, while
> updating the kernel packages, I see:
> 
> /etc/kernel/postinst.d/zz-update-grub:
> Generating grub configuration file ...
> Found linux image: /boot/vmlinuz-4.16.0-2-sparc64-smp
> Found initrd image: /boot/initrd.img-4.16.0-2-sparc64-smp
> /usr/sbin/grub-probe: error: disk `md0' not found.
> /usr/sbin/grub-probe: error: disk `md0' not found.
> /usr/sbin/grub-probe: error: disk `md0' not found.
> Found linux image: /boot/vmlinuz-4.16.0-1-sparc64-smp
> Found initrd image: /boot/initrd.img-4.16.0-1-sparc64-smp
> /usr/sbin/grub-probe: error: disk `md0' not found.
> /usr/sbin/grub-probe: error: disk `md0' not found.
> Found Debian GNU/Linux buster/sid on /dev/sdd2
> done
> 
> This leads me to the same problem I had earlier, grub (grub-probe or
> grub-install) saying "error: disk `md0' not found."  I think this is why
> I started down a path of looking for an alternative grub2.

Well, you need to tell GRUB to install on the individual disks
and not on the RAID (md0), this won't work - with any boot loader.

> Googling for this error leads me to many people that had had this error,
> sometimes an old double-free problem that isn't hitting me,
> and problems with one-disk md RAID arrays, which isn't my issue.  But I
> don't see anyone with a solution to my problem without the others.  I
> fear I just don't know what I'm looking for.

What double-free problem? That would indicate a software bug, but
this isn't a bug. You just need to tell GRUB not to use md0 as the
target block device as GRUB won't be able to map this to actual
physical disks.

> If anyone else is more familiar with using grub, and has any idea
> how to work around this current situation, I'd appreciate a pointer.
> 
> (chroot) root@t5120# grub-install --force --skip-fs-probe /dev/md0 
> Installing for sparc64-ieee1275 platform.
> grub-install: error: disk `md0' not found.
> (chroot) root@t5120# ls -l /dev/md*
> brw-rw 1 root disk  9,  0 Jul  3 14:26 /dev/md0
> crw--- 1 root root 10, 62 Jul  3 12:19 /dev/mdesc
> (chroot) root@t5120# df /boot
> Filesystem 1K-blocks  Used Available Use% Mounted on
> /dev/md0  458396 63776366432  15% /boot
> (chroot) root@t5120# 

Don't use /dev/md0, use /dev/sd* and install on any of the disks that
are part of the RAID. You cannot boot from /dev/md0 as the kernel needs
to be running to be able to access the software RAID device.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Grub, sparc64, and compressed kernels

[Chris Ross]

On Tue, Jul 03, 2018 at 03:24:12PM -0400, Chris Ross wrote:
> Okay.  So, in prepping a chroot'd md/zfs environemnt on this machine, while
> updating the kernel packages, I see:
> 
> /etc/kernel/postinst.d/zz-update-grub:
> Generating grub configuration file ...
> Found linux image: /boot/vmlinuz-4.16.0-2-sparc64-smp
> Found initrd image: /boot/initrd.img-4.16.0-2-sparc64-smp
> /usr/sbin/grub-probe: error: disk `md0' not found.
> /usr/sbin/grub-probe: error: disk `md0' not found.
> /usr/sbin/grub-probe: error: disk `md0' not found.
> Found linux image: /boot/vmlinuz-4.16.0-1-sparc64-smp
> Found initrd image: /boot/initrd.img-4.16.0-1-sparc64-smp
> /usr/sbin/grub-probe: error: disk `md0' not found.
> /usr/sbin/grub-probe: error: disk `md0' not found.
> Found Debian GNU/Linux buster/sid on /dev/sdd2
> done
> 
> This leads me to the same problem I had earlier, grub (grub-probe or
> grub-install) saying "error: disk `md0' not found."  I think this is why
> I started down a path of looking for an alternative grub2.

Sorry, stupid user trick.  I had mdadm and friends in the disk I was running
on, but had _not_ installed those packages into the environment in md/ZFS
that I chrooted into.  After installing mdadm (and the collection it brought),
I am able to update-grub.  And grub-probe gives me the answer I'd expect:

(chroot) root@t5120# grub-probe -d /dev/md0
ext2

But, I'm seeing the following if I try to grub-install:

(chroot) root@t5120# grub-install --force --skip-fs-probe /dev/md0
Installing for sparc64-ieee1275 platform.
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..
zsh: segmentation fault  grub-install --force --skip-fs-probe /dev/md0

(1) Is this supposed to work?
(2) Assuming it's not actually installed correctly yet, booting will fail.
Should I grub-install onto /dev/sda1 or /dev/sda2?  Whether one or both,
won't that mess up the RAID of those devices?

   - Chris

Re: Grub, sparc64, and compressed kernels

[Chris Ross]

On Tue, Jul 03, 2018 at 12:22:34PM -0400, Chris Ross wrote:
> I'll run with this for a bit, and respond back with questions about getting
> it installed onto software-raid partitions later.  Thanks again.

Okay.  So, in prepping a chroot'd md/zfs environemnt on this machine, while
updating the kernel packages, I see:

/etc/kernel/postinst.d/zz-update-grub:
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.16.0-2-sparc64-smp
Found initrd image: /boot/initrd.img-4.16.0-2-sparc64-smp
/usr/sbin/grub-probe: error: disk `md0' not found.
/usr/sbin/grub-probe: error: disk `md0' not found.
/usr/sbin/grub-probe: error: disk `md0' not found.
Found linux image: /boot/vmlinuz-4.16.0-1-sparc64-smp
Found initrd image: /boot/initrd.img-4.16.0-1-sparc64-smp
/usr/sbin/grub-probe: error: disk `md0' not found.
/usr/sbin/grub-probe: error: disk `md0' not found.
Found Debian GNU/Linux buster/sid on /dev/sdd2
done

This leads me to the same problem I had earlier, grub (grub-probe or
grub-install) saying "error: disk `md0' not found."  I think this is why
I started down a path of looking for an alternative grub2.

Googling for this error leads me to many people that had had this error,
sometimes an old double-free problem that isn't hitting me,
and problems with one-disk md RAID arrays, which isn't my issue.  But I
don't see anyone with a solution to my problem without the others.  I
fear I just don't know what I'm looking for.

If anyone else is more familiar with using grub, and has any idea
how to work around this current situation, I'd appreciate a pointer.

(chroot) root@t5120# grub-install --force --skip-fs-probe /dev/md0 
Installing for sparc64-ieee1275 platform.
grub-install: error: disk `md0' not found.
(chroot) root@t5120# ls -l /dev/md*
brw-rw 1 root disk  9,  0 Jul  3 14:26 /dev/md0
crw--- 1 root root 10, 62 Jul  3 12:19 /dev/mdesc
(chroot) root@t5120# df /boot
Filesystem 1K-blocks  Used Available Use% Mounted on
/dev/md0  458396 63776366432  15% /boot
(chroot) root@t5120# 

Thanks.

- Chris

Re: Grub, sparc64, and compressed kernels

[Chris Ross]

On Tue, Jul 03, 2018 at 12:04:09PM -0400, Chris Ross wrote:
> It sounds from Eric like the grub I built from him doesn't want to deal with
> gzip.  But the one shipping (2.02+dfsg1-4) does?  Well, easy enough to try
> that on the same disk to see.  But, I presume I will face the same problem
> with it not being willing to install onto md0.  I'll face that later.
> 
> Back shortly with data on Debian's grub 2.02+dfsg1-4 results.

Okay.  Took me a couple attempts, and the grub 2.02+ is a lot more alarming
in what it says:

% sudo grub-install --force --skip-fs-probe /dev/sdd1
Installing for sparc64-ieee1275 platform.
grub-install: warning: Discarding improperly nested partition 
(hostdisk//dev/sdd,sun1,sun2).
grub-install: warning: Discarding improperly nested partition 
(hostdisk//dev/sdd,sun1,sun4).
grub-install: warning: Discarding improperly nested partition 
(hostdisk//dev/sdd,sun1,sun5).
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.
% 

But, after getting that installed, the machine rebooted with the default
(vmlinuz, gzip'd) kernel.  Thought i do notice before it puts up the initial
boot menu:

Boot device: disk3  File and args: 
GRUB Loading kernel
error: out of memory.
error: no suitable video mode found.

...then the screen clears and shows the boot menu, and when left alone to
boot the default kernel, it succeeds.  So, I'm curious to read the conversation
spawned by your comment back on the bug I'd opened in grub2-sparc in github.

I'll run with this for a bit, and respond back with questions about getting
it installed onto software-raid partitions later.  Thanks again.

- Chris

Re: Grub, sparc64, and compressed kernels

[Chris Ross]

On Tue, Jul 03, 2018 at 05:46:18PM +0200, John Paul Adrian Glaubitz wrote:
> Hi Chris!
> 
> Any reason why you aren't just using the normal Debian procedure to setup
> and install GRUB?

Well, IIRC, because it wasn't working for me.  But, I must admit, I'm not 100%
sure I tried that on the simple disk.  I know I was having no luck getting it
installed on md0 when I tried, and eventually punted back to trying on sdd
just to get something working.  I am no longer 100% sure I hadn't already
switched to trying https://github.com/esnowberg/grub2-sparc/ before that.

> Debian stores its kernel compressed by default and I don't see how this is
> supposed to be a problem. All SPARCs that we have installed with Debian
> for sparc64 are using the grub2 package from Debian with a compressed
> kernel.

It sounds from Eric like the grub I built from him doesn't want to deal with
gzip.  But the one shipping (2.02+dfsg1-4) does?  Well, easy enough to try
that on the same disk to see.  But, I presume I will face the same problem
with it not being willing to install onto md0.  I'll face that later.

Back shortly with data on Debian's grub 2.02+dfsg1-4 results.

- Chris

Re: Grub, sparc64, and compressed kernels

[John Paul Adrian Glaubitz]

Hi Chris!

On 07/03/2018 05:38 PM, Chris Ross wrote:
> As I was mentioning in other threads, I was getting grub installed onto the
> "normal" sun-labeled ext2/4 partitioned disk in my T5120.  Working with
> Eric (https://github.com/esnowberg/grub2-sparc/issues/14) he helped me
> figure out that grub wasn't working because the kernel in /boot was gzip'd.

Any reason why you aren't just using the normal Debian procedure to setup
and install GRUB?

> Is there something that's told Debian that I want my kernels in /boot to be
> gzip'd?  Is there a way to make it _not_ do that, since grub apparently
> needs them not to be gzip'd on this machine?

Debian stores its kernel compressed by default and I don't see how this is
supposed to be a problem. All SPARCs that we have installed with Debian
for sparc64 are using the grub2 package from Debian with a compressed
kernel.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: GRUB is now the default bootloader on sparc64

[Chris Ross]

On Fri, May 18, 2018 at 01:44:45PM +0200, John Paul Adrian Glaubitz wrote:
> Hi!
> 
> I have now disabled SILO support in debian-installer meaning that
> it's no longer possible to install the SILO bootloader when installing
> Debian on sparc64.
> 
> [...]
> 
> GRUB is fully supported on sparc64 and, from the various feedback we got
> on the mailing list, should be compatible with even the oldest UltraSPARC
> machines. So it will work on any machine that run Debian's sparc64 port.

Hello Adrian, all.  I have been working on getting grub2 running as a step
in getting my t5120 running, as the list has been hearing from me.  I was/am
building from https://github.com/esnowberg/grub2-sparc, using the guide
https://github.com/esnowberg/grub2-sparc/wiki.  But, this makes me wonder,
what is it you've included in the installer if the core grub2 code is not
yet inclusive of these changes?  (I did try to use the grub2 2.02++ that
was on the host, but wasn't able to get it to install, and shifted to the
above.)

Thanks.  I have enough balls in the air on this machine that I'm starting to
think I might be better starting from scratch with grub2 now the default.
I don't know where to find built ISO's since approximately the date of this
email, so I want to ensure the above is effective in an ISO before trying
to reinstall from such.

- Chris

Re: GRUB is now the default bootloader on sparc64

[John Paul Adrian Glaubitz]

On 07/02/2018 05:17 AM, Chris Ross wrote:
> Hello Adrian, all.  I have been working on getting grub2 running as a step
> in getting my t5120 running, as the list has been hearing from me.  I was/am
> building from https://github.com/esnowberg/grub2-sparc, using the guide
> https://github.com/esnowberg/grub2-sparc/wiki.  But, this makes me wonder,
> what is it you've included in the installer if the core grub2 code is not
> yet inclusive of these changes?  (I did try to use the grub2 2.02++ that
> was on the host, but wasn't able to get it to install, and shifted to the
> above.)

All the sparc64-related changes in GRUB that Debian is carrying in a local
patch have already been upstreamed, they are part of the master git repository
of GRUB:

> http://git.savannah.gnu.org/cgit/grub.git

However, the current released version of GRUB - 2.02 - does not contain
the changes yet, they will be part of GRUB 2.04. That's why Debian's grub2
package is still carrying an additional sparc64 patch. This patch will
be dropped once 2.04 has been released and uploaded to Debian.

> Thanks.  I have enough balls in the air on this machine that I'm starting to
> think I might be better starting from scratch with grub2 now the default.
> I don't know where to find built ISO's since approximately the date of this
> email, so I want to ensure the above is effective in an ISO before trying
> to reinstall from such.

The image found here should be fine and should install GRUB as the default
bootloader on sparc64:

> https://cdimage.debian.org/cdimage/ports/10.0/sparc64/iso-cd/

It might be though that both the grub-installer and partman-auto 
debian-installer
packages are not up-to-date in this ISO yet which might lead to smaller issues.

I will build updated images soonish.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Re: GRUB testers on SPARC needed

[Hermann Lauer]

On Mon, Mar 05, 2018 at 11:45:16AM +0100, John Paul Adrian Glaubitz wrote:
> > 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
> supported by the grub-installer:
> 
> > 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.

> > 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.

> > 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: hermann.la...@iwr.uni-heidelberg.de

Re: Re: GRUB testers on SPARC needed

[Hermann Lauer]

On Sat, Mar 03, 2018 at 01:09:40AM +0100, John Paul Adrian Glaubitz wrote:
> On 03/02/2018 10:27 PM, Frank Scheiner wrote:
> >> On x86, it will automatically use GPT if the machine is booted in EFI 
> >> mode. ...
...
> >> 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.
...
> 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: hermann.la...@iwr.uni-heidelberg.de

Re: GRUB testers on SPARC needed

[John Paul Adrian Glaubitz]

On 03/05/2018 11:32 AM, Hermann Lauer wrote:

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
supported by the grub-installer:


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 - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: GRUB testers on SPARC needed

[John Paul Adrian Glaubitz]

On 03/02/2018 10:27 PM, Frank Scheiner wrote:
>> 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.

>> 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 - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: GRUB testers on SPARC needed

[Frank Scheiner]

On 03/02/2018 10:10 PM, John Paul Adrian Glaubitz wrote:

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.




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.




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.

Re: GRUB testers on SPARC needed

[John Paul Adrian Glaubitz]

> On Mar 2, 2018, at 9:53 PM, Frank Scheiner  wrote:
> 
> 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 `) 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

Re: GRUB testers on SPARC needed

[Frank Scheiner]

Hi Adrian,

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 
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 
800100497648 (rpc 800100308f74) sp 07feff91a961 error 1 in 
libc.so.6[80010041+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 SizeFile system Name  Flags
1   1049kB  7340kB  6291kBbios_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?



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




This information should be used here:

https://anonscm.debian.org/git/d-i/grub-installer.git/tree/grub-installer#n628 



and here:

https://anonscm.debian.org/git/d-i/grub-installer.git/tree/grub-installer#n853 



and here:

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 `) 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

Re: GRUB testers on SPARC needed

[John Paul Adrian Glaubitz]

On 02/27/2018 11:42 AM, John Paul Adrian Glaubitz wrote:

I am building a new installer image necessary to work on this.


Image here:


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 - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: GRUB testers on SPARC needed

[John Paul Adrian Glaubitz]

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.

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

This information should be used here:


https://anonscm.debian.org/git/d-i/grub-installer.git/tree/grub-installer#n628


and here:


https://anonscm.debian.org/git/d-i/grub-installer.git/tree/grub-installer#n853


and here:


https://anonscm.debian.org/git/d-i/grub-installer.git/tree/grub-installer#n867


For the different invocations of grub-install on Sun and GPT partition tables, 
see:


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 - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: GRUB testers on SPARC needed

[Frank Scheiner]

On 02/23/2018 11:38 PM, John Paul Adrian Glaubitz wrote:

On 02/23/2018 11:37 PM, John Paul Adrian Glaubitz wrote:

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: /pci@83,4000/network@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.58] PROMLIB: Sun IEEE Boot Prom 'OBP 3.18.1 2006/01/23 17:06'
[0.67] PROMLIB: Root node compatible: sun4us
[0.000259] Linux version 4.15.0-1-sparc64-smp 
(debian-ker...@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 0xf800 (max_phys_bits == 40)
[0.508875] MM: VMALLOC [0x0001 --> 0x0600]
[0.583726] MM: VMEMMAP [0x0600 --> 0x0c00]
[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

Re: GRUB testers on SPARC needed

[John Paul Adrian Glaubitz]

On 02/23/2018 11:37 PM, John Paul Adrian Glaubitz wrote:
> 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 - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: GRUB testers on SPARC needed

[John Paul Adrian Glaubitz]

On 02/19/2018 10:26 AM, Frank Scheiner wrote:
> 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:

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 - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: GRUB testers on SPARC needed

[txt.file]

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

John Paul Adrian Glaubitz:
> Hello!
> 
> On 02/19/2018 10:26 AM, Frank Scheiner wrote:
>> 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:
> 
> 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
> 
>> @Adrian:
>> 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
> 



signature.asc
Description: OpenPGP digital signature

Re: GRUB testers on SPARC needed

[Frank Scheiner]

Hi,

On 02/19/2018 02:37 PM, John Paul Adrian Glaubitz wrote:
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:


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.



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

Re: GRUB testers on SPARC needed

[John Paul Adrian Glaubitz]

Hello!

On 02/19/2018 10:26 AM, Frank Scheiner wrote:

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:


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


@Adrian:
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 - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: GRUB testers on SPARC needed

[Frank Scheiner]

On 12/08/2017 01:24 PM, John Paul Adrian Glaubitz wrote:

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

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


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

Re: GRUB testers on SPARC needed

[louis ayotte]

Tested on a Sparc Ultra 10 workstation and it boots fine using your 
instructions.

Had to use an image from 2016 as the newer ones from september and december 
2017 did not work at all(both fail during installation).

Lshw

ultra
     description: Computer
     product: SUNW,375-0066
     width: 64 bits
   *-core
    description: Motherboard
    physical id: 0
    clock: 110MHz
  *-firmware
   product: SUNW,3.31
   physical id: 0
   logical name: /proc/device-tree
  *-memory
   description: System memory
   physical id: 2
   size: 740MiB
  *-cpu
   physical id: 3
   bus info: cpu@0
  *-pci:0
   description: PCI bridge
   product: Simba Advanced PCI Bridge
   vendor: Oracle/SUN
   physical id: 1
   bus info: pci@:00:01.0
   version: 13
   width: 32 bits
   clock: 66MHz
   capabilities: pci normal_decode bus_master
   resources: ioport:0(size=12582912) memory:1ff-1ffbfff
     *-usb:0
  description: USB controller
  product: VT82xx/62xx UHCI USB 1.1 Controller
  vendor: VIA Technologies, Inc.
  physical id: 1
  bus info: pci@:02:01.0
  version: 61
  width: 32 bits
  clock: 33MHz
  capabilities: pm uhci bus_master cap_list
  configuration: driver=uhci_hcd latency=22
  resources: irq:15 ioport:400(size=32)
    *-usbhost
     product: UHCI Host Controller
     vendor: Linux 4.14.0-3-sparc64 uhci_hcd
     physical id: 1
     bus info: usb@2
     logical name: usb2
     version: 4.14
     capabilities: usb-1.10
     configuration: driver=hub slots=2 speed=12Mbit/s
     *-usb:1
  description: USB controller
  product: VT82xx/62xx UHCI USB 1.1 Controller
  vendor: VIA Technologies, Inc.
  physical id: 1.1
  bus info: pci@:02:01.1
  version: 61
  width: 32 bits
  clock: 33MHz
  capabilities: pm uhci bus_master cap_list
  configuration: driver=uhci_hcd latency=22
  resources: irq:16 ioport:420(size=32)
    *-usbhost
     product: UHCI Host Controller
     vendor: Linux 4.14.0-3-sparc64 uhci_hcd
     physical id: 1
     bus info: usb@3
     logical name: usb3
     version: 4.14
     capabilities: usb-1.10
     configuration: driver=hub slots=2 speed=12Mbit/s
     *-usb:2
  description: USB controller
  product: USB 2.0
  vendor: VIA Technologies, Inc.
  physical id: 1.2
  bus info: pci@:02:01.2
  version: 63
  width: 32 bits
  clock: 33MHz
  capabilities: pm ehci bus_master cap_list
  configuration: driver=ehci-pci latency=22
  resources: irq:17 memory:1ff2000-1ff20ff
    *-usbhost
     product: EHCI Host Controller
     vendor: Linux 4.14.0-3-sparc64 ehci_hcd
     physical id: 1
     bus info: usb@1
     logical name: usb1
     version: 4.14
     capabilities: usb-2.00
     configuration: driver=hub slots=4 speed=480Mbit/s
     *-firewire
  description: FireWire (IEEE 1394)
  product: VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller
  vendor: VIA Technologies, Inc.
  physical id: 1.3
  bus info: pci@:02:01.3
  version: 46
  width: 32 bits
  clock: 33MHz
  capabilities: pm ohci bus_master cap_list
  configuration: driver=firewire_ohci latency=0 maxlatency=32
  resources: irq:15 memory:1ff4000-1ff47ff
ioport:480(size=128)
     *-multimedia UNCLAIMED
  description: Multimedia audio controller
  product: EMU10k1 [Sound Blaster Live! Series]
  vendor: Creative Labs
  physical id: 2
  bus info: pci@:02:02.0
  version: 07
  width: 32 bits
  clock: 33MHz
  capabilities: pm cap_list
  configuration: latency=0 maxlatency=20 mingnt=2
  resources: ioport:800(size=32)
     *-input UNCLAIMED
  description: Input device controller
  product: SB Live! Game Port
  vendor: Creative Labs
  physical id: 2.1
  bus info: pci@:02:02.1
  version: 07
  width: 32 bits
  clock: 33MHz
  capabilities: pm cap_list
  

Re: GRUB testers on SPARC needed

[Frank Scheiner]

Hi Adrian, hi Eric, 

thanks for getting GRUB2 with support for sparc64 into Debian Ports. 
Looks very good so far. :-D


On 12/08/2017 01:24 PM, John Paul Adrian Glaubitz wrote:

root@andi:~#

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//pci@1f\,4000/scsi@3/disk@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:00 33.9G  0 disk
├─sda1   8:10 94.1M  0 part /boot
├─sda2   8:20 22.3G  0 part /
├─sda3   8:30 33.9G  0 part
└─sda4   8:40 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 

Re: GRUB testers on SPARC needed

[txt.file]

I tested it on a SunFire V440 and it is booting. I plan to test it also
on a Sun Netra T1.

root@txt-sunfire-v440:~# lsblk
NAME  MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda 8:00 67.9G  0 disk
├─sda1  8:10 94.1M  0 part /boot
├─sda2  8:20 67.8G  0 part
│ ├─txt--sunfire--v440--vg-root   254:00 11.7G  0 lvm  /
│ ├─txt--sunfire--v440--vg-swap_1 254:10  7.7G  0 lvm  [SWAP]
│ ├─txt--sunfire--v440--vg-var254:20  4.2G  0 lvm  /var
│ ├─txt--sunfire--v440--vg-tmp254:30  800M  0 lvm  /tmp
│ └─txt--sunfire--v440--vg-home   254:40 43.5G  0 lvm  /home
└─sda3  8:30 67.9G  0 part
sr011:01 1024M  0 rom
root@txt-sunfire-v440:~#

kind regards
txt.file

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.
> 
> 1. Install the grub2 package:
> 
> root@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) ...
> root@andi:~#
> 
> 2. Make sure you have version 2.02-2+sparc64.3
> 
> root@andi:~# apt-cache show grub2 |grep Version
> Version: 2.02-2+sparc64.3
> root@andi:~#
> 
> 3. Find your boot partition:
> 
> root@andi:~# mount |grep /boot
> /dev/sda1 on /boot type ext3 (rw,relatime,data=ordered)
> root@andi:~#
> 
> If you don't have one but just one root file system, grep for " / " instead
> 
> 4. Install grub into your boot partition:
> 
> root@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.
> root@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:
> 
> root@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
> root@andi:~#
> 

Re: GRUB testers on SPARC needed

[John Paul Adrian Glaubitz]

Hi Tony!

On 12/16/2017 09:45 AM, Tony Rodriguez wrote:
> 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 - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: GRUB testers on SPARC needed

[Tony Rodriguez]

FYI, as requested, successfully installed Debian 9 using grub2 on my sun 
T5120 and T4-2.


Tony Rodriguez

On 12/08/2017 04:24 AM, John Paul Adrian Glaubitz wrote:

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:

root@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) ...
root@andi:~#

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

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

3. Find your boot partition:

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

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

4. Install grub into your boot partition:

root@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.
root@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:

root@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
root@andi:~#

6. Reboot:

root@andi:~#

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

Thanks,
Adrian

Re: GRUB testers on SPARC needed

[Mark Morgan Lloyd]

On 11/12/17 22:00, Frans van Berckel wrote:

Hi Mark,

On Mon, 2017-12-11 at 21:23 +, Mark Morgan Lloyd wrote:


On 08/12/17 12:30, John Paul Adrian Glaubitz wrote:


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]

Re: GRUB testers on SPARC needed

[Frans van Berckel]

Hi Mark,

On Mon, 2017-12-11 at 21:23 +, Mark Morgan Lloyd wrote:

> On 08/12/17 12:30, John Paul Adrian Glaubitz wrote:
> 
> > 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

Re: GRUB testers on SPARC needed

[Mark Morgan Lloyd]

On 08/12/17 12:30, John Paul Adrian Glaubitz wrote:


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]

Re: GRUB testers on SPARC needed

[Frans van Berckel]

On Fri, 2017-12-08 at 14:37 +0100, Frans van Berckel wrote:

> On Fri, 2017-12-08 at 14:28 +0100, John Paul Adrian Glaubitz wrote:
> > 
> > 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

Re: GRUB testers on SPARC needed

[John Paul Adrian Glaubitz]

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

> On Dec 8, 2017, at 4:27 PM, Tony Rodriguez  wrote:
> 
> 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
> 
>> On 12/08/2017 05:27 AM, Frans van Berckel wrote:
>> Hi Adrian,
>> 
>>> On Fri, 2017-12-08 at 13:24 +0100, John Paul Adrian Glaubitz wrote:
>>> 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
>> 
>> NAMEMAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
>> sda   8:00 136.7G  0 disk
>> ├─sda18:10 902.1M  0 part  /boot
>> ├─sda28:20 135.9G  0 part
>> │ └─md0   9:00 135.7G  0 raid1 /
>> └─sda38:30 136.7G  0 part
>> sdb   8:16   0 136.7G  0 disk
>> ├─sdb18:17   0 902.1M  0 part
>> ├─sdb28:18   0 135.9G  0 part
>> │ └─md0   9:00 135.7G  0 raid1 /
>> └─sdb38:19   0 136.7G  0 part
>> sdc   8:32   0  33.9G  0 disk
>> ├─sdc18:33   030G  0 part
>> │ └─md1   9:1030G  0 raid1 /home
>> └─sdc28:34   0   3.9G  0 part  [SWAP]
>> sdd   8:48   0  33.9G  0 disk
>> ├─sdd18:49   030G  0 part
>> │ └─md1   9:1030G  0 raid1 /home
>> └─sdd28:50   0   3.9G  0 part  [SWAP]
>> sr0  11:01 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
>> 

Re: GRUB testers on SPARC needed

[Tony Rodriguez]

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

On 12/08/2017 05:27 AM, Frans van Berckel wrote:

Hi Adrian,

On Fri, 2017-12-08 at 13:24 +0100, John Paul Adrian Glaubitz wrote:

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

NAMEMAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda   8:00 136.7G  0 disk
├─sda18:10 902.1M  0 part  /boot
├─sda28:20 135.9G  0 part
│ └─md0   9:00 135.7G  0 raid1 /
└─sda38:30 136.7G  0 part
sdb   8:16   0 136.7G  0 disk
├─sdb18:17   0 902.1M  0 part
├─sdb28:18   0 135.9G  0 part
│ └─md0   9:00 135.7G  0 raid1 /
└─sdb38:19   0 136.7G  0 part
sdc   8:32   0  33.9G  0 disk
├─sdc18:33   030G  0 part
│ └─md1   9:1030G  0 raid1 /home
└─sdc28:34   0   3.9G  0 part  [SWAP]
sdd   8:48   0  33.9G  0 disk
├─sdd18:49   030G  0 part
│ └─md1   9:1030G  0 raid1 /home
└─sdd28:50   0   3.9G  0 part  [SWAP]
sr0  11:01 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

Re: GRUB testers on SPARC needed

[Frans van Berckel]

On Fri, 2017-12-08 at 14:28 +0100, John Paul Adrian Glaubitz wrote:

> On 12/08/2017 02:27 PM, Frans van Berckel wrote:

> > 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 ...
> 
> 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

Re: GRUB testers on SPARC needed

[John Paul Adrian Glaubitz]

On 12/08/2017 02:27 PM, Frans van Berckel wrote:

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 ...


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 - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: GRUB testers on SPARC needed

[Frans van Berckel]

Hi Adrian,

On Fri, 2017-12-08 at 13:24 +0100, John Paul Adrian Glaubitz wrote:
> 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

NAMEMAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda   8:00 136.7G  0 disk  
├─sda18:10 902.1M  0 part  /boot
├─sda28:20 135.9G  0 part  
│ └─md0   9:00 135.7G  0 raid1 /
└─sda38:30 136.7G  0 part  
sdb   8:16   0 136.7G  0 disk  
├─sdb18:17   0 902.1M  0 part  
├─sdb28:18   0 135.9G  0 part  
│ └─md0   9:00 135.7G  0 raid1 /
└─sdb38:19   0 136.7G  0 part  
sdc   8:32   0  33.9G  0 disk  
├─sdc18:33   030G  0 part  
│ └─md1   9:1030G  0 raid1 /home
└─sdc28:34   0   3.9G  0 part  [SWAP]
sdd   8:48   0  33.9G  0 disk  
├─sdd18:49   030G  0 part  
│ └─md1   9:1030G  0 raid1 /home
└─sdd28:50   0   3.9G  0 part  [SWAP]
sr0  11:01 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

Re: grub

[Robert Wolfe {MCP}]

On Fri, 03 Jun 2005 08:17:29 +0200
Andreas Schindler [EMAIL PROTECTED] wrote:

 Martín Marqués wrote:
  Why isn't there a version of grub for Linux SPARC?
  
 Because SILO is much better ;-)

Heh heh :)  Which reminds me, is thhe Sparc version of 3.0r6 out already?  I am 
running 3.0r5 on an Ultra 5 right now and I THINK I have all the updates since 
I run both apt-get update and apt-get upgrade on almost a daily basis.

Re: grub

[Frans Pop]

On Thursday 02 June 2005 14:03, Martín Marqués wrote:
 Why isn't there a version of grub for Linux SPARC?

Because Sparc uses the SUN disklabel for boot disks and not the msdos 
disklabel and grub does not support the SUN disklabel.

Cheers,
FJP


pgpAp9WdshQCk.pgp
Description: PGP signature