Re: Getting a serial console to work on Jessie
On Wednesday 02 September 2015 23:29:40 Sven Hartge wrote:
> Eike Lantzsch <zp6cge@gmx.net> wrote:
> > On Wednesday 02 September 2015 20:58:29 Sven Hartge wrote:
> >> David Parker <dparker@utica.edu> wrote:
> >>> Thanks. I actually found that site in a Google search, and it's where
> >>> I found the tip on copying the
> >>> /lib/systemd/system/serial-getty@.service template file to customize
> >>> the baud rate, etc. Specifically, I found the info I needed at:
> >>>
> >>> http://users.wowway.com/~zlinuxman/serial.htm#Systemd
> >>
> >> Well, the advise given on that website is wrong, or at least suboptimal,
> >> because it totally overrides the system configuration instead of only
> >> ammending it, which preserves future changes to the system file.
> >
> > May I kindly ask you to elaborate on that? Please, because I'm
> > interested too. Where is better information to be had or can you at
> > least point out where exactly one needs to start to iron out the
> > failings of the mentioned document?
> >
> > I'm not exactly understanding what you mean by "preserves future
> > changes to the system file". I always had the impression that my
> > changes to config files can either be overwritten by updates (bad),
> > merged into the newer config files (difficult without administrator
> > intervention) or left alone and new config files installed as
> > "release" files, or the new files installed and the old ones backed-up
> > as *.pkg-old.
> >
> > Preserves seem always to be from the past yield, can the future be
> > preserved?
> >
> > Also, what do you mean exactly by "system file" in the case of systemd
> > - those in /lib/systemd/system/?
>
> Please excuse this misunderstanding, my native language got the better
> of me in that case. "system file" means "the one from the package".
>
> Now, the explanation:
>
> systemd provides a way to override or ammend parts of units. You do this
> by creating a directory structure like this:
>
> /etc/systemd/system/foo.service.d/
>
> This will contain all additional config files for the unit
> "foo.service".
>
> For example: I don't want systemd to clear the screen on tty1 when it
> starts a new getty. The unit responsible for this TTY is named
> "getty@tty1.service". I created
>
> /etc/systemd/system/getty@tty1.service.d
>
> and put a file named "noclear.conf" in it with this content:
>
> ,----
>
> | [Service]
> | TTYVTDisallocate=no
>
> `----
>
> This will add (or change) the TTYVTDisallocate option to the unit.
> The original path to the unit is "/lib/systemd/system/getty@.service"
> and if this file is changed by a package update, its new content will be
> used.
>
> If I had copied the _whole_ file to /etc/systemd/system then the new
> version of the unit in "/lib/systemd/system" would never get used, just
> my own version. This may be fine but may also cause major problems in
> the future.
>
> This is what I meant by "future changes are preserved" as you don't just
> clobber them with your own full copy of the (then) old unit file.
>
> You can check which files are used for a unit with systemctl:
>
> systemctl cat getty@tty1.service
>
> and you will get an output like this (a bit shortened by me for this
> mail):
>
> ,----
>
> | # /lib/systemd/system/getty@.service
> |
> | [Unit]
> | Description=Getty on %I
> | Documentation=man:agetty(8) man:systemd-getty-generator(8)
> | Documentation=http://0pointer.de/blog/projects/serial-console.html
> | After=systemd-user-sessions.service plymouth-quit-wait.service
> | <<----8<--->>
> | [Service]
> | # the VT is cleared by TTYVTDisallocate
> | TTYVTDisallocate=yes
> | KillMode=process
> | IgnoreSIGPIPE=no
> | SendSIGHUP=yes
> |
> | # Unset locale for the console getty since the console has problems
> | # displaying some internationalized messages.
> | Environment=LANG= LANGUAGE= LC_CTYPE= LC_NUMERIC= LC_TIME= LC_COLLATE=
> | LC_MONETARY= LC_MESSAGES= LC_
> |
> | [Install]
> | WantedBy=getty.target
> | DefaultInstance=tty1
> |
> | # /etc/systemd/system/getty@tty1.service.d/noclear.conf
> | [Service]
> | TTYVTDisallocate=no
>
> `----
>
> Note how my own addition shows up at the bottom.
>
> Also note how a later "TTYVTDisallocate=no" overrides the earlier
> "TTYVTDisallocate=yes".
>
> You can also use "systemd-delta" to check which units have overrides or
> extentions. And with newer systemd (Stretch and newer) you can even use
> "systemctl edit unitname" and it will create the needed directory
> structure in the correct place for you.
>
> But you are also correct that this "override feature" is a bit different
> than the normal proceedings during upgrades and dealing with
> .dpkg-{old,new,dist}.
>
> But it is the way systemd is designed and you can either work with it or
> fight it every centimeter of the way.
I sure won't fight anything I do not thoroughly understand. That's always a
means to lose.
>
> I hope this explains my thoughts.
Very well.
>
> Grüße,
> Sven.
Thank you Sven!
This clears things up and sends me further[*] up the ladder to understand
systemd.
Herzliche Grüße
Eike
* I sincerely thought about writing "farther" but this ladder is figurative and
fits in more with the idea of time and effort.
Reply to: