Unable to register RPi3 clients

SUSE Manager
1

Hi
This is a fresh install of SLES 12 SP3 and SuMA 3.2.3 with SLES 15 aarch64 and x86_64 products added. My x86_64 systems register fine, but the aarch64 systems die with the following error;

REGISTRATION
------------
* registering
Error reading network FQDNs information: <class 'AttributeError'>
/bin/bash: line 676: 11223 Bus error               (core dumped) /usr/sbin/rhnreg_ks --force --activationkey "$ACTIVATION_KEYS" $profilename_opt

*** Error: Registering the system failed.

I’ve tried a system registered to SSC (This works fine and online repositories added) and updated as well as a fresh image (SLES15-RaspberryPi.aarch64-15.0-GM.raw.xz) not registered to SCC.

These are non-salt systems so this box is unchecked when creating the activation key and bootstrap script. Even setting the FQDN still emits the first error.

Both systems fail to register as above.

2

Hi Malcolm,

have you had a look at the core file and/or ran strace against rhnreg_ks? That might help to identify where the problem origin is. Also have a look at the (httpd) logs on the SuMa machine, I guess you’ll find an error message with at least some details on the message exchange during registration.

I remember related problems in the x86_64 world (may have been CentOS), where finding the proper version of the RHN tool stack for the client was the basic issue. But in your scenario, these tools should be provided by the SUSE Manager / SLES (SuMa Tools) environment, so version conflicts shouldn’t happen.

Regards,
J

3

[QUOTE=jmozdzen;54927]Hi Malcolm,

have you had a look at the core file and/or ran strace against rhnreg_ks? That might help to identify where the problem origin is. Also have a look at the (httpd) logs on the SuMa machine, I guess you’ll find an error message with at least some details on the message exchange during registration.

I remember related problems in the x86_64 world (may have been CentOS), where finding the proper version of the RHN tool stack for the client was the basic issue. But in your scenario, these tools should be provided by the SUSE Manager / SLES (SuMa Tools) environment, so version conflicts shouldn’t happen.

Regards,
J[/QUOTE]
Hi
No coredumps, nothing in the apache2 logs, added --verbose and --nohardware to the rhnreg_ks section of the script etc…

rt_sigaction(SIGILL, {sa_handler=0xffff7e06a2d8, sa_mask=[ILL], sa_flags=SA_RESTART}, {sa_handler=SIG_DFL, sa_mask=[ILL], sa_flags=SA_RESTART}, 8) = 0
openat(AT_FDCWD, "/dev/mem", O_RDONLY)  = 3
mmap(NULL, 32, PROT_READ, MAP_SHARED, 3, 0x3cb33000) = 0xffff80022000
munmap(0xffff80022000, 32)              = 0
close(3)                                = 0
rt_sigaction(SIGILL, {sa_handler=SIG_DFL, sa_mask=[ILL], sa_flags=SA_RESTART}, {sa_handler=0xffff7e06a2d8, sa_mask=[ILL], sa_flags=SA_RESTART}, 8) = 0
rt_sigaction(SIGILL, {sa_handler=0xffff7e06a2d8, sa_mask=[ILL], sa_flags=SA_RESTART}, {sa_handler=SIG_DFL, sa_mask=[ILL], sa_flags=SA_RESTART}, 8) = 0
openat(AT_FDCWD, "/dev/mem", O_RDONLY)  = 3
mmap(NULL, 285, PROT_READ, MAP_SHARED, 3, 0x3cb33000) = 0xffff80022000
--- SIGBUS {si_signo=SIGBUS, si_code=BUS_ADRALN, si_addr=0xffff800220dd} ---
+++ killed by SIGBUS (core dumped) +++
/bin/bash: line 676: 25582 Bus error               (core dumped) /usr/bin/strace /usr/sbin/rhnreg_ks --verbose --nohardware --force --activationkey "$ACTIVATION_KEYS" $profilename_opt

*** Error: Registering the system failed.

Looks like it might be the call to /dev/mem for the RPi3…?

cat /dev/mem
cat: /dev/mem: Bad address
4

Hi Malcolm,

Looks like it might be the call to /dev/mem for the RPi3…?

what makes this look confusing is that both identical attempts to map storage work fine - so it’s something that’s done with that mapped area that fails (the final munmap() is missing or rather would have been called after the instructions that triggered the SIGBUS). Likely the core dump has more details, or running rhnreg_ks via gdb might even be easier. (And I believe there indeed is a core dump file - the system does report it’s generated (“11223 Bus error (core dumped)”), maybe systemd simply moved it away? (see “coredumpctl” or https://www.suse.com/de-de/support/kb/doc/?id=7017137 for details)(and maybe check your core dump file limits, too?)

Regards,
J

5

Hi
The script doesn’t produce a dump, but looks like the command itself
does…

coredumpctl dump 31411 --output test.txt
PID: 31411 (rhnreg_ks)
UID: 0 (root)
GID: 0 (root)
Signal: 7 (BUS)
Timestamp: Tue 2018-10-23 12:23:57 CDT (7h ago)
Command Line: /usr/bin/python3 /usr/sbin/rhnreg_ks --verbose
--nohardware --force --activationkey 1-sles_15_aarch64
--profilename=gekkota-dns2.homelinux.org Executable: /usr/bin/python3.6
Control Group: /user.slice/user-0.slice/session-4.scope Unit:
session-4.scope Slice: user-0.slice
Session: 4
Owner UID: 0 (root)
Boot ID: c7fb84c57c934336b6423929e074d01b
Machine ID: 347ddf89fa2a4834bcd5910716ad92a4
Hostname: gekkota-dns2
Storage: /var/lib/systemd/coredump/core.rhnreg_ks.0.c7fb84c57c934336b6423929e074d01b.31411.1540315437000000.lz4
Message: Process 31411 (rhnreg_ks) of user 0 dumped core.

–
Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
SLES 15 | GNOME Shell 3.26.2 | 4.12.14-25.22-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

6

[QUOTE=malcolmlewis;54936]
Looks like it might be the call to /dev/mem for the RPi3…?

cat /dev/mem cat: /dev/mem: Bad address [/QUOTE]

Ugh, this looks like a hardware problem to me.

7

Hi
All my RPi’s exhibit this?

Machine model: Raspberry Pi 3 Model B Rev 1.2

Two running SLES 15, one Leap 15 and the other Tumbleweed.

–
Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
SLES 15 | GNOME Shell 3.26.2 | 4.12.14-25.22-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

8

Hi
So have created a bug report, lets see what happens;
https://bugzilla.suse.com/show_bug.cgi?id=1113160