Dear Release Notes Maintainers,

Some text based on below would make sense for the Release Notes for
buster. If agreed I'll try to come up with a wording.

A web search found #802211[1].

Short version:

For systemd >= 240 (buster[2]) run as root

    systemctl edit rescue.service

and add:

    [Service]
    Environment=SYSTEMD_SULOGIN_FORCE=1

(see /usr/share/doc/systemd/ENVIRONMENT.md.gz)


The 'rescue.service' is started by systemd in case it detects 'single'
on the kernel command line (see systemd(1)).

You might want to do the same for 'emergency.service' as well (or
instead), since this service is started *automatically* in case of
certain errors (see systemd.special(7)) or if you add 'emergency' to the
kernel command line (e.g. if you can't fix your system via the 'rescue'
service).


An untested patch to the Debian Installer exists to add both snippets if
the user chooses to leave the root password blank.


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802211
[2] see the bug for another snippet that should work for squeeze or
earlier.

Kind regards,
Andrei

On Mon, 14 Dec 2020 13:12:59 +0200 Andrei POPESCU <andreimpopescu@gmail.com> wrote:

Sure. Does this also apply for bullseye, or is the issue fix somehow?

Paul

This is still an issue for bullseye. Patch was not applied, but solution
works if you apply it manually after OS installation.
I've tested it on latest weekly build (debian-testing-amd64-netinst.iso).

Ok, here is something, just to get the discussion started:


    The `rescue` boot option is unusable without a root password.


    If a password for the `root` account is not set the system will
    still ask for the root password if booted with the `rescue` option,
    effectively making the rescue mode unusable. In order to avoid this
    it is possible to boot using the kernel parameter
    `init=/sbin/sulogin --force`.

    To configure pkg:systemd to always to do the equivalent of this on
    selecting the `rescue` option add `SYSTEMD_SULOGIN_FORCE=1` to the
    Environment of the rescue.service unit (see
    file:/usr/share/doc/systemd/ENVIRONMENT.md.gz). The `rescue.service`
    unit is started by pkg:systemd in case it detects `single` in the
    kernel command line (see man:systemd).

    It might be useful to do the same for the `emergency.service` unit
    (or instead) which is started ''automatically'' in case of certain
    errors (see man:systemd.special), or if `emergency` is added to the
    kernel command line (e.g. in case the system can't be recovered by
    using the `rescue` mode).

    For background and a discussion on the security implications see
    bts:802211.


The pseudo-markup should be obvious. I'll try to come up with a patch
later, unless Someone Else (TM) beats me to it ;)

Kind regards,
Andrei

Andrei POPESCU wrote:

Thanks!  My suggestions below still need some work, but I'll call this
my first pass:

Simplifying:

    <title>
      The <literal>rescue</literal> boot option is unusable without a root password
    </title>
    <para>
      Booting with the <literal>rescue</literal> option always requires
      the root password. If one has not been set, this makes the rescue
      mode effectively unusable. However it is still possible to boot
      using the kernel parameter <literal>init=/sbin/sulogin --force</literal>
    </para>

