=== himcesjf_ is now known as him-cesjf
[10:04] <alkisg> Hi, can anyone imagine why the netconsole module works properly early in the boot process, yet it stops broadcasting when systemd services start, at about the point when systemd-journald starts? (maybe that's when networking starts too...)
[10:05] <alkisg> UDP traffic isn't blocked, e.g. sending messages with `nc` works fine; it seems like the netconsole module just stops sending; it even loads successfully with no errors, yet it sends nothing
[10:06] <alkisg> Example commands to test with: server: nc -l -u 6666; client: modprobe netconsole netconsole=@client-ip/enp0s3,@server-ip/
[10:06] <alkisg> These work at e.g. init=/bin/bash, but not on "recovery" or later
[10:32] <alkisg> I tried downloading netconsole-setup from 19.04; this manages to send a single test message, and then nothing more
[10:47] <alkisg> It works in Ubuntu 4.10, fails on Ubuntu 8.04. Hehe, first time trying Warty.
[10:48] <jeremy31> alkisg: Why mess with unsupported versions?
[10:49] <alkisg> jeremy31: to see when it broke, to help in finding why it broke
[10:49] <alkisg> (netconsole isn't working in ubuntu since at least 10 years now)
[10:49] <alkisg> (while it still works fine in buster and all the rest distros)
[10:54] <alkisg> 6.06.1 is broken too, so it broke sometime between 4.10 and 6.06.1
[11:05] <alkisg> So, it works on 4.10 and fails on 5.04 and up to now. Ancient bug. :)
[11:05] <alkisg> ip a
[13:12] <alkisg> Got it; it needed `dmesg -n 8` to actually transfer the messages in 5.04+
[13:39] <alkisg> ...or, echo '4 3 1 7' > /proc/sys/kernel/printk, or loglevel=8 in /proc/cmdline etc; but it appears that this only lasts up until journald is started
[13:40] <alkisg> Something resets the log level, so one needs to manually run it again after the system completes its boot process
[13:44] <TJ-> alkisg: "grep LogLevel /etc/systemd/system.conf" 
[13:47] <alkisg> TJ-: thanks; I tried settings that to "debug", I rebooted, but /proc/sys/kernel/printk is again reset to "4 4 1 7"
[13:49] <alkisg> What I want is to have "4 3 1 7" or "5 4 1 7" after the system boots, so that a simple "date > /proc/kmsg" reaches the server,
[13:49] <alkisg> So, I start with passing "loglevel=5" in the kernel cmdline, and that works up until journal starts, where it's reset to 4.
[13:49] <TJ-> alkisg: how about a sysctl setting?
[13:50] <alkisg> Do you think journald will respect that? I can try...
[13:50] <alkisg> loglevel is supposedly the kernel parameter that is equivalent to kernel.printk...
[13:52] <TJ-> alkisg: check out journald.conf, it's man-page shows options MaxLevelStore=, MaxLevelSyslog=, MaxLevelKMsg=, MaxLevelConsole=, MaxLevelWall=
[13:52] <alkisg> Those sound interesting, let me try...
[13:53] <TJ-> alkisg: see "man journald.conf"
[13:59] <alkisg> I tried these in the cmdline, but no joy so far: systemd.journald.max_level_kmsg=5 systemd.journald.max_level_console=5
[13:59] <alkisg> I'll try again after a small nap. Ty, later... :)
[14:53] <alkisg> TJ-: I put init=/bin/bash, I run `systemctl mask journald; exec /sbin/init`, and the level is still reset to 4. So it's probably some other component that resets it, not journald...
[14:55] <TJ-> alkisg: it does sound like a sysctl thing
[14:56] <alkisg> Oh, I see sysctl.d/10-console-message.conf has 4 4 1 7, maybe it's that one, looking...
[14:56] <TJ-> I did mention that earlier
[14:59] <alkisg> Yup that was it. Sorry I didn't realize you said "maybe it's a setting in sysctl.d", I thought you meant "maybe you can set the one you want in sysctl.d"
[14:59] <alkisg> And since I already set it in the cmdline, I didn't look into it more
[15:00] <TJ-> well, it took you as long to find that as it's taken me to find a missing managed switch on my network!
[15:02] <alkisg> Haha, I had a nap too :D
[15:03] <alkisg> It took me all Friday to find a loop in the cabling a school though... a teacher removed a utp cable from a pc, put it to his laptop, and when he was done, he put it back to... the switch, creating a loop
[15:04] <alkisg> The school lost networking for a week :D
[15:04] <TJ-> arghh!
[15:06] <TJ-> well in my case I have a netgear GS748TP, used for labs, so it is powered off most of the time. It should be on the management vlan on 10.254.0.253, but I couldn't find it despite all manner of permutations of looking for it on both the management and default vlans, and trying alternate (inc. default) IP addresses, different ports, and so on
[15:07] <TJ-> eventually downloaded the Netgeat SmartWizard windows software, ran it under wine, it found the device instantly and confirmed I had the correct IP address... so at that point I added the management subnet to the default vlan and there it was! so it had forgotten it was supposed to be on the management vlan
[15:08]  * alkisg got a headache just reading about it :D