Re: [systemd-devel] workaround for systemd-networkd-wait-online boot fail/delay on systems with bridge for v234? (fix @ systemd/issues/2154 requires v>242)
On 6/16/20 1:35 AM, Lennart Poettering wrote: > On Sa, 30.05.20 18:02, PGNet Dev (pgnet@gmail.com) wrote: > >> IS there a backport of this^^ fix available for v234 that popped up in >> the meantime? >> >> If not, as is likely, is there a "safe" workaround for quieting the >> fail, and rm'ing the associated boot delay? Is rm'ing either the "Also=" or >> "WantedBy=" a reasonable band-aid? >> >> Or, some other approach? > > You could use RequiredForOnline= in the bridge's .network file to mark > it as irrelevant for systemd-network-wait-online. > > Lennart > > -- > Lennart Poettering, Berlin On my current machine, just upgraded to new OS version (still same distro -- for the moment) I've, networkctl IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 enp3s0 ether no-carrier configuring 3 enp5s0 ether routableconfigured infc #3 is active; intfc #2 is unused I added to each cd /etc/systemd/network grep Link -A1 * 20-enp3s0.network:[Link] 20-enp3s0.network-RequiredForOnline=no -- 20-enp5s0.network:[Link] 20-enp5s0.network-RequiredForOnline=no and rebooted. still, there's a 2min delay on startup systemd-analyze blame | head 2min 284ms systemd-networkd-wait-online.service 5.803s dkms.service 5.409s rc-local.service 4.270s mariadb-custom.service 3.952s after-local.service 3.647s udisks2.service 2.985s rpcbind.service 2.936s mcelog.service 2.901s ca-certificates.service 2.878s smartd.service in dmesg, dmesg | grep wait-online -A1 -B1 [ 129.299191] systemd[1]: Started update geoipdb service. [ 130.961418] systemd-networkd-wait-online[1664]: Event loop failed: Connection timed out [ 130.971019] systemd[1]: systemd-networkd-wait-online.service: Main process exited, code=exited, status=1/FAILURE [ 130.971276] systemd[1]: Failed to start Wait for Network to be Configured. [ 130.974180] systemd[1]: systemd-networkd-wait-online.service: Unit entered failed state. [ 130.974187] systemd[1]: systemd-networkd-wait-online.service: Failed with result 'exit-code'. [ 130.974266] systemd[1]: Reached target Network is Online. other than the two interfaces I _do_ have -- and have set [Link] RequiredForOnline=no for, what's possibly _still_ causing this delay? this^ is, as before, with rpm -qa | grep ^systemd-2 systemd-234-lp152.30.1.x86_64 switching back to non-systemd-networkd network stack eliminates any such delay. not surprising, given the bug -- and certainly not ideal. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] vt220 default for serial console still relevant?
Nevermind that, I just forgot to remove my override file that set TERM=linux for serial-getty@ttyS0. Daan On Sat, 11 Jul 2020 at 20:31, Daan De Meyer wrote: > > TERM=linux means Linux console, but that's just too much, as it not > > only implies a multitude of ESC sequences specific to the Linux > > console, but also indicates that certain ioctls might work. In our own > > code we also bind certain behaviour to TERM=linux, as indicator if we > > are on the Linux console. > > > > I am not aware of any widely-supported TERM value that would be a > > reasonable subset of all currently used terminals and does color. > > I did some more research and it turns out VT220 does support colors. My > terminal emulator (Konsole) just doesn't seem to support it. I installed > xterm (which explicitly advertises support for VT220 escape codes) and got > colored output as expected. I guess this means it's up to Konsole to > support more of VT220 if I want this to work seamlessly (or I switch > terminals to xterm). > > Thanks for the extra info and context. > > Daan > > On Sat, 11 Jul 2020 at 20:04, Lennart Poettering > wrote: > >> On Sa, 11.07.20 17:51, Daan De Meyer (daan.j.deme...@gmail.com) wrote: >> >> > Hi, >> > >> > I was playing around with mkosi's qemu support, more specifically adding >> > the -nographic option to have the virtual machine output in my terminal >> > instead of a separate window. After figuring out that I had to add >> > console=ttyS0 to mkosi's kernel command line, I got the output from the >> vm >> > in my terminal as expected. However, because systemd defaults to >> TERM=vt220 >> > for serial consoles, the output is not colorized. I searched around a >> bit >> > and found that this is done for compatibility reasons. Will there ever >> be a >> > point where we can switch the default to something that supports colors >> > (like TERM=linux)? >> >> TERM=linux means Linux console, but that's just too much, as it not >> only implies a multitude of ESC sequences specific to the Linux >> console, but also indicates that certain ioctls might work. In our own >> code we also bind certain behaviour to TERM=linux, as indicator if we >> are on the Linux console. >> >> I am not aware of any widely-supported TERM value that would be a >> reasonable subset of all currently used terminals and does color. >> >> > I managed to get around the problem by overriding serial-getty@ttyS0 >> and >> > setting Environment=TERM=linux explicitly but it's a bit of a pain and >> has >> > to be added to every rootfs that wants to support colored output on its >> > serial console. >> >> Unfortunately we can't guess the right terminal, we cannot propagate >> TERM=xterm or TERM=linux depending if you invoke qemu on an xterm or >> from a Linux console, hence the best thing we can do is stick to a >> reasonably powerful subset that is likely going to exist everywhere, >> and that's vt220 right now, as noone had a better suggestion so far... >> >> Lennart >> >> -- >> Lennart Poettering, Berlin >> > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] vt220 default for serial console still relevant?
> TERM=linux means Linux console, but that's just too much, as it not > only implies a multitude of ESC sequences specific to the Linux > console, but also indicates that certain ioctls might work. In our own > code we also bind certain behaviour to TERM=linux, as indicator if we > are on the Linux console. > > I am not aware of any widely-supported TERM value that would be a > reasonable subset of all currently used terminals and does color. I did some more research and it turns out VT220 does support colors. My terminal emulator (Konsole) just doesn't seem to support it. I installed xterm (which explicitly advertises support for VT220 escape codes) and got colored output as expected. I guess this means it's up to Konsole to support more of VT220 if I want this to work seamlessly (or I switch terminals to xterm). Thanks for the extra info and context. Daan On Sat, 11 Jul 2020 at 20:04, Lennart Poettering wrote: > On Sa, 11.07.20 17:51, Daan De Meyer (daan.j.deme...@gmail.com) wrote: > > > Hi, > > > > I was playing around with mkosi's qemu support, more specifically adding > > the -nographic option to have the virtual machine output in my terminal > > instead of a separate window. After figuring out that I had to add > > console=ttyS0 to mkosi's kernel command line, I got the output from the > vm > > in my terminal as expected. However, because systemd defaults to > TERM=vt220 > > for serial consoles, the output is not colorized. I searched around a bit > > and found that this is done for compatibility reasons. Will there ever > be a > > point where we can switch the default to something that supports colors > > (like TERM=linux)? > > TERM=linux means Linux console, but that's just too much, as it not > only implies a multitude of ESC sequences specific to the Linux > console, but also indicates that certain ioctls might work. In our own > code we also bind certain behaviour to TERM=linux, as indicator if we > are on the Linux console. > > I am not aware of any widely-supported TERM value that would be a > reasonable subset of all currently used terminals and does color. > > > I managed to get around the problem by overriding serial-getty@ttyS0 and > > setting Environment=TERM=linux explicitly but it's a bit of a pain and > has > > to be added to every rootfs that wants to support colored output on its > > serial console. > > Unfortunately we can't guess the right terminal, we cannot propagate > TERM=xterm or TERM=linux depending if you invoke qemu on an xterm or > from a Linux console, hence the best thing we can do is stick to a > reasonably powerful subset that is likely going to exist everywhere, > and that's vt220 right now, as noone had a better suggestion so far... > > Lennart > > -- > Lennart Poettering, Berlin > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] vt220 default for serial console still relevant?
On Sa, 11.07.20 17:51, Daan De Meyer (daan.j.deme...@gmail.com) wrote: > Hi, > > I was playing around with mkosi's qemu support, more specifically adding > the -nographic option to have the virtual machine output in my terminal > instead of a separate window. After figuring out that I had to add > console=ttyS0 to mkosi's kernel command line, I got the output from the vm > in my terminal as expected. However, because systemd defaults to TERM=vt220 > for serial consoles, the output is not colorized. I searched around a bit > and found that this is done for compatibility reasons. Will there ever be a > point where we can switch the default to something that supports colors > (like TERM=linux)? TERM=linux means Linux console, but that's just too much, as it not only implies a multitude of ESC sequences specific to the Linux console, but also indicates that certain ioctls might work. In our own code we also bind certain behaviour to TERM=linux, as indicator if we are on the Linux console. I am not aware of any widely-supported TERM value that would be a reasonable subset of all currently used terminals and does color. > I managed to get around the problem by overriding serial-getty@ttyS0 and > setting Environment=TERM=linux explicitly but it's a bit of a pain and has > to be added to every rootfs that wants to support colored output on its > serial console. Unfortunately we can't guess the right terminal, we cannot propagate TERM=xterm or TERM=linux depending if you invoke qemu on an xterm or from a Linux console, hence the best thing we can do is stick to a reasonably powerful subset that is likely going to exist everywhere, and that's vt220 right now, as noone had a better suggestion so far... Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] vt220 default for serial console still relevant?
Hi, I was playing around with mkosi's qemu support, more specifically adding the -nographic option to have the virtual machine output in my terminal instead of a separate window. After figuring out that I had to add console=ttyS0 to mkosi's kernel command line, I got the output from the vm in my terminal as expected. However, because systemd defaults to TERM=vt220 for serial consoles, the output is not colorized. I searched around a bit and found that this is done for compatibility reasons. Will there ever be a point where we can switch the default to something that supports colors (like TERM=linux)? I managed to get around the problem by overriding serial-getty@ttyS0 and setting Environment=TERM=linux explicitly but it's a bit of a pain and has to be added to every rootfs that wants to support colored output on its serial console. Cheers, Daan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