(I don't think "root" needs special markup; "rescue" only needs it
when we're talking about an untranslatable literal string).

(Should there be some hint here at the fact that this has happened
because we've switched to an implementation of sulogin without the
slightly dodgy Debian-specific patches?)
                   ^^^         ^^        ^^
When we're talking about machines booting with systemd-sysv, we should
avoid mentioning <systemitem role="package">systemd</systemitem>
(which is a pain to type anyway).

The "to" might go in either position, but not both.  Here perhaps we
might be better off saying

      To configure systemd to do the equivalent of this whenever the
      <literal>rescue</literal> option is used,

At least this information is already on my system before the
dist-upgrade.
                                     ^^^^^^^

Bad use of "in case" - most English-speakers interpret "in case of" as
"unconditionally, to avert the danger of".

systemd(1) defines "single" and "rescue" (and "1"!) as aliases of
"systemd.unit=rescue.target", so maybe we can make that clearer
earlier.

    <para>
      To configure systemd to do the equivalent of this whenever it
      boots into rescue mode (also known as single mode - see <ulink
      url="&url-man;/bullseye/systemd/systemd.1.html">systemd(1)</ulink>),
      add <literal>SYSTEMD_SULOGIN_FORCE=1</literal> to the
      Environment of the <literal>rescue.service</literal> unit (see
      <filename>/usr/share/doc/systemd/ENVIRONMENT.md.gz</filename>).
    </para>

Unfortunately we also need readers to know
 * how to add things to a systemd unit (we don't want people editing
   /lib/systemd/system/rescue.service and losing it in an upgrade)
 * how much of the rest of the file they should copy (as little as
   possible, I think, but how much is that?)
 * how the syntax for multiple items in an Environment= line works

This probably needs an external link, but I'm not optimistic we'll
find one.  Maybe this is another case where we'll need a dedicated
page on wiki.debian.org.

(And why *is* the systemd man page in section 1, anyway?  Shouldn't it
be in section 8, like systemv init used to be?)
       ^^^^^^^^^^                                     ^^^^^^^^^^
                                ^^^^^^^

"The same or instead" needs to be reorganised as "as well or instead".

One of those "in case"s almost works.

I'm not sure what markup you mean for ''automatically''.

    <para>
      It might be useful to do this for the <literal>emergency.service</literal>
      unit (as well or instead), which is started automatically in the case
      of certain errors (see <ulink
      url="&url-man;/bullseye/systemd/systemd.special.7.html">systemd.special(7)</ulink>),
      or if <literal>emergency</literal> is added to the kernel command line
      (e.g. if the system can't be recovered by using the rescue mode).
    </para>

(Why *did* setting these systems up with passwords in the first place
go out of fashion?)

I forget if we've got special markup for this or whether we just say

    <para>
      For background and a discussion on the security implications see
      <ulink url="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802211">bug
      #802211</ulink>.
    </para>

Or even delegate it to the wiki link.  Oh well, buster needed two
last-minute wiki pages for complicated issues, so if bullseye only
needs one for this we'll still be improving...

Ok

This is explained in the bug report for who cares to investigate, in my
opinion it's not needed in the Release Notes.

It's a consequence of some rewrite :)

I'll have to trust you on this (and make a mental note about it).

As you probably know, it's as simple as:

    systemctl edit rescue.service

    and add

    [Service]
    Environment=SYSTEMD_SULOGIN_FORCE=1


It seemed a little bit much to add this as well, but I'm fine either
way.

Some form of emphasis, to draw attention to the fact that users might
find themselves stuck at the emergency console.

For me it was a natural consequence of using sudo exclusively ;)

All entities are in a dedicated file (I don't have a checkout handy to
look it up).

This is actually applicable for buster as well, unfortunately it wasn't
fixed for bullseye (patch for d-i was still pending last time I
checked).

Kind regards,
Andrei

Andrei POPESCU wrote:

This was mostly a note to myself in the hope that I'd find a way of
leading into it that accentuated the positive - after all, this is
just a side-effect of improvements elsewhere.  But when we're this
late documenting it, it's a non-starter.

[...]

Well, I know that now, because I've been looking it up, but I wasn't
sure as I wrote that, and it's not as easy to pull the details
together as it should be.  Still, at least it doesn't need the usual
reminders to run daemon-reload or reboot.  But instead of telling
people all about where to hunt for the information it might be quicker
in this case just to put the answer in the text!

   <title>
     The <literal>rescue</literal> boot option is unusable without a root password
   </title>
   <para>
     Booting with the <literal>rescue</literal> option always requires
     the root password. If one has not been set, this makes the rescue
     mode effectively unusable. However it is still possible to boot
     using the kernel parameter <literal>init=/sbin/sulogin --force</literal>
   </para>
   <para>
     To configure systemd to do the equivalent of this whenever it boots
     into rescue mode (also known as single mode: see <ulink
     url="&url-man;/bullseye/systemd/systemd.1.html">systemd(1)</ulink>),
     run <command>sudo systemctl edit rescue.service</command> and create
     a file saying just:
   </para>
   <screen>
     [Service]
     Environment=SYSTEMD_SULOGIN_FORCE=1
   </screen>
   <para>
     It might also (or instead) be useful to do this for the
     <literal>emergency.service</literal> unit, which is started
     <emphasis>automatically</emphasis> in the case of certain
     errors (see <ulink
     url="&url-man;/bullseye/systemd/systemd.special.7.html">systemd.special(7)</ulink>),
     or if <literal>emergency</literal> is added to the kernel
     command line (e.g. if the system can't be recovered by using
     the rescue mode).
   </para>

[...]
yourself in each toe individually."

I can't see the definition, but judging by old .po files we want

    <para>
      For background and a discussion on the security implications see
      <ulink url="&url-bts;/802211">#802211</ulink>.
    </para>

Hi Justin, Andrei,

Thanks for the proposed text below. I struggle a bit with where to place
it. What do you suggest? It's not really an upgrading issue, is it?

Paul
@Andrei, I guess I should put it in the equivalent place in the buster
release notes too, right, after fixing suite names in the text?

Paul Gevers wrote:

Maybe at the end of "issues", next to the similarly chronic issue of
GNOME mouseless a11y?  That's under "package-specific-issues" at
present, mislabelled as a case where the package might not upgrade
smoothly; we don't really have any known cases of that to list, so
maybe we ought to reorganise the subsections a bit.  I would have
hoped we could arrange things so that the bookworm deprecations
subsection is at the very end, and whether we do that or not we might
want the "limited-security-support" bit to be alongside the a11y and
rescue.service bits in a "chronic-problems" section (but don't call it
that).

If this goes in a list that's organised in terms of packages then it
needs to give more of a hint about where the problem originated:

        ^With the implementation of <literal>sulogin</literal> now used,

Looking at that paragraph again, the man page is good enough to make
me consider shortening it to

        The same applies to the <literal>emergency.service</literal>
        unit, for booting into emergency mode; see <ulink
        url="&url-man;/bullseye/systemd/systemd.special.7.html">systemd.special(7)</ulink>.
                                      ^bug
-- 
JBR	with qualifications in linguistics, experience as a Debian
	sysadmin, and probably no clue about this particular package

Or maybe

    /now used/used since buster?


Otherwise Justin's suggestions are fine for me.

Kind regards,
Andrei

Hi Justin,
upgrade items):
5.1. Upgrade specific items for bullseye
5.2. Items not limited to the upgrade process
     * Limitations in security support
     * Gnome accessibility issue
     * password-less rescue mode
