On 02/05/2018 09:49 AM, Frank Scheiner wrote:
Sorry, but my tests this morning after I again upgraded to the *8-* versions of the above libs plus rebuilding initramfs again and reboot showed segfaults when trying to login via serial console.

So I think I have to revert my conclusion from yesterday, it now more looks like a "sporadic" issue or a local problem. For a sproadic issues it'd be strange that this hit both T1000 and T5220. And as I used the same disk on both machines, maybe it's the disk that creates the issues, e.g. bad blocks. This could make sense, because netbooting the exact same kernel and initramfs (w/on-disk root FS) that allowed successful serial logins yesterday, today also has issues.

I'll have to check with a new disk to be sure. Well, gives me the opportunity to test another machine with the SPARC64 installer ISO.

A short follow-up:

So I did a new installation on a fresh SSD and checked the mentioned possibly bad disk with `badblocks` from there, but it didn't find any issues on that disk. In addition `fsck.ext4` also didn't show any problems for `/` and `/boot` file systems, so did `smartctl` for the whole disk. From this I conclude that the segfaults weren't related to the disk.

As a sort of weak confirmation, the recent upgrades to the following packages and versions made logins via serial console working again when using that disk:

libgcc-7-dev:sparc64 (7.3.0-1+b2, 7.3.0-2)
cpp-7:sparc64 (7.3.0-1+b2, 7.3.0-2)
gcc-8-base:sparc64 (8-20180130-1, 8-20180207-2)
libitm1:sparc64 (8-20180130-1, 8-20180207-2)
gcc-7-base:sparc64 (7.3.0-1+b2, 7.3.0-2)
libgfortran-7-dev:sparc64 (7.3.0-1+b2, 7.3.0-2)
libcilkrts5:sparc64 (7.3.0-1+b2, 7.3.0-2)
libasan4:sparc64 (7.3.0-1+b2, 7.3.0-2)
libgcc1:sparc64 (1:8-20180130-1, 1:8-20180207-2)
libstdc++-7-dev:sparc64 (7.3.0-1+b2, 7.3.0-2)
libubsan0:sparc64 (7.3.0-1+b2, 7.3.0-2)
g++-7:sparc64 (7.3.0-1+b2, 7.3.0-2)
libgfortran4:sparc64 (7.3.0-1+b2, 7.3.0-2)
gcc-7:sparc64 (7.3.0-1+b2, 7.3.0-2)
gfortran-7:sparc64 (7.3.0-1+b2, 7.3.0-2)
libgomp1:sparc64 (8-20180130-1, 8-20180207-2)
libatomic1:sparc64 (8-20180130-1, 8-20180207-2)
libcc1-0:sparc64 (8-20180130-1, 8-20180207-2)
libstdc++6:sparc64 (8-20180130-1, 8-20180207-2)

So maybe it was a problematic combination of package versions that (re)created the described issue initially and in between.


Reply via email to