[systemd-devel] Antw: [EXT] [systemd‑devel] starting networking from within single user mode?

2022-11-10 Thread Ulrich Windl 
>>> Brian Reichert  schrieb am 10.11.2022 um 23:04 in
Nachricht <20221110220426.ga17...@numachi.com>:
> I've managed to hose a SLES12 SP5 host; it starts to boot, then hangs.

And what did you do to mess it up? And what do the boot messages say?

> 
> If I get it into single‑user mode (getting into the grub menu, and adding
> init=/bin/bash) I can at least review the file system.
> 
> What I want to do is get networking running, so that I can at least gather
> logs, etc.
> 
> When I try to start networking with 'systemctl', I see this error:
> 
> systemd "failed to connect to bus; No such file or directory"
> 
> What can I do to minimally bring up the networking service? I don't even
> have any network devices at this point...
> 
> ‑‑ 
> Brian Reichert
> BSD admin/developer at large

Re: [systemd-devel] starting networking from within single user mode?

2022-11-10 Thread Mantas Mikulėnas 
On Fri, Nov 11, 2022 at 12:04 AM Brian Reichert 
wrote:

> I've managed to hose a SLES12 SP5 host; it starts to boot, then hangs.
>
> If I get it into single-user mode (getting into the grub menu, and adding
> init=/bin/bash) I can at least review the file system.
>
> What I want to do is get networking running, so that I can at least gather
> logs, etc.
>
> When I try to start networking with 'systemctl', I see this error:
>
> systemd "failed to connect to bus; No such file or directory"
>
> What can I do to minimally bring up the networking service? I don't even
> have any network devices at this point...
>

Running without init isn't really single-user mode. You won't be able to
start any services using systemctl without init, because... systemctl
controls init. You also won't have any network devices because drivers for
those are loaded by a service that's not running without init (namely
systemd-udevd).

Boot with either "s" (aka "single" aka "rescue") or "-b" (aka "emergency")
for two variants of single-user mode with init. The former starts some
basic stuff (it's the real single-user mode) including udev so that modules
for your network interfaces still get loaded automatically, while the
latter doesn't start anything except init and a shell (emergency mode is
*almost* like init=/bin/sh but in theory might at least let you `systemctl
start` something).

