Re: M4000 failing to boot Debian Sparc64

[Frank Scheiner]

Hi,

On 02.07.23 16:35, Vocalía Infraestructura TIC CEEINA wrote:

Hi Frank,

Thank you for your fast answer. I also thought when installing that it 
was an incompatibility problem with the processor architecture, as you 
stated.


However, having a look at the wiki (https://wiki.debian.org/Sparc64 
) it seems to me that machines with a 
sun4u SPARC VII+ processor should be able to run it, right? Our M4000 
has a VII+ processor.


Can you post the kernel messages for your boot, so we can reference it 
in the Debian Wiki? Maybe by comparing them to what was posted about a 
M3000 with SPARC64 VII on [1] and SPARC64 V on [2], we can conclude if 
support for SPARC64 VII+ is any better than for those other processors.


[1]: 
https://oss.oracle.com/pipermail/linux-sparc-users/2017-October/27.html


[2]: https://lists.debian.org/debian-sparc/2017/09/msg00017.html

You don't happen to have a SPARC64 X based system for testing? I think I 
never saw a dmesg from such a system, too.


Maybe I have not fully understood the wiki or your message, therefore 
sorry if I'm wrong.


I went through the history of changes and the one that adds the 
information about SPARC64 processors ([3]) was done by an Alex McWhirter.


[3]: https://wiki.debian.org/Sparc64?action=diff=25=26

Checking my email archive I actually even asked him (via 
alexmcwhir...@triadic.us, though not sure if that is the correct 
address) exactly about this change, but never got a reply IIRC.


Cheers,
Frank

Re: M4000 failing to boot Debian Sparc64

[Frank Scheiner]

Hi,

On 02.07.23 12:35, Vocalía Infraestructura TIC CEEINA wrote:

Hi,

We are trying to boot Debian Sparc64 on a SPARC Enterprise M4000 server 
(SPARC64 VII+), but, after selecting normal / expert / secure install 
mode, we get this error message and the installer quits:


/ERROR: Last Trap: Division by Zero/
/%TL:1 %TT:28 %TPC:43056c %TnPC:430570 %TSTATE:1180001603/
/%PSTATE:16 ( IE:1 PRIV:1 PEF:1 )/


We have tried with the following ISO images: 
/debian-12.0.0-sparc64-NETINST-1.iso/, 
/debian-10.0-sparc64-NETINST-1.iso/ and /debian-9.0-sparc64-NETINST-1.iso/.


Maybe this is an unknown incompatibility, or we are missing some steps 
when installing.


No, it just does not work on those machines. E.g. the only thing that 
works on e.g. SPARC64 V (tested on a PRIMEPOWER 250) is GRUB2.


AFAIK the Linux kernel only works (fully) on Sun's (Ultra)SPARC (I, II, 
IIi/e, III, IIIi, IV and T)s and Fujitsu's SPARC64 X.



¿Any ideas on how to fix this? ¿Has anyone experienced something similar?


It would require some development effort. OpenBSD has support for those 
machines, though, if that could be an alternative for you.


Cheers,
Frank

Re: Updated installation images for Debian Ports 2023-06-06

[Frank Scheiner]

Hi!

On 06.06.23 16:22, John Paul Adrian Glaubitz wrote:

Hello!

On Tue, 2023-06-06 at 16:19 +0200, Frank Scheiner wrote:

On 06.06.23 15:52, John Paul Adrian Glaubitz wrote:

Hello!

I have created updated installation images for Debian Ports.

These can be found here:

- https://cdimage.debian.org/cdimage/ports/snapshots/2023-06-06/

I have already successfully tested the sparc64 installer.


On what machine did you test it?


Inside an LDOM on a SPARC-T5.


Thanks, good to know.

Cheers,
Frank

Re: Updated installation images for Debian Ports 2023-06-06

[Frank Scheiner]

Hi Adrian,

On 06.06.23 15:52, John Paul Adrian Glaubitz wrote:

Hello!

I have created updated installation images for Debian Ports.

These can be found here:

- https://cdimage.debian.org/cdimage/ports/snapshots/2023-06-06/

I have already successfully tested the sparc64 installer.


On what machine did you test it?

Cheers,
Frank

Re: USB still dies during boot on Ultra 25 with kernel 6.0.0

[Frank Scheiner]

Hi Connor,

On 17.12.22 14:51, Connor McLaughlan wrote:

Hello All,

i still have trouble with newer kernels than 5.6.0 on my Ultra25 up to
and including 6.0.0.
During boot the USB ohci-pci dies and mouse and keyboard (both Sun HW)
stop working.

I found no way to get mouse and keyboard recognized after that event,
e.g. by unloading and reloading ohci_pci and ohci_hcd and replugging
devices:
[7.421723] ohci-pci :05:1c.0: HcDoneHead not written back; disabled
[7.422034] ohci-pci :05:1c.0: HC died; cleaning up


No idea what's the problem here - I mainly use my SPARC gear via serial
console - but maybe it's worth a try to attach your keyboard and mouse
via an USB hub to one of the USB ports of the Ultra25.

Just got a few other ideas:

* Does it make a difference which USB port(s) you use for keyboard and
mouse?

* Does it make a difference with non-Sun keyboard and mouse?

* Does it work with just the keyboard?

* If your mouse is attached via the keyboard, does it make a difference
to put both keyboard and mouse and separate ports?

* Does the above also happen when you start-up w/o keyboard and mouse?

Cheers,
Frank

Re: unable to install (upgrade) git - git-man dependency

[Frank Scheiner]

Hi Adrian,

On 24.11.22 19:50, John Paul Adrian Glaubitz wrote:

[...]

Would be a nice surprise if this particular stability issue has been
fixed now.


Machine is still running with the 6.0.0 kernel which is definitely a
huge improvement
over the 5.x kernels which would have already crashed the machine.


Sounds great!


Guess it's time to build new installation images based on the 6.0.0
kernels then ;-).


Dito.

If Linux 6.x also makes V480 and V490 going again on GNU/Linux, this
will be early Christmas for me. :-)

Cheers,
Frank

Re: unable to install (upgrade) git - git-man dependency

[Frank Scheiner]

Hi Adrian,

On 23.11.22 16:27, John Paul Adrian Glaubitz wrote:

On 11/23/22 17:23, Riccardo Mottola wrote:

let's see how 6.0 will fare for you.


[...]
Would be a nice surprise if this particular stability issue has been
fixed now.


Indeed. I will test it with my reproducer (i.e. apt upgrade on older NFS
root FS), which so far always triggered the issue for me on USIIIi.

Cheers,
Frank

Re: unable to install (upgrade) git - git-man dependency

[Frank Scheiner]

Hi Riccardo,

On 23.11.22 17:23, Riccardo Mottola wrote:

[...]
let's see how 6.0 will fare for you.

I did try to mount nfs v3 on my system and it worked, I did a classic
mount with mount.nfs once booted. Mount works and I was able list and to
touch and remove a file. I did not try further because I didn't set up
permission properly, could do though.

Is this significative for you or is your issue NFS mount within kernel
for NFS boot and that goes through another path?


Not necessarily but I think we can conclude from this, that my T1000
might work with an initramfs build by dracut as it does not use klibc
based tools but glibc based ones ([1]) - which work as you showed above.
Standard initramfs-tools use klibc ([2]).

[1]: https://packages.debian.org/sid/dracut-core

[2]: https://packages.debian.org/sid/initramfs-tools-core

Something is bad with klibc since a while - for the DHCP case actually
since I tried for the first time years ago - on e.g. UltraSPARC T1 and
III(i) which breaks IP autoconfiguration with DHCP and NFS mounts from
within the initramfs. That's why I need to use a kernel comand line with
IP address information (+ NFS server address) hardcoded to get it going:

```
root=/dev/nfs
ip=172.16.2.137:172.16.0.2:172.16.0.1:255.255.0.0:v210:enp0s2f0:off
nfsroot=172.16.0.2:/srv/nfs/v210/root nfsrootdebug rw
```

...which is good enough for my purposes. Not been able to mount the NFS
root FS is unfortunately not. :-(

I will see for myself when I get to try Linux 6.x on my gear.

Cheers,
Frank

Re: unable to install (upgrade) git - git-man dependency

[Frank Scheiner]

Hi Riccardo

On 22.11.22 00:52, Riccardo Mottola wrote:

On 2022-11-18 10:16:07 +0100 Frank Scheiner  wrote:

IIRC in the past newer kernels (>5.9.0-2) already crashed during startup
on your T2000. "Running kernel 6.0.x" would then be already an
advancement. That gives hope for UltraSPARC IIIi (and maybe also III)
driven machines. I'll give it a try on my gear.


True... it was fixed in some 5.x series already though, I wrote back on
the list.

5.18 wored already and also 5.17 IIRC.


Good to know, looks like I missed that. Checking my logs 5.18.0-2 still
oopses on my T1000 when trying to `nfsmount` its root FS using the klibc
tools eventually making it unresponsive. So although this kernel looks
OK on your T2000, the klibc based stuff seems to be not - at least for
the NFS mounting stuff, plus DHCP using klibc tools is also broken here
IIRC.


So far Linux 6.0.x looks like a very good kernel for the extraordinaire
machines supported by Debian ports. That's really good! \o/


Yes, quite nice to see that. I'm typing this exact mail running:

Linux 6.0.0-4-sparc64-smp #1 SMP Debian 6.0.8-1 (2022-11-11) sparc64
GNU/Linux


So, try yourself on your systems.


Yeah, will do that.

Cheers,
Frank

Re: unable to install (upgrade) git - git-man dependency

[Frank Scheiner]

Hi Riccardo,

On 18.11.22 02:32, Riccardo Mottola wrote:

I fetched the older version of git-man required from
snapshot.debian.org, installed it with dpkg. Then I was able to install
git, compile stuff again and also finish upgrading. Running kernel 6.0.x
serie son the Niagara CPU now... let's see how it goes.


IIRC in the past newer kernels (>5.9.0-2) already crashed during startup
on your T2000. "Running kernel 6.0.x" would then be already an
advancement. That gives hope for UltraSPARC IIIi (and maybe also III)
driven machines. I'll give it a try on my gear.

So far Linux 6.0.x looks like a very good kernel for the extraordinaire
machines supported by Debian ports. That's really good! \o/

Cheers,
Frank

Re: Sun Ultra 45: Kernel Panic (corrupted stack end detected inside scheduler) with 5.19

[Frank Scheiner]

Hi Jake,

On 13.10.22 07:13, j...@pawlicker.com j...@pawlicker.com wrote:

I've also been able to confirm that this happens with Kernel 5.16 or at
least similar bugs do such as Unable to handle kernel NULL pointer
dereference, programs such as postgresql break dramatically, and another
time SSH panicked the system with a kernel unaligned access. This
happened during apt-get:
[...]

Try with kernel 5.9.x, or maybe better already use 4.19.x on UltraSPARC
IIIi which works OK most of the time AFAIR. You can get those from
snapshot.debian.org (e.g. [1] or [2]).

[1]:
http://snapshot.debian.org/archive/debian-ports/20190719T183113Z/pool-sparc64/main/l/linux/linux-image-4.19.0-5-sparc64_4.19.37-6_sparc64.deb

[2]:
http://snapshot.debian.org/archive/debian-ports/20190719T183113Z/pool-sparc64/main/l/linux/linux-image-4.19.0-5-sparc64-smp_4.19.37-6_sparc64.deb

...but unsure if your system will run stable enough to successfully
finish the installation. Alternatively try to reinstall with an older
ISO and work from there:

* with 5.9.0-4:
https://cdimage.debian.org/cdimage/ports/snapshots/2020-12-03/debian-10.0.0-sparc64-NETINST-1.iso

* with 4.19.0-5:
https://cdimage.debian.org/cdimage/ports/snapshots/2019-06-26/debian-10.0-sparc64-NETINST-1.iso



There seems to be a problem with UltraSPARC T1s and I strongly believe
this or another problem also affects UltraSPARC III(i)s. I have tested a
variety of processors here:

https://lists.debian.org/debian-sparc/2021/12/msg4.html

For more details on this/these issue(s) see:

https://lists.debian.org/debian-sparc/2021/03/msg00045.html

...and:

https://lists.debian.org/debian-sparc/2022/02/msg0.html

Cheers,
Frank

Re: Anyone ever tried Debian on a Fujitsu/Oracle M3000 ?

[Frank Scheiner]

Hi Betrand, Dennis,

On 13.05.22 17:32, BERTRAND Joël wrote:

Dennis Clarke a écrit :

Thus with 64G of ECC memory and four very expensive 15k rpm SAS disks
the thing is a brick.  Or is it ?

Is there any reasonable way to :


     [A] netboot Debian

     [B] toss it on a scrap heap for re-cycle


Would love to hear any input from folks who have tried.


I haven't this kind of server, but some others Sparc64. OpenBSD and
NetBSD don't run on M3000. You can test FreeBSD that supported some
SPARC64, but...


@Bertrand:
Did you actually test OpenBSD on a M3000? Because from what can be read
at [1]:

```
Supported machines
[...]
* Fujitsu SPARC Enterprise M4000/M5000/M8000/M9000
[...]
OpenBSD 4.4 may trigger a hardware fault on the SPARC Enterprise
M4000/M5000/M8000/M9000 that can only be cleared by a field engineer. A
workaround for this problem is available in OpenBSD 4.5 and later.
[...]
Unsupported machines
[...]
* Fujitsu SPARC Enterprise M3000
* Sun SPARC Enterprise M3000

OpenBSD may trigger a hardware fault on the SPARC Enterprise M3000. With
older versions of the firmware, this fault can only be cleared by a
field engineer. Make sure you update the firmware before trying to run
OpenBSD on these machines. Firmware XCP 1116 and later are known to
allow end users to clear the fault themselves. There is no evidence that
running OpenBSD actually damages the hardware.
[...]
```

It actually sounds more like OpenBSD could work on a M3000 like on a
M4000 and up. And if a recent enough firmware is running, user's can
clear the possible fault - triggered by an ancient OpenBSD 4.4? -
themselves, if need be with modern OpenBSD versions.

I don't have one of these but would assume that the hardware
configuration (chipset, etc.) of M3000 and M4000 should be close enough
to expect to run the same OS.

[1]: http://www.openbsd.org/sparc64.html

UPDATE:
Ok, I did a search for M3000 and OpenBSD and stumbled upon this thread here:

https://sparc.openbsd.narkive.com/oKF6NMGJ/hardware-fault-on-m3000

It confirms that users can clear that fault with a recent enough
firmware - well, Mark Kettenis is also the maintainer of the sparc64
port of OpenBSD - but also states that the M3000 is different to M4000
and up in handling character output on the serial console. WTF?

So maybe using a graphics card and keyboard instead of the serial
console to boot this machine could make it work with OpenBSD? Just make
sure to never output anything on the serial console... :-)



For Linux on SPARC64 (on a PRIMEPOWER 250 with SPARC64 V+ actually) you
can see how that goes on [2]. GRUB runs there and Linux even starts to
boot (incl. printout of kernel messages) but leads to a "RED State
Exception" really fast. OpenBSD runs fine on them, though.

[2]: https://lists.debian.org/debian-sparc/2018/02/msg00074.html

Cheers,
Frank

Re: 5.10.0-4-sparc64-smp #1 Debian 5.10.19-1 crashes on T2000

[Frank Scheiner]

Hi Riccardo, all,

On 17.01.22 21:35, Riccardo Mottola wrote:

Hi,


Riccardo Mottola wrote:

John Paul Adrian Glaubitz wrote:

Not nice. I started compiling some stuff and the box froze, I connected
serial console and could not resume due to Fast Data Access MMU miss"

So, this crash occurs with the latest 5.15 kernel on your T2000?

exactly latest kernel.

I will retest it with stress-ng as soon as I finish this email and copy
the dmesg errors.




wow, running the test suite once or twice, I am able to have the system
power-cycle... wow

Frank test latest kernel on yours :)


I yesterday found the time to give Linux 5.15.0-3 a try on my T1000
(UltraSPARC T1) and V210 (US IIIi), but the boot issue is still there -
at least for my use case: The klibc based tools inside of the initramfs
are not able to mount the root FS over NFS (details further below).

But it's still good to see that mounting an on-disk root FS seems to
work now for your T2000, though the instabilities during runtime are not
reassuring.

For me the last good Debian kernel - at least for booting, more on that
shortly - is 5.9.0-5. Both T1000 and V210 boot fine with it (incl.
mounting the root FS via NFS(v3 BTW)). But during operation (tested with
`apt upgrade` on a root FS replicated multiple times for testing from
the same tarball) the V210 crashes (=> kernel panic), the T1000 does
not. For the V210 I also see that for 5.8.0-3. Doing the same with
kernel 4.19.0-5 running on the V210, no problems are seen, not even the
messages below.

The crash when running 5.9.0-5 or 5.8.0-3 is usually "announced" (or at
least accompanied) by one or more occurrence(s) of the following messages:
```
[...]
[  360.489852] CPU[0]: Cheetah+ D-cache parity error at
TPC[005b28c8]
[  360.580300] TPC
[...]
```
...which should be familiar for UltraSPARC IIIi users with newer kernels
(see for example [1] which shows it for 4.16.x). According to [2] this
error should be recoverable (otherwise it would be followed by a panic
and "Irrecoverable Cheetah+ parity error."), which seems to happen,
until it is no longer, but I don't see that second message, so something
else must happen.

[1]: https://www.spinics.net/lists/sparclinux/msg21019.html

[2]:
https://github.com/torvalds/linux/blob/master/arch/sparc/kernel/traps_64.c#L1767..L1799

Of course our CPU's caches don't go pop magically. There is something
broken in the newer kernels (> 4.19.x) for UltraSPARC IIIi (and most
likely all the other related processors, too), apart from the mounting
issues for NFS (see [3] for processors affected by this, update to that:
US II is not affected, too).

[3]: https://lists.debian.org/debian-sparc/2021/12/msg4.html

If I find the time and mood I'll try to bisect this US IIIi specific
issue in the hope that we will eventually get a fix for it, also still
hoping for a fix for [4].

[4]: https://lists.debian.org/debian-sparc/2021/03/msg00045.html

Cheers,
Frank



## T1000 ##

