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&DEFAULTOP=or&B=Gdebian-sparc&SORT=&HITSPERPAGE=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&id=f2b38f03a3f71c30c77a4516b26c8bea13cc08ce

> Running on the v215 was a real nightmare yesterday. They will be stable for 
> hours, but
> certain actions (in one occurence executing dmesg (!), apt-get installing 
> nfs-common,
> some mounts systemd tries) crashed both of the boxes with various errors, 
> most of them the
> dreaded line with "p

Try to use a 4.19 kernel from snapshot.debian.org, these are known to run more 
stable on the
older machines. Any machine older than T2 seem to have some issues with the 
more recent kernels.

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

On the newer CPUs (>= SPARC T2), the kernel runs stable. Dave Miller (the Linux 
SPARC maintainer)
uses a T5 himself for testing.

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

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: 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
  configurati

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 se

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