• Execution of setupcon at boot

    From Anton Shepelev@ant@tilde.culb to comp.sys.raspberry-pi,alt.os.linux.debian on Sunday, September 15, 2024 21:20:37
    From Newsgroup: comp.sys.raspberry-pi

    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.
    --- Synchronet 3.19b-Win32 NewsLink 1.113
  • From Lawrence D'Oliveiro@ldo@nz.invalid to comp.sys.raspberry-pi,alt.os.linux.debian on Sunday, September 15, 2024 23:58:34
    From Newsgroup: comp.sys.raspberry-pi

    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? ;)
    --- Synchronet 3.19b-Win32 NewsLink 1.113
  • From Chris Green@cl@isbd.net to comp.sys.raspberry-pi,alt.os.linux.debian on Monday, September 16, 2024 07:18:06
    From Newsgroup: comp.sys.raspberry-pi

    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
    ·
    --- Synchronet 3.19b-Win32 NewsLink 1.113
  • From Anton Shepelev@ant@tilde.culb to comp.sys.raspberry-pi,alt.os.linux.debian on Tuesday, September 17, 2024 23:43:48
    From Newsgroup: comp.sys.raspberry-pi

    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.
    --- Synchronet 3.19b-Win32 NewsLink 1.113
  • From Anton Shepelev@ant@tilde.culb to comp.sys.raspberry-pi,alt.os.linux.debian on Tuesday, September 17, 2024 23:47:00
    From Newsgroup: comp.sys.raspberry-pi

    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 .
    --- Synchronet 3.19b-Win32 NewsLink 1.113