```
[...]
[0.000116] Linux version 5.15.0-3-sparc64-smp
(debian-ker...@lists.debian.org) (gcc-11 (Debian 11.2.0-14) 11.2.0, GNU
ld (GNU Binutils for Debian) 2.37.90.20220123) #1 SMP Debian 5.15.15-2
(2022-01-30)
[...]
[   12.484314] tg3 0001:03:04.0 enP1p3s4f0: Link is up at 1000 Mbps,
full duplex
[   12.484520] tg3 0001:03:04.0 enP1p3s4f0: Flow control is on for TX
and on for RX
[   12.484689] IPv6: ADDRCONF(NETDEV_CHANGE): enP1p3s4f0: link becomes ready
[   16.765173] Unable to handle kernel paging request at virtual address
6120
[   16.765384] tsk->{mm,active_mm}->context = 006e
[   16.765493] tsk->{mm,active_mm}->pgd = 800014af
[   16.765650]   \|/  \|/
[   16.765650]   "@'/ .. \`@"
[   16.765650]   /_| \__/ |_\
[   16.765650]  \__U_/
[   16.765975] nfsmount(374): Oops [#1]
[   16.766167] CPU: 2 PID: 374 Comm: nfsmount Tainted: GE
  5.15.0-3-sparc64-smp #1  Debian 5.15.15-2
[   16.766345] TSTATE: 11001607 TPC: 006a5fe8 TNPC:
006a5fec Y: Tainted: GE
[   16.766642] TPC: 
[   16.766704] g0: 8f2e7451 g1: 0004 g2:
6000 g3: 8001fd786000
[   16.766802] g4: 800014245e80 g5: 8001fd786000 g6:
8f2e4000 g7: 8f2e7c30
[   16.766983] o0: fffe o1: 006fd714 o2:
2000 o3: 8f2cbaf8
[   16.767209] o4: 0008 o5: 0cc0 sp:
8f2e7491 ret_pc: 006fd6d4
[   16.767292] RPC: 
[   16.767456] l0: 800014398408 l1: 8001fedeaa00 l2:
00422db4 l3: 00201e00
[   16.767591] l4: 029c l5: 8001c1a0 l6:
8f2e4000 l7: 006fd660
[   16.767771] i0: 0cc0 i1: 00201ff0 i2:
0001 i3: 8f2e7dd0
[   16.767996] i4:  i5: 6120 i6:
8f2e7561 i7: 006fd714
[   16.768079] I7: 
[   16.768189] Call Trace:
[   16.768326] 

Re: 5.10.0-4-sparc64-smp #1 Debian 5.10.19-1 crashes on T2000

[Frank Scheiner]

Hi guys,

On 11.12.21 18:59, John Paul Adrian Glaubitz wrote:

On 12/11/21 18:40, Riccardo Mottola wrote:

I remember you bisected about the breaking commits. Has there been any progress?
A better place where to report this issue other than this mailing list?


The proper place is to send an email to the author of the breaking commit and
CC the sparclinux Linux kernel mailing list. Most kernel developers don't read
the debian-sparc mailing list.


We actually did discuss this in late March 2021 starting here:

https://lists.debian.org/debian-sparc/2021/03/msg00045.html

...with Christoph Hellwig and CCed to sparcli...@vger.kernel.org and
this list, but no solution back then.



Back in October I did some testing on various UltraSPARC machines to
sort out which processor( generation)s are affected but didn't found the
time to make something out of it apart from notes and a conclusion.

I couldn't get my Ultra 80 to netboot, so no result for UltraSPARC II.

My Ultra 10 with US IIi worked though with kernel 5.14.0-3.

My 280r with US III worked with kernel 5.9.0-5 and with 5.14.0-3 gives:

```
Begin: Retrying nfs mount ... mount: Invalid argument
done.
```

...when trying to mount the root FS.

My v480 crashes with 5.14.0-3 but it crashed with every kernel version I
tried since I own it, so perfectly normal. I don't know what the issue
is, because hardware-wise, the - working with 5.9.0-5 - 280r seems to be
very similar though with only 2 processors instead of 4 for the V480.

My T5220 with T2 crashed once with 5.14.0-3 but worked with 5.14.0-4. It
later also worked with 5.14.0-3. And the crash happened way before a
mount of the root FS was tried, so possibly unrelated.

My T1000 with T1 panics with 5.14.0-3 because it can't mount the root
FS. Using `break=premount` in the kernel command line and issueing the
mount command manually gives;

```
(initramfs) nfsmount -o nolock "172.16.0.2:/srv/nfs/t1000/root" "$rootmnt"
[  641.272949] Unable to handle kernel paging request at virtual address
6120
[  641.273138] tsk->{mm,active_mm}->context = 038f
[  641.273248] tsk->{mm,active_mm}->pgd = 800016c1c000
[  641.273310]   \|/  \|/
[  641.273310]   "@'/ .. \`@"
[  641.273310]   /_| \__/ |_\
[  641.273310]  \__U_/
[  641.273444] nfsmount(750): Oops [#182]
[  641.273497] CPU: 12 PID: 750 Comm: nfsmount Tainted: G  D E
   5.14.0-3-sparc64-smp #1  Debian 5.14.12-1
[  641.273603] TSTATE: 11001607 TPC: 0069ce48 TNPC:
0069ce4c Y: Tainted: G  D E
[  641.273705] TPC: 
[  641.273775] g0: 0006 g1: 0004 g2:
6000 g3: 8001fda18000
[  641.273858] g4: 800013b13340 g5: 8001fda18000 g6:
800016bd g7: 800016bd3c30
[  641.273942] o0: fffe o1: 006f4c94 o2:
2000 o3: 8000146d3aa8
[  641.274024] o4: 0008 o5: 0cc0 sp:
800016bd34a1 ret_pc: 006f4c54
[  641.274107] RPC: 
[  641.274165] l0: 00f1a000 l1: 0111f000 l2:
00422db4 l3: 00201db0
[  641.274292] l4: 029c l5: 8001c1a0 l6:
800016bd l7: 006f4be0
[  641.274377] i0: 0cc0 i1: 00201fe0 i2:
0001 i3: 800016bd3dd0
[  641.274460] i4:  i5: 6120 i6:
800016bd3561 i7: 006f4c94
[  641.274542] I7: 
[  641.274599] Call Trace:
[  641.274640] [<006f4c94>] sys_mount+0xb4/0x1a0
[  641.274712] [<006f4c54>] sys_mount+0x74/0x1a0
[  641.274783] [<00406274>] linux_sparc_syscall+0x34/0x44
[  641.274866] Caller[006f4c94]: sys_mount+0xb4/0x1a0
[  641.274939] Caller[006f4c54]: sys_mount+0x74/0x1a0
[  641.275011] Caller[00406274]: linux_sparc_syscall+0x34/0x44
[  641.275090] Caller[00100aa8]: 0x100aa8
[  641.275143] Instruction DUMP:
[  641.275150]  ba074001
[  641.275192]  bb2f7003
[  641.275233]  ba074002
[  641.275274] 
[  641.275314]  84086001
[  641.275355]  82007fff
[  641.275395]  8378841d
[  641.275436]  ba11
[  641.275525]  c2586008
[  641.275614]
Killed
```

Doing the same on a V210 with US IIIi gives:

```
(initramfs) nfsmount -o nolock "172.16.0.2:/srv/nfs/v210/root" "$rootmnt"
mount: Invalid argument
(initramfs) echo $?
1
```

...so similar to 280r with US III.

From all that, I assume UltraSPARC IIi driven machines (and most likely
also older ones with US II) are not affected by this, as are UltraSPARC
T2 driven ones and possibly machines with newer processors (I didn't
have time to try one of my T5240s with T2+).

UltraSPARC III, IIIi and T1 driven machines are affected and to me it
now looks more like some of the klibc programs from the initramfs are at
fault.

I also tested my V210 with an on-disk root FS and although the mounting
seemed to work for that method with 5.14.0-3 I faced multiple problems
later on that crashed the machine.

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: Regression in 028abd92 for Sun UltraSPARC T1

[Frank Scheiner]

On 24.03.21 17:33, Frank Scheiner wrote:

On 24.03.21 17:10, Christoph Hellwig wrote:

On Wed, Mar 24, 2021 at 04:58:39PM +0100, Frank Scheiner wrote:

[   20.090279] [<006c6494>] sys_mount+0x114/0x1e0
[   20.090338] [<006c6454>] sys_mount+0xd4/0x1e0
[   20.090499] [<00406274>] linux_sparc_syscall+0x34/0x44
[   20.090697] Disabling lock debugging due to kernel taint
[   20.090770] Caller[006c6494]: sys_mount+0x114/0x1e0
[   20.090926] Caller[006c6454]: sys_mount+0xd4/0x1e0
[   20.091133] Caller[00406274]: linux_sparc_syscall+0x34/0x44
[   20.091196] Caller[00100aa8]: 0x100aa8
[...]
```

[1]: https://pastebin.com/ApPYsMcu

Here the result for the suggested command:


Thanks.  And very strange, as i can't find what would free options
before.  Does the system boot if you comment out that kfree in line
3415 (even if that casues a memleak elsewhere).


Unfortunately not, the result with the kfree() commented in
fs/namespace.c:3415 looks pretty similar in my eyes.


Actually on second view the result looks different. :-/

Re: Regression in 028abd92 for Sun UltraSPARC T1

[Frank Scheiner]

On 24.03.21 17:10, Christoph Hellwig wrote:

On Wed, Mar 24, 2021 at 04:58:39PM +0100, Frank Scheiner wrote:

[   20.090279] [<006c6494>] sys_mount+0x114/0x1e0
[   20.090338] [<006c6454>] sys_mount+0xd4/0x1e0
[   20.090499] [<00406274>] linux_sparc_syscall+0x34/0x44
[   20.090697] Disabling lock debugging due to kernel taint
[   20.090770] Caller[006c6494]: sys_mount+0x114/0x1e0
[   20.090926] Caller[006c6454]: sys_mount+0xd4/0x1e0
[   20.091133] Caller[00406274]: linux_sparc_syscall+0x34/0x44
[   20.091196] Caller[00100aa8]: 0x100aa8
[...]
```

[1]: https://pastebin.com/ApPYsMcu

Here the result for the suggested command:


Thanks.  And very strange, as i can't find what would free options
before.  Does the system boot if you comment out that kfree in line
3415 (even if that casues a memleak elsewhere).


Unfortunately not, the result with the kfree() commented in
fs/namespace.c:3415 looks pretty similar in my eyes. Log is on [2]

[1]: https://pastebin.com/zmSFpv3R

Cheers,
Frank

Re: Regression in 028abd92 for Sun UltraSPARC T1

[Frank Scheiner]

On 24.03.21 16:22, Jan Engelhardt wrote:


On Wednesday 2021-03-24 14:57, Frank Scheiner wrote:


(gdb) l *(sys_mount+0x114/0x1e0)
0x6c6380 is in __se_sys_mount (fs/namespace.c:3390).


/0x1e0 does not normally belong there. Just

l *(sys_mount+0x114)



I guess this comes from my log on [1]:

```
[...]
[   20.089289] RPC: 
[   20.089415] l0: 8001f8885cc8 l1: 8001f8881380 l2:
8001ec434558 l3: 00201db0
[   20.089586] l4: 029c l5: 8001c1a0 l6:
8001ec79c000 l7: 006c6380
[   20.089802] i0: 1000 i1: 8001ec436000 i2:
006c6494 i3: 8001ec436000
[   20.089877] i4: 88405340 i5: 645396c0 i6:
8001ec79f561 i7: 006c6494
[   20.090051] I7: 
[   20.090186] Call Trace:
[   20.090279] [<006c6494>] sys_mount+0x114/0x1e0
[   20.090338] [<006c6454>] sys_mount+0xd4/0x1e0
[   20.090499] [<00406274>] linux_sparc_syscall+0x34/0x44
[   20.090697] Disabling lock debugging due to kernel taint
[   20.090770] Caller[006c6494]: sys_mount+0x114/0x1e0
[   20.090926] Caller[006c6454]: sys_mount+0xd4/0x1e0
[   20.091133] Caller[00406274]: linux_sparc_syscall+0x34/0x44
[   20.091196] Caller[00100aa8]: 0x100aa8
[...]
```

[1]: https://pastebin.com/ApPYsMcu

Here the result for the suggested command:
```
root@t1000:~/mnt/torvalds-linux# gdb -q vmlinux
Reading symbols from vmlinux...
(gdb) l *(sys_mount+0x114)
0x6c6494 is in __se_sys_mount (fs/namespace.c:3415).
3410if (IS_ERR(options))
3411goto out_data;
3412
3413ret = do_mount(kernel_dev, dir_name, kernel_type, flags, 
options);
3414
3415kfree(options);
3416out_data:
3417kfree(kernel_dev);
3418out_dev:
3419kfree(kernel_type);
(gdb)
```

Cheers,
Frank

Re: Regression in 028abd92 for Sun UltraSPARC T1

[Frank Scheiner]

On 24.03.21 09:28, Christoph Hellwig wrote:

On Tue, Mar 23, 2021 at 11:17:41PM +0100, Frank Scheiner wrote:

028abd9222df0cf5855dab5014a5ebaf06f90565

...is broken on my T1000.

As I don't know how big attachments can be on this list, I put the logs
on pastebin.

A log for 028abd9222df is here:

https://pastebin.com/ApPYsMcu


Just do confirm:  in this tree line 304 in mm/slub.c is this BUG_ON:

BUG_ON(object == fp); /* naive detection of double free or corruption */

which would mean we have a double free.  In that case it would be
interesting which call to kfree this is, which could be done by
calling gdb on vmlinux and then typing;

l *(sys_mount+0x114/0x1e0)

Not that a double free caused by this conversion makes any sense to me..



Finally - a T1 thread is so slow (for untaring) that I untared the
tarball from my X4270 cross-compile host to the T1000's root FS in the end:

```
root@t1000:~/mnt/torvalds-linux# git describe
v5.9-rc1-3-g028abd9222df
root@t1000:~/mnt/torvalds-linux# gdb -q vmlinux
Reading symbols from vmlinux...
(gdb) l *(sys_mount+0x114/0x1e0)
0x6c6380 is in __se_sys_mount (fs/namespace.c:3390).
3385/* ... and return the root of (sub)tree on it */
3386return path.dentry;
3387}
3388EXPORT_SYMBOL(mount_subtree);
3389
3390SYSCALL_DEFINE5(mount, char __user *, dev_name, char __user *,
dir_name,
3391char __user *, type, unsigned long, flags, void __user 
*, data)
3392{
3393int ret;
3394char *kernel_type;
(gdb)
```

...not sure if that adds anything to what Anatoly already provided apart
from the "correct" line numbers for the actually used kernel.

Cheers,
Frank

Re: Regression in 028abd92 for Sun UltraSPARC T1

[Frank Scheiner]

On 24.03.21 14:24, Anatoly Pugachev wrote:

On Wed, Mar 24, 2021 at 4:19 PM Frank Scheiner  wrote:

On 24.03.21 14:16, John Paul Adrian Glaubitz wrote:

On 3/24/21 2:09 PM, Frank Scheiner wrote:> Kernel sources are not available on 
the T1000.


If need be, where do they need to exist and how should the directory be
named - `/usr/src/[...]`?


Try installing "linux-source" and the "-dbg" package for your Debian kernel.


But don't I need the source for the kernel at 028abd92? I figured, I
need the sources in `/usr/src/linux-source-5.9.0-rc1+` because
"5.9.0-rc1+" is the version the corresponding modules are installed -
could that be correct?


Frank,

i'm using gdb from kernel sources directory (from which kernel is
installed), like:

$ uname -a
Linux ttip 5.12.0-rc4 #203 SMP Wed Mar 24 15:50:29 MSK 2021 sparc64 GNU/Linux
$ cd linux-2.6
linux-2.6$ git describe
v5.12-rc4
linux-2.6$ gdb -q vmlinux
Reading symbols from vmlinux...
(gdb) l *(sys_mount+0x114/0x1e0)
0x6dd7c0 is in __se_sys_mount (fs/namespace.c:3431).
3426/* ... and return the root of (sub)tree on it */
3427return path.dentry;
3428}
3429EXPORT_SYMBOL(mount_subtree);
3430
3431SYSCALL_DEFINE5(mount, char __user *, dev_name, char __user *, dir_name,
3432char __user *, type, unsigned long, flags,
void __user *, data)
3433{
3434int ret;
3435char *kernel_type;
(gdb)



Ok, will try that approach. I'm currently `tar`ing the kernel sources
@028abd92 on the cross-compiling host and will move them over to the T1000.

Cheers,
Frank

Re: Regression in 028abd92 for Sun UltraSPARC T1

[Frank Scheiner]

On 24.03.21 14:16, John Paul Adrian Glaubitz wrote:

On 3/24/21 2:09 PM, Frank Scheiner wrote:> Kernel sources are not available on 
the T1000.


If need be, where do they need to exist and how should the directory be
named - `/usr/src/[...]`?


Try installing "linux-source" and the "-dbg" package for your Debian kernel.


But don't I need the source for the kernel at 028abd92? I figured, I
need the sources in `/usr/src/linux-source-5.9.0-rc1+` because
"5.9.0-rc1+" is the version the corresponding modules are installed -
could that be correct?

Cheers,
Frank

Re: Regression in 028abd92 for Sun UltraSPARC T1

[Frank Scheiner]

On 24.03.21 09:28, Christoph Hellwig wrote:

On Tue, Mar 23, 2021 at 11:17:41PM +0100, Frank Scheiner wrote:

028abd9222df0cf5855dab5014a5ebaf06f90565

...is broken on my T1000.

As I don't know how big attachments can be on this list, I put the logs
on pastebin.

A log for 028abd9222df is here:

https://pastebin.com/ApPYsMcu


Just do confirm:  in this tree line 304 in mm/slub.c is this BUG_ON:

BUG_ON(object == fp); /* naive detection of double free or corruption */

which would mean we have a double free.  In that case it would be
interesting which call to kfree this is, which could be done by
calling gdb on vmlinux and then typing;

l *(sys_mount+0x114/0x1e0)

Not that a double free caused by this conversion makes any sense to me..


This is what I get:

```
root@t1000:~/kernels-in-question# gdb vmlinux-028abd9222df-new
GNU gdb (Debian 9.2-1+b1) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "sparc64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from vmlinux-028abd9222df-new...
(gdb) l *(sys_mount+0x114/0x1e0)
0x6c6380 is in __se_sys_mount (fs/namespace.c:3390).
3385fs/namespace.c: No such file or directory.
(gdb)
```

Kernel sources are not available on the T1000.

If need be, where do they need to exist and how should the directory be
named - `/usr/src/[...]`?

Cheers,
Frank

Re: Regression in 028abd92 for Sun UltraSPARC T1

[Frank Scheiner]

On 24.03.21 13:42, Anatoly Pugachev wrote:

On Wed, Mar 24, 2021 at 3:31 PM Frank Scheiner  wrote:

Sorry, but I can't install `gdb` on my T1000 ATM, because it depends on
"libpython3.8" for sparc64 (see [1]) and "libpython3.9" for the other
architectures, but "libpython3.8" is actually not available for sparc64,
"libpython3.9" is available for sparc64 though:
...
The following packages have unmet dependencies:
   gdb : Depends: libpython3.8 (>= 3.8.2) but it is not installable
 Recommends: libc-dbg
E: Unable to correct problems, you have held broken packages.
```
Something wrong with the dependencies. Any suggestions?


Frank,

you could use http://snapshot.debian.org to install old versions of
packages, i.e. gdb and libpython-3.8


Of course, didn't think about that. Will try that and report my findings.

Thanks and cheers,
Frank

Re: Regression in 028abd92 for Sun UltraSPARC T1

[Frank Scheiner]

On 24.03.21 09:28, Christoph Hellwig wrote:

On Tue, Mar 23, 2021 at 11:17:41PM +0100, Frank Scheiner wrote:

028abd9222df0cf5855dab5014a5ebaf06f90565

...is broken on my T1000.

As I don't know how big attachments can be on this list, I put the logs
on pastebin.

A log for 028abd9222df is here:

https://pastebin.com/ApPYsMcu


Just do confirm:  in this tree line 304 in mm/slub.c is this BUG_ON:

BUG_ON(object == fp); /* naive detection of double free or corruption */

which would mean we have a double free.  In that case it would be
interesting which call to kfree this is, which could be done by
calling gdb on vmlinux and then typing;

l *(sys_mount+0x114/0x1e0)

Not that a double free caused by this conversion makes any sense to me..


Sorry, but I can't install `gdb` on my T1000 ATM, because it depends on
"libpython3.8" for sparc64 (see [1]) and "libpython3.9" for the other
architectures, but "libpython3.8" is actually not available for sparc64,
"libpython3.9" is available for sparc64 though:

```
root@t1000:~# apt install gdb
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 gdb : Depends: libpython3.8 (>= 3.8.2) but it is not installable
   Recommends: libc-dbg
E: Unable to correct problems, you have held broken packages.
```

[1]: https://packages.debian.org/sid/gdb

Something wrong with the dependencies. Any suggestions?

Cheers,
Frank

Re: Regression in 028abd92 for Sun UltraSPARC T1

[Frank Scheiner]

On 23.03.21 17:57, Christoph Hellwig wrote:> Frank, can you double check
that commit

67e306c6906137020267eb9bbdbc127034da3627 really still works, and
only 028abd9222df0cf5855dab5014a5ebaf06f90565 broke your setup?


So I manually checked out both 67e306c6906137020267eb9bbdbc127034da3627
and 028abd9222df0cf5855dab5014a5ebaf06f90565 and recompiled both (doing
`make [...] mrproper` before each run).

The results didn't change from the ones from the bisecting process:

67e306c6906137020267eb9bbdbc127034da3627

...is working and:

028abd9222df0cf5855dab5014a5ebaf06f90565

...is broken on my T1000.

As I don't know how big attachments can be on this list, I put the logs
on pastebin.

A log for 028abd9222df is here:

https://pastebin.com/ApPYsMcu

A log for 67e306c69061 is here:

https://pastebin.com/uGLXX7RS

Cheers,
Frank

Re: Regression in 028abd92 for Sun UltraSPARC T1

[Frank Scheiner]

On 23.03.21 17:57, Christoph Hellwig wrote:

On Tue, Mar 23, 2021 at 05:50:59PM +0100, Jan Engelhardt wrote:

Some participants in the discussion over at the debian-sparc list mentioned
"NFS" and "Invalid argument", which is something I know just too well from
iptables. NFS is a filesystem that uses an extra data blob (5th argument to the
mount syscall). Such blobs have historically not always been designed to bear
the same layout between ILP32 and LP64 modes, and nfs's structs fell prey to
this as well.

My hypothesis now is that fs/nfs/fs_context.c line 1160:

if (in_compat_syscall())
nfs4_compat_mount_data_conv(data);

and ones similar to it (I didn't look too close where nfs3 gets to do its
conversion), no longer trigger as a result of compat_sys_mount being
wiped from the syscall table:


No, if in_compat_syscall() syscall doesn't trigger properly the kernel
would not get this far.

That being said, the NFS compat code was moved out of the compat mount
handler and into nfs and refactored in the commit just before this one.

Frank, can you double check that commit
67e306c6906137020267eb9bbdbc127034da3627 really still works, and
only 028abd9222df0cf5855dab5014a5ebaf06f90565 broke your setup?


Indeed, I also expected 67e306c6906137020267eb9bbdbc127034da3627 to fail
because of its commit message, but from my log it did work correctly.

As the T1000 is at home and I don't have another T1 based system in my
storage location where I am now, I'll double check that in the evening
and report back.

Strangely for a V245 (with UltraSPARC IIIi) both commits seem to work
according to my testing, but 5.10.x (from Debian) doesn't work and
5.9.15 (also from Debian) does work - tested now both for boot from
network and boot from disk.

Possibly unrelated to the problem with the T1000, the V245 emits the
following for boot from disk with 5.10.x:

```
[...]
Loading Linux 5.10.0-5-sparc64-smp ...
Loading initial ramdisk ...

[2.602821] rtc_cmos rtc_cmos: IRQ index 0 not found
/dev/sda2: clean, 33516/8454144 files, 1105784/33798750 blocks
[   13.542728] autofs4:pid:1:autofs_fill_super: called with bogus options
[   13.628931] systemd[1]: proc-sys-fs-binfmt_misc.automount: Failed to
initialize automounter: Invalid argument
[   13.759917] systemd[1]: Failed to set up automount Arbitrary
Executable File Formats File System Automount Point.
[FAILED] Failed to set up automount  File System Automount Point.
[   14.456396] Unable to handle kernel paging request in mna handler
[   14.456400]  at virtual address da65f2fed110e482
[   14.597474] current->{active_,}mm->context = 00ce
[   14.597478] current->{active_,}mm->pgd = fff006d5c000
[   14.752380] Unable to handle kernel paging request in mna handler
[   14.752383]  at virtual address da65f2fed110e482
[   14.893509] current->{active_,}mm->context = 0094
[   14.969141] current->{active_,}mm->pgd = fff00011010e
[   15.040554] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0009
[   15.141430] Press Stop-A (L1-A) from sun keyboard or send break
[   15.141430] twice on console to return to the boot prom
[   15.141459] kernel BUG at kernel/cpu.c:960
```

Cheers,
Frank

Re: 5.10.0-4-sparc64-smp #1 Debian 5.10.19-1 crashes on T2000

[Frank Scheiner]

Hi,

On 23.03.21 17:30, Connor McLaughlan wrote:

Hi,

can anyone possible give a list of known stable kernel versions for
SPARC machines? (is there a difference necessary between
architectures/old vs. newer machines? sun4u/sun4v)?

Also this instability manifests such that the machine is crashing during
high workload? (halting? rebooting?)

I ask, because on three different SPARC machines i have been
experiencing a weird effect when using debian:
I would start a high compiling load for several days (7-10) where the
machines are running fine without any apparent error visible in dmesg or
somewhere else.
Then when i power off tand on again, the filesystem would be corrupt and
sometimes impossible to repair without reinstallation.


Can you be sure that your used disks are in full working order? Maybe
you have bad sectors on them and their EOL is nearing, manifesting in
these FS errors? I assume the more accesses you have on your disks the
more a problem is prone to show up. And the accesses happening during
compile runs could be already too much for your disks. If you have
enough RAM, you could try to run your compile jobs in a RAM disk and
check if this makes a difference.


This seems to only happen when the machines do a long run with high
workload and seemingly not when i just power them off again for night
with no high workload.


I believe the error this thread is about is unrelated to what you
experience on your machines. This because the problem happens early on
when the root FS is to be mounted.

Cheers,
Frank

Re: 5.10.0-4-sparc64-smp #1 Debian 5.10.19-1 crashes on T2000

[Frank Scheiner]

Hi Jan,

On 23.03.21 16:36, Jan Engelhardt wrote:

On Tuesday 2021-03-23 16:29, Frank Scheiner wrote:

```
[...]
Begin: Retrying nfs mount ... [   41.753937] NFS: mount program didn't
pass remote address
mount: Invalid argument


I seem to recall that NFS is one of those filesystems that (a) makes use of
filesystem-specific data, i.e. mount(2)'s 5th argument, and (b) a mount helper,
/usr/sbin/mount.nfs.

Now, with the change in Linux kernel 028abd9222df0cf5855dab5014a5ebaf06f90565,
I am postulating the hypothesis that that the fs/nfs/ code for parsing this
binary blob is no longer aware that it is being invoked in a compat32 context.


That sounds interesting. Can you perhaps post your hypothesis also in
this thread:

https://marc.info/?t=16164490063=1=2

Maybe this gives the kernel developers some ideas.


Since T2 systems were said to be fine and T1 not, perhaps the T1 systems in
question were all on NFS mounts and the T2 one wasn't?


No, the T5220 was also running diskless, actually using the same root FS
as the T1000 (in form of a btrfs subvolume snapshot) plus identical
kernel and initramfs:

```
root@nfs:/srv/tftp# ls -la $( host2hex t5220 )*
lrwxrwxrwx 1 root root 35 Feb 28  2018 AC10026E ->
boot/grub/sparc64-ieee1275/core.img
lrwxrwxrwx 1 root root 38 Mar 15 18:16 AC10026E.initrd.img ->
initrd.img.5.10.0-4.debian.sid.sparc64
lrwxrwxrwx 1 root root 36 Mar 15 18:16 AC10026E.vmlinuz ->
linux.mp.5.10.0-4.debian.sid.sparc64
```

Cheers,
Frank

Re: 5.10.0-4-sparc64-smp #1 Debian 5.10.19-1 crashes on T2000

[Frank Scheiner]

Hi all,

On 09.03.21 13:23, Riccardo Mottola wrote:

Hi all,

while I was able to "install" correctly using a slightly older ISO, I
get not a bootable system. The kernel appears to crash very early during
boot.

Anybody else has this issue?

   Booting `Debian GNU/Linux'

Loading Linux 5.10.0-4-sparc64-smp ...
Loading initial ramdisk ...



From my current testing it looks like "UltraSPARC IIIi"s are also
affected by this problem with UltraSPARC T1s in some way:

With the latest Linux 5.10.x (from Debian) the root FS can't be
successfully mounted, with the latest Linux 5.9.x (also from Debian) it
just works fine. Unfortunately the V245 doesn't fail/work for the exact
same kernels that I tested during the bisecting for the T1000, e.g. the
first bad commit version that didn't work on the T1000 seems to work on
the V245 but some good versions don't with:

```
[...]
Begin: Retrying nfs mount ... [   41.753937] NFS: mount program didn't
pass remote address
mount: Invalid argument
done.
[...]
```

I'm unsure what could go wrong here, as I always pass the remote address
via the kernel commandline:

```
[...]
[2.928512] Kernel command line: BOOT_IMAGE=(tftp)/AC10027A.vmlinux
root=/dev/nfs
ip=172.16.2.122:172.16.0.2:172.16.0.1:255.255.0.0:v245-2:enp9s4f0:off
nfsroot=172.16.0.2:/srv/nfs/v245-2/root nfsrootdebug rw
[...]
```

Maybe there is some breakage in the klibc based programs in the
initramfs, but why they don't affect both UltraSPARC IIIi and T1 in the
same way is somewhat strange.

Cheers,
Frank

Re: Regression in 028abd92 for Sun UltraSPARC T1

[Frank Scheiner]

Hi,

On 22.03.21 22:48, John Paul Adrian Glaubitz wrote:

On 3/22/21 10:30 PM, Frank Scheiner wrote:

Riccardo Mottola first recognized a problem with 5.10.x kernels on his
Sun T2000 with UltraSPARC T1 (details in [this thread]). I could verify
the problem also on my Sun T1000 and it looks like this specific issue
breaks the mounting of the root FS or maybe mounting file systems at
all. This affects both booting from disk and from network.
(...)
...as first bad commit.

```
commit 028abd9222df0cf5855dab5014a5ebaf06f90565
Author: Christoph Hellwig 
Date:   Thu Sep 17 10:22:34 2020 +0200

 fs: remove compat_sys_mount

 compat_sys_mount is identical to the regular sys_mount now, so
remove it
 and use the native version everywhere.
```

[1]:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=028abd9222df0cf5855dab5014a5ebaf06f90565


Looking at this change, I think it's rather unexpected that this particular
change would break the kernel on a specific CPU target. Are you sure that
this is the right bad commit?


Well, I strictly followed the `git bisect` process and tested each and
every proposed revision. It's indeed strange that this only affects
UltraSPARC T1s, but the changes match the behavior: mounting of (root)
FS is broken.


If you found the right commit, then I assume there is something wrong with
the syscall handling on UltraSPARC T1.


Could be, all in all the T1 is a first of its kind.

Cheers,
Frank

Regression in 028abd92 for Sun UltraSPARC T1

[Frank Scheiner]

Dear all,

Riccardo Mottola first recognized a problem with 5.10.x kernels on his
Sun T2000 with UltraSPARC T1 (details in [this thread]). I could verify
the problem also on my Sun T1000 and it looks like this specific issue
breaks the mounting of the root FS or maybe mounting file systems at
all. This affects both booting from disk and from network.

[this thread]: https://lists.debian.org/debian-sparc/2021/03/msg4.html

I bisected the Linux kernel between:

bbf5c979011a099af5dc76498918ed7df445635b (good)

...and:

3650b228f83adda7e5ee532e2b90429c03f7b9ec (bad)

...and the process identified:

028abd9222df0cf5855dab5014a5ebaf06f90565 ([1])

...as first bad commit.

```
commit 028abd9222df0cf5855dab5014a5ebaf06f90565
Author: Christoph Hellwig 
Date:   Thu Sep 17 10:22:34 2020 +0200

fs: remove compat_sys_mount

compat_sys_mount is identical to the regular sys_mount now, so
remove it
and use the native version everywhere.
```

[1]:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=028abd9222df0cf5855dab5014a5ebaf06f90565

Details about the bisecting on [2].

[2]: https://lists.debian.org/debian-sparc/2021/03/msg00042.html

So far this only affects UltraSPARC T1 processors. I didn't see that
problem on a T5220 with UltraSPARC T2 and I also didn't see that problem
on a Sun Ultra Enterprise 450 with UltraSPARC II when testing a recent
Debian installation media with 5.10.x kernel some weeks ago. Other
UltraSPARC processors weren't tested yet. I plant to check UltraSPARC
IIIi and maybe others if time allows.



Do you maybe have an idea, what could go wrong with 028abd92
specifically on an UltraSPARC T1 processor?

I can provide a full log of a broken (network) boot process if that's
useful, I just need to re-create it. IIRC the kernel oopses for each
hardware thread (similar to what Riccardo wrote on the debian-sparc
mailing list above) and then stops.

Cheers,
Frank

Re: 5.10.0-4-sparc64-smp #1 Debian 5.10.19-1 crashes on T2000

[Frank Scheiner]

Hi Adrian,

On 17.03.21 13:39, John Paul Adrian Glaubitz wrote:

On 3/17/21 1:22 PM, Frank Scheiner wrote:

```
johndoe@x4270:~/git-projects/torvalds/linux$ git bisect bad
028abd9222df0cf5855dab5014a5ebaf06f90565 is the first bad commit
[...]

Did you verify that reverting this commit or - if reverting is not possible - 
testing
out the revision just before the commit?


I did not yet revert the bad commit in a current kernel and test it, but
from my understanding the parent commit of the first bad one must have
been a good one and indeed, [67e306c6906137020267eb9bbdbc127034da3627]
is the parent of [028abd9222df0cf5855dab5014a5ebaf06f90565] and was
working for me on my T1000:


```
johndoe@x4270:~/git-projects/torvalds/linux$ git bisect log
[...]
# good: [67e306c6906137020267eb9bbdbc127034da3627] fs,nfs: lift compat
nfs4 mount data handling into the nfs code
git bisect good 67e306c6906137020267eb9bbdbc127034da3627
# bad: [028abd9222df0cf5855dab5014a5ebaf06f90565] fs: remove
compat_sys_mount
git bisect bad 028abd9222df0cf5855dab5014a5ebaf06f90565
# first bad commit: [028abd9222df0cf5855dab5014a5ebaf06f90565] fs:
remove compat_sys_mount
```


[67e306c6906137020267eb9bbdbc127034da3627]:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=67e306c6906137020267eb9bbdbc127034da3627

[028abd9222df0cf5855dab5014a5ebaf06f90565]:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=028abd9222df0cf5855dab5014a5ebaf06f90565


Just to be safe you found the correct commit.

If that has been verified, please report the issue to the sparclinux LKML and 
CC Christoph.


Will do that soon-ish but maybe also try to revert that commit in
Debian's 5.10.0-4 and test it for additional assurance (then not so
soon-ish - maybe this weekend). I'll put you and Riccardo in CC, too.

Hopefully this will be easier to fix than the kernel breakage on the
rx2800 i2 - assuming that problem is still there ([1], [2]).

[1]: https://marc.info/?l=linux-ia64=156114769908890=2
[2]: https://marc.info/?l=linux-ia64=156144480821712=2

Cheers and thanks for the pointers,
Frank

Re: 5.10.0-4-sparc64-smp #1 Debian 5.10.19-1 crashes on T2000

[Frank Scheiner]

Hi Adrian, Riccardo

so I'm finished with bisecting and it points to the following commit as
first bad commit:

```
johndoe@x4270:~/git-projects/torvalds/linux$ git bisect bad
028abd9222df0cf5855dab5014a5ebaf06f90565 is the first bad commit
commit 028abd9222df0cf5855dab5014a5ebaf06f90565
Author: Christoph Hellwig 
Date:   Thu Sep 17 10:22:34 2020 +0200

fs: remove compat_sys_mount

compat_sys_mount is identical to the regular sys_mount now, so
remove it
and use the native version everywhere.

Signed-off-by: Christoph Hellwig 
Signed-off-by: Al Viro 

 arch/arm64/include/asm/unistd32.h  |  2 +-
 arch/mips/kernel/syscalls/syscall_n32.tbl  |  2 +-
 arch/mips/kernel/syscalls/syscall_o32.tbl  |  2 +-
 arch/parisc/kernel/syscalls/syscall.tbl|  2 +-
 arch/powerpc/kernel/syscalls/syscall.tbl   |  2 +-
 arch/s390/kernel/syscalls/syscall.tbl  |  2 +-
 arch/sparc/kernel/syscalls/syscall.tbl |  2 +-
 arch/x86/entry/syscalls/syscall_32.tbl |  2 +-
 fs/Makefile|  1 -
 fs/compat.c| 57
--
 fs/internal.h  |  3 --
 fs/namespace.c |  4 +-
 include/linux/compat.h |  6 ---
 include/uapi/asm-generic/unistd.h  |  2 +-
 tools/include/uapi/asm-generic/unistd.h|  2 +-
 tools/perf/arch/powerpc/entry/syscalls/syscall.tbl |  2 +-
 tools/perf/arch/s390/entry/syscalls/syscall.tbl|  2 +-
 17 files changed, 14 insertions(+), 81 deletions(-)
 delete mode 100644 fs/compat.c
```

Seems to be indeed related to mounting (the root FS). Why it only
affects UltraSPARC T1 CPUs is another question. I don't have any other
UltraSPARC II, IIi, IIe, III and IIIi driven machines at hand now for
checking those.

So what now?

Cheers,
Frank

P.S.

Here's the log for reference:

```
johndoe@x4270:~/git-projects/torvalds/linux$ git bisect log
git bisect start
# good: [bbf5c979011a099af5dc76498918ed7df445635b] Linux 5.9
git bisect good bbf5c979011a099af5dc76498918ed7df445635b
# bad: [3650b228f83adda7e5ee532e2b90429c03f7b9ec] Linux 5.10-rc1
git bisect bad 3650b228f83adda7e5ee532e2b90429c03f7b9ec
# bad: [c48b75b7271db23c1b2d1204d6e8496d91f27711] Merge tag
'sound-5.10-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
git bisect bad c48b75b7271db23c1b2d1204d6e8496d91f27711
# bad: [7fafb54c7d390e9b273a1d7d377e38d9c408046e] Merge tag
'leds-5.10-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds
git bisect bad 7fafb54c7d390e9b273a1d7d377e38d9c408046e
# bad: [fd5c32d80884268a381ed0e67cccef0b3d37750b] Merge tag
'media/v5.10-1' of
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
git bisect bad fd5c32d80884268a381ed0e67cccef0b3d37750b
# bad: [865c50e1d279671728c2936cb7680eb89355eeea] x86/uaccess: utilize
CONFIG_CC_HAS_ASM_GOTO_OUTPUT
git bisect bad 865c50e1d279671728c2936cb7680eb89355eeea
# good: [13cb73490f475f8e7669f9288be0bcfa85399b1f] Merge tag
'x86-entry-2020-10-12' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good 13cb73490f475f8e7669f9288be0bcfa85399b1f
# good: [dd502a81077a5f3b3e19fa9a1accffdcab5ad5bc] Merge tag
'core-static_call-2020-10-12' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good dd502a81077a5f3b3e19fa9a1accffdcab5ad5bc
# good: [ced3a9eb3cd0d07462cdbaa8a0f3d46e5aaeadec] Merge tag
'ia64_for_5.10' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux
git bisect good ced3a9eb3cd0d07462cdbaa8a0f3d46e5aaeadec
# good: [fc67d5bc876b6b224538c8848fc02e70f269ec99]
Documentation/admin-guide: README & svga: remove use of "rdev"
git bisect good fc67d5bc876b6b224538c8848fc02e70f269ec99
# good: [c90578360c92c71189308ebc71087197080e94c3] Merge branch
'work.csum_and_copy' of
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs
git bisect good c90578360c92c71189308ebc71087197080e94c3
# good: [85ed13e78dbedf9433115a62c85429922bc5035c] Merge branch
'work.iov_iter' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs
git bisect good 85ed13e78dbedf9433115a62c85429922bc5035c
# bad: [22230cd2c55bd27ee2c3a3def97c0d5577a75b82] Merge branch
'compat.mount' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs
git bisect bad 22230cd2c55bd27ee2c3a3def97c0d5577a75b82
# good: [e18afa5bfa4a2f0e07b0864370485df701dacbc1] Merge branch
'work.quota-compat' of
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs
git bisect good e18afa5bfa4a2f0e07b0864370485df701dacbc1
# good: [67e306c6906137020267eb9bbdbc127034da3627] fs,nfs: lift compat
nfs4 mount data handling into the nfs code
git bisect good 67e306c6906137020267eb9bbdbc127034da3627
# bad: [028abd9222df0cf5855dab5014a5ebaf06f90565] fs: remove
compat_sys_mount
git bisect bad 028abd9222df0cf5855dab5014a5ebaf06f90565
# first bad commit: [028abd9222df0cf5855dab5014a5ebaf06f90565] fs:

Re: 5.10.0-4-sparc64-smp #1 Debian 5.10.19-1 crashes on T2000

[Frank Scheiner]

Hi Adrian,

On 16.03.21 14:27, John Paul Adrian Glaubitz wrote:

Hello Frank!

On 3/16/21 2:07 PM, Frank Scheiner wrote:

After a first cross compile run, I can confirm that 5.10-rc1 is also
broken on my T1000. I'll take this version (parent commit:
33def8498fdde180023444b08e12b72a9efed41d) as "bad". But taking v5.9 as
good means more than 5000 commits in between. Linus's tree doesn't
contain v5.9.16 or at least I didn't find it there. How can I get "good"
closer to "bad"? I don't want to check too many good versions if I know
that v5.9.16 most likely will be good, as v5.9.15 (5.9.0-5 on Debian) is
good? Should I switch to the stable kernel sources from GKH?