If udev is not running, try to `modprobe` whichever drivers you need for
the Ethernet interface. (The name can be found by PCI ID, e.g. for
10ec:8136 "grep -i 10EC.*8136 /lib/modules/`uname -r`/modules.alias") Then
manually bring eth0 up, add the IP address, add a default route (dhclient
or dhcpcd will also work without udev, while systemd-networkd probably
won't).

ip link set eth0 up
ip addr add 192.168.1.55/24 dev eth0
ip route add default via 192.168.1.1

-- 
Mantas Mikulėnas

[systemd-devel] starting networking from within single user mode?

2022-11-10 Thread Brian Reichert 
I've managed to hose a SLES12 SP5 host; it starts to boot, then hangs.

If I get it into single-user mode (getting into the grub menu, and adding
init=/bin/bash) I can at least review the file system.

What I want to do is get networking running, so that I can at least gather
logs, etc.

When I try to start networking with 'systemctl', I see this error:

systemd "failed to connect to bus; No such file or directory"

What can I do to minimally bring up the networking service? I don't even
have any network devices at this point...

-- 
Brian Reichert  
BSD admin/developer at large

Re: [systemd-devel] BUG: kworker + systemd-udevd memory leaks found in 6.1.0-rc4

2022-11-10 Thread Greg KH 
On Thu, Nov 10, 2022 at 05:57:57AM +0100, Mirsad Goran Todorovac wrote:
> On 04. 11. 2022. 11:40, Mirsad Goran Todorovac wrote:
> 
> > Dear Sirs,
> > 
> > When building a RPM 6.1.0-rc3 for AlmaLinux 8.6, I have enabled
> > CONFIG_DEBUG_KMEMLEAK=y
> > and the result showed an unreferenced object in kworker process:
> > 
> > # cat /sys/kernel/debug/kmemleak
> > unreferenced object 0xa01dabff6100 (size 16):
> >   comm "kworker/u12:4", pid 400, jiffies 4294894771 (age 5284.956s)
> >   hex dump (first 16 bytes):
> >     6d 65 6d 73 74 69 63 6b 30 00 00 00 00 00 00 00 memstick0...
> >   backtrace:
> >     [<9ff951f6>] __kmem_cache_alloc_node+0x380/0x4e0
> >     [<451f4268>] __kmalloc_node_track_caller+0x55/0x150
> >     [<05472512>] kstrdup+0x36/0x70
> >     [<2f797ac4>] kstrdup_const+0x28/0x30
> >     [] kvasprintf_const+0x78/0xa0
> >     [] kobject_set_name_vargs+0x23/0xa0
> >     [<4158a6c0>] dev_set_name+0x53/0x70
> >     [<1a120541>] memstick_check+0xff/0x384 [memstick]
> >     [<122bb894>] process_one_work+0x214/0x3f0
> >     [] worker_thread+0x34/0x3d0
> >     [<02409855>] kthread+0xed/0x120
> >     [<7b02b4a3>] ret_from_fork+0x1f/0x30
> > unreferenced object 0xa01dabff6ec0 (size 16):
> >   comm "kworker/u12:4", pid 400, jiffies 4294894774 (age 5284.944s)
> >   hex dump (first 16 bytes):
> >     6d 65 6d 73 74 69 63 6b 30 00 00 00 00 00 00 00 memstick0...
> >   backtrace:
> >     [<9ff951f6>] __kmem_cache_alloc_node+0x380/0x4e0
> >     [<451f4268>] __kmalloc_node_track_caller+0x55/0x150
> >     [<05472512>] kstrdup+0x36/0x70
> >     [<2f797ac4>] kstrdup_const+0x28/0x30
> >     [] kvasprintf_const+0x78/0xa0
> >     [] kobject_set_name_vargs+0x23/0xa0
> >     [<4158a6c0>] dev_set_name+0x53/0x70
> >     [<1a120541>] memstick_check+0xff/0x384 [memstick]
> >     [<122bb894>] process_one_work+0x214/0x3f0
> >     [] worker_thread+0x34/0x3d0
> >     [<02409855>] kthread+0xed/0x120
> >     [<7b02b4a3>] ret_from_fork+0x1f/0x30
> > #
> > 
> > Please fing the build config and lshw output attached.
> > 
> > dmesg is useless, as it is filled with events like:
> > 
> > [ 6068.996120] evbug: Event. Dev: input4, Type: 1, Code: 31, Value: 0
> > [ 6068.996121] evbug: Event. Dev: input4, Type: 0, Code: 0, Value: 0
> > [ 6069.124145] evbug: Event. Dev: input4, Type: 4, Code: 4, Value: 458762
> > [ 6069.124149] evbug: Event. Dev: input4, Type: 1, Code: 34, Value: 1
> > [ 6069.124150] evbug: Event. Dev: input4, Type: 0, Code: 0, Value: 0
> > [ 6069.196003] evbug: Event. Dev: input4, Type: 4, Code: 4, Value: 458762
> > [ 6069.196007] evbug: Event. Dev: input4, Type: 1, Code: 34, Value: 0
> > [ 6069.196009] evbug: Event. Dev: input4, Type: 0, Code: 0, Value: 0
> > [ 6069.788129] evbug: Event. Dev: input4, Type: 4, Code: 4, Value: 458792
> > [ 6069.788133] evbug: Event. Dev: input4, Type: 1, Code: 28, Value: 1
> > [ 6069.788135] evbug: Event. Dev: input4, Type: 0, Code: 0, Value: 0
> 
> This bug is confirmed in 6.1-rc4, among the "thermald" and "systemd-dev"
> kernel memory leaks, potentially exposing race conditions or other more
> serious bug.

How is a memory leak a race condition?

> The bug is now also confirmed and now manifested also in the Ubuntu 22.04
> LTS jammy 6.1-rc4 build.
> 
> Here is the kmemleak output:
> 
> unreferenced object 0x9242b13b3980 (size 64):
>   comm "kworker/5:3", pid 43106, jiffies 4305052439 (age 71828.792s)
>   hex dump (first 32 bytes):
>     80 8b a0 f0 42 92 ff ff 00 00 00 00 00 00 00 00 B...
>     20 86 a0 f0 42 92 ff ff 00 00 00 00 00 00 00 00 ...B...
>   backtrace:
>     [] __kmem_cache_alloc_node+0x380/0x4e0
>     [<2b17af47>] kmalloc_node_trace+0x27/0xa0
>     [<4c09eee5>] xhci_alloc_command+0x6e/0x180

This is a totally different backtrace from above, how are they related?

This looks like a potential xhci issue.  Can you use 'git bisect' to
track down the offending change that caused this?

thanks,

greg k-h