5.3. Obsolescence and deprecation
     * Noteworthy obsolete packages
     * Deprecated components for bullseye

Now I'm going over it, the Python2 is probably also not in the right
section. I think it warrants to be mentioned under "Noteworthy obsolete
packages" (section of 5.1) as the Python2 deprecation has resulted in *a
lot* of Python2 packages to have been removed.

Paul
PS: on the one hand it feels more natural to have deprecate before
obsolete, but on the other hand I guess it's more important to learn
about obsolete packages, so that goes first?

Paul Gevers wrote:

That's just about what I was thinking, if I'd taken the trouble to
look up the section numbers.

If we move it then it probably also needs... maybe just an extra line:

    Python 2 is already beyond its End Of Life, and will receive no
    security updates. It is not supported for running applications,
  + and packages relying on it have either been switched to Python 3 or removed.
    However, Debian bullseye does still include a version of Python 2.7,

I like having "obsolete" first; maybe that's because I'm hoping to
get a py2less system this summer but I'm still treating the
deprecation of unmerged /usr as just a cloud on the horizon.

I pushed the proposed text.

paul

[ including some text I sent within a control message* that doesn't appear
  in-thread as I was hoping; sending in quiet mode to reduce noisy repetition

  * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977358;msg=69 ]

Although this was documented for bullseye, the underlying cause
remains, and I think that it could be valuable for users to continue
to have this documentation available.

I've tested that the previously-added guidance from the bullseye
release notes remains valid and works on a bookworm system, and have
pushed a branch[1] to Salsa to restore the documentation.

Bugreport #952450 tracks a longer-term fix, and once that is resolved
I think it'd be fine to drop this note from the release-notes.

(for most other temporary/transitional release note issues, I think
it's fine to drop them between releases - this one seems to me like an
exception)

It's possible that this is too late to be included in the bookworm
release notes (and my apologies, if so).  If not, though, I'll provide
a similar commit for the reStructuredText migration (cc'd).

[1] - https://salsa.debian.org/jayaddison/release-notes-docbook/-/tree/bug-977358/retain-issue-note

On Sat, 03 Jun 2023 13:10:09 +0100

The original bug referred to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802211 - fixed in
bookworm
The above refers to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952450 is open as of
23 Dec 2024


I think this bug is about using system and rescue mode, which we
currently have section 4.1.4.2
trixie: https://www.debian.org/releases/trixie/release-notes/upgrading.en.html#debug-shell-during-boot-using-systemd
source: https://salsa.debian.org/ddp-team/release-notes/-/blame/master/source/upgrading.rst#L161

bookworm: https://www.debian.org/releases/bookworm/amd64/release-notes/ch-upgrading.en.html#recovery
source: https://salsa.debian.org/ddp-team/release-notes/-/blame/bookworm/en/upgrading.dbk?ref_type=heads#L188

Is there still something to document for a) bookworm and b) trixie,
and if so, what should it say?

Hi Richard,

Yep, as mentioned in Andrei's report, the SYSTEMD_SULOGIN_FORCE config
option, allowing successful emergency/rescue login when the root
account is locked, became available in systemd v240 and was included
in bookworm.

Indeed - it is yet-to-be-decided whether SYSTEMD_SULOGIN_FORCE will be
automatically enabled by the Debian installer when a locked root
account is requested.  Currently, the setting is not configured.

The intention of that documentation appears to be to explain how to
users/sysadmins how to reach a root shell in case of unexpected
boot-time system failures (I say that based on the sentence, "If the
boot fails under systemd, it is possible to obtain a debug root shell
by changing the kernel command line.").

In my experience, if the root password on a Debian installation is
locked, then rebooting into the systemd rescue.target and/or
emergency.target targets will _not_ provide a root shell (repeating
myself in an attempt to communicate my understanding: this is due to
the absence of the SYSTEMD_SULOGIN_FORCE setting).

As a result, I think there does indeed continue to be a gap in the
documentation, and that either Andrei's suggested issue-note[1] -
and/or mentioning the relevant systemd config setting may be required
to boot into rescue/emergency mode, would be worthwhile.

(I have confirmed locally that it is still necessary to add the config
option to get to a root shell when rebooting into those targets)

Regards,
James

[1] - https://salsa.debian.org/ddp-team/release-notes/-/commit/ad648eb9abc159d60319eccb81756e3825eae374