Bug#1036658: release-notes: 5.1.8. rsyslog creates fewer log files - mail.log is not dropped
Am 24.05.23 um 15:25 schrieb Christoph Anton Mitterer:
On Wed, 2023-05-24 at 15:19 +0200, Michael Biebl wrote:
Sorry, I meant: It (the expresssion like /var/log/lpr.log.*) only
matches rotated files, but not the actual log file itself.
But for that I would have had both:
/var/log/mail.{info,warn,err} /var/log/lpr.log
/var/log/{messages,debug,daemon.log}
/var/log/mail.{info,warn,err}.* /var/log/lpr.log.*
/var/log/{messages,debug,daemon.log}.*
Indeed, I overlooked that part.
Anyway... if everyone agrees that we should leave out the rotated files
and leave that up to the user (which a note bout that being the case in
the release notes)... it would IMO be safer.
I could make a PR if desired so.
In the interest of keeping the list of file names short, I wouldn't
duplicate them (one with .* and one without). But that's just a personal
preference.
OpenPGP_signature
Description: OpenPGP digital signature
Bug#1036658: release-notes: 5.1.8. rsyslog creates fewer log files - mail.log is not dropped
Am 24.05.23 um 14:52 schrieb Christoph Anton Mitterer:
On Wed, 2023-05-24 at 09:47 +0200, Michael Biebl wrote:
The following would be at least a bit more restrictive:
/var/log/mail.{info,warn,err} /var/log/lpr.log
/var/log/{messages,debug,daemon.log}
/var/log/mail.{info,warn,err}.* /var/log/lpr.log.*
/var/log/{messages,debug,daemon.log}.*
not perfect though, cause it could still select unrelated files
It only matches compressed files though
Mine? That I don't understand... I have the ones with just the name of
the logfile itself... and then .*, which should match the non-
compressed .0, .1, etc. as any .0.xz, .1.xz, etc.?
Sorry, I meant: It (the expresssion like /var/log/lpr.log.*) only
matches rotated files, but not the actual log file itself.
OpenPGP_signature
Description: OpenPGP digital signature
Bug#1036658: release-notes: 5.1.8. rsyslog creates fewer log files - mail.log is not dropped
See https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/177
> Am 24.05.2023 um 02:30 schrieb Christoph Anton Mitterer
> :
>
> Oh and there's more which IMO can be improved.
>
> If people take the currently named pattern:
> - /var/log/mail.{info,warn,err,log}*
> - /var/log/lpr.log*
> - /var/log/{messages,debug,daemon}*
>
> the may accidentally delete quite some other files. e.g. anything that
> starts with debug.
>
> Also, daemon is actually daemon.log .
>
>
> The following would be at least a bit more restrictive:
> /var/log/mail.{info,warn,err} /var/log/lpr.log
> /var/log/{messages,debug,daemon.log}
> /var/log/mail.{info,warn,err}.* /var/log/lpr.log.*
> /var/log/{messages,debug,daemon.log}.*
>
> not perfect though, cause it could still select unrelated files
It only matches compressed files though
Maybe just drop the “*” and leave it up to the user
Bug#1023596: bookworm: document changes in default rsyslog configuration
Am 07.11.22 um 23:15 schrieb RL: Are both rsyslog and systemd's journal still both the default in bookworm? I see rsyslog is still priority: important - any plans to reduce that in future releases? That's actually good point: rsyslog in bookworm has been demoted to prio optional [1], so is no longer installed by default. Regards, Michael [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1018788 OpenPGP_signature Description: OpenPGP digital signature
Bug#1023596: bookworm: document changes in default rsyslog configuration
Package: release-notes
Severity: normal
The rsyslog configuration changed significantly in bookworm.
Copying the relevant parts from the changelog:
rsyslog (8.2210.0-3) unstable; urgency=medium
* Stop splitting up mail.*
This avoids having mail related messages duplicated in mail.log and
mail.{info,warn,err}. (Closes: #508376)
* Drop catch-all log files /var/log/{messages,debug}
Avoid unnecessary duplication as those log messages end up in
/var/log/syslog anyway. (Closes: #580552)
* Stop splitting lpr facility into its own log file.
The default printing system CUPS is not using this facility so its
basically unused nowadays.
* Stop splitting daemon facility into its own log file.
The daemon facility is too vaguely defined to be really useful and since
those log messages end up in /var/log/syslog anyway, stop duplicating
them.
* Split cron facility into its own log file /var/log/cron.log.
The cron facility is widely used and limited enough in scope to have it
split out separately. (Closes: #625483)
* Update comments in rsyslog.conf
* Enable high precision timestamps with timezone information.
Use the default rsyslog file format, which provides several benefits
like:
- sortable
- time zone information
- sub-second time resolution
(Closes: #475303)
-- Michael Biebl Sat, 29 Oct 2022 22:54:41 +0200
Assuming there is no huge backlash regarding those changes and they will
stay as-is, they should probably be documented in the release notes.
Regards,
Michael
Bug#985446: release-notes: cgroupv2 is the default cgroup hierarchy
Package: release-notes Severity: normal X-Debbugs-Cc: pkg-systemd-maintain...@lists.alioth.debian.org Starting with bullseye, the default cgroup hierarchy will be unified, ie. cgroupv2 only. We have this section in our systemd.NEWS file: systemd (247.2-2) unstable; urgency=medium systemd now defaults to the "unified" cgroup hierarchy (i.e. cgroupv2). This change reflects the fact that cgroups2 support has matured substantially in both systemd and in the kernel. All major container tools nowadays should support cgroupv2. If you run into problems with cgroupv2, you can switch back to the previous, hybrid setup by adding "systemd.unified_cgroup_hierarchy=false" to the kernel command line. You can read more about the benefits of cgroupv2 at https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html -- Michael Biebl Mon, 21 Dec 2020 18:40:10 +0100 We should add something similar to the release notes. The above text could be a good starting point. We track issues related to cgroupv2 via user tags [1]. Some tools, most notably probably is libcgroup [2], don't support cgroupv2 yet. Regards, Michael [1] https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=pkg-systemd-maintain...@lists.alioth.debian.org;tag=cgroupv2 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959022
Bug#950447: Document that persistent journal is now enabled in systemd
Hi Paul Am 18.03.2021 um 11:29 schrieb Paul Gevers: Control: tags -1 moreinfo HI Michael, On Sat, 01 Feb 2020 21:45:06 +0100 Michael Biebl wrote: See https://lists.debian.org/debian-devel/2020/02/msg4.html We should document in the release notes, that systemd has enabled persistent logging in journald. Personally, I would prefer to do that on upgrades and new installations and document that accordingly (and that is what the systemd package currently does). The discussions on debian-devel are still ongoing, so this might still change though. So, what's the end status in bullseye now? Can you propose a text? Yes, the persistent journal is enabled on upgrades and new installations. What I didn't push for is the demotion of rsyslog from important to optional, so rsyslog is still installed by default as well. I plan to change that in bullseye+1 (*) This is sort of deliberate to have both installed for one release cycle. Just in case something goes horribly wrong with the persistent journal (which I don't expect), users still have their known plaintext log files as fallback. I'm a bit uncertain, whether I should go into that much detail in the release notes, especially wrt to rsyslog. But on the other hand, this way our users are notified in advance that this change is coming. Paul, wdyt? (*) My plan would be, to simply demote rsyslog to optional, but not actively remove it on upgrades. OpenPGP_signature Description: OpenPGP digital signature
Bug#950447: Document that persistent journal is now enabled in systemd
Package: release-notes Severity: normal See https://lists.debian.org/debian-devel/2020/02/msg4.html We should document in the release notes, that systemd has enabled persistent logging in journald. Personally, I would prefer to do that on upgrades and new installations and document that accordingly (and that is what the systemd package currently does). The discussions on debian-devel are still ongoing, so this might still change though. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-3-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#939671: 5.3.6 "gnome-disk-utility fails to change LUKS password causing permanent data loss" has been fixed
Package: release-notes Severity: normal Hi, the underlying issue resulting in 5.3.6 "gnome-disk-utility fails to change LUKS password causing permanent data loss" has been fixed being documented in the release notes has been fixed in 10.1. It would probably be a good idea to amend the section in the release notes accordingly. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Re: Release Notes for buster: 70-persistent-net-rules still supported?
Am 03.07.19 um 18:48 schrieb Justin B Rye: >> As said, net.ifnames=0 does not enforce the old naming scheme, it means >> use the kernel provided names. > I don't follow. Surely the old naming scheme *is* to use the > kernel-provided names? Where did names like "eth0" come from if not > the kernel? > Not quite. The old scheme (let's called it 70-persistent-net.rules for that matter) used the same name space as the kernel (i.e. eth* and wlan*) but it bound it to the MAC address. So, an interface could be called eth0 by the kernel but 70-persistent-net.rules would map this to eth1 (this can happen if 70-persistent-net.rules already had an old eth0 entry from a card that no longer existed). The result is that 70-persistent-net.rules renames eth0 to eth1. This is one, if not the most problematic aspect of the old scheme as it was using the kernel name space to pick the new names from. It's not hard to see that this is riddled with race conditions if you have multiple interfaces. Now, with net.ifnames=0 we don't do any renaming in user space at all. We just take the interface names that are given to us by the kernel. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Release Notes for buster: 70-persistent-net-rules still supported?
Am 03.07.19 um 18:52 schrieb andreimpope...@gmail.com: > On Mi, 03 iul 19, 18:22:30, Michael Biebl wrote: >> Am 03.07.19 um 17:53 schrieb andreimpope...@gmail.com: >>> >>> diff --git a/en/issues.dbk b/en/issues.dbk >>> index 4769f9d6..c7634151 100644 >>> --- a/en/issues.dbk >>> +++ b/en/issues.dbk >>> @@ -136,7 +136,7 @@ information mentioned in . >>> the old-style network interface names that were deprecated with >>> stretch (such as eth0 or wlan0), >>> you should be aware that udev >>> - in buster no longer supports the mechanism of defining their names via >>> + in buster does not reliably support the mechanism of defining their >>> names via >> >> I'd prefer if we rephrased that and declared the old naming scheme as >> officially unsupported in buster. > > As per the e-mail thread that started this, users will find out it does > work. If the Release Notes entry contradicts their experience they will > dismiss the advice as outdated/incorrect/etc. Being a supported configuration and still working (to some extent) are two different issues, I'd say. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Release Notes for buster: 70-persistent-net-rules still supported?
Am 03.07.19 um 17:53 schrieb andreimpope...@gmail.com: > On Mi, 03 iul 19, 16:47:36, Michael Biebl wrote: >> Am 03.07.19 um 16:12 schrieb Michael Biebl: >>> Am 03.07.19 um 15:50 schrieb andreimpope...@gmail.com: >>>> Please kindly confirm this Release Notes entry is needed/correct/etc. >>>> https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#migrate-interface-names >>>> >>>> #919390 appears to contradict /usr/share/doc/udev/README.Debian.gz. >>> >>> In short: yes please keep this section in the release notes. >>> We still ship >>> https://salsa.debian.org/systemd-team/systemd/blob/master/debian/patches/debian/Revert-udev-network-device-renaming-immediately-give.patch >>> in buster, which sort of makes 70-persistent-net.rules work most of the >>> time. >>> This patch is a horrible hack though and has already been removed in the >>> experimental branch which will be buster+1 >>> https://salsa.debian.org/systemd-team/systemd/commit/3d45a7af959cf260bffcb1ad0262973b5750ae36 >>> >>> We want people to switch to the new naming scheme for two reasons: >>> 1/ It makes buster backports of newer systemd versions possible >>> 2/ People are already prepared when they upgrade to buster+1. Say the >>> buster+1 kernel fails, they can still boot with the buster kernel+initramfs. >>> >>> >>> I can go into more detail but hope that clarifies the situation. >> >> Hm, reading the release notes again, there should be a big fat warning >> when using net.ifnames=0 (there is also a typo, note the missing 's'). >> >> It does not enforce the old naming scheme, it simply means use the >> kernel provided names. This is only advisable if you ever have a single >> interface. If you have multiple interfaces it is possible that the names >> change as the kernel probes devices asynchronously nowadays. > > Would the kernel opetion work in case the interfaces are of different > types (e.g. one ethernet and one wireless)? > > Based on your comments I prepared the patch below (also attached for > convenience), that I could push anytime. > > diff --git a/en/issues.dbk b/en/issues.dbk > index 4769f9d6..c7634151 100644 > --- a/en/issues.dbk > +++ b/en/issues.dbk > @@ -136,7 +136,7 @@ information mentioned in . > the old-style network interface names that were deprecated with > stretch (such as eth0 or wlan0), > you should be aware that udev > - in buster no longer supports the mechanism of defining their names via > + in buster does not reliably support the mechanism of defining their > names via I'd prefer if we rephrased that and declared the old naming scheme as officially unsupported in buster. It might still work under certain circumstances (not sure if it makes sense to go into detail here what those circumstances are) but users are strongly advised to migrate to the new naming scheme. > /etc/udev/rules.d/70-persistent-net.rules. To > avoid the danger of your machine losing networking after the upgrade > to buster, it is recommended that you migrate in advance to the new > @@ -148,10 +148,11 @@ information mentioned in . > > > The alternative is to switch to a supported mechanism for enforcing > - the old naming scheme, such as the net.ifname=0 > - kernel commandline option or a systemd .link > - file (see - url="https://manpages.debian.org/systemd.link;>systemd.link(5)). > + the old naming scheme, such as a systemd .link As said, net.ifnames=0 does not enforce the old naming scheme, it means use the kernel provided names. If users want to stick with the kernel provided interfaces names, they should be aware that this is can lead to interfaces having different names on each boot if they have multiple interfaces. Usually ethernet interfaces are name eth* and wifi interfaces are named wlan*, so yeah, if you have a single ethernet interface which is named eth0 and a single wifi interface that is named wlan0, then you are safe as well. I do vaguely remember seeing wifi interfaces named as eth* though. I've seen this a long time ago, not sure if this is still valid today and you can safely say nowadays that wifi interfaces are always called wlan*. > + file (see https://manpages.debian.org/systemd.link;> > + systemd.link(5)). > + The net.ifnames=0 kernel commandline option might > + also work for systems with only one network interface. > > > To find the new-style names that will be used, first find the > > Kind regards, > Andrei > > > ___ > Pkg-systemd-maintainers mailing list > pkg-systemd-maintain...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers > -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Release Notes for buster: 70-persistent-net-rules still supported?
Am 03.07.19 um 16:12 schrieb Michael Biebl: > Am 03.07.19 um 15:50 schrieb andreimpope...@gmail.com: >> Please kindly confirm this Release Notes entry is needed/correct/etc. >> https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#migrate-interface-names >> >> #919390 appears to contradict /usr/share/doc/udev/README.Debian.gz. > > In short: yes please keep this section in the release notes. > We still ship > https://salsa.debian.org/systemd-team/systemd/blob/master/debian/patches/debian/Revert-udev-network-device-renaming-immediately-give.patch > in buster, which sort of makes 70-persistent-net.rules work most of the > time. > This patch is a horrible hack though and has already been removed in the > experimental branch which will be buster+1 > https://salsa.debian.org/systemd-team/systemd/commit/3d45a7af959cf260bffcb1ad0262973b5750ae36 > > We want people to switch to the new naming scheme for two reasons: > 1/ It makes buster backports of newer systemd versions possible > 2/ People are already prepared when they upgrade to buster+1. Say the > buster+1 kernel fails, they can still boot with the buster kernel+initramfs. > > > I can go into more detail but hope that clarifies the situation. Hm, reading the release notes again, there should be a big fat warning when using net.ifnames=0 (there is also a typo, note the missing 's'). It does not enforce the old naming scheme, it simply means use the kernel provided names. This is only advisable if you ever have a single interface. If you have multiple interfaces it is possible that the names change as the kernel probes devices asynchronously nowadays. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Release Notes for buster: 70-persistent-net-rules still supported?
Am 03.07.19 um 16:12 schrieb Michael Biebl: > Am 03.07.19 um 15:50 schrieb andreimpope...@gmail.com: >> Please kindly confirm this Release Notes entry is needed/correct/etc. >> https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#migrate-interface-names >> >> #919390 appears to contradict /usr/share/doc/udev/README.Debian.gz. > > In short: yes please keep this section in the release notes. > We still ship > https://salsa.debian.org/systemd-team/systemd/blob/master/debian/patches/debian/Revert-udev-network-device-renaming-immediately-give.patch > in buster, which sort of makes 70-persistent-net.rules work most of the > time. > This patch is a horrible hack though and has already been removed in the > experimental branch which will be buster+1 > https://salsa.debian.org/systemd-team/systemd/commit/3d45a7af959cf260bffcb1ad0262973b5750ae36 > > We want people to switch to the new naming scheme for two reasons: > 1/ It makes buster backports of newer systemd versions possible > 2/ People are already prepared when they upgrade to buster+1. Say the > buster+1 kernel fails, they can still boot with the buster kernel+initramfs. > > > I can go into more detail but hope that clarifies the situation. > To sum this up: While an existing 70-persistent-net.rules might still work most of the time in buster, it is no longer a supported scheme by the pkg-systemd-maintainer team. And in buster+1 it will most likely be completely broken withouth the patch I referenced above. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Release Notes for buster: 70-persistent-net-rules still supported?
Am 03.07.19 um 15:50 schrieb andreimpope...@gmail.com: > Please kindly confirm this Release Notes entry is needed/correct/etc. > https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#migrate-interface-names > > #919390 appears to contradict /usr/share/doc/udev/README.Debian.gz. In short: yes please keep this section in the release notes. We still ship https://salsa.debian.org/systemd-team/systemd/blob/master/debian/patches/debian/Revert-udev-network-device-renaming-immediately-give.patch in buster, which sort of makes 70-persistent-net.rules work most of the time. This patch is a horrible hack though and has already been removed in the experimental branch which will be buster+1 https://salsa.debian.org/systemd-team/systemd/commit/3d45a7af959cf260bffcb1ad0262973b5750ae36 We want people to switch to the new naming scheme for two reasons: 1/ It makes buster backports of newer systemd versions possible 2/ People are already prepared when they upgrade to buster+1. Say the buster+1 kernel fails, they can still boot with the buster kernel+initramfs. I can go into more detail but hope that clarifies the situation. Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#871721: After upgrade to stretch, booting fails due to late mounting of /var
Control: reassign -1 binfmt-support On Fri, 11 Aug 2017 00:26:18 +0200 mat...@web.de wrote: > Package: release-notes > > After upgrading from jessie to stretch, the boot process fails and goes into > the emergency mode. Several programs try to access /var which is, however, > mounted later. > > The Release Notes comment on /usr but not on /var: > > https://www.debian.org/releases/stretch/i386/release-notes/ch-information.en.html#late-mounting-usr > > I got the system booting again after spending hours with reading man pages > and finally creating /etc/systemd/system/var.mount, a modified version of > /run/systemd/generator/var.mount: > > [Unit] > SourcePath=/etc/fstab > Documentation=man:fstab(5) man:systemd-fstab-generator(8) > Before=console-kit-log-system-start.service binfmt-support.service That sounds like a bug in consolekit and/or binfmt-support (in stretch). consolekit has been removed from the archive, which leaves binfmt-support. binfmt-support.service uses DefaultDependencies=no [1], so is responsible for declaring all necessary dependencies/orderings itself. I'm thus re-assigning this bug to binfmt-support. Might be that this issue is already fixed, but I'd like its maintainers have a look first. Regards, Michael [1] https://salsa.debian.org/debian/binfmt-support/blob/master/init/systemd/binfmt-support.service.in -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#931130: Document that local configuration for dummy and bonding modules are getting overwritten by systemd
Am 29.06.2019 um 19:52 schrieb Justin B Rye: > diff --git a/en/issues.dbk b/en/issues.dbk > index 2edb9838..bf007277 100644 > --- a/en/issues.dbk > +++ b/en/issues.dbk > @@ -203,33 +203,28 @@ $ sudo update-initramfs -u > > Module configuration for bonding and dummy interfaces > > - Administrators who are using channel bonding and/or dummy > - interfaces (for instance to configure a machine as a router), and > - who have set up module parameters in a file under > - /etc/modprobe.d, may need to change the name > - of the local configuration file used, to avoid these parameters > - being ignored after the upgrade to buster. > - > - > - In buster, udev ships a > - file /lib/modprobe.d/systemd.conf designed to > - make it easier to configure such interfaces using > - systemd-networkd. This contains the lines > + Systems using channel bonding and/or dummy interfaces, for instance to > + configure a machine as a router, may encounter problems upgrading to > buster. > + New versions of systemd > install a > + file /lib/modprobe.d/systemd.conf (intended to > + simplify configuration via systemd-networkd) which > + contains the lines > > > options bonding max_bonds=0 > options dummy numdummies=0 > > > - A file in /lib/modprobe.d can be overridden by > - one with the same name under /etc/modprobe.d, > - but the names are processed in alphabetical order, so > - /lib/modprobe.d/systemd.conf follows and > - overrides (for instance) > - /etc/modprobe.d/dummy.conf. Make sure that any > - local configuration file has a name that sorts after > - systemd.conf, such as > - /etc/modprobe.d/zz-local.conf. > + Admins who were depending on different values will need to ensure they > are > + set in the correct way to take precedence. A file in > + /etc/modprobe.d will override one with the same > name > + under /lib/modprobe.d, but the names are > + processed in alphabetical order, so > + /lib/modprobe.d/systemd.conf follows and overrides > + (for instance) /etc/modprobe.d/dummy.conf. Make > sure > + that any local configuration file has a name that sorts after > + systemd.conf, such as > + /etc/modprobe.d/zz-local.conf. > > lgtm, fwiw. Thanks Justin. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#931130: Document that local configuration for dummy and bonding modules are getting overwritten by systemd
Am 29.06.19 um 15:09 schrieb Justin B Rye: > + configure a machine as a router, may encounter problems upgrading to > buster. > + New versions of udev install a That modprobe config file is shipped by the systemd package, not by udev. > A file in > + /lib/modprobe.d can be overridden by one with the > + same name under /etc/modprobe.d, but the names are > + processed in alphabetical order, so That sentence is a bit confusing: files with the same name are overridden. period. there is no but. Are you trying to say that files can be overridden as a whole but usually its better to only override specific settings in a local configuration file which doesn not have the same name? (which is indeed a useful recommendation because future updates of systemd.conf might be missed if you name the file /etc/modprobe.d/systemd.conf). -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
Bug#931130: Document that local configuration for dummy and bonding modules are getting overwritten by systemd
Am 28.06.19 um 12:58 schrieb Justin B Rye: > Michael Biebl wrote: >> Afaiu, the kernel default is to create one dummy device by default when >> the module is loaded. .. or bond device, for that matter. >> I assume there might be cases where users rely on that default behaviour >> without having explicitly configured anything. > > Do we have any idea what their use case would be? Apparently a > different one from Baptiste's, if it's true that he needed to > explicitly configure "numdummies=1"... Dunno why Baptiste had to do that. I just verified that by removing /lib/modprobe.d/systemd.conf, I got the following when running "modprobe dummy" and "modprobe bonding": 6: bond0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 82:e5:b3:41:67:17 brd ff:ff:ff:ff:ff:ff 7: dummy0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 5e:eb:30:64:69:ef brd ff:ff:ff:ff:ff:ff With the modprobe.d config file installed, there obviously was neither a dummy0 nor bond0 device. Fwiw, I know too little about those dummy and bonding devices and how they are usually used. E.g. network-manager and networkd seem to create them on the fly as needed. So I'm not sure, which users will actually be affected by that change. Would be good to know how Baptiste is setting up those devices. If he is doing it manually via some scripting of low level tool or uses a higher level network management tool Fwiw, with "ip link add dummy0 type dummy" (or "ip link add bond0 type bond") I was e.g. able to create such a device manually as well. I wonder whether such an approach isn't better then statically setting the number of devices via a kernel module option. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
Bug#931130: Document that local configuration for dummy and bonding modules are getting overwritten by systemd
Am 27.06.19 um 20:02 schrieb Justin B Rye: > Justin B Rye wrote: >> Okay, so here's a first rough idea of what the release-notes might >> say. > > Properly formatted patch attached. > Afaiu, the kernel default is to create one dummy device by default when the module is loaded. I assume there might be cases where users rely on that default behaviour without having explicitly configured anything. Atm, the release note entry reads like only admins who have a modprobe.d config are possibly affected. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
Bug#931130: Document that local configuration for dummy and bonding modules are getting overwritten by systemd
Am 26.06.19 um 21:39 schrieb andreimpope...@gmail.com: > > On Mi, 26 iun 19, 20:23:59, Baptiste BEAUPLAT wrote: >> The only way to force modprobe to use local configuration is to rename >> the /etc/modprobe.d/dummy.conf file to /etc/modprobe.d/systemd.conf. > > Is this documented anywhere else? According to the docs in man 5 modules-load.d it should be sufficient to name the local config so that is sorted after systemd.conf. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
Bug#931130: Document that local configuration for dummy and bonding modules are getting overwritten by systemd
Am 26.06.19 um 21:39 schrieb andreimpope...@gmail.com: > Control: tags -1 moreinfo > > On Mi, 26 iun 19, 20:23:59, Baptiste BEAUPLAT wrote: >> Package: release-notes >> >> Dear maintainers, >> >> Systemd, in buster, will ship the file /lib/modprobe.d/systemd.conf, >> which contains the following: >> >> options bonding max_bonds=0 >> >> # Do the same for dummy0. >> >> options dummy numdummies=0 >> >> This breaks any configuration that an administrator could have added to >> /etc/modprobe.d regarding the dummy and bonding modules. > > Would you have background information on why this is done? > What would be the impact on local configuration (networking unusable, > degraded, etc.)? Assuming this was targeted at pkg-systemd-maintainers, I assume xnox can tell you more. See https://github.com/systemd/systemd/pull/6448 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
Re: New network interface names (Was: Re: Installing chapter in the release notes)
Hi Baptiste! Sorry for not replying earlier. Am 18.05.2017 um 14:48 schrieb Baptiste Jammet: > Hello, > > Dixit Baptiste Jammet, le 27/04/2017 : > > [...] >> Before finalising the wording for the release notes, we would like to >> know if we understood correctly this new network interface naming >> method. >> I would like to add a quick note about it in the "installing" chapter, >> and a full explanation in "whats-new". > > As nobody answers, I've commited the last proposed patch as r11493. > Feel free to open a bug against release-notes if you want a > better tracking. I quickly glanced of the text a while back and it looks fine to me. A link to the upstream documentation at https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ would probably be useful, but then again, you already refer to /usr/share/doc/udev/README.Debian.gz which contains a link to that wiki. Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: manpages.debian.org has been modernized!
Hi Michael Am 18.01.2017 um 18:23 schrieb Michael Stapelberg: > https://manpages.debian.org has been modernized! We have just launched Thanks a lot, this looks really nice. One feature I'd like to see added is search as you type, like tracker.d.o offers. Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#830719: Document the removal of upstart, suggest switch to supported init
Package: release-notes Severity: normal The upstart init system has been removed from unstable/testing, so it looks like it won't be part of the upcoming stretch release. I raised this issue on debian-devel [1] and one recommendation was, that this fact should be mentioned in the release notes. We should suggest that users switch to a supported alternative because post-stretch it's likely that maintainers start removing native upstart jobs. Regards, Michael [1] https://lists.debian.org/debian-devel/2016/06/msg00025.html -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#723613: udev in jessie requires a kernel with CONFIG_DEVTMPFS=y
Package: release-notes Severity: normal Tags: jessie udev 176 and newer requires a kernel with devtmpfs support since it no longer creates any device nodes itself [1]. The Debian provided kernels in wheezy and jessie do have CONFIG_DEVTMPFS=y already, so are not affected by this change. Users with self-compiled kernels should check their kernel configuration and update if needed. We should add a section about this new kernel requirement to the jessie release notes. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=722580 -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.10-3-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-doc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130917225746.2223.80830.report...@pluto.milchstrasse.xx
Bug#706768: release-notes: new in wheezy: systemd
Package: release-notes Severity: normal Hi, please consider applying the attached patch to the release notes which adds a section about systemd to what's new. Cheers, Michael -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (500, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.8-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Index: en/whats-new.dbk === --- en/whats-new.dbk (Revision 10039) +++ en/whats-new.dbk (Arbeitskopie) @@ -458,6 +458,30 @@ /section +section id=systemd + titlesystemd/title + para +debian; release; introduces preliminary support for systemd, a modern +init system with advanced monitoring, logging and service management +capabilities. + /para + para +While it is designed as a drop-in sysvinit replacement and as such makes +use of the existing SysV init scripts, the +systemitem role=packagesystemd/systemitem package can be installed +safely alongside sysvinit and started via the +literalinit=/bin/systemd/literal kernel option. +To utilize the features provided by systemd, about 50 packages already +provide native systemd support, among them core packages like udev, dbus +and rsyslog. + /para + para +systemd is shipped as a technology preview in debian; release;. +For more information on this topic, see the Debian +ulink url=http://wiki.debian.org/systemd;wiki/ulink. + /para +/section + !-- Copied from http://wiki.debian.org/NewInWheezy -- section id=multimedia titleMultimedia/title
Bug#548336: restart gnome on squeeze2wheezy upgrades?
Am 29.04.2013 11:31, schrieb Holger Levsen: Hi, is it desirable to restart gnome on squeeze2wheezy upgrades, like it was for lenny2squeeze upgrades? If not, we should close #548336. Else, we should document this as requested by this bug. Patches welcome. A restart of your desktop session is definitely desirable after a squeeze - wheezy dist-upgrade. I even think we should advice users to *not* upgrade from within a running X/GNOME session but from the console. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#491180: release-notes: Document the switch of default system log daemon from sysklogd to rsyslog
Jonas Meurer wrote: On 04/10/2008 Luk Claes wrote: Can you please provide a proposed text (license: GPL v2) regarding the switch of the default system log daemo to include in the release notes? It should not be too technical (a pointer to README.Debian for the technical details would do), but should mention that it's something which doesn't happen automatically while upgrading etc. Hello, Attached is a first rough patch. I guess it's better than nothing. Feel free to improve it as you want. License is GPLv2. Hi Jonas, hi Luk, I think Jonas text is quite good already. What I'd like to change though is the following sentence: In most cases it should be sufficient to copying filename/etc/syslog.conf/ filename to filename/etc/rsyslog.conf/filename. rsyslog v3 is much more modular than previous releases, and you have to load a couple of modules (such as imuxsock for local logging), otherwise it could lead to subtle failures. rsyslog can be run in a sort of compat mode, where it loads a default set of modules and thus is more compatible to old sysklogd behaviour, but this requires to edit /etc/default/rsyslog and changing -c3 to -c2. Instead of copying the old syslog.conf over rsyslog.conf, I'd rather suggest to migrate custom configuration from syslog.conf to rsyslog.conf So this would be my recommendation: If you have custom logging rules, you should migrate them to the new configuration file filename/etc/rsyslog.conf/filename. Comments welcome. A patch is attached. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? Index: en/whats-new.dbk === --- en/whats-new.dbk(Revision 5625) +++ en/whats-new.dbk(Arbeitskopie) @@ -395,9 +395,8 @@ role=packagersyslog/systemitem instead of systemitem role=packagesysklogd/systemitem. systemitem role=packagersyslog/systemitem is quite compatible to stock sysklogd and -can be used as a drop-in replacement. In most cases it should be sufficient to -copying filename/etc/syslog.conf/filename to -filename/etc/rsyslog.conf/filename. +can be used as a drop-in replacement. If you have custom logging rules, you +should migrate them to the new configuration file filename/etc/rsyslog.conf/filename. /para para Users upgrading from oldreleasename; need to install systemitem signature.asc Description: OpenPGP digital signature
Bug#491180: sysklogd/rsyslog switch
Jonas Meurer wrote: On 17/07/2008 Henrique de Moraes Holschuh wrote: On Wed, 16 Jul 2008, Bernd Eckenfels wrote: In article [EMAIL PROTECTED] you wrote: Well, it doesn't affect upgrades. And for new installs, _all_ the packages are new, so this falls under the case of Debian picking one alternative of something as a default. Well, if Debian defaults change long term users need to know - even for new installs. So that they will consider ditching sysklogd and installing the new default in its place. I'd say that alone merits an inclusion in the release notes. It is not like the syslog daemon is an unimportant part of a Debian system. I think so too. I've submitted a bugreport against release-notes: #491180. Thanks Jonas, for being such a driving force regarding that matter. If I can be of any assisstance in crafting the release notes [1], please let me know. Cheers, Michael [1] I'm not sure, if the release notes should contain too technical information regarding upgrade procedures and such or if it should only refer to the packages' README.Debian (which I have started to write and will contain upgrade/migration instructions, see #484083) -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