I'm not sure I am understand your problem here. The bisecting algorithm
has a runtime O(ln(n)), so even with 5000 commits, it will converge quite
quickly.


Yeah, you're right, I think I make this error every time I try to bisect
the kernel - i.e. once every two years... ;-)


Just make sure you are using a fast machine when compiling the kernel
as otherwise it won't be fun.


Other topic: As the compile times are actually taking less time than the
preparation of the test boot (copy over modules to T1000 root FS, boot
T1000 with working kernel, create initramfs, reboot with kernel in
question and that initramfs), is there a way to create the initramfs
(for sparc64) on the cross compile host (amd64)?

Cheers,
Frank

Re: 5.10.0-4-sparc64-smp #1 Debian 5.10.19-1 crashes on T2000

[Frank Scheiner]

Hi again,

On 16.03.21 14:07, Frank Scheiner wrote:

@Adrian:
After a first cross compile run, I can confirm that 5.10-rc1 is also
broken on my T1000. I'll take this version (parent commit:
33def8498fdde180023444b08e12b72a9efed41d) as "bad". But taking v5.9 as
good means more than 5000 commits in between. Linus's tree doesn't
contain v5.9.16 or at least I didn't find it there. How can I get "good"
closer to "bad"? I don't want to check too many good versions if I know
that v5.9.16 most likely will be good, as v5.9.15 (5.9.0-5 on Debian) is
good? Should I switch to the stable kernel sources from GKH?


Forget about that, [1] shows 5000+ commits between v5.9.16 and
v5.10-rc1, too. So no difference.

[1]: https://github.com/gregkh/linux/compare/v5.9.16...v5.10-rc1

Cheers,
Frank

Re: 5.10.0-4-sparc64-smp #1 Debian 5.10.19-1 crashes on T2000

[Frank Scheiner]

Hi Riccardo, Adrian,

so I did some testing yesterday and also see your problem on my T1000.
Because of some kernel command line misconfiguration, my machine at
first couldn't find its root FS as it tried to use a non-existent NIC.
This lead to a lot of kernel oopses (I assume at least one per hardware
thread) that looked very similar to the ones you see. And this happens
even with "working" kernels (tested 4.19.x and 5.9.x). So the actual
result of that problem in 5.10.x seems to be that the kernel can't find
its root FS.

On 11.03.21 23:43, Frank Scheiner wrote:

On 11.03.21 23:03, Riccardo Mottola wrote:

I suppose the Niagara CPU gives the kernel issue


 From [1] I assume T2 CPUs are not affected, but yeah, the issue could
be that selective that it only affects the very first generation.

[1]: https://lists.debian.org/debian-sparc/2021/03/msg00010.html


I can also indeed confirm that this problem only affects the T1 CPU, as
my T5220 with T2 CPU works w/o problems with kernel 5.10.x.

I didn't get any further yesterday as it took a lot of time to update
the root FSes of my T1000 and my X4270 - my intended machine for cross
compilation, not sure if it will be "fast" enough*. In addition cloning
Linus's linux tree alone took a lot of time (about an hour).

* it will:

```
## with config of Debian's 5.9.0-5 kernel as `.config`
$ make ARCH=sparc64 CROSS_COMPILE=sparc64-linux-gnu- olddefconfig
[...]
## with lsmod output from T1000
$ make ARCH=sparc64 CROSS_COMPILE=sparc64-linux-gnu-
LSMOD=$HOME/t1000-lsmod localmodconfig
[...]
$ time make -j16 ARCH=sparc64 CROSS_COMPILE=sparc64-linux-gnu- all
[...]
  kernel: arch/sparc/boot/zImage is ready

real3m12.264s
user42m5.325s
sys 3m27.843s
```

