XPost: alt.os.linux.debian

Hello, all

On RPi OS Bookworm, console and keyboard initialisation via `setupcon' seem doubly duplicated (sic), and I am x-posting this to .debian because it
may not be speific to Pi OS:

1. in that systemd services and init.d scripts do the same thing:
/etc/init.d:
console-setup.sh -> /lib/console-setup/console-setup.sh
keyboard-setup.sh -> /lib/console-setup/keyboard-setup.sh

/usr/lib/systemd/system:
console-setup.service -> /lib/console-setup/console-setup.sh
keyboard-setup.service -> /lib/console-setup/keyboard-setup.sh

2. in that /lib/console-setup/console-setup.sh includes both console and
keyboard setup, making keyboard-setup.sh redundant.

This is futher complicated by what I consider two crutches in /lib/console-setup/keyboard-setup.sh :

1. `setupcon' is invoked if and only if at least one of following
conditions is met:

1. this is /not/ the first time after reboot that the script runs --
a special case misleadingly annotated in the source as skipping an
invocation "after boot," without an explanation why it should be
skipped. Nor does it always /skip/ the invocation, because this is
only one of the two sufficient (OR'ed) conditions .

2. the cache (from a previous invocation with --size) does not exist
or is older than the default configuration in
/etc/default/console-setup.

2. it invokes `setupcon' with the --size option, which causes it to
cache the necessary data files under /etc/console-setup so that they
are available to subsequent invocations before /usr is mounted, e.g.
at an early state of the boot process. In the script, however, --size
seems redunadant, because:

1. if at the time of invocation /usr is not yet mounted, `setupcon'
will take its data from the cache, and --size will have no effect,
(expect, perhaps, rewriting the cache with the same contents).

2. if at the time invocation /usr is already mounted, `setupcon' will
build the data based on its config file,
/etc/default/console-setup ,
and the files in /usr .

Therefore, I think that all this confusing complexity can be reduced to
a very simple invocation that configures both keyboard and console:

if [ -f /etc/default/locale ]; then
# In order to permit auto-detection of the charmap when
# console-setup-mini operates without configuration file.
. /etc/default/locale
export LANG
fi
setupcon

and is invoked by a single systemd service requiring that /usr be
mounted, as the current services already do. Perhaps it is a newbie's
wishful thinking, so what is the reason for current setup? Also, are
able to configure your Bookworms to set the font in your TTYs without
changing the aforementioned shell scripts? I was not, and had to
simplify the process as described above.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.os.linux.debian

On Sun, 15 Sep 2024 21:20:37 -0000 (UTC), Anton Shepelev wrote:

1. in that systemd services and init.d scripts do the same thing:
/etc/init.d:
console-setup.sh -> /lib/console-setup/console-setup.sh
keyboard-setup.sh -> /lib/console-setup/keyboard-setup.sh

/usr/lib/systemd/system:
console-setup.service -> /lib/console-setup/console-setup.sh
keyboard-setup.service -> /lib/console-setup/keyboard-setup.sh

Remember that systemd includes a high degree of backward compatibility
with old sysvinit scripts. That would be why you see the exact same things showing up in both init.d and systemd. This way, “systemctl start/stop” is able to start/stop sysvinit scripts, without you having to know the
difference.

Therefore, I think that all this confusing complexity can be reduced to
a very simple invocation that configures both keyboard and console:

Well, the only way to know for sure is to try it.

What have you got to lose? ;)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.os.linux.debian

Anton Shepelev <ant@tilde.culb> wrote:

Hello, all

On RPi OS Bookworm, console and keyboard initialisation via `setupcon' seem doubly duplicated (sic), and I am x-posting this to .debian because it
may not be speific to Pi OS:

1. in that systemd services and init.d scripts do the same thing:
/etc/init.d:
console-setup.sh -> /lib/console-setup/console-setup.sh
keyboard-setup.sh -> /lib/console-setup/keyboard-setup.sh

/usr/lib/systemd/system:
console-setup.service -> /lib/console-setup/console-setup.sh
keyboard-setup.service -> /lib/console-setup/keyboard-setup.sh

2. in that /lib/console-setup/console-setup.sh includes both console and
keyboard setup, making keyboard-setup.sh redundant.

Isn't the init.d startup actually emulated by systemd when a system
uses systemd? The files still exist but the implementation is systemd.

--
Chris Green
·

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.os.linux.debian

In alt.os.linux.debian Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On Sun, 15 Sep 2024 21:20:37 -0000 (UTC), Anton Shepelev wrote:

1. in that systemd services and init.d scripts do the same thing:
/etc/init.d:
console-setup.sh -> /lib/console-setup/console-setup.sh
keyboard-setup.sh -> /lib/console-setup/keyboard-setup.sh

/usr/lib/systemd/system:
console-setup.service -> /lib/console-setup/console-setup.sh
keyboard-setup.service -> /lib/console-setup/keyboard-setup.sh

Remember that systemd includes a high degree of backward compatibility
with old sysvinit scripts. That would be why you see the exact same
things showing up in both init.d and systemd. This way, ôsystemctl start/stopû is able to start/stop sysvinit scripts, without you having
to know the difference.

Of course, but I don't thinkg the duplication is required for that compatibitly: systemd executes everything from /etc/init.d /and/ also
from its service records. Therefore, each init service should be
implemented as /eiterh/ one or the other, but not as both.

Therefore, I think that all this confusing complexity can be reduced to
a very simple invocation that configures both keyboard and console:

Well, the only way to know for sure is to try it.

I the part you snipped, I write that I have done as I proposed, and it
works for me. Futhermore, the original Pi OS config does not work for
me, wherefore I asked (also snipped) if anybody else has been able to
use it as is.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.os.linux.debian

In alt.os.linux.debian Chris Green <cl@isbd.net> wrote:

Anton Shepelev <ant@tilde.culb> wrote:

On RPi OS Bookworm, console and keyboard initialisation via
`setupcon' seem doubly duplicated (sic), and I am x-posting this to
.debian because it may not be speific to Pi OS:

1. in that systemd services and init.d scripts do the same thing:
/etc/init.d:
console-setup.sh -> /lib/console-setup/console-setup.sh
keyboard-setup.sh -> /lib/console-setup/keyboard-setup.sh

/usr/lib/systemd/system:
console-setup.service -> /lib/console-setup/console-setup.sh
keyboard-setup.service -> /lib/console-setup/keyboard-setup.sh

2. in that /lib/console-setup/console-setup.sh includes both console
and keyboard setup, making keyboard-setup.sh redundant.

Isn't the init.d startup actually emulated by systemd when a system
uses systemd? The files still exist but the implementation is systemd.

Yes, but why the duplication? The emulation of init.d is there for
functonality that has not yet been migrated to systemd services, whereas
the console and keyboard setup are /already/ present and propser systemd services, and therefore no longer needed in init.d .

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)