@Adrian:
After a first cross compile run, I can confirm that 5.10-rc1 is also
broken on my T1000. I'll take this version (parent commit:
33def8498fdde180023444b08e12b72a9efed41d) as "bad". But taking v5.9 as
good means more than 5000 commits in between. Linus's tree doesn't
contain v5.9.16 or at least I didn't find it there. How can I get "good"
closer to "bad"? I don't want to check too many good versions if I know
that v5.9.16 most likely will be good, as v5.9.15 (5.9.0-5 on Debian) is
good? Should I switch to the stable kernel sources from GKH?

Cheers,
Frank

Re: watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [systemd:1]

[Frank Scheiner]

On 14.03.21 18:21, John Paul Adrian Glaubitz wrote:

On 3/14/21 5:55 PM, Mike Tremaine wrote:

Let’s assume it’s not hardware, Dennis has posted the tests and states
the machine ran Sol10 fine.


The fact that Solaris runs fine can be an indicator the hardware is okay, but
it's not a proper verification that it's actually the case.

For example, if one of the memory modules is bad, it could happen that the error
shows on Linux but not on Solaris because both allocate different memory regions
right after the machine has started.


Agreed, but...


So, if, for example, you want to verify that the memory is okay, you should run
a memtest program.


...the built-in (memory) diagnostics of Sun machines are pretty
thorough. This is not a PC. :-)

Cheers,
Frank

Re: watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [systemd:1]

[Frank Scheiner]

Hi Dennis,

On 13.03.21 20:21, Dennis Clarke wrote:

On 3/13/21 5:29 PM, Mike Tremaine wrote:

On Mar 12, 2021, at 5:56 AM,
Dennis Clarke  wrote:

[...]
I did sent a BRK to the serial port and that drops us into the firmware
"ok" prompt.  There is a failed fan but in fact the fan is entirely not
there. At all. I removed it because it had failed five or six years ago
and getting another one is just annoying.  Also it is not really needed.


Is the heatsink on the board cooled by a chassis then?



We can see that there is 1G of ECC memory and the memory passes all the
basic tests.

Now I setup a few of the firmware variables and reset the unit :

ok printenv
Variable Name Value  Default Value

[...]
local-mac-address?false  false
[...]

>

ceres# ip link show
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode
DEFAULT group default qlen 1000
 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp1s1f1:  mtu 1500 qdisc pfifo_fast
state UNKNOWN mode DEFAULT group default qlen 1000
 link/ether 08:00:20:c2:46:48 brd ff:ff:ff:ff:ff:ff
3: enp1s3f1:  mtu 1500 qdisc noop state DOWN mode
DEFAULT group default qlen 1000
 link/ether 08:00:20:c2:46:48 brd ff:ff:ff:ff:ff:ff
ceres#

However there must be a bug somewhere because the physical MAC address
is the same on both interfaces.


This is due to `local-mac-address?` set to `false` in OBP. See e.g. [1]
for details.

[1]: https://docs.oracle.com/cd/E36784_01/html/E37475/eyprp.html

Cheers,
Frank

Re: 5.10.0-4-sparc64-smp #1 Debian 5.10.19-1 crashes on T2000

[Frank Scheiner]

Hi Riccardo,

On 11.03.21 23:03, Riccardo Mottola wrote:

Hi Frank!

I suppose the Niagara CPU gives the kernel issue


From [1] I assume T2 CPUs are not affected, but yeah, the issue could
be that selective that it only affects the very first generation.

[1]: https://lists.debian.org/debian-sparc/2021/03/msg00010.html



Frank Scheiner wrote:

If I remember there was a repository with many snapshots of different
versions, already as package, which one can test quickly. That way we
can restrict breakage range without git bisect.

Do you have a link?


I assume you mean "http://snapshot.debian.org; .


Exactly. With this I did some more tests.

Still Works:
5.9.0-4-sparc64-smp #1 SMP Debian 5.9.11-1 (2020-11-27)
5.9.0-5-sparc64-smp #1 SMP Debian 5.9.15-1 (2020-12-17)

Broken:

linux-image-5.10.0-trunk-sparc64-smp_5.10.2-1~exp1_sparc64.deb

So later series 5.9 series continue to work and even very early 5.10 do not

Do you know if I can via serial-console reset the system?


Reset from the serial console might work via the kernel with the [magic
system request] functionality.

[magic system request]:
https://www.kernel.org/doc/html/v4.11/admin-guide/sysrq.html

But you can always reset the system using the SC. The T1000 (and the
T2000, too) has both serial (on T2000 right of the DB-9 ttya port,
should work with a blue Cisco serial cable) and network port (on T2000
above the two USB ports). The serial port of the SC automatically
switches to the system console after some (configurable) time and you
need to escape to the SC login prompt with a configurable key sequence
(`#.` by default, see [2]).

[2]:
https://docs.oracle.com/cd/E19076-01/t2k.srvr/819-2549-12/ontario-consoleConfig.html#28277


I tried sending a break on the serial console, but the errors just keep
running.
Break is received, since I see it as SC Alert, but I am not put into the
console, maybe there is some further trick on these newer machine?


So you already got access to the SC. Then you can reset the machine from
there, too.


I am
used to old SparcStations and UltraSparc Netras, where it was sufficient.
It is inconvenient at every hang to power-cycle, since at every turn on,
it runs a self-test which lasts minutes :)


I think depending on the SC configuration, these machines also run a
self-test for every X resets, but this should be configurable.

Hope that helps
Cheers,
Frank

Re: 5.10.0-4-sparc64-smp #1 Debian 5.10.19-1 crashes on T2000

[Frank Scheiner]

Hi Riccardo,

On 10.03.21 10:17, Riccardo Mottola wrote:

Frank Scheiner wrote:

We have an older UltraSPARC IIIi that has issues with newer kernels, but
usually only after longer operation and the issue might be related to
the
bug that was just fixed recently by Rob Gardner.


Which kernel version will have this bug (which one?) fixed, 5.11.x? I
can also check with one of my UltraSPARC IIIi powered systems, too, next
week.


as written in the title, I have issues with:
5.10.0-4-sparc64-smp #1 Debian 5.10.19-1


I know.


If I remember there was a repository with many snapshots of different
versions, already as package, which one can test quickly. That way we
can restrict breakage range without git bisect.

Do you have a link?


I assume you mean "http://snapshot.debian.org; .

Cheers,
Frank

Re: 5.10.0-4-sparc64-smp #1 Debian 5.10.19-1 crashes on T2000

[Frank Scheiner]

On 09.03.21 22:09, John Paul Adrian Glaubitz wrote:

On 3/9/21 9:38 PM, Frank Scheiner wrote:

I have a T1000 with which I could try to reproduce Riccardo's issues.
Hardware wise they should be pretty similar. As the T1000 doesn't have a
CDROM, I'll try to netboot a few newer kernels and report my findings.
Will take me until next week though, as the machine is in (cold) storage
now.

@Adrian:
Aren't there some build servers using UltraSPARC T2 or T2+? Do they run
with the latest kernels?


The oldest buildd we are running is a T5120 and that's a T2.


And these don't show the problems Riccardo's T1 powered T2000 has?


We have an older UltraSPARC IIIi that has issues with newer kernels, but
usually only after longer operation and the issue might be related to the
bug that was just fixed recently by Rob Gardner.


Which kernel version will have this bug (which one?) fixed, 5.11.x? I
can also check with one of my UltraSPARC IIIi powered systems, too, next
week.

Cheers,
Frank

Re: 5.10.0-4-sparc64-smp #1 Debian 5.10.19-1 crashes on T2000

[Frank Scheiner]

Hi guys,

On 09.03.21 18:31, John Paul Adrian Glaubitz wrote:

Hi!

On 3/9/21 6:26 PM, Riccardo Mottola wrote:

John Paul Adrian Glaubitz wrote:

while I was able to "install" correctly using a slightly older ISO, I get not a 
bootable
system. The kernel appears to crash very early during boot.

I think this is more likely a hardware issue. We haven't seen any machines 
crashing that
early. Please make sure the RAM modules in this machine are working properly.


I don't think so... I think it is a Kernel issue, since with kernel
5.9.0-2-sparc64-smp #1 SMP Debian 5.9.6-1 (2020-11-08) sparc64 GNU/Linux

the machine is performing fine with network, disk and compiler usage on all 32 
CPUs.


Then you need to bisect the kernel as I don't have any means to reproduce the 
issue.


I have a T1000 with which I could try to reproduce Riccardo's issues.
Hardware wise they should be pretty similar. As the T1000 doesn't have a
CDROM, I'll try to netboot a few newer kernels and report my findings.
Will take me until next week though, as the machine is in (cold) storage
now.

@Adrian:
Aren't there some build servers using UltraSPARC T2 or T2+? Do they run
with the latest kernels?

Cheers,
Frank

Re: Newer kernels fail to boot on a U450?

[Frank Scheiner]

Hi Mark,

On 24.02.21 14:01, Mark Cave-Ayland wrote:

On 24/02/2021 12:29, Frank Scheiner wrote:

On 24.02.21 12:14, Mark Cave-Ayland wrote:

Next time you have the U450 fired up, I'd be interested to find out if
it is possible to boot directly from the latest debian ports CDROM for
comparison.


So I fetched her from (cold) storage this morning and let her warm up in
the morning sun. When ready I booted with the latest image I did find
yesterday evening ([1]) and...

[1]:
https://cdimage.debian.org/cdimage/ports/snapshots/2021-02-02/debian-10.0.0-sparc64-NETINST-1.iso

...it worked through until the first screen of the rescue mode is shown.
No crashes, no nothing.

Here is the start of the syslog - I didn't have any storage at hand so
copied it from screen directly:

```
Feb 28 10:21:24 syslogd started: BusyBox v1.30.1
Feb 28 10:21:24 kernel: klogd started: BusyBox v1.30.1 (Debian 1:1.30.1-4)
Feb 28 10:21:24 kernel: [0.000145] PROMLIB: Sun IEEE Boot Prom 'OBP
3.30.0 2003/11/11 10:41'
Feb 28 10:21:24 kernel: [0.000232] PROMLIB: Root node compatible: sun4u
Feb 28 10:21:24 kernel: [0.000527] Linux version 5.10.0-3-sparc64
(debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1
20210110, GNU ld (GNU Binutils for Debian) 2.35.1) #1 Debian 5.10.12-1
(2021-01-30)
Feb 28 10:21:24 kernel: [0.000721] Unknown boot switch (--)
Feb 28 10:21:24 kernel: [0.000730] Unknown boot switch (--)
Feb 28 10:21:24 kernel: [0.000905] printk: bootconsole [earlyprom0]
enabled
Feb 28 10:21:24 kernel: [0.000914] ARCH: SUN4U
Feb 28 10:21:24 kernel: [0.001033] Ethernet address: 08:00:20:a7:5e:0a
Feb 28 10:21:24 kernel: [0.001073] MM: PAGE_OFFSET is
0xf800 (max_phys_bits == 40)
Feb 28 10:21:24 kernel: [0.001084] MM: VMALLOC [0x0001
--> 0x0600]
Feb 28 10:21:24 kernel: [0.001095] MM: VMEMMAP [0x0600
--> 0x0c00]
Feb 28 10:21:24 kernel: [0.005132] Kernel: Using 4 locked TLB
entries for main kernel image.
Feb 28 10:21:24 kernel: [0.005189] Remapping the kernel...
Feb 28 10:21:24 kernel: [0.052850] done.
Feb 28 10:21:24 kernel: [1.098314] OF stdout device is:
/pci@1f,4000/ebus@1/



   /se@14,40:a
Feb 28 10:21:24 kernel: [1.098327] PROM: Built device tree with
139414 bytes of memory.
Feb 28 10:21:24 kernel: [1.098734] Top of RAM: 0xffea2000, Total
RAM: 0xffe96000
Feb 28 10:21:24 kernel: [1.098744] Memory hole size: 0MB
Feb 28 10:21:24 kernel: [1.124511] Allocated 16384 bytes for kernel
page tables.
Feb 28 10:21:24 kernel: [1.124575] Zone ranges:
Feb 28 10:21:24 kernel: [1.124586]   Normal   [mem
0x-0xffea1fff]
Feb 28 10:21:24 kernel: [1.124608] Movable zone start for each node
Feb 28 10:21:24 kernel: [1.124616] Early memory node ranges
Feb 28 10:21:24 kernel: [1.124628]   node   0: [mem
0x-0xffdfdfff]
Feb 28 10:21:24 kernel: [1.124644]   node   0: [mem
0xffe0-0xffe81fff]
Feb 28 10:21:24 kernel: [1.124656]   node   0: [mem
0xffe8c000-0xffea1fff]
Feb 28 10:21:24 kernel: [1.124746] Zeroed struct page in unavailable
ranges: 181 pages
Feb 28 10:21:24 kernel: [1.124760] Initmem setup node 0 [mem
0x-0xffea1fff]
Feb 28 10:21:24 kernel: [1.124777] On node 0 totalpages: 524107
Feb 28 10:21:24 kernel: [1.124790]   Normal zone: 4607 pages used
for memmap
Feb 28 10:21:24 kernel: [1.124801]   Normal zone: 0 pages reserved
Feb 28 10:21:24 kernel: [1.124814]   Normal zone: 524107 pages, LIFO
batch:31

Feb 28 10:21:24 kernel: [1.289565] Booting
 Linux...
Feb 28 10:21:24 kernel: [1.289591] CPU CAPS:
[flush,stbar,swap,muldiv,v9,mul32,div32,v8plus]
Feb 28 10:21:24 kernel: [1.289674] CPU CAPS: [vis]
Feb 28 10:21:24 kernel: [1.302223] pcpu-alloc: s0 r0 d32768 u32768
alloc=1*32768
Feb 28 10:21:24 kernel: [1.302239] pcpu-alloc: [0] 0
Feb 28 10:21:24 kernel: [1.308282] Built 1 zonelists, mobility
grouping on.  Total pages: 519500
Feb 28 10:21:24 kernel: [1.308299] Kernel command line:
BOOT_IMAGE=/install/vmlinux rescue/enable=true --- quiet
Feb 28 10:21:24 kernel: [1.333950] Dentry cache hash table entries:
524288 (order: 9, 4194304 bytes, linear)
Feb 28 10:21:24 kernel: [1.343863] Inode-cache hash table entries:
262144 (order: 8, 2097152 bytes, linear)
Feb 28 10:21:24 kernel: [1.343878] Sorting __ex_table...
Feb 28 10:21:24 kernel: [1.346444] mem auto-init: stack:off, heap
alloc:on, heap free:off
Feb 28 10:21:24 kernel: [1.531560] Memory: 4114688K/4192856K
available (8081K kernel code, 1417K rwdata, 2152K rodata, 496K init,
405K bss, 78168K reserved, ,
0K cma-reserved)
[...]
```

For referenced my machine has four US II running at 400 MHz and 16 x 256
MiB memory modules installed:

```
~ # cat /proc/cpuinfo
cpu : TI UltraSparc II  (BlackBir

Re: Newer kernels fail to boot on a U450?

[Frank Scheiner]

Hi Mark,

On 24.02.21 14:01, Mark Cave-Ayland wrote:

On 24/02/2021 12:29, Frank Scheiner wrote:

On 24.02.21 12:14, Mark Cave-Ayland wrote:

Thanks for the information! Do you have a display on your U450 at all?


No, access was/is via serial console.


The U450 we were trying to rescue was headless (i.e. connect via serial
only) so the only differences I can see might either be the display or
the fact that the boot was occurring from the CDROM rather than a local
disk installation.


I'd agree to no display and serial console except that my machine had no
local disk and was netbooted - so netboot instead of boot from CDROM.

Other idea, can you be sure that the used disc was w/o errors and the
used disc drive was OK, too?


Next time you have the U450 fired up, I'd be interested to find out if
it is possible to boot directly from the latest debian ports CDROM for
comparison.


I can give that a try end of the week and report back.

Cheers,
Frank

Re: Newer kernels fail to boot on a U450?

[Frank Scheiner]

Hi Adrian,

On 24.02.21 13:04, John Paul Adrian Glaubitz wrote:

Hi Mark!

On 2/24/21 12:14 PM, Mark Cave-Ayland wrote:

Do people still run newer kernels on older hardware? If there is interest,
I may be able to get some more diagnostic information. In particular I'd be
curious to know if Oracle do any routine testing of newer kernels on machines
such as the U450 and whether anyone there can reproduce the problem.


I think this must be an issue specific to this machine or this model as I 
haven't
seen such issues myself when testing on older machines.

There is a stability issue on newer kernels on older hardware that is currently
being debugged though [1].


Didn't know of that thread. I wonder if this could be the reason for the
crashes on my v480 and v490, though they happened already during kernel
boot.



Adrian


[1] https://marc.info/?l=linux-sparc=161399891728083=2




Cheers,
Frank

Re: Newer kernels fail to boot on a U450?

[Frank Scheiner]

Hi Mark,

On 24.02.21 12:14, Mark Cave-Ayland wrote:

[...]
I then asked them to work backwards through a collection of historical
debian-ports ISOs that I own until we found one that would boot. The
results were as follows:


debian-10.0.0-sparc64-NETINST-1.iso (kernel 5.9.0-1-sparc64, grub) - FAILS
debian-9.0-sparc64-NETINST-1.iso (kernel 4.14.0-3-sparc64, SILO) - FAILS
debian-7.7.0-sparc-netinst.iso (kernel 3.2.0-4-sparc64, SILO) - FAILS
debian-6.0.4-sparc-netinst.iso (kernel 2.6.32-5-sparc64, SILO) - WORKS


Having eliminated the change of bootloader from SILO to grub as the
problem, it really seems as if something in the kernel broke booting on
a U450 between versions 2.6.32 and 3.2.0. I should add that these ISOs
all boot fine under qemu-system-sparc64 which is a U5 machine, so the
newer kernels are not completely broken.


I have checked my logs and (probably) the last time I used my Ultra
Enterprise 450 - 2018-04-21 - it was running a kernel v4.15.4:

```
root@e450:~# uname -a
Linux e450 4.15.0-1-sparc64-smp #1 SMP Debian 4.15.4-1 (2018-02-18)
sparc64 GNU/Linux
```

...successfully (incl. `openssl`, `7za` and STREAM benchmarks for half
an hour or so). And according to my netboot configuration it was booted
with GRUB - from the "[...]2.02+dfsg1-3" package. Looks like I didn't
test with any later GRUB version/package.

From my experience, US II (and derived versions like IIi and IIe)
is/was still working well at that time, though US III and IIIi sometimes
had problems, though not sure if that is due to the processor or the
other components on the respective system boards.


Do people still run newer kernels on older hardware? If there is
interest, I may be able to get some more diagnostic information. In
particular I'd be curious to know if Oracle do any routine testing of
newer kernels on machines such as the U450 and whether anyone there can
reproduce the problem.


I did run "newer" (to that time) kernels on older hardware, with the one
from the 4.19.0-5 versioned limux-image package being the latest one
used according to my configuration. But I don't have a log of this one
with US II or IIIi. I have logged crashes with that on v480 and v490 though.

I have a successful log of a 280R with two US IIIs running a kernel v4.16.5:

```
root@280r:~# uname -a
Linux 280r 4.16.0-1-sparc64-smp #1 SMP Debian 4.16.5-1 (2018-04-29)
sparc64 GNU/Linux
```

...together with the benchmarks I mentioned earlier. This one was also
netbooted with GRUB, but at that time from the "[...]2.02+dfsg1-4" package.

Cheers,
Frank

Re: mkfs.ext2 - state D partitioning stops at 33% /boot

[Frank Scheiner]

On 22.06.20 18:30, Gregor Riepl wrote:

Rethinking that, I assume if an UltraSPARC machine boots from a CDROM
drive attached to the built-in ATA controller and the installer later
can find the disc to start the installation, it should also work with
HDDs on that controller, though maybe not with UDMA speeds, but that was
a common issue with some older chipsets IIRC. Not sure if these issues
were with disc drives exclusively or also with disk drives.


My Ultra 10 has a CMD646 though, which supposedly supports up to UDMA2.

Dumb question: Did you check the cabling/jumper settings?


No, not that I remember, it looked like from the factory.

But I was also referring to something like [1]. And I also seem to
remember similar issues with ALi/ULi chipsets (e.g. used in Blade 100
and 150).

[1]: https://ata.wiki.kernel.org/index.php/Pata_cmd64x#Limitations

Cheers,
Frank

Re: mkfs.ext2 - state D partitioning stops at 33% /boot

[Frank Scheiner]

On 22.06.20 17:37, Connor McLaughlan wrote:

Can you by any chance tell me how i could obtain a list of all PCI
cards that are possibly supported  and might work on debian sparc?


Sorry, no idea. I avoid disks in my machines wherever possible.

Even the list from OpenBSD ([1]) for PCI IDE Controllers is rather
short. I assume it's like they say there also on Debian: "Other PCI IDE
adapters may work, but are untested."

[1]: http://www.openbsd.org/sparc64.html

The same might hold true for other removable PCI hardware.

Cheers,
Frank

Re: mkfs.ext2 - state D partitioning stops at 33% /boot

[Frank Scheiner]

On 22.06.20 17:17, Gregor Riepl wrote:

@all:
Are there any users that had success with Promise based ATA controllers
on UltraSPARC?


As a matter of fact, I do. I had a software RAID running on 2 SATA disks
on a Promise SATA300 TX4 controller and even built a custom mounting
bracket for my old Ultra 10 to hold more than one disk.
But, this was with Debian 4 (or thereabouts) and the sparc32 userland,
and the boot disk was connected to the internal PATA controller.

Not sure if this still bears much relevance.


Well, so the driver was at least working somewhere in the past. OTOH
you're speaking about SATA, so most likely this was with another driver.
Looking at [1] the Promise SATA300 TX4 looks like a "real" SATA
controller not like older ones that were actually ATA controllers and
used some adapter chips. Maybe things also look differently with SATA.
But interesting point anyhow - SATA RAID on Ultra 10. :-)

[1]: https://www.phoronix.com/scan.php?page=article=815=1




@Mike:
I wonder if your problems could be an endianness issue in the Promise
drivers. In the end, I assume these were mostly used on x86. I'd expect
it to work with the onboard ATA controller of the Ultra 5 - at least it
worked for me when I tried an installation on my Ultra 10 and I believe
the hardware used in both machines is similar to identical. That it
works with OpenBSD for you could be due to their development process
which takes into account the specifics of many different architectures.


If there is any relevance to my older success story, the issue may have
creeped in much later than kernel 2.6.18. It could also be a 32/64-bit
issue, as the the Debian sparc kernel was 64-bit and the userland 32-bit
back then (as far as I remember).


Yeah, but the drivers don't depend on the userland, or do they? Maybe
the specific Promise driver for Mike's controller just broke some time
ago or was broken on UltraSPARC ever since.

Cheers,
Frank

Re: mkfs.ext2 - state D partitioning stops at 33% /boot

[Frank Scheiner]

On 22.06.20 16:58, Mike Tremaine wrote:

[...] Worth checking, I’ll have look at the drive code and see if I
can make sense of it. A follow up question might be does anyone have
ATA based install other than the Ultra 5/10 running? Example does
anyone have SunFire v100 running debian 9 or 10? I have one that’s
offline in a rack (Solaris 10 when it was powered down several years
back), I might be able to get my hands on it for testing.


Years ago I had Debian - I believe 5 - running from disk on a Blade 100
using the built-in ATA controller. Later I only ran it diskless with
Debian unstable IIRC, same for my V100.

Rethinking that, I assume if an UltraSPARC machine boots from a CDROM
drive attached to the built-in ATA controller and the installer later
can find the disc to start the installation, it should also work with
HDDs on that controller, though maybe not with UDMA speeds, but that was
a common issue with some older chipsets IIRC. Not sure if these issues
were with disc drives exclusively or also with disk drives.

Cheers,
Frank

Re: mkfs.ext2 - state D partitioning stops at 33% /boot

[Frank Scheiner]

Hi Mike, all on the list,

On 22.06.20 02:06, Mike Tremaine wrote:

[...]

Can you try replacing the IDE cable or try a different disk?

Adrian


[...]

Sadly no good outcome. Different cables made no difference, I tried a
PDC20269 Card (which uses pata_pdc2027x
)
and in that case I can not see the disk nor the cdrom once the kernel
has loaded. (Which is consistent with Debian 9 SILO installer on that card)
That is I can boot the cd and then when it comes to the stage of loading
from the media it can not be found. asmod shows the pdc2027x drive is
loaded and lspci shows the card but no devices are on it.
The PDC20267 (Promise ATA 100 using pata_pdc202xx_old) is the original
card I was working with today and it can’t make the filesystem. [Opps
posted]
I went ahead and tried OpenBSD6.7 on this new disk to see if it works
and it does. So I’m right back where I was before I began this exercise.
I need to find a HighPoint HPT366 the non-raid kind of card to see if it
can been used. I know I tried at least one SILxxx and it was not useable
by OpenBoot.  I’ll keep thinking about ways around this. I wonder if the
FCode linking I do to the card somehow limits the DMA mode to match the
onboard limit. It’s kind of a blackbox to me. But I thought once the
kernels take over they would sort it out.


@all:
Are there any users that had success with Promise based ATA controllers
on UltraSPARC?

@Mike:
I wonder if your problems could be an endianness issue in the Promise
drivers. In the end, I assume these were mostly used on x86. I'd expect
it to work with the onboard ATA controller of the Ultra 5 - at least it
worked for me when I tried an installation on my Ultra 10 and I believe
the hardware used in both machines is similar to identical. That it
works with OpenBSD for you could be due to their development process
which takes into account the specifics of many different architectures.

Cheers,
Frank

Re: mkfs.ext2 - state D partitioning stops at 33% /boot

[Frank Scheiner]

On 21.06.20 19:21, Mike Tremaine wrote:

I spent a few hours trying different things on this but no luck.

Hardware: Sun Ultra 5 - 333mhz / 512MB  - Promise 100 PCI card as IDE
interface..

Install Image:2020-05-30/debian-10.0.0-sparc64-NETINST-1.iso

Boots CDROM and finds disks no problem.

Issue is after the partitioning is done and the installer runs mkfs.ext2
-F /dev/sda1 it hangs and the process goes Defunct. I’ve tried many
different layouts with/without LVM, with/without /home always the same
spot 33% ….


If it's the same issue as with my Ultra 10, you (1) either have to wait
longer or (2) have to remove your floppy disk drive from the controller
before doing an installation. #2 definitely saves some time.

Cheers,
Frank

Re: Fail to boot Fujitsu M10-4

[Frank Scheiner]

Hi,

On 6/1/19 04:52, Sonnie Hook wrote:

I have installed Debian/SPARC port from ISO image of 2019-05-24. At
first, I just followed the default "Use entire disk" to partition the
whole disk into
/dev/sda1 grub-boot
/dev/sda2 /
/dev/sda3 swap
GRUB was installed without any error message. But when boot from prompt:
{0} ok boot disk
Boot device: /pci@8000/pci@4/pci@0/pci@0/scsi@0/disk@p0,0  File and args:

Can't open boot device

After googling for quite a long time, I entered rescue mode via booting
from cdrom, and re-partitioned the disk into
/dev/sda1 grub-boot 30M
/dev/sda2 /boot 1G
/dev/sda3 / 500G
/dev/sda4 swap left


Can this be done from the installer without reinstalling the whole OS?



Still I got the same error.

Could someone tell me how I can boot this machine?


The "d-i/grub-installer" can install GRUB on systems that support GPT
partitioned drives and systems that don't support GPT partitioned
drives, and IIRC uses a subarchitecture string to differentiate between
the capabilities of the respective machine. It could be that this
doesn't apply to your M10-4 with SPARC64 X/X+ or the resulting
partitioning isn't what your machine expects or the path to the boot
device wasn't correctly translated.

When you are in rescue mode, could you issue `archdetect` on a console
in the installer UI and post the resulting string?

And could you also issue `partmap ` (with  being your actual
disk device, e.g. /dev/sda) and post the result? This should show if GPT
partitioning was used or not.

And as this machine would be the first SPARC64 driven machine I know of
that runs Debian GNU/Linux, could you please also post your `dmesg`
output or your syslog from an installer boot?

Depending on how GRUB was installed, it could also work to just issue
`boot disk` from the OBP if "disk" is a device alias pointing to your
actual install disk - if non-GPT partitioning was used.

I don't know what needs to be added to boot when GPT partitioning was
used though. According to [1] and your partitioning scheme, maybe add
`,0` at the end, i.e. `boot disk,0`.

[1]:
https://github.com/esnowberg/grub2-sparc/wiki#installation-instructions-for-sparc-t4-and-above

Cheers,
Frank

Re: Updated installation images for Debian Ports 2019-05-09

[Frank Scheiner]

Hi all,

On 5/10/19 07:00, Meelis Roos wrote:

Hello Meelis,

Perhaps of interest ... i was being hit with the qla2xxx driver panics
as well on my v880.
I unplugged the second FCAL loop to the backplane, and this fixed it.

Perhaps this is something you could try?


I have not tried on my V880 but I got similar trouble on V480.

But where is the secondary loop on SB1000/E280R (having the same
mainboard)? Hmm,
come to think of it, there is a connector marked with double arrow, the
back of mainboard but I do
not think I have seen any cable that would fit there.


Thanks, Meelis and Kevin.

The problems with the qla2xxx could also explain, why I couldn't get my
V480 and V490 fully working with Linux earlier last year. IIRC both
crashed during kernel boot.

I could reproduce and later avoid the problem with the qla2xxx driver on
my 280R by just blacklisting it (see [1]) - the machine boots from
network, so no problem that the internal disks are not usable. But I
didn't conclude that this could actually also help my V480 and V490. I
hope blacklisting the qla2xxx module will also make them usable with
Linux. Well, if Kevin's V880 runs Linux, V480 and V490 will most
certainly also run it with the qla2xxx problem out of the way.

[1]: https://wiki.debian.org/Sparc64#Sun_Fire_280R

Cheers,
Frank

Re: Updated installation images for Debian Ports 2019-05-09

[Frank Scheiner]

Hi Adrian,

On 5/9/19 18:24, John Paul Adrian Glaubitz wrote:

I just uploaded updated installation images 2019-05-09 for the
following Debian Ports architectures:
[...]
  * sparc64

I uploaded both CD images [1] as well as netboot images [2].

Please test those images and report back over the mailing list for
the corresponding architecture.

Known issues:
[...]
  * sparc64
- Installation over a serial console is currently broken
  on sparc64 due to a bug in the rootskel package
  (can also be considered a kernel bug), see: #926539.
  Use any image before 2019-04-06 as workaround.


Looks like this doesn't affect sun4u machines, at least this ISO worked
for my v245 using the serial console without any problems. Nice work! :-D

Just one odd thing: I didn't see any kernel messages when booting from
the installer disc. I assumed that there might be a `quiet` in the
kernel command line, but editing the GRUB menu options showed no
arguments for the kernel command line at all for the "default" option,
just "boot_one" IIRC.

Cheers,
Frank

Re: Updated installation images for Debian Ports 2019-05-09

[Frank Scheiner]

On 5/9/19 20:01, Dennis Clarke wrote:

I tried to breath life into an old Netra which was just too old for
the task. Are you aware of any issues with the M3000 type machine?

Or even M4000 ?


I'm starting to wonder if my mails about ...


No I am not ignoring you.

I simply didn't recall over my coffee this morning.

I have not looked at linux on sparc in ... nearly forever.  Possibly an
actual forever. There is no reason to think about it. Now I see from my
hardware list on hand there is even less reason to even bother testing.

Thanks for listening.


Please don't mind, I was just a little upset, as I assumed my mails on
this topic were just wasted.

[2] also has some further reading about this topic. Maybe you get in
touch with Meelis Roos, who started a thread titled "Adding support for
Fujitsu SPARC64 machines?" on the linux-sparc mailing list (see [3])
some years ago. Maybe this can be revived.

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

[3]: https://marc.info/?l=linux-sparc=142067252101925=2



I appreciate your patience and perserverance. I seem to have way way too
many little irons in the fire and too many machines running to recall
all the bits about all of them.  I don't think I am alone in that
experience.

In my mind an Oracle M4000 with 256G of memory and a stack of processor
cores is a terrible waste.  Baffles me that it can not run with even
some basic sparc v9 type mode. Regardless the devices are most likely an
issue also.


It can't be that that much of an issue, because OpenBSD runs on these
machines (according to [4] and my tests on serveral PRIMEPOWER 250s).
And for the Linux kernel you can actually see some Linux kernel messages
before the machine experiences a red state exception...

[4]: http://www.openbsd.org/sparc64.html

Re: Updated installation images for Debian Ports 2019-05-09

[Frank Scheiner]

On 5/9/19 19:42, Dennis Clarke wrote:

On 5/9/19 1:35 PM, Frank Scheiner wrote:

Hi Dennis,

On 5/9/19 18:29, Dennis Clarke wrote:

On 5/9/19 12:24 PM, John Paul Adrian Glaubitz wrote:

Hello!

I just uploaded updated installation images 2019-05-09 for the
following Debian Ports architectures:

  * alpha
  * hppa
  * ia64
  * m68k
  * powerpc
  * ppc64
  * sh4
  * sparc64


I tried to breath life into an old Netra which was just too old for
the task. Are you aware of any issues with the M3000 type machine?

Or even M4000 ?


I'm starting to wonder if my mails about ...


No I am not ignoring you.

I simply didn't recall over my coffee this morning.

I have not looked at linux on sparc in ... nearly forever.  Possibly an
actual forever. There is no reason to think about it. Now I see from my
hardware list on hand there is even less reason to even bother testing.

Thanks for listening.


Please don't mind, I was just a little upset, as I assumed my mails on
this topic were just wasted.

[2] also has some further reading about this topic. Maybe you get in
touch with Meelis Roos, who started a thread titled "Adding support for
Fujitsu SPARC64 machines?" on the linux-sparc mailing list (see [3])
some years ago. Maybe this can be revived.

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

[3]: https://marc.info/?l=linux-sparc=142067252101925=2

Cheers,
Frank

Re: Updated installation images for Debian Ports 2019-05-09

[Frank Scheiner]

Hi Dennis,

On 5/9/19 18:29, Dennis Clarke wrote:

On 5/9/19 12:24 PM, John Paul Adrian Glaubitz wrote:

Hello!

I just uploaded updated installation images 2019-05-09 for the
following Debian Ports architectures:

  * alpha
  * hppa
  * ia64
  * m68k
  * powerpc
  * ppc64
  * sh4
  * sparc64


I tried to breath life into an old Netra which was just too old for
the task. Are you aware of any issues with the M3000 type machine?

Or even M4000 ?


I'm starting to wonder if my mails about "Linux not working on Fujitsu's
SPARC64 V(+) and possibly later processors" don't reach you or if you
just ignore them. E.g. I sent [1] directly to you and the debian-sparc
list about a week ago and seem to remember that we "talked" about this
same topic already last year. Nevertheless, maybe you just try if your
Mx000s boot the installer ISO, at least GRUB should work.

[1]: https://lists.debian.org/debian-sparc/2019/05/msg0.html

Cheers,
Frank

Re: Request for a Debian CD logo - was: Re: Sorry for the noise...

[Frank Scheiner]

changing lists...

On 5/2/19 11:23, Dennis Clarke wrote:

Slightly off topic but I really need to do some SPARC testing as I am
swimming in that stuff.  There just is no way to keep Solaris running
anymore on anything older than eight or nine years ago and so testing
my fav Linux distro seems like a damn fine idea.


I agree. Apart from that, ever tried Tribblix ([1])? I never found the
time to test it, but there's a variant for SPARC available.

[1]: http://www.tribblix.org/



This is a note mostly to remind myself to get that going.

I have an M4000 sitting around with 256G of memory and fully loaded
doing nothing but fighting gravity.  That seems wrong to me.


Sorry to discourage you, but I expect you will only get GRUB running on
that machine unless the Linux support for Fujitsu's SPARC64 - what
version do you got in this machine: VI, VII or VII+? - has been improved
in the meantime (see [2]). But nevertheless you could give it a try, as
I only have SPARC64 V+ powered machines available.

[2]: https://lists.debian.org/debian-sparc/2017/09/msg00017.html

Apart from GNU/Linux, OpenBSD has support for this machine (see [3]) if
you want some "current" OS on it.

[3]: http://www.openbsd.org/sparc64.html

Cheers,
Frank

Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64

[Frank Scheiner]

On 4/24/19 22:07, John Paul Adrian Glaubitz wrote:
> On 4/24/19 9:46 PM, Mark Cave-Ayland wrote:
>> For reference the CHRP bootinfo.txt isn't a configuration file, but is 
>> actually
>> parsed by CHRP-compliant open firmwares directly - SPARC firmwares, including
>> OpenBIOS don't support them. Can you explain why grub on SPARC is trying to 
>> access
>> this file?
>
> Good point, I didn't notice that there is a CHRP header and assumed that we 
> need
> this file on sparc and sparc64 as well.
>
> I haven't actually done any runtime tests yet, I replaced the configuration 
> files
> from ppc64el for grub-ieee1275 and adapted them for sparc64. debian-installer
> builds fine with those changes, but as I said, I haven't tested anything yet.
>
> I am very welcome for any pointers though for what else is needed to use GRUB
> for CD boot on sparc64.

`grub-mkimage` has a (target) format named "sparc64-ieee1275-cdcore".
But I'm unsure if this is of any use for us, or needed at all, because
if GRUB can load kernel and initramfs from disc, it should also be able
to load its modules from disc, so a small GRUB image and separate
modules (like for on-disk or diskless installations) could also work.

OTOH: if a "sparc64-ieee1275-cdcore" image and a corresponding grub.cfg
works for disc booting, we could just exchange the SILO image and config
for these.

Cheers,
Frank

Re: sparc 32bit userland?

[Frank Scheiner]

On 1/27/19 21:02, John Paul Adrian Glaubitz wrote:

On 1/27/19 8:20 PM, Frank Scheiner wrote:

Although I don't have much of a preference for 32bit sparc userland, as
there is no kernel support for old SPARC gear, but anything substantial
on why not, Dennis?


My last information was that the kernel still has supported for
some SPARCStations that was fixed some months ago, but I haven't
tried that yet.


Wow, now it gets interesting - I think I could even hear my
SPARCstations in storage making a few jumps! :-D

I thought support was removed somewhere in 3.x. Do you still remember
which machines and the people involved?

Cheers,
Frank

Re: sparc 32bit userland?

[Frank Scheiner]

On 1/27/19 20:11, Dennis Clarke wrote:

On 1/27/19 2:08 PM, Frank Scheiner wrote:

On 1/27/19 19:50, John Paul Adrian Glaubitz wrote:

On 1/27/19 4:24 PM, John Paul Adrian Glaubitz wrote:

Although, oddly enough, I didn't see this issue on sparc64, so it
might be that I have just forgotten to add the package for powerpc
after it moved from release to ports.


That guess was correct, just fixed it:


https://salsa.debian.org/images-team/debian-cd/commit/57cae1891492ba74901e88b4252ee69265cca402



On a side note: As you also added sparc, say, is it planned to revive
the 32bit sparc userland? :-)


oh please .. no.


Although I don't have much of a preference for 32bit sparc userland, as
there is no kernel support for old SPARC gear, but anything substantial
on why not, Dennis?

Cheers,
Frank

sparc 32bit userland?

[Frank Scheiner]

On 1/27/19 19:50, John Paul Adrian Glaubitz wrote:

On 1/27/19 4:24 PM, John Paul Adrian Glaubitz wrote:

Although, oddly enough, I didn't see this issue on sparc64, so it
might be that I have just forgotten to add the package for powerpc
after it moved from release to ports.


That guess was correct, just fixed it:


https://salsa.debian.org/images-team/debian-cd/commit/57cae1891492ba74901e88b4252ee69265cca402


On a side note: As you also added sparc, say, is it planned to revive
the 32bit sparc userland? :-)

Cheers,
Frank

Re: Any progress with grub-installer?

[Frank Scheiner]

On 1/7/19 16:31, John Paul Adrian Glaubitz wrote:

On 1/7/19 4:22 PM, John Paul Adrian Glaubitz wrote:

I have done this now:

glaubitz@kyoto:~/grub-debian/test$ find /usr/lib/grub/sparc64-ieee1275/ -name 
"*.img" -exec file {} \;
/usr/lib/grub/sparc64-ieee1275/diskboot.img: data
/usr/lib/grub/sparc64-ieee1275/cdboot.img: SPARC executable
/usr/lib/grub/sparc64-ieee1275/kernel.img: ELF 64-bit MSB executable, SPARC V9, 
relaxed memory ordering, version 1 (SYSV), statically linked, stripped
/usr/lib/grub/sparc64-ieee1275/boot.img: SPARC executable
glaubitz@kyoto:~/grub-debian/test$

Try the packages from here:


I tried to install GRUB using a ELF boot image:

root@debian:~/grub2# grub-install /dev/vdiska
Installing for sparc64-ieee1275 platform.
grub-install: error: the size of `/boot/grub/sparc64-ieee1275/boot.img' is not 
512.
root@debian:~/grub2# ls -l /boot/grub/sparc64-ieee1275/boot.img
-rw-r--r-- 1 root root 816 Jan  7 18:29 /boot/grub/sparc64-ieee1275/boot.img
root@debian:~/grub2#

So, the generated ELF image is too big. No idea yet how to address this.


That's odd. Installed on my machine (a V240 this time) the "boot.img" 
from the grub-sparc-elf-v2 packages from [1] is actually smaller than 
the original one from the packages in Debian Ports currently:


```
## 2.02+dfsg1-9
root@v240-2:/usr/lib/grub/sparc64-ieee1275# ls -l boot.img
-rw-r--r-- 1 root root 480 Dec  7 10:38 boot.img

## 2.02+dfsg1-4
$ ls -l boot.img
-rw-r--r-- 1 user user 512 Apr  1  2018 boot.img
```

...which is backed by the output of `hexdump -C` for both files:

```
## 2.02+dfsg1-9
# hexdump -C boot.img
  40 00 00 51 a0 10 00 0c  00 00 00 00 00 00 00 00 
|@..Q|
0010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 
||

*
0080  00 00 00 00 00 00 04 00  00 00 42 00 66 69 6e 64 
|..B.find|

[...]

## 2.02+dfsg1-4
$ hexdump -C boot.img
  01 03 01 07 00 00 01 e0  00 00 00 00 00 00 00 00 
||
0010  00 00 00 00 00 00 40 00  00 00 00 00 00 00 00 00 
|..@.|
0020  40 00 00 51 a0 10 00 0c  00 00 00 00 00 00 00 00 
|@..Q|
0030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 
||

*
00a0  00 00 00 00 00 00 04 00  00 00 42 00 66 69 6e 64 
|..B.find|

[...]
```

The newer one is missing 32 bytes at the beginning.

[1]: https://people.debian.org/~glaubitz/grub-sparc-elf-v2/

I still have to test this with an on-disk installation.

Cheers,
Frank

Re: Any progress with grub-installer?

[Frank Scheiner]

On 1/7/19 21:14, John Paul Adrian Glaubitz wrote:




On Jan 7, 2019, at 9:07 PM, Frank Scheiner  wrote:


On 1/7/19 16:35, John Paul Adrian Glaubitz wrote:

On 1/7/19 4:31 PM, John Paul Adrian Glaubitz wrote:
I tried to install GRUB using a ELF boot image:

root@debian:~/grub2# grub-install /dev/vdiska
Installing for sparc64-ieee1275 platform.
grub-install: error: the size of `/boot/grub/sparc64-ieee1275/boot.img' is not 
512.
root@debian:~/grub2# ls -l /boot/grub/sparc64-ieee1275/boot.img
-rw-r--r-- 1 root root 816 Jan  7 18:29 /boot/grub/sparc64-ieee1275/boot.img
root@debian:~/grub2#

So, the generated ELF image is too big. No idea yet how to address this.

It does seem to work, however. At least with GPT:
  GNU GRUB  version 2.02+dfsg1-9
  ++
  |*Debian GNU/Linux   |



Did you maybe already install the v1 version on this GPT disk?


No, I didn’t. I only ever tried v2 on this machine. In fact, I built v2 first, 
then ran the tests.


As both v1 and v2 use the same version number it's not clear if this is one or 
the other.


Yes, but I know what I did. I‘m not sure why you are questioning that. Do you 
see any unexpected results?


No, but from the `grub-install` output I didn't expect that the 
installation worked and after comparing the versions of v1 and v2, I 
just wanted to be sure about the details. I was not questioning what you 
did. :-)


Cheers,
Frank

Re: Any progress with grub-installer?

[Frank Scheiner]

On 1/7/19 16:35, John Paul Adrian Glaubitz wrote:

On 1/7/19 4:31 PM, John Paul Adrian Glaubitz wrote:

I tried to install GRUB using a ELF boot image:

root@debian:~/grub2# grub-install /dev/vdiska
Installing for sparc64-ieee1275 platform.
grub-install: error: the size of `/boot/grub/sparc64-ieee1275/boot.img' is not 
512.
root@debian:~/grub2# ls -l /boot/grub/sparc64-ieee1275/boot.img
-rw-r--r-- 1 root root 816 Jan  7 18:29 /boot/grub/sparc64-ieee1275/boot.img
root@debian:~/grub2#

So, the generated ELF image is too big. No idea yet how to address this.


It does seem to work, however. At least with GPT:


  GNU GRUB  version 2.02+dfsg1-9

  ++
  |*Debian GNU/Linux   |



Did you maybe already install the v1 version on this GPT disk?

As both v1 and v2 use the same version number it's not clear if this is 
one or the other. And maybe the above `grub-install /dev/vdiska` didn't 
install the v2 version at all. Did it exit with `0`, as it actually 
reports an "error" and not a "warning"?


Cheers,
Frank

Re: Any progress with grub-installer?

[Frank Scheiner]

Hi Adrian,

On 1/6/19 21:43, Frank Scheiner wrote:

On 1/6/19 21:40, John Paul Adrian Glaubitz wrote:

On 1/6/19 9:35 PM, Frank Scheiner wrote:
If an ELF 
version of GRUB can be provided by someone, I have a lot of sparc64 
gear to test on - though not as many as OpenBSD supports ;-).


I do actually. I have built a version of GRUB for sparc64 with the COFF
linker options stripped off. Feel free to try the packages from [1].

If we actually don't ned COFF even on older SPARC boxes, that would be
great.


I tried to test these packages, but the created core.img (for netboot 
though) is still a COFF binary IIUIC:


```
root@e250-5:~# grub-mknetdir -v
[...]
grub-mknetdir: info: copying `/usr/share/grub/unicode.pf2' -> 
`/srv/tftp/boot/grub/fonts/unicode.pf2'.
grub-mknetdir: info: grub-mkimage --directory 
'/usr/lib/grub/sparc64-ieee1275' --prefix '/boot/grub' --output 
'/srv/tftp/boot/grub/sparc64-ieee1275/core.img' --format 
'sparc64-ieee1275-aout' --compression 'auto'  'tftp' 'ofnet'

.
grub-mknetdir: info: the total module size is 0x2ba48.
grub-mknetdir: info: reading /usr/lib/grub/sparc64-ieee1275/kernel.img.
grub-mknetdir: info: locating the section .text at 0x0.
grub-mknetdir: info: locating the section .rodata at 0x106b0.
grub-mknetdir: info: locating the section .data at 0x13618.
grub-mknetdir: info: locating the section .module_license at 0x14bb8.
grub-mknetdir: info: locating the section .bss at 0x14bd8.
grub-mknetdir: info: reading /usr/lib/grub/sparc64-ieee1275/bufio.mod.
grub-mknetdir: info: reading /usr/lib/grub/sparc64-ieee1275/datetime.mod.
grub-mknetdir: info: reading /usr/lib/grub/sparc64-ieee1275/boot.mod.
grub-mknetdir: info: reading 
/usr/lib/grub/sparc64-ieee1275/priority_queue.mod.

grub-mknetdir: info: reading /usr/lib/grub/sparc64-ieee1275/net.mod.
grub-mknetdir: info: reading /usr/lib/grub/sparc64-ieee1275/tftp.mod.
grub-mknetdir: info: reading /usr/lib/grub/sparc64-ieee1275/ofnet.mod.
grub-mknetdir: info: kernel_img=0xf8010005c010, kernel_size=0x14bd8.
grub-mknetdir: info: the core size is 0x40620.
grub-mknetdir: info: writing 0x40640 bytes.
Netboot directory for sparc64-ieee1275 created. Configure your DHCP 
server to point to /srv/tftp/boot/grub/sparc64-ieee1275/core.img

```

Checking the man page of `grub-mkimage` the available formats for 
sparc64 are (1) "sparc64-ieee1275-raw", (2) "sparc64-ieee1275-cdcore" 
and (3) "sparc64-ieee1275-aout". Using format 1 and 2 creates a file 
that is identified by `file` as "data". The one from the `mknetdir` run 
above is of type "SPARC executable". The "underlying" binary is ELF though:


```
root@e250-5:~# file /usr/lib/grub/sparc64-ieee1275/kernel.img
/usr/lib/grub/sparc64-ieee1275/kernel.img: ELF 64-bit MSB executable, 
SPARC V9, relaxed memory ordering, version 1 (SYSV), statically linked, 
stripped

```

I can of course create an on-disk installation and try to use this image 
instead as "core.img", but I think this is not enough and needs at least 
the module to access the bootstrap partition added in some way.


I assume we need to create a new format named "sparc64-ieee1275-elf" in 
e.g. `grub-mkimage` ([1]) and possibly other places, though I don't know 
what configuration is needed for formats in the struct "image_targets". 
The above three formats only differ in the used "id", hence I think the 
actual format is defined somewhere else.


[1]: https://salsa.debian.org/grub-team/grub/blob/master/util/mkimage.c

What do you think?

Cheers,
Frank

Re: Any progress with grub-installer?

[Frank Scheiner]

On 1/6/19 21:40, John Paul Adrian Glaubitz wrote:

Switching list for GRUB on SPARC.

On 1/6/19 9:35 PM, Frank Scheiner wrote:

I think I will work on GRUB on SPARC next to address the build issues there.


Before re-enabling COFF for GRUB, we could look into GRUB as ELF on sparc64, 
because looking at OpenBSD, their second stage bootloader is actually an ELF 
binary:

```
root@nfs:/srv/nfs/openbsd/6.3/sparc64# file ofwboot.net
ofwboot.net: ELF 64-bit MSB executable, SPARC V9, relaxed memory ordering, 
version 1 (SYSV), statically linked, stripped

root@nfs:/srv/nfs/openbsd/6.3/sparc64# file bsd.mp
bsd.mp: ELF 64-bit MSB executable, SPARC V9, total store ordering, version 1 
(SYSV), statically linked, not stripped
```

...so the sparc64 firmware seems to also support ELF binaries. And according to 
[6] this seems to work for a lot of systems. If an ELF version of GRUB can be 
provided by someone, I have a lot of sparc64 gear to test on - though not as 
many as OpenBSD supports ;-).


I do actually. I have built a version of GRUB for sparc64 with the COFF
linker options stripped off. Feel free to try the packages from [1].

If we actually don't ned COFF even on older SPARC boxes, that would be
great.

Adrian


[1] https://people.debian.org/~glaubitz/grub-sparc-elf/




Cool, thanks, will give that a try on my current local machines for a 
start and report back.


Cheers,
Frank

Re: sparc64 most important tasks

[Frank Scheiner]

On 08/07/2018 05:52 PM, John Paul Adrian Glaubitz wrote:

On 08/07/2018 05:51 PM, John Paul Adrian Glaubitz wrote:

Hi Frank!

On 08/07/2018 05:41 PM, Frank Scheiner wrote:

I'm no expert in these matters, but as per e.g. [1] it looks like the target 
"a.out-sunos-big" is not supported by the used `objcopy`.

Yep, James already mentioned that on #debian-ports (you should really join now 
;)).


Not sure if I can find the time for all this, but I can at least try 
to... :-)




Upstream removed support for a.out and coff on sparc* and mips*, see:


https://sourceware.org/ml/binutils/2018-08/msg00138.html


Ooops and already happened in April. Would be cool if we knew the reason 
for this removal.


I sometimes wonder if it means more effort to (re-)port code to a 
specific architecture than to maintain existing code for a specific 
architecture.




Aha, COFF/A.OUT support for MIPS was already restored:


https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=8e415ce8fee234cd86f29d8f4ebbbdf0f9c0b031


Hopefully this can also be done for sparc(64).

Re: sparc64 most important tasks

[Frank Scheiner]

Hi Adrian,

On 08/07/2018 11:53 AM, John Paul Adrian Glaubitz wrote:

In case anyone wonders, here's a list of top priority bugs on
sparc64 that need to be worked on:
[...]
grub2: FTBTS (no bug report yet)


https://buildd.debian.org/status/fetch.php?pkg=grub2=sparc64=2.02%2Bdfsg1-5=1533001924=0


```
[...]
if test x0 = x1; then   ../grub-macho2img boot.image boot.img; else 
objcopy  -O a.out-sunos-big  --strip-unneeded -R .note -R .comment -R 
.note.gnu.build-id -R .MIPS.abiflags -R .reginfo -R .rel.dyn -R 
.note.gnu.gold-version -R .ARM.exidx boot.image boot.img; fi


if test x0 = x1; then   ../grub-macho2img cdboot.image cdboot.img; else 
 objcopy  -O a.out-sunos-big  --strip-unneeded -R .note -R .comment -R 
.note.gnu.build-id -R .MIPS.abiflags -R .reginfo -R .rel.dyn -R 
.note.gnu.gold-version -R .ARM.exidx cdboot.image cdboot.img; fi


[...]

objcopy:boot.img: invalid bfd target

make[5]: *** [Makefile:42941: boot.img] Error 1
make[5]: *** Waiting for unfinished jobs

objcopy:cdboot.img: invalid bfd target
[...]
```

I'm no expert in these matters, but as per e.g. [1] it looks like the 
target "a.out-sunos-big" is not supported by the used `objcopy`.


[1]: https://github.com/yasuoka/openbsd-uefi/issues/1

...and indeed, the `objcopy` currently shipped with binutils v2.31.1 is 
missing "a.out-sunos-big" in the supported targets list.


```
root@ultra-10:~# objcopy -V
GNU objcopy (GNU Binutils for Debian) 2.31.1
[...]

root@ultra-10:~# objcopy -h
[...]
objcopy: supported targets: elf64-sparc elf32-sparc elf64-little 
elf64-big elf32-little elf32-big plugin srec symbolsrec verilog tekhex 
binary ihex

Report bugs to 
```

...but an older version does include it:
```
root@ultra-10:~/binutils-2.30-22# objcopy -V
GNU objcopy (GNU Binutils for Debian) 2.30
[...]

root@ultra-10:~/binutils-2.30-22# objcopy -h
[...]
objcopy: supported targets: elf64-sparc elf32-sparc a.out-sparc-linux 
a.out-sunos-big elf64-little elf64-big elf32-little elf32-big plugin 
srec symbolsrec verilog tekhex binary ihex

Report bugs to 
```

Cheers,
Frank

Re: Latest netinst iso

[Frank Scheiner]

On 08/07/2018 02:56 AM, Fred wrote:

[...]
Out of frustration I changed the cdrom drive and the installation 
proceeded with only one problem.  The network has to be configured 
manually but either the installer didn't provide this option or I missed 
it.


It's there.

When you hit "Continue" in the "Network autoconfiguration failed" 
dialogue, the next dialogue offers an option named "Configure network 
manually". I tested this in the default non-expert installation mode. In 
the expert installation mode you should be able to choose that option 
right from the start after you select the "Configure the network" step.


Cheers,
Frank

Re: Latest netinst iso

[Frank Scheiner]

On 08/07/2018 11:02 AM, Thomas Schmitt wrote:

Hi,

Fred wrote:

[...] DVD drive [...]


Frank Scheiner wrote:

if a specific CDROM drive and
the assumed "compatible" driver don't work together, this results in a
situation like yours


Oh, sorry for my ignorance, as my Ultra 10 has a CDROM drive installed 
instead of a DVDROM drive I was mislead to write "CDROM drive" (although 
Fred had problems with a DVDROM drive) but that shouldn't make much of a 
difference, or?




All DVD capable drives at IDE are supposed to work by the SCSI/MMC protocol
via ATAPI. So there is few chance that the drive itself is not matched by
the kernel's sr driver.

If the drive does not show up as Linux device, i would rather bet on
a driver mismatch with the IDE/ATAPI controller of the machine.


But interestingly the assumed same controller driver works well for 
Gregor's and my Ultra 10 and it also works well when Fred uses a CDROM 
drive.


What could be the reason for that?

Maybe Fred's Ultra 10 is using another revision of the CMD 646 IDE 
controller - my Ultra 10 for example uses a CMD 646U - or a DMA mode is 
used for the DVDROM drive that is not working correctly with the CMD 646.


I seem to remember to have read about problems with CMD IDE controllers 
used  in some Sun machines in the past, but cannot find the info now. 
But I did find an interesting post on the NetBSD sparc list ([1]), which 
gives some background info on different revisions of CMD 646 
controllers. So every CMD 646 controller below 646U2 seems to do things 
wrong with UltraDMA modes or it only works with very specific drives.


[1]: http://mail-index.netbsd.org/port-sparc/2001/12/16/0005.html

And it could be that the CDROM drives used (by me and later also by 
Fred) just support MWDMA or PIO modes that work well with all CMD 646 
revisions. That the DVDROM drive works when used from the firmware could 
mean that OBP generally does not activate DMA or specifically disables 
it for the CMD 646 controller.




UPDATE: I just tested an UltraDMA2 (UDMA/33) capable DVDROM drive in my 
Ultra 10 and didn't have any problems. But it also looks like the 
controller driver specifically disables UltraDMA modes and only 
configures a maximum of MWDMA2:

```
[   35.255080] scsi host0: pata_cmd64x
[   35.300865] hme :01:01.1 enp1s1f1: renamed from eth0
[   35.369538] scsi host1: pata_cmd64x
[   35.432494] ata1: PATA max MWDMA2 cmd 0x1fe02c0 ctl 0x1fe02c8 
bmdma 0x1fe02c00020 irq 14
[   35.542765] ata2: PATA max MWDMA2 cmd 0x1fe02c00010 ctl 0x1fe02c00018 
bmdma 0x1fe02c00028 irq 14

[   35.653931] pata_cmd64x: active 10 recovery 10 setup 3.
[   35.653947] pata_cmd64x: active 10 recovery 10 setup 3.
[   35.855471] ata1.01: both IDENTIFYs aborted, assuming NODEV
[   35.858949] ata1.00: ATA-5: WDC WD800AB-00CBA0, 03.06A03, max UDMA/100
[   35.940006] ata1.00: 156301488 sectors, multi 0: LBA
[   36.003451] pata_cmd64x: active 3 recovery 1 setup 1.
[   36.003471] pata_cmd64x: active 3 recovery 1 setup 1.
[   36.009072] ata1.00: configured for MWDMA2
[   36.061880] scsi 0:0:0:0: Direct-Access ATA  WDC WD800AB-00CB 
6A03 PQ: 0 ANSI: 5

[   36.169978] pata_cmd64x: active 10 recovery 10 setup 3.
[   36.169992] pata_cmd64x: active 10 recovery 10 setup 3.
[   36.327225] ata2.00: ATAPI: SAMSUNG DVD-ROM SD-616Q, F401, max UDMA/33
[   36.409059] pata_cmd64x: active 3 recovery 1 setup 1.
[   36.409075] pata_cmd64x: active 3 recovery 1 setup 1.
[   36.411667] ata2.00: configured for MWDMA2
[   36.465435] scsi 1:0:0:0: CD-ROMSAMSUNG  DVD-ROM SD-616Q 
F401 PQ: 0 ANSI: 5
[   36.642314] sd 0:0:0:0: [sda] 156301488 512-byte logical blocks: 
(80.0 GB/74.5 GiB)

[   36.745958] sd 0:0:0:0: [sda] Write Protect is off
[   36.807635] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[   36.807957] sd 0:0:0:0: [sda] Write cache: enabled, read cache: 
enabled, doesn't support DPO or FUA
[   36.926295] sr 1:0:0:0: [sr0] scsi3-mmc drive: 16x/48x cd/rw xa/form2 
cdda tray

[   37.023810] cdrom: Uniform CD-ROM driver Revision: 3.20
[   37.098287] sr 1:0:0:0: Attached scsi CD-ROM sr0
[   37.250888]  sda: sda1 sda2 sda3
[   37.299576] sd 0:0:0:0: [sda] Attached SCSI disk
```

Retesting with the CDROM drive shows that it gets also configured to MWDAM2:
```
[   36.294580] ata2.00: ATAPI: CRD-8322B, 1.05, max MWDMA2
[   36.360599] pata_cmd64x: active 3 recovery 1 setup 1.
[   36.360615] pata_cmd64x: active 3 recovery 1 setup 1.
[   36.365323] ata2.00: configured for MWDMA2
[   36.418764] scsi 1:0:0:0: CD-ROM   LGCD-ROM CRD-8322B 
1.05 PQ: 0 ANSI: 5
[   36.605717] sr 1:0:0:0: [sr0] scsi3-mmc drive: 32x/32x cd/rw xa/form2 
cdda tray

[   36.702402] cdrom: Uniform CD-ROM driver Revision: 3.20
[   37.055470] sr 1:0:0:0: Attached scsi CD-ROM sr0
```

So actually any support for UltraDMA in the DVDROM or CDROM drive does 
not seem to make a difference.


Cheers,
Frank

Re: Latest netinst iso

[Frank Scheiner]

On 08/07/2018 09:45 AM, Frank Scheiner wrote:

On 08/06/2018 10:39 PM, Fred wrote:

On 08/06/2018 11:20 AM, Frank Scheiner wrote:

 >> [...]
The CDROM drive in my Ultra 10 is attached to IDE channel #2 (the IDE 
port farer away from the CPU) and configured as Master device.


And I just now tested with the ISO in question (from 20180516-18:22) 
and didn't recognize an issue. Sure, hardware detection takes long on 
the Ultra 10, but it eventually succeeds and the CDROM drive is 
correctly detected.

 >> [...]

Hi Frank,
The MB has only three connectors: floppy, IDE HD and IDE cdrom.


But the two existing IDE ports are not labeled as such on the PCB, there 
is J14 which is the second IDE channel and J13 which is the first IDE 
channel (both according to [1]). At least that's the case on the system 
board PCB of my Ultra 10 and hence I referenced my known good 
configuration in this way.


Correction: The first IDE channel is labeled J15 not J13.

Re: Latest netinst iso

[Frank Scheiner]

On 08/06/2018 10:39 PM, Fred wrote:

On 08/06/2018 11:20 AM, Frank Scheiner wrote:

>> [...]
The CDROM drive in my Ultra 10 is attached to IDE channel #2 (the IDE 
port farer away from the CPU) and configured as Master device.


And I just now tested with the ISO in question (from 20180516-18:22) 
and didn't recognize an issue. Sure, hardware detection takes long on 
the Ultra 10, but it eventually succeeds and the CDROM drive is 
correctly detected.

>> [...]

Hi Frank,
The MB has only three connectors: floppy, IDE HD and IDE cdrom.


But the two existing IDE ports are not labeled as such on the PCB, there 
is J14 which is the second IDE channel and J13 which is the first IDE 
channel (both according to [1]). At least that's the case on the system 
board PCB of my Ultra 10 and hence I referenced my known good 
configuration in this way.


[1]: 
http://www.shrubbery.net/~heas/sun-feh-2_1/Devices/System_Board/SYSBD_Ultra5_10.html#0066


I 
changed the DVD drive jumper from cable select to master but the 
installer still could not find it.  Whatever loaded the installer 
program didn't have any problem using the drive.


This is perfectly normal, as soon as the Linux kernel is started it 
usually uses its own drivers to access devices. And if a specific CDROM 
drive and the assumed "compatible" driver don't work together, this 
results in a situation like yours:


Your firmware (OBP) can load and start the boot loader (SILO) from the 
CDROM, which itself - presumably using the same drivers as the firmware 
- can load and start the Linux kernel (plus initrd) from CDROM. The 
kernel then uses its own driver to access or to try to access the CDROM 
drive and fails for some reason.

Re: Latest netinst iso

[Frank Scheiner]

On 08/06/2018 07:34 PM, Gregor Riepl wrote:

Could you be also more specific about which instructions you followed to make
it work for you?


The specific problem I had was due to the sparc64 installation requiring
unstable repositories, which is apparently not very well supported in the
Debian installer.


Thanks for the clarification.



I was able to get around this by just installing the minimal base system,
booting into it, fixing the repositories manually, then installing the
standard system package (i.e. what tasksel would install) by hand. I also
needed to dig a bit to find a mirror carrying sparc64 packages.


You should be able to avoid this in future installations by just using 
"ftp.ports.debian.org" and "/debian-ports/" when asked for mirror and 
directory respectively.




It should also be noted that the desktop tasks are currently uninstallable
because certain packages are missing from sparc64, but that is a minor issue.


There's currently a lot of information on the sparc64 page ([1]) but I don't
know of anything specific to the Ultra 10.


Mostly the part under "Caveats": https://wiki.debian.org/Sparc64#Known_Caveats


Ok, I see. Maybe this should be changed to the information above, 
because AFAIK the issue with the Debian Ports GPG key not recognized by 
the installer is already solved since quite a while, but using a 
different mirror and directory is obviously not always expected or known 
by (new) users. I'll have a look.

Re: Latest netinst iso

[Frank Scheiner]

On 08/06/2018 05:01 PM, Fred wrote:

On 08/06/2018 02:18 AM, Frank Scheiner wrote:

Dear Gregor,
[...]
Cheers,
Frank



Hi,
I am the original poster for this thread.


Yes I know, but up to the point, where I asked Gregor to provide more 
details about the problems he experienced, you didn't report a problem 
at all. Or am I missing something?


I tried installing the 
NETINST.iso and also had a problem.  The U10 has an HP DVD drive in it. 
The install CD seemed to load ok and the installer started.  When it got 
to the detecting hardware function it decided that no cdrom drive was 
installed and would not proceed. I am going to install the original Sun 
cdrom drive and try again when I have time.


In addition to the information Adrian asked for, it could be interesting 
to know, to which IDE channel your CDROM drive is attached and how it is 
configured (Master, Slave, Cable select).


The CDROM drive in my Ultra 10 is attached to IDE channel #2 (the IDE 
port farer away from the CPU) and configured as Master device.


And I just now tested with the ISO in question (from 20180516-18:22) and 
didn't recognize an issue. Sure, hardware detection takes long on the 
Ultra 10, but it eventually succeeds and the CDROM drive is correctly 
detected.


Cheers,
Frank

Re: Latest netinst iso

[Frank Scheiner]

Dear Gregor,

On 08/06/2018 10:40 AM, Gregor Riepl wrote:

The latest net install image I have found is dated 18 May 2018. Is that the
latest version?  Will that install on an Ultra 10 without problems?


I wasn't able to install with the netinst ISO on my Ultra 10 without problems,


Are you referring to the ISO dated 18 May 2018 or to an ISO from another 
date?


And what problems did you experience on your Ultra 10?

Because the last time I checked an installation on my Ultra 10 - albeit 
with the ISO created on 20180516-10:56 - it worked for me. BTW the exact 
creation date can be found in `/boot/debian.txt` or `/README.txt` on the 
ISO.



but if you follow the instructions on the Debian Wiki, it should work fine.


Could you be also more specific about which instructions you followed to 
make it work for you?


There's currently a lot of information on the sparc64 page ([1]) but I 
don't know of anything specific to the Ultra 10.


[1]: https://wiki.debian.org/Sparc64

Cheers,
Frank

Re: Installation tests with GRUB on GPT disks

[Frank Scheiner]

On 07/28/2018 06:34 PM, John Paul Adrian Glaubitz wrote:

On 05/18/2018 10:15 PM, Frank Scheiner wrote:

BTW although this ISO ([1]) already has d-i/silo-installer removed, the 
d-i/grub-installer on it does not yet include the patch you committed on May 
15th. But
one can fix that during installation.


I have uploaded both partman-auto and grub-installer with the missing
patches for sparc64 now, so we should be all set now.

The upload got delayed because Christian Perrier stepped down as an
uploader for the d-i stuff, so I have stepped up now to help with
the efforts.


Great, that should speed up the inclusion of future changes (e.g. for 
ppc64 capable Power Macs).




Let me know when there are other issues that need attention in d-i.


I'm currently not aware of any issues with d-i on sparc64.

Re: installing current ports iso

[Frank Scheiner]

Hi,

On 05/29/2018 04:34 PM, Anatoly Pugachev wrote:

and indeed , http://ftp.ports.debian.org/debian-ports/dists/ does not
have buster subdirectory.



Doesn't it work to continue and then choose "sid" as release?

Cheers,
Frank

Re: Sun Blade 1000

[Frank Scheiner]

Hi Rick, hi Tom,

On 05/17/2018 03:09 PM, Rick Leir wrote:

Tom, Frans
Yes, perhaps it is fixed. However there are not many eyes on this 
problem, so maybe it's not fixed.


There was a suggestion that this driver would only fail during 
installation, but would be fine if you had booted from some SCSI disk, 
and are mounting the FibreChannel disk from a running Linux.


I tried Debian GNU/Linux Sid on my 280R (in storage) yesterday, though I 
didn't do an installation but netbooted from a ready-made NFS root FS.


I can confirm that Sid works on the 280R and hence most likely will also 
work on a Blade 1000, but still the qla2xxx driver makes problems as 
soon as it begins working - as Frans already mentioned.


At first the qla2xxx module didn't work due to missing firmware, but 
after installing the missing firmware (from the `firmware-qlogic` 
package) and rebooting, the currently used kernel 4.16.5 panics soon 
(about 15 seconds) after the qla2xxx module is loaded (see below).


So when testing a Debian installation on a Blade 1000, one should also 
prepare an internal/external SCSI disk for installation. There might be 
a 68 pin SCSI connector plus power connector available below the disc 
drive. The qla2xxx module can be blacklisted with e.g. 
`modprobe.blacklist=qla2xxx` in the kernel command line if it creates 
problems during installation.


```
[   45.422523] qla2xxx [:00:00.0]-0005: : QLogic Fibre Channel HBA 
Driver: 10.00.00.05-k.

[...]
[   45.698591] qla2xxx [0001:00:04.0]-001d: : Found an ISP2200 irq 17 
iobase 0x82de312a.

[   45.812219] qla2xxx [0001:00:04.0]-0050:2: No matching ROM signature.
[...]
[   46.112936] qla2xxx [0001:00:04.0]-0065:2: Falling back to 
functioning (yet invalid -- WWPN) defaults.

[   46.234884] qla2xxx [0001:00:04.0]-0069:2: NVRAM configuration failed.
 St[   46.335599] qla2xxx 0001:00:04.0: firmware: 
direct-loading firmware ql2200_fw.bin

[...]
[   61.869433] ERROR(1): Cheetah error trap taken afsr[0800] 
afar[07fd00100040] TL1(0)
[   61.987605] ERROR(1): TPC[103917c8] TNPC[103917cc] O7[103915f0] 
TSTATE[4411001602]

[   62.086349] ERROR(1):
[   62.086700] TPC
[   62.193646] ERROR(1): M_SYND(0),  E_SYND(0)
[   62.247720] ERROR(1): Highest priority error (0800) "Bus 
error response from system bus"
[   62.367084] ERROR(1): D-cache idx[0] tag[] 
utag[] stag[]
[   62.491042] ERROR(1): D-cache data0[] 
data1[] data2[] data3[

]
[   62.638956] ERROR(1): I-cache idx[0] tag[] 
utag[] stag[] u[]

 l[]
[   62.808637] ERROR(1): I-cache INSN0[] 
INSN1[] INSN2[] INSN3[

]
[   62.956564] ERROR(1): I-cache INSN4[] 
INSN5[] INSN6[] INSN7[

]
[   63.104483] ERROR(1): E-cache idx[100040] tag[0001fe20]
[   63.181372] ERROR(1): E-cache data0[124ffb93193fffe0] 
data1[c45fa75fca5e2408] data2[c258a980ca77a7b7] data3[82006001cc5e2400

]
[   63.329380] Kernel panic - not syncing: Irrecoverable deferred error 
trap.

[   63.329380]
[   63.438349] CPU: 1 PID: 188 Comm: systemd-udevd Not tainted 
4.16.0-1-sparc64-smp #1 Debian 4.16.5-1

[   63.556579] Call Trace:
[   63.587742]  [0046b8a8] panic+0xe8/0x2a0
[   63.647533]  [0042a470] cheetah_deferred_handler+0x270/0x440
[   63.730240]  [00405e48] c_deferred+0x18/0x24
[   63.794701]  [103917c8] qla2x00_mailbox_command+0x928/0x10a0 
[qla2xxx]
[   63.62]  [103944e8] qla2x00_init_firmware+0xe8/0x240 
[qla2xxx]

[   63.978449]  [103861d4] qla2x00_init_rings+0x374/0x460 [qla2xxx]
[   64.065740]  [1038f364] 
qla2x00_initialize_adapter+0x324/0x6c0 [qla2xxx]

[   64.162201]  [1037d7ec] qla2x00_probe_one+0x1f2c/0x3080 [qla2xxx]
[   64.250560]  [007d77cc] pci_device_probe+0xcc/0x160
[   64.322956]  [0085cd48] driver_probe_device+0x2a8/0x4c0
[   64.399932]  [0085d044] __driver_attach+0xe4/0x120
[   64.471186]  [0085a654] bus_for_each_dev+0x54/0x80
[   64.542433]  [0085c47c] driver_attach+0x1c/0x40
[   64.610247]  [0085bd28] bus_add_driver+0x1a8/0x2a0
[   64.681494]  [0085dd34] driver_register+0x74/0x120
[   64.752746]  [007d5d20] __pci_register_driver+0x40/0x60
[   64.829744] Press Stop-A (L1-A) from sun keyboard or send break
[   64.829744] twice on console to return to the boot prom
```

Frank

Re: Installation tests with GRUB on GPT disks

[Frank Scheiner]

On 05/19/2018 10:03 AM, John Paul Adrian Glaubitz wrote:

On 05/18/2018 10:16 PM, Frank Scheiner wrote:

Ok, thank you.


Ok, after testing I can confirm that at least on my T5220 a separate partition 
for `/boot` is not needed. I'll try to check what my oldest UltraSPARC machines
make out if it.


Yes, but as you correctly mentioned, without a separate /boot partition, there
is always the risk that the blocklist method fails if the GRUB files are put
too far at the end of the / filesystem. We should maybe forward this question
upstream.


Yeah, I just thought about figuring out by experiment if there are any 
limits on the older UltraSPARC machines available to me.



One thing to note is, that per default GRUB uses `quiet` in the kernel command 
line, so depending on the speed of a machine and/or its disk drives, it might at
first look that nothing happens after GRUB has loaded kernel and initrd 
although the kernel is actually booting.


I *think* the GRUB parameters are set in finish-install, but
I am not sure.

See: 
https://salsa.debian.org/installer-team/finish-install/tree/master/finish-install.d


I had a look, but this seems to be defined elsewhere. I traced it back 
to the grub-ieee1275 package which creates `/etc/default/grub` in its 
`postinst` script. This includes the var `GRUB_CMDLINE_LINUX_DEFAULT` 
which defaults to "quiet" as per [1] => [2] => [3].


[1]: https://salsa.debian.org/grub-team/grub/blob/master/debian/templates.in

[2]: https://salsa.debian.org/grub-team/grub/blob/master/debian/rules#L441

[3]: https://salsa.debian.org/grub-team/grub/blob/master/debian/rules#L85

Hm, I actually don't want to divert from the defaults - although maybe 
the defaults sometimes might lead to irritations (no output for dozens 
of seconds). Few people have that much patience. ;-)


Cheers,
Frank

Re: Installation tests with GRUB on GPT disks

[Frank Scheiner]

On 05/19/2018 09:49 AM, John Paul Adrian Glaubitz wrote:

In the meantime I found a way to extract the initrd from the TILO image. But 
trying an installation with it and the CDROM kernel (which I assume is 
identical to
the kernel inside of the TILO image) showed some issues (missing Debian ports 
keys, defaults to buster, debootstrap fails to install initramfs-tools, etc.) 
that
prevented a successful installation.


Please search the debian-sparc mailing list regarding the netboot topic,
we have discussed netboot in the past. Maybe this discussion can shed
some light onto your questions:


https://lists.debian.org/debian-sparc/2017/04/msg2.html


Thanks for this hint, I believe I read this already in the past, but 
then forgot about it and hence - maybe again - wrongly assumed that the 
installer image is a TILO image where it is not.

Re: Installation tests with GRUB on GPT disks

[Frank Scheiner]

On 05/16/2018 10:44 PM, John Paul Adrian Glaubitz wrote:

1. Can you test whether we can drop the /boot partition on Sun
     partition tables?


I actually don't remember if I tested such a configuration. At least 
d-i/grub-installer should support this now. I'll check that on my T5220 and 
report back.


Ok, thank you.


Ok, after testing I can confirm that at least on my T5220 a separate 
partition for `/boot` is not needed. I'll try to check what my oldest 
UltraSPARC machines make out if it.



So, to summarize:

1. Can you test whether adding "$iflabel { sun }" creates the
separate /boot partition for you?


Just tested this now and yes:

```
50 500 100 ext2 

$iflabel { sun } 

method{ format } 

format{ } 

use_filesystem{ } 

filesystem{ ext2 } 


mountpoint{ /boot } .
```

...creates the separate partition for `/boot` on my T5220 and:



2. Do you need "$bootable { }" for /boot to work with GRUB?


...no, the bootable flag seems to be unneeded by GRUB (or OBP), as the 
system booted without an issue after the installation finished.


One thing to note is, that per default GRUB uses `quiet` in the kernel 
command line, so depending on the speed of a machine and/or its disk 
drives, it might at first look that nothing happens after GRUB has 
loaded kernel and initrd although the kernel is actually booting.


Frank

Re: Installation tests with GRUB on GPT disks

[Frank Scheiner]

On 05/16/2018 08:53 PM, John Paul Adrian Glaubitz wrote:

On 05/16/2018 08:15 PM, Frank Scheiner wrote:

Unfortunately booting the CDROM kernel and initrd via GRUB2 over the network 
did not work as expected by me:

After the installer started it wants to load its components from the 
non-existing CDROM, of course... :-(

There is no command line switch for the installer (kernel) that will make it 
behave like a netboot installer, right?


This is expected. You cannot use the cdrom debian-installer initrd for netboot
and vice versa. If you want to perform a netboot, you have to use the initrd
for netboot which is inside the debian-installer-images tarball as found
on the FTP servers in the pool-sparc64/main/d/debian-installer subdirectory.


Ah, good to know.



Since the d-i current image is outdated, use the one from here:


https://people.debian.org/~glaubitz/debian-cd/debian-installer-images_20171204_sparc64.tar.gz


Please note that even the "NETINST" images are still CD images. Real netboot
images just require a kernel and initrd. The netboot initrd contains the
necessary network drivers and is designed to fetch udebs over the internet.


I had a look at the netboot "boot.img". The problem is - or was - that I 
didn't know how to extract the initrd from this TILO image.


In the meantime I found a way to extract the initrd from the TILO image. 
But trying an installation with it and the CDROM kernel (which I assume 
is identical to the kernel inside of the TILO image) showed some issues 
(missing Debian ports keys, defaults to buster, debootstrap fails to 
install initramfs-tools, etc.) that prevented a successful installation.


We could start a separate thread for these issues and we should maybe 
also change from TILO image to just kernel and netboot initrd or only 
netboot initrd (using the CDROM kernel in addition), as we now know how 
to netboot these with GRUB.


So for testing I again used the ISO.

BTW although this ISO ([1]) already has d-i/silo-installer removed, the 
d-i/grub-installer on it does not yet include the patch you committed on 
May 15th. But one can fix that during installation.


[1]: 
https://people.debian.org/~glaubitz/debian-cd/debian-10.0-sparc64-NETINST-1.iso


Frank

Re: Installation tests with GRUB on GPT disks

[Frank Scheiner]

On 05/16/2018 09:16 PM, John Paul Adrian Glaubitz wrote:

Ok, I just successfully tested this change.

Two questions left:

1. Can you test whether we can drop the /boot partition on Sun
partition tables?


I actually don't remember if I tested such a configuration. At least 
d-i/grub-installer should support this now. I'll check that on my T5220 
and report back.


Just a thought:

Could it happen that - depending on the size of the root FS and the 
amount of packages installed - the GRUB image gets installed so far away 
from the start of a disk - it usually gets installed at the end of an 
installation - that older machines with older OBP versions could have 
problems to access it via block lists? Are there any such limits?


If yes, a separate smaller partition for "/boot" might be required in 
such a case.




2. Now that we can use GRUB, what about updating the default
partitioning scheme? Maybe one that is inspired by the layout
used on ppc64el:

> 
https://salsa.debian.org/installer-team/partman-auto/tree/master/recipes-ppc64el


You want to add "$defaultignore{ }" for the "/boot" partition, so it's 
only active by default for installations using LVM? Maybe there are also 
other use cases for a separate "/boot" partition than LVM. Such a change 
would make it harder for people with those other use cases then.




3. GRUB installs fine now on Sun partition tables without any further ado?


For my tested configuration - t5220, atomic recipe, single disk - yes.



4. And, just to be safe: Your previous mail contained hashes
before the partition layout lines (#). You did not actually
have those in your atomic file, correct?


Correct, those # marks were just for "markup" and not included in the 
actual recipe I modified from the installer environment.


Frank

Re: Installation tests with GRUB on GPT disks

[Frank Scheiner]

On 05/16/2018 07:11 PM, John Paul Adrian Glaubitz wrote:

I'll give it a try on my T5220 with kernel and initrd from the image you 
provided today and report back.


Thanks. We should definitely test this before committing those changes.


Unfortunately booting the CDROM kernel and initrd via GRUB2 over the 
network did not work as expected by me:


After the installer started it wants to load its components from the 
non-existing CDROM, of course... :-(


There is no command line switch for the installer (kernel) that will 
make it behave like a netboot installer, right?


So I wrote the image to a CDRW and started the installation from there.

The partitioning worked correctly with the added snippet and created a 
layout that resembles the recipe without the snippet:


```
~ # fdisk -l 

Disk /dev/sda: 149.1 GiB, 160041885696 bytes, 312581808 sectors 

Units: sectors of 1 * 512 = 512 bytes 

Sector size (logical/physical): 512 bytes / 512 bytes 


I/O size (minimum/optimal): 512 bytes / 512 bytes

/lib/partman/recipes-sparc64 # nano 30atomic

## Added this part on top ##
## 10 10 10 free
##  $iflabel{ gpt }
##  $reusemethod{ }
##  method{ biosgrub } .

/lib/partman/recipes-sparc64 # archdetect 


sparc64/sun4v_sun

## Partitioning took place ##

/lib/partman/recipes-sparc64 # fdisk -l
Disk /dev/sda: 149.1 GiB, 160041885696 bytes, 312581808 sectors
Geometry: 255 heads, 63 sectors/track, 19457 cylinders
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: sun

Device Start   End   Sectors   Size Id Type Flags
/dev/sda1  0192779192780  94.1M  1 Boot
/dev/sda2 192780 296656289 296463510 141.4G 83 Linux native
/dev/sda3  0 312576704 312576705   149G  5 Whole disk
/dev/sda4  296656290 312576704  15920415   7.6G 82 Linux swap
```

If it creates the bios_grub "partition" on your gpt capable machine with 
the snippet included, it could be save for inclusion in d-i/partman-auto.


Frank

Re: Installation tests with GRUB on GPT disks

[Frank Scheiner]

On 05/16/2018 05:23 PM, John Paul Adrian Glaubitz wrote:

```
10 10 10 free
$iflabel{ gpt }
$reusemethod{ }
method{ biosgrub } .
```
Did you test whether this becomes a no-op one systems with Sun-label?


I don't remember, but I'd say no, because I wrote "[...] if the 
assumption is correct that "$iflabel{ gpt }" line will only make this 
part effective on GPT partitioned disks" in early March.


I'll give it a try on my T5220 with kernel and initrd from the image you 
provided today and report back.




I can test whether it does the right thing on GPT labels, provided that
the recipe files can be found somewhere on the disk where I can change
them.


The recipes are located below `/lib/partman/` in the installer 
environment. They can be modified before entering the partitioning step 
(`nano` is available in the installer environment) - even multiple times 
if you can repeat the partitioning step (e.g. in expert mode).


Frank

Re: Installation tests with GRUB on GPT disks

[Frank Scheiner]

On 05/16/2018 03:03 PM, John Paul Adrian Glaubitz wrote:

Adding those recipes for partman-auto will resolve the issue.


Should we add additional recipes or better modify the existing sparc recipe?


However, we
should probably add a warning like we had for SILO which reminds users
they have to add a bios_grub partition on a GPT machine:


https://anonscm.debian.org/git/d-i/attic/silo-installer.git/tree/check.d/silo_check


Does any of the other architectures which use GRUB require a bios_grub 
partition?


The "default" recipes use a bios_grub partition (see e.g. [1]). It's 1 
MiB in size, but I expect that when partitioned on a gpt capable system 
this will result in 1 MiB space at the beginning of the disk and a 1 MiB 
partition after it. I assume this is created automatically on gpt 
capable systems, because of:


```
$iflabel{ gpt }
```

I don't know if this is required for GRUB2 on i386/amd64 though, but 
maybe yes, so GRUB2 doesn't touch the 1 MiB space at the beginning.


[1]: 
https://salsa.debian.org/installer-team/partman-auto/blob/master/recipes/atomic

Re: Installation tests with GRUB on GPT disks

[Frank Scheiner]

Hi,

On 05/16/2018 01:29 PM, John Paul Adrian Glaubitz wrote:

Hi!

I have been testing the installation of GRUB in debian-installer on disks
with GPT labels. Unfortunately, that doesn't work as grub-install
complains it cannot find the filesystem for /dev/vdiska1.

Looking at the partition table with parted, it seems that the actual problem
is a corrupted GPT partition table (see below).

Since a new partition table is created by debian-installer, it shouldn't be
corrupted at this point. So, I'm wondering what problem we are running
into.


Maybe it wasn't created correctly by partman:

On [1] Eric has a ca. 7 MiB partition between 1 MiB at the beginning of 
the disk and the remainder of the disk. It's garbled on GitHub, so here 
it is reformatted:


```

Number Start  EndSize   File system Name  Flags
1  1049kB 8389kB 7340kB bios_grub   bios_grub
2  8389kB 1151MB 1143MB ext3boot
3  1151MB 600GB  599GB  lvm
```

[1]: 
https://github.com/esnowberg/grub2-sparc/wiki#installation-instructions-for-sparc-t4-and-above


During my testing end of February/beginning of March this partition was 
needed, because otherwise the gpt label was corrupted after grub-install 
ran IIRC - i.e. similar to what you saw. I don't know the exact size 
requirements for this partition though, so just rounded up to 10 MiB 
which worked fine.


I submitted a patch ([2]) which adds specific recipes for gpt capable 
systems which add the additional 10 MiB partition. Partman than creates 
this partition after the first 1 MiB on the disk in question. The post 
also contains an alternative approach which might also work (i.e. just 
extending the sparc recipes).


[2]: https://lists.debian.org/debian-sparc/2018/03/msg7.html

Frank

Re: 8e9800 Fast Data Access MMU Miss

[Frank Scheiner]

On 05/14/2018 08:27 PM, Dennis Clarke wrote:
But as the GRUB2 part alone is already useful for people that are 
familiar with the supporting service infrastructure, I just finished 
up this part and put it into the Debian wiki. I will add more 
information later if need be - I have to check the available 
information about network services first.


The methods described on [1] work for me to network boot my UltraSPARC 
gear, but you need kernel and initramfs as separate files.


I will go take a look at that.  Perhaps even separate the NFS and TFTP
services into two machines just because I can.  I don't think that there
is any need to worry about the RARP and IP address bits for now as that
all seems to happen in three quick packets from the forth firmware on
most sparc units with a "net boot" command.  Note that the tftp request
does not require a suffix ".SUN4U" on the filename.


Ah yes, you're correct. I corrected that part just now. Not sure where I 
got the idea from, maybe I mixed things with older Sun systems (e.g. 
sun4m, sun4d, sun4c).


Cheers,
Frank

Re: regarding the M3000 issue on the wiki

[Frank Scheiner]

On 05/14/2018 09:16 PM, Dennis Clarke wrote:

It may be worth testing an M3000 unit that has a Fujitsu SPARC-VII+
  processor in it.

I have one :

$ psrinfo -pv
The physical processor has 8 virtual processors (0-7)
   SPARC64-VII+ (portid 1024 impl 0x7 ver 0xa1 clock 2860 MHz)

>

So if the cpu is the issue then it may be interesting to look at.


Please give it a try and report back!

Cheers,
Frank

Re: sparc64 debian netboot chicken and egg

[Frank Scheiner]

On 05/14/2018 08:37 PM, Dennis Clarke wrote:


Looking at https://wiki.debian.org/Sparc64#Network_booting it says :

     "If you already have a working installation of Debian GNU/Linux
   Sid for sparc64"

nope.

So this is chicken and egg here.


But I also later ([1]) wrote that you can create the required directory 
structure on an arbitrary amd64 system. And most likely this will also 
work on any non-sparc64 system that runs Debian GNU/Linux Sid because of 
Multiarch support.


[1]: https://wiki.debian.org/Sparc64#Preparing_GRUB2_files_for_TFTP_service



I think what I need to do is just get a cdrom ( not a dvd ) and attach
it to an IDE bus on the netra motherboard and then hope that there
exists an iso which will work.


No need for that, see above. You should be able to netboot with the 
kernel and initramfs from a recent Debian netinstall ISO, e.g. [2]. 
Those files are located in `/boot` as `sparc64` and `initrd.gz` 
respectively.


[2]: 
https://cdimage.debian.org/cdimage/ports/debian-10.0-sparc64-NETINST-1.iso


 However this means ripping the netra out

of the rack and playing around with hardware. None of this is reasonable
with an M4000 that I have standing by as that thing is a monster to
lift.


Although GRUB2 will start on a system using SPARC64 CPUs from Fujitsu - 
I tested this with a PRIMEPOWER 250 with SPARC64 V+ CPUs - the Linux 
kernel doesn't yet support these CPUs apart from the SPARC64 X AFAIK 
(see last paragraph in [3] and [4]).


[3]: https://wiki.debian.org/Sparc64#Installing_the_Debian_SPARC64_Port
[4]: https://oss.oracle.com/projects/linux-sparc/

Cheers,
Frank

Re: 8e9800 Fast Data Access MMU Miss

[Frank Scheiner]

Hi all,

On 05/13/2018 07:21 PM, Dennis Clarke wrote:

On 05/13/2018 01:11 PM, Jan Engelhardt wrote:


On Sunday 2018-05-13 18:05, Dennis Clarke wrote:

Can you try the netboot image contained in this tarball [1]?


Hrmm .. new problem. I think that the firmware on ye older Sun Netra
type units was limited as to how much it could fetch and deal with
for a "net boot" process. Looks to be precisely 10MB :


And I wonder if they ever bumped it at all, because it is not a 
problem for

Solaris, and 10 MB is ample space for a "bootloader" of sorts (think
wanboot(1m)/inetboot(1m)). Perhaps grub2 is the answer to that, since 
I have

never gotten TILO to do it.



Me neither.  I tested my setup of tftp/dhcp/nfs etc with a net install
of Solaris 10 u11 and that works fine. That is actually using grub from
way back at version 1.97 ( or there abouts ) however it was madly hacked
inside Sun and then more hackary was done during the OpenSolaris
project. Definately grub. I should go have a look and see if I have the
sources laying about somewhere.  Could be useful.

Regardless ... I will keep poking at this with a stick and see what I
  can come up with.


Sorry, I'm a little late but was quite occupied by other things recently.

I'm using GRUB2 for netbooting my UltraSPARC and NewWorld PowerPC gear 
since a while and also already started to document the process to get it 
going. But for netbooting it can get quite elaborate if you want to 
write an all-in-one how-to (incl. all needed or useful services, e.g. 
RARP, DNS, DHCP, TFTP and NFS) so one easily gets carried away and 
rambles on. :-/


But as the GRUB2 part alone is already useful for people that are 
familiar with the supporting service infrastructure, I just finished up 
this part and put it into the Debian wiki. I will add more information 
later if need be - I have to check the available information about 
network services first.


The methods described on [1] work for me to network boot my UltraSPARC 
gear, but you need kernel and initramfs as separate files.


Cheers,
Frank

[1]: https://wiki.debian.org/Sparc64#Network_booting

Re: Ultra5 successful install - PGX64 issues

[Frank Scheiner]

On 04/14/2018 08:53 PM, Dennis Clarke wrote:

On 04/14/2018 08:26 PM, Frank Scheiner wrote:
I have successfully tested GRUB on a PRIMEPOWER 250 with SPARC64 V+ 
(see [1]). The problem is that the Linux kernel doesn't work on any 
Fujitsu SPARC64 gear currently, not even on newer M-class machines 
(see [2]).

So anything like this is a waste of time to try ?

$ psrinfo -pv
The physical processor has 8 virtual processors (0-7)
   SPARC64-VII+ (portid 1024 impl 0x7 ver 0xa1 clock 2860 MHz)


As I don't have any M-class gear myself, I have to rely on the info 
given in the mailing list threads mentioned on [1]. Though it will never 
hurt to try again if you have the hardware, as the threads were already 
from late 2017 and 2015 respectively. Things might be different now, 
although I have my doubts.


[1]: https://wiki.debian.org/Sparc64#Installing_the_Debian_SPARC64_Port




Or does one need to do a cross compile from some other platform of a 
kernel?


No I don't think so. I believe support for Fujitsu's SPARC64 processors 
and accompanying chipsets is just missing in the Linux kernel currently. 
BTW OpenBSD has support for Fujitsu SPARC64 gear (see [2]) - just be 
careful when trying it on a M3000 ([3]).


[2]: http://www.openbsd.org/sparc64.html

[3]: https://marc.info/?l=openbsd-sparc=151586763100964=2

Re: Ultra5 successful install - PGX64 issues

[Frank Scheiner]

Hi Adrian,

On 04/14/2018 08:32 PM, John Paul Adrian Glaubitz wrote:

Hi Frank!

On 04/14/2018 08:26 PM, Frank Scheiner wrote:
I have successfully tested GRUB on a PRIMEPOWER 250 with SPARC64 V+ 
(see [1]). The problem is that the Linux kernel doesn't work on any 
Fujitsu SPARC64 gear currently, not even on newer M-class machines 
(see [2]).


That reminds me: I will have a look at your two sparc64 patches
tomorrow to make sure people can install GRUB on setups with
GPT partition tables.


Take your time. :-)

Cheers,
Frank

Re: Ultra5 successful install - PGX64 issues

[Frank Scheiner]

On 04/14/2018 06:11 PM, Dennis Clarke wrote:>> FWIW, we also have 
several machines with hypervisor support (sun4v).




I was thinking Oracle M-class gear and the late generation Fujitsu gear.


I have successfully tested GRUB on a PRIMEPOWER 250 with SPARC64 V+ (see 
[1]). The problem is that the Linux kernel doesn't work on any Fujitsu 
SPARC64 gear currently, not even on newer M-class machines (see [2]).


[1]: https://lists.debian.org/debian-sparc/2018/02/msg00074.html

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

Cheers,
Frank

[PATCH] Add support for GPT partitioned disks on sparc/sparc64

[Frank Scheiner]

The following patch adds support for GPT partitioned disks on sparc(64)
to d-i/grub-installer. The installation method is chosen based on the
detected subarch currently. It auto-selects the partition for /boot
as target for grub-install on systems without GPT support and the
actual disk device on systems with GPT support. The grub-install
arguments are configured respectively.

The current implementation is very simple and based on the assumption
that we will always have a partition containing "/boot" and that we
either need to use this partition or the disk containing this partition
as target for `grub-install` (depending on used partitioning). For
partitioning it either expects GPT or assumes a Sun disklabel.

No user-interaction is provided during the GRUB installation step, so it
might fail in complex situations. I.e. it worked for me when using empty
disks without already installed other OSes. But although the
installation on a disk with Sun disklabel and Solaris 10 installed and
enough free space at the end of the disk worked as far as I can tell,
booting from the disk did not start GRUB but the Solaris 10 boot loader.
And booting from the actual "/boot" partition of the installed Debian
didn't work as expected:

```
{0} ok boot disk0:d
Boot device: /pci@0/pci@0/pci@2/scsi@0/disk@0:d  File and args: 
GRUB ERROR: Last Trap: Fast Instruction Access MMU Miss
```

In the absence of a T4 or other GPT capable system I cannot test booting
from a GPT partioned disk. But I can provide the modified parts of the
Debian installer as tarball for easy application during a Debian
installation if someone volunteers for testing.

Cheers,
Frank

---
 debian/changelog |  7 +++
 grub-installer   | 31 +--
 2 files changed, 36 insertions(+), 2 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index b5856a3..2c44fdf 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+grub-installer (1.154) UNRELEASED; urgency=medium
+
+  [ Frank Scheiner ]
+  * Add support for GPT partitioned disks on sparc/sparc64.
+
+ -- Frank Scheiner <frank.schei...@web.de>  Mon, 05 Mar 2018 19:03:48 +0100
+
 grub-installer (1.153) unstable; urgency=medium
 
   [ Updated translations ]
diff --git a/grub-installer b/grub-installer
index f9f0761..c06639f 100755
--- a/grub-installer
+++ b/grub-installer
@@ -39,6 +39,7 @@ debug () {
 
 ARCH="$(archdetect)"
 info "architecture: $ARCH"
+SUBARCH=${ARCH#*/}
 
 # Ensure proc is mounted in all the $chroot calls;
 # needed for RAID+LVM for example
@@ -626,7 +627,7 @@ if db_get cdrom-detect/hybrid; then
hybrid="$RET"
 fi
 case $ARCH:$grub_package in
-*:grub|*:grub-pc|sparc/*:grub-ieee1275|sparc64/*:grub-ieee1275)
+*:grub|*:grub-pc)
if [ "$(device_to_disk "$cdsrc")" = "$default_bootdev" ] || \
   ([ -n "$hdsrc" ] && [ "$(device_to_disk "$hdsrc")" = 
"$default_bootdev" ]) || \
   ([ "$default_bootdev" = '(hd0)' ] && \
@@ -645,6 +646,23 @@ case $ARCH:$grub_package in
fi
fi
;;
+sparc/*:grub-ieee1275|sparc64/*:grub-ieee1275)
+   bootfs=$(findfs /boot)
+   [ "$bootfs" ] || bootfs="$(findfs /)"
+   # see: https://github.com/esnowberg/grub2-sparc/wiki
+   case $SUBARCH in
+   *_gpt)
+   # For GPT partitioning grub-install should use the device as 
target
+   disk=$(device_to_disk "$bootfs")
+   db_set grub-installer/bootdev "$disk"
+   ;;
+   *)
+   # For Sun disklabel grub-install should use the boot partition 
as target
+   db_set grub-installer/bootdev "$bootfs"
+   ;;
+   esac
+   state=3
+   ;;
 
powerpc/chrp*:grub-ieee1275|ppc64/chrp*:grub-ieee1275|ppc64el/*:grub-ieee1275)
# Hack to pick the right boot device.  This should really be done in
# grub-install instead, and will need to be done there in order to
@@ -852,7 +870,16 @@ EOF
;;
sparc/*|sparc64/*)
# see: https://github.com/esnowberg/grub2-sparc/wiki
-   grub_install_params="$grub_install_params 
--skip-fs-probe"
+   case $SUBARCH in
+   *_gpt)
+   # no additional parameters for installations on 
GPT partitioned
+   # disks
+   :
+   ;;
+   *)
+   grub_install_params="$grub_install_params 
--skip-fs-probe"
+   ;;
+   esac
;;
esac
 
-- 
1.9.1

[PATCH] Add specific recipes for GPT partitioning on sparc/sparc64

[Frank Scheiner]

The following patch will add d-i/partman-auto recipes for sparc/sparc64
on sun4u and sun4v based systems with GPT support. 

They are based on the default recipes (below ./recipes) and the recipes
for sparc (below ./recipes-sparc).

In contrast to the default of a 1 MB sized BIOS_GRUB partition after
1 MB of empty space from the beginning of the device these use a 10 MB
sized partition. Eric mentions a slightly smaller size on [1] though I
actually don't know what minimum space is needed there.

[1]: https://github.com/esnowberg/grub2-sparc/wiki

An alternative would be to just include the:
```
10 10 10 free
$iflabel{ gpt }
$reusemethod{ }
method{ biosgrub } .
```
...part on top of the recipes for sparc - if the assumption is correct
that "$iflabel{ gpt }" line will only make this part effective on GPT
partitioned disks.

The patch to d-i/grub-installer follows.

Cheers,
Frank

---
 debian/changelog   |  7 ++
 recipes-sparc-sun4u_gpt|  1 +
 recipes-sparc-sun4v_gpt|  1 +
 recipes-sparc64-sun4u_gpt/_numbers |  3 +++
 recipes-sparc64-sun4u_gpt/atomic   | 26 +++
 recipes-sparc64-sun4u_gpt/home | 35 ++
 recipes-sparc64-sun4u_gpt/multi| 51 ++
 recipes-sparc64-sun4v_gpt  |  1 +
 8 files changed, 125 insertions(+)
 create mode 12 recipes-sparc-sun4u_gpt
 create mode 12 recipes-sparc-sun4v_gpt
 create mode 100644 recipes-sparc64-sun4u_gpt/_numbers
 create mode 100644 recipes-sparc64-sun4u_gpt/atomic
 create mode 100644 recipes-sparc64-sun4u_gpt/home
 create mode 100644 recipes-sparc64-sun4u_gpt/multi
 create mode 12 recipes-sparc64-sun4v_gpt

diff --git a/debian/changelog b/debian/changelog
index c5d2208..0ea969f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+partman-auto (145) UNRELEASED; urgency=medium
+
+  [ Frank Scheiner ]
+  * Add specific recipes for GPT partitioning on sparc/sparc64.
+
+ -- Frank Scheiner <frank.schei...@web.de>  Mon, 05 Mar 2018 19:39:43 +0100
+
 partman-auto (144) unstable; urgency=medium
 
   [ Updated translations ]
diff --git a/recipes-sparc-sun4u_gpt b/recipes-sparc-sun4u_gpt
new file mode 12
index 000..ed2fff1
--- /dev/null
+++ b/recipes-sparc-sun4u_gpt
@@ -0,0 +1 @@
+recipes-sparc64-sun4v_gpt
\ No newline at end of file
diff --git a/recipes-sparc-sun4v_gpt b/recipes-sparc-sun4v_gpt
new file mode 12
index 000..ed2fff1
--- /dev/null
+++ b/recipes-sparc-sun4v_gpt
@@ -0,0 +1 @@
+recipes-sparc64-sun4v_gpt
\ No newline at end of file
diff --git a/recipes-sparc64-sun4u_gpt/_numbers 
b/recipes-sparc64-sun4u_gpt/_numbers
new file mode 100644
index 000..341b03f
--- /dev/null
+++ b/recipes-sparc64-sun4u_gpt/_numbers
@@ -0,0 +1,3 @@
+30 atomic
+50 home
+80 multi
diff --git a/recipes-sparc64-sun4u_gpt/atomic b/recipes-sparc64-sun4u_gpt/atomic
new file mode 100644
index 000..84563a4
--- /dev/null
+++ b/recipes-sparc64-sun4u_gpt/atomic
@@ -0,0 +1,26 @@
+partman-auto/text/atomic_scheme ::
+
+10 10 10 free
+   $iflabel{ gpt }
+   $reusemethod{ }
+   method{ biosgrub } .
+
+50 500 100 ext2
+   method{ format }
+   format{ }
+   use_filesystem{ }
+   filesystem{ ext2 }
+   mountpoint{ /boot } .
+
+800 1 -1 $default_filesystem
+   $lvmok{ }
+   method{ format }
+   format{ }
+   use_filesystem{ }
+   $default_filesystem{ }
+   mountpoint{ / } .
+
+100% 512 300% linux-swap
+   $lvmok{ }
+   method{ swap }
+   format{ } .
diff --git a/recipes-sparc64-sun4u_gpt/home b/recipes-sparc64-sun4u_gpt/home
new file mode 100644
index 000..7cca0b2
--- /dev/null
+++ b/recipes-sparc64-sun4u_gpt/home
@@ -0,0 +1,35 @@
+partman-auto/text/home_scheme ::
+
+10 10 10 free
+   $iflabel{ gpt }
+   $reusemethod{ }
+   method{ biosgrub } .
+
+50 500 100 ext2
+   method{ format }
+   format{ }
+   use_filesystem{ }
+   filesystem{ ext2 }
+   mountpoint{ /boot } .
+
+1500 6000 3 $default_filesystem
+   $lvmok{ }
+   method{ format }
+   format{ }
+   use_filesystem{ }
+   $default_filesystem{ }
+   mountpoint{ / } .
+
+100% 512 300% linux-swap
+   $lvmok{ }
+   method{ swap }
+   format{ } .
+
+1000 1 -1 $default_filesystem
+   $lvmok{ }
+   method{ format }
+   format{ }
+   use_filesystem{ }
+   $default_filesystem{ }
+   mountpoint{ /home } .
+
diff --git a/recipes-sparc64-sun4u_gpt/multi b/recipes-sparc64-sun4u_gpt/multi
new file mode 100644
index 000..43cb060
--- /dev/null
+++ b/recipes-sparc64-sun4u_gpt/multi
@@ -0,0 +1,51 @@
+partman-auto/text/multi_scheme ::
+
+10 10 10 free
+   $iflabel{ gpt }
+   $reusemethod{ }
+   method{ biosgrub } .
+
+30 500 100 ext2
+   method{ format }
+   format{ }
+   use_filesystem{ }
+   filesystem{ ext2 }
+   mountpoint{ /boot } .
+

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

[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