Re: Superblock time check causes problems for fsck in initramfs
On Sun, 2015-03-29 at 04:29 +0200, Michael Biebl wrote: > Hi Ben! > > On Mon, 27 Oct 2014 22:51:53 + Ben Hutchings > wrote: > > Package: e2fsprogs > > Version: 1.42.12-1 > > Severity: important > > Tags: upstream > > > > We discussed this previously in person, but unfortunately the proposed > > solution doesn't work. > > > > The plan for jessie (yes I know it's late) is to mount and fsck the > > root and (if separate) /usr filesystems from initramfs code, before > > handing over to the real init system. > > > > e2fsck complains if the superblock write time is in the future, and > > because the RTC is set to local time on some systems, we are doing the > > necessary correction of system time in the initramfs. This is > > undesirable because changing the time zone may now require an > > initramfs rebuild. > > > > You said that this check could be disabled in a configuration file, > > e2fsck.conf, and we can create that in the initramfs. This works in > > so far as it suppresses warnings while the initramfs code is running. > > Unfortunately, every init system currently still checks the root > > file-system again. If the RTC is set to local time and that is east > > of UTC, the first fsck sets the write time in the future, and the > > second fsck warns. > > > > Please disable this warning by default. > > First of all, thanks for pushing forward on this issue in initramfs-tools. > > I was wondering, if an alternative to disabling the superblock time > check in e2fsprogs, By the way, Lennart Poettering told me that other distributions have done that, though I haven't checked whether it is done with a configuration file or a patch to the code. > it wouldn't be better to just skip the fsck of / (and /usr, if separate). > For that, initramfs-tools could create a flag file for / and /usr in > /run and we'd update systemd-fsck-root.service and systemd-fsck@.service > and add a Condition= which checks for that flag file. > (suggestion, let's call them /run/fsck/root and /run/fsck/usr) > > > The sysv init scripts could do something similar (therefore CCed). Not easily - they currently rely on the fsck binary to iterate over all filesystems, and don't have any logic to do so themselves. (That's why initramfs-tools still doesn't mount /usr if it's going to hand over to sysvinit.) > What do you think? I'm not convinced. Ben. -- Ben Hutchings If at first you don't succeed, you're doing about average. signature.asc Description: This is a digitally signed message part ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Re: Superblock time check causes problems for fsck in initramfs
On Wed, 2015-04-01 at 05:59 +0200, Janis Hamme wrote: > On Tue, 31 Mar 2015 03:14:53 +0100 Ben Hutchings > wrote: > > By the way, Lennart Poettering told me that other distributions have > > done that, though I haven't checked whether it is done with a > > configuration file or a patch to the code. > > > > > it wouldn't be better to just skip the fsck of / (and /usr, if > separate). > > > For that, initramfs-tools could create a flag file for / and /usr in > > > /run and we'd update systemd-fsck-root.service and systemd-fsck@.service > > > and add a Condition= which checks for that flag file. > > > (suggestion, let's call them /run/fsck/root and /run/fsck/usr) > > > > > > > > > The sysv init scripts could do something similar (therefore CCed). > > > > Not easily - they currently rely on the fsck binary to iterate over all > > filesystems, and don't have any logic to do so themselves. (That's why > > initramfs-tools still doesn't mount /usr if it's going to hand over to > > sysvinit.) > > Actually it's not so difficult, as long as the following condition > holds: filesystems that are mounted before handing over to the init > system have been checked before. Since initramfs-tools are now > responsible for checking partitions that are mounted prior to init, > duplicate fsck's from sysvinit and systemd should be consequently avoided. > > Root partition checking could be disabled in /etc/init.d/checkroot.sh > and systemd-fsck-root.service should be masked. > For all other partitions the fsck tool has the option "-M" to ignore > mounted file systems. It could be applied to /etc/init.d/checkfs.sh and > systemd-fsck internally. I've uploaded a new version of clock-setup which creates /etc/e2fsck.conf if the RTC is set to local time. Bug #782178 against release-notes covers documentation of the need to do that on upgrade. I've also uploaded a version of initramfs-tools to <https://people.debian.org/~benh/packages/> (version 0.120~bwh.1) which creates the stamp files: /run/initramfs/fsck-root /run/initramfs/fsck-usr If you think you have time to get the init systems using these, please let me know I should upload these changes to the archive. Ben. -- Ben Hutchings I'm always amazed by the number of people who take up solipsism because they heard someone else explain it. - E*Borg on alt.fan.pratchett signature.asc Description: This is a digitally signed message part ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Re: Superblock time check causes problems for fsck in initramfs
On Mon, 2015-04-13 at 02:05 +0200, Michael Biebl wrote: > Am 09.04.2015 um 04:02 schrieb Ben Hutchings: > > I've also uploaded a version of initramfs-tools to > > <https://people.debian.org/~benh/packages/> (version 0.120~bwh.1) which > > creates the stamp files: > > > > /run/initramfs/fsck-root > > /run/initramfs/fsck-usr > > > > If you think you have time to get the init systems using these, please > > let me know I should upload these changes to the archive. > > I do have a patch ready for systemd which skips the fsck for / and /usr, > if those flag file exists. > > Would be great if you can upload initramfs-tools accordingly. Uploading it now... Ben. -- Ben Hutchings Everything should be made as simple as possible, but not simpler. - Albert Einstein signature.asc Description: This is a digitally signed message part ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Re: base-installer: NTP daemon should be installed on any system missing an RTC
On Sat, 2015-05-09 at 03:38 +0200, Michael Biebl wrote: > Am 09.05.2015 um 03:32 schrieb Michael Biebl: > > On Sun, 03 May 2015 17:23:30 +0100 Ben Hutchings > > >> 1. Install/enable NTP client > >> 2. Disable hwclock-save.service > > See below for the changes in systemd > > >> 3. Disable e2fsck time check > > What exactly do you mean here? e2fsck checks whether the current system time is earlier than the last mount time of the filesystem. If so, it may (depending on configuration) perform a full check. > >> I think these could all be done in clock-setup, so I'm reassigning to > >> that. > > > > FWIW: > > http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=experimental&id=929bece53261ddd2797d4f3518a05a88704c5b01 > > http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=experimental&id=5ea1b2bd1c57f9d3095252229c4ba1e50a7248d6 > > > > We enable timesyncd by default now and have dropped the > > hwclock-save.service in systemd for the systemd version targetted at > > stretch. > > > > Is there anything left which needs to be done? > > Ben, just to clarify: Those changes you propose, are they meant for > stretch or do you want to see them in a jessie point release? I don't know whether they are important enough to go into a point release. Ben. -- Ben Hutchings Theory and practice are closer in theory than in practice. - John Levine, moderator of comp.compilers signature.asc Description: This is a digitally signed message part ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Re: base-installer: NTP daemon should be installed on any system missing an RTC
On Sat, 2015-05-09 at 03:32 +0200, Michael Biebl wrote: > On Sun, 03 May 2015 17:23:30 +0100 Ben Hutchings > wrote: > > Control: reassign -1 clock-setup > > Control: retitle -1 Missing support for systems without battery-backed RTC > > > > On Sun, 2015-05-03 at 17:40 +0200, Geert Stappers wrote: > > > Debian installations on hardware with no (battery-backuped) RTC > > > is likely an installation that hasn't network connection. > > > > What makes you think that? > > > > > So please do not push (too hard) > > > for "you MUST allway known what time it is" > > > > > > Make it possible to do installs on hardware without RTC > > > and no access to a NTP server. > > > > Of course this should still be supported. > > > > > Installing fake-hwclock https://packages.debian.org/stretch/fake-hwclock > > > on the absence of the a RTC > > > > > > Avoiding filesystem checks when no RTC present would also be good. > > > Simular as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767040 > > > > Good point. > > > > I'm retitling this because we now have three small related changes > > wanted in the installer: > > > > 1. Install/enable NTP client > > 2. Disable hwclock-save.service > > 3. Disable e2fsck time check > > > > I think these could all be done in clock-setup, so I'm reassigning to > > that. > > FWIW: > http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=experimental&id=929bece53261ddd2797d4f3518a05a88704c5b01 So what happens if another ntp daemon is packaged, or they move executables into /usr/bin? > http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=experimental&id=5ea1b2bd1c57f9d3095252229c4ba1e50a7248d6 > > We enable timesyncd by default now and have dropped the > hwclock-save.service in systemd for the systemd version targetted at > stretch. > > Is there anything left which needs to be done? Point 3 still needs to be fixed; at least on systems not using systemd-networkd the system clock will still be wrong when fsck runs. Ben. -- Ben Hutchings Theory and practice are closer in theory than in practice. - John Levine, moderator of comp.compilers signature.asc Description: This is a digitally signed message part ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Re: Proposal: enable stateless persistant network interface names
On Mon, 2015-05-11 at 05:53 +0200, Marco d'Itri wrote: [...] > It will be even worse when not even ID_NET_NAME_PATH is defined (e.g. on > my Allwinner-based ARM computer), which means that interfaces will get > a mac-based name like enx028909xx. [...] For ARM (and any other architecture using Device Tree) the on-board indices should be specified as aliases 'ethernet0', 'ethernet1', etc. The aliases will be listed in the uevent as OF_ALIAS_0 (or OF_ALIAS_1, etc., as a device can have multiple aliases). Ben. -- Ben Hutchings For every action, there is an equal and opposite criticism. - Harrison signature.asc Description: This is a digitally signed message part ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#785445: Bug#785419: linux-image-4.0.0-1-armmp: with 2 RTC devices -- need way to chose which one sets system clock on boot
On Sat, 2015-05-16 at 05:01 -0700, Rick Thomas wrote: > On May 16, 2015, at 3:13 AM, Ian Campbell wrote: > > > On Fri, 2015-05-15 at 17:55 -0700, Rick Thomas wrote: > > [...] > >> There does not seem to be any way to over-ride this. There's code in > >> /etc/default/hwclock > >> that would do part of the work in a sysvinit setup, but it seems to be > >> ignored under systemd. > > [...] > >> Presumably, there is systemd magic that could do the same thing as was > >> available under > >> sysvinit. Is there anybody out there with enough systemd foo to tell me > >> how to do that? > > > > I think that if systemd is not supporting /etc/default/hwclock and the > > replacement mechanism is not apparent after some searching of the docs > > etc then this should be considered a systemd bug (either in the docs if > > not an actual code bug or missing feature). > > > > Perhaps someone on the pkg-systemd-maintainers@alioth list will be > > better able to advise on if/how systemd solves this problem? > > > > Ian. > > Thanks, Ian, for the prompt response. I’ve submitted a separate bug > to systemd asking for a fix. However, it may not be possible to do > this with systemd… Looking at the dmesg output, it looks like the > decision to use /dev/rtc0 is being made at the kernel level, before > systemd even gets started. That's right, the kernel optionally reads an RTC into the system time at boot (CONFIG_RTC_HCTOSYS) and the name of the RTC to use is also part of the kernel configuration (CONFIG_RTC_HCTOSYS_DEVICE). > If that’s correct, I’m not sure if even sysvinit > with /etc/default/hwclock could have done the right thing in my case. This is not implemented directly by the init system. util-linux installs the script /lib/udev/hwclock-set and a udev rule that runs it for each RTC device. However, the hwclock-set script does nothing if systemd is running. > Do you happen to know why the patch I came across never made it into > the kernel? Don't know. Ben. -- Ben Hutchings The obvious mathematical breakthrough [to break modern encryption] would be development of an easy way to factor large prime numbers. - Bill Gates signature.asc Description: This is a digitally signed message part ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Re: [PATCH] Disable kdbus support
On Sun, 2015-07-26 at 16:22 +0200, Michael Biebl wrote: [...] > I think the current default is fine. Someone who compiles kdbus.ko > probably does that for a reason. The only reason, why we might consider > switching the default to off, is that the Debian kernel suddenly starts > building kdbus.ko and we don't feel comfortable yet, running kdbus by > default for everyone. So far, kdbus has not yet been merged upstream and > I don't know of any plans that the Debian kernel team considers shipping > a distro-specific patch which adds kdbus support. > > But let's bring them into the loop here: > @Debian kernel maintainers: Please give us (pkg-systemd) a heads up, > whenever you consider enabling kdbus in the Debian kernel. This won't happen unless and until it's accepted upstream. Also, you will need to ensure that udev does not depend on kdbus until kdbus initialisation is done in the initramfs. (I have to say, kdbus is looking less and less like a good idea... and I'm not at all impressed at systemd upstream trying to go around the review process. Oh well.) Ben. -- Ben Hutchings Hoare's Law of Large Problems: Inside every large problem is a small problem struggling to get out. signature.asc Description: This is a digitally signed message part ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Re: Bug#857743: installation-report: Jessie stable ++ all Backports cause kernel-panic on HP EliteBook 8440p
Control: reassign -1 systemd On Tue, 2017-03-14 at 17:05 +0100, Andreas Glaeser wrote: [...] > Kernel-Panic appears both with Kernel 3.16 and 4.9, when all backports are > installed, > see attachment [k-panic-sshot.JPG], [...] That shows that the kernel panicked because init (systemd) exited. That suggests a bug in systemd, not the kernel. Unfortunately the screen shows too little to provide any clue as to why that happened. Ben. -- Ben Hutchings The obvious mathematical breakthrough [to break modern encryption] would be development of an easy way to factor large prime numbers. - Bill Gates signature.asc Description: This is a digitally signed message part ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Re: Bug#872999: qemu image built by vmdebootstrap is unbootable due to bad root=/dev/mapper/loop0p1 kernel parameter
On Thu, 2017-09-07 at 12:53 +0200, Raphael Hertzog wrote: > On Thu, 07 Sep 2017, Raphael Hertzog wrote: > > What informs udev about the new filesystem? > > Somehow, it's the kernel apparently. > > > Or is this a bug in the kernel really? > > At least "udevadm monitor" shows that the kernel is sending > less uevents when I run the command in the chroot. Which command? Ben. > I attach > two logs of "udevadm monitor -k -u -p", once for the run in > the host, and one for the run in schroot. > > And I also attach a diff of edited logs where I dropped the > timestamps. We can clearly see the lack of a "KERNEL[] change > /devices/virtual/block/dm-4 (block)" with its associated > UDEV rule adding the by-uuid links. > > So this is with 4.12.6-1 (unstable). -- Ben Hutchings Time is nature's way of making sure that everything doesn't happen at once. signature.asc Description: This is a digitally signed message part ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Re: Bug#872999: qemu image built by vmdebootstrap is unbootable due to bad root=/dev/mapper/loop0p1 kernel parameter
On Thu, 2017-09-07 at 17:53 +0200, Raphael Hertzog wrote:
> On Thu, 07 Sep 2017, Ben Hutchings wrote:
> > On Thu, 2017-09-07 at 12:53 +0200, Raphael Hertzog wrote:
> > > On Thu, 07 Sep 2017, Raphael Hertzog wrote:
> > > > What informs udev about the new filesystem?
> > >
> > > Somehow, it's the kernel apparently.
> > >
> > > > Or is this a bug in the kernel really?
> > >
> > > At least "udevadm monitor" shows that the kernel is sending
> > > less uevents when I run the command in the chroot.
> >
> > Which command?
>
> vmdebootstrap (for example as called by "make sid.raw" in that directory):
> https://anonscm.debian.org/cgit/cloud/debian-vm-templates.git/tree/vmdebootstrap-generic-qcow2
>
> The command creates the disk image with commands similar to those shown in
> this log:
> 2017-09-07 16:11:54 DEBUG runcmd: ['qemu-img', 'create', '-f', 'raw',
> '/srv/autopkgtest-images/sid-amd64-new.img', '100'] None {}
> 2017-09-07 16:11:54 INFO Creating partitions
> 2017-09-07 16:11:54 DEBUG runcmd: ['parted', '-s',
> '/srv/autopkgtest-images/sid-amd64-new.img', 'mklabel', 'msdos'] None {}
> 2017-09-07 16:11:54 DEBUG runcmd: ['parted', '-s',
> '/srv/autopkgtest-images/sid-amd64-new.img', 'mkpart', 'primary', '0%',
> '100%'] None {}
> 2017-09-07 16:11:54 DEBUG runcmd: ['parted', '-s',
> '/srv/autopkgtest-images/sid-amd64-new.img', 'set', '1', 'boot', 'on'] None {}
> 2017-09-07 16:11:54 DEBUG runcmd: ['kpartx', '-avs',
> '/srv/autopkgtest-images/sid-amd64-new.img'] None {}
> 2017-09-07 16:11:54 INFO Creating filesystem ext4
> 2017-09-07 16:11:54 DEBUG runcmd: ['mkfs', '-t', 'ext4',
> u'/dev/mapper/loop0p1'] None {}
> 2017-09-07 16:11:55 DEBUG mkdir /tmp/tmpSEWpRs
> 2017-09-07 16:11:55 INFO Mounting /dev/mapper/loop0p1 on /tmp/tmpSEWpRs
> 2017-09-07 16:11:55 DEBUG runcmd: ['mount', u'/dev/mapper/loop0p1',
> '/tmp/tmpSEWpRs'] None {}
>
> Then goes on with debootstrap but at this point already you are past the point
> where the kernel should have emitted the uevent that triggers the by-uuid
> symlink
> creation.
It's the mkfs command that triggers it; specifically the close() call
on the block device. But I can't see why the kernel would send device
events at that time for a device mapper device (or a loop device, which
I tested with because it's simpler to set up).
The answer seems to be that udev doesn't just listen for device events,
but also uses inotify to watch block devices. But inotify operates on
inodes, not the underlying devices. The chroot has a separate /dev
directory and inodes, so writing to a block device through one of those
inodes doesn't trigger the inotify watch.
If I bind-mount /dev into the chroot before running mkfs there, udev
does see the change events because mkfs opens the inodes that it's
watching.
So this is a limitation of udev and of the kernel's inotify interface,
but I don't think it's a bug in either of them. vmdebootstrap should
not assume that udev will notice changes made by mkfs unless they are
operating on the same /dev filesystem (and even then, it should use
'udevadm settle' to avoid races).
Ben.
--
Ben Hutchings
All the simple programs have been written, and all the good names
taken.
signature.asc
Description: This is a digitally signed message part
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Re: Bug#872999: qemu image built by vmdebootstrap is unbootable due to bad root=/dev/mapper/loop0p1 kernel parameter
On Mon, 2017-09-11 at 21:47 +0200, Raphael Hertzog wrote: > Hi Ben, > > On Mon, 11 Sep 2017, Ben Hutchings wrote: > > The answer seems to be that udev doesn't just listen for device events, > > but also uses inotify to watch block devices. But inotify operates on > > inodes, not the underlying devices. The chroot has a separate /dev > > directory and inodes, so writing to a block device through one of those > > inodes doesn't trigger the inotify watch. > > > > If I bind-mount /dev into the chroot before running mkfs there, udev > > does see the change events because mkfs opens the inodes that it's > > watching. > > This is strange because schroot does bind-mount /dev in the default > profile that I used: > $ grep profile /etc/schroot/chroot.d/sid-amd64 > profile=default > profile=default > $ grep /dev /etc/schroot/default/fstab > /dev/devnonerw,bind 0 0 > /dev/pts/dev/ptsnonerw,bind 0 0 > /dev/shm /dev/shmnonerw,bind 0 0 > > (and a stat call inside the chroot and outside of it returns the same inode > number and the same device number) Then I don't know what's going wrong in your chroot environment. > > So this is a limitation of udev and of the kernel's inotify interface, > > but I don't think it's a bug in either of them. vmdebootstrap should > > not assume that udev will notice changes made by mkfs unless they are > > operating on the same /dev filesystem (and even then, it should use > > 'udevadm settle' to avoid races). > > Assuming your analysis is right, what would be the right course of action? > > Calling "udevadm trigger " after the mkfs call? I think that's right... except now I wonder whether it's reasonable to assume udevadm in a chroot can talk to udev on the outside. It looks like they would have to share /run/udev/control. It seems like maybe vmdebootstrap shouldn't be used in a chroot. Ben. > FWIW, this udevadm trigger call does work (as in the missing symlink gets > created)... and it works when called outside of the chroot but also when > called > within the chroot. > > And thanks for the investigation you made! -- Ben Hutchings Kids! Bringing about Armageddon can be dangerous. Do not attempt it in your own home. - Terry Pratchett and Neil Gaiman, `Good Omens' signature.asc Description: This is a digitally signed message part ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#886731: linux-image-4.9.0-4-amd64: DKMS sends system in suspend since linux-image-4.9.0-3-amd64
On Thu, 2018-01-11 at 12:25 +0100, Marc-Robin Wendt wrote: > Hello Ben and Michael, > > thanks for taking time. Of course its DPMS. Sorry for the typo. > > Reproducing the bug turns out, it first appears in linux-image-4.9.0-4- > amd64 and now linux-image-4.9.0-5-amd64. > > When I boot the system from grub with old kernel linux-image-4.9.0-3- > amd64 or linux-image-4.9.0-2-amd64, behavior is as expected ok, means > switching off the monitor doesnt trigger suspend of the system. So are *you* switching off the monitor? You mentioned DPMS, which is the way for the display adapter to control the monitor - it doesn't involve any signalling in the other direction. And is the monitor attached to a VGA or digital port? If it's a digital port, turning off power to the monitor will look exactly the same as unplugging it... > Graphic card, see my first mail. Its a Lenovo T430s, so probably NVIDIA > NVS 5200M inside. Monitor is LG 34UM88C-P. ...and if you have a laptop that is already closed, unplugging the last external display is *supposed* to trigger suspend by default. (The same as when you have the laptop open with no external display, and then close the laptop.) But if this happens with the laptop still open, then this might be a kernel problem with lid switch detection. Ben. > Attached is the journalctl output once with linux-image-4.9.0-3-amd64 > booted and once with linux-image-4.9.0-4-amd64. -- Ben Hutchings If you seem to know what you are doing, you'll be given more to do. signature.asc Description: This is a digitally signed message part ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#809069: logind sometimes blocks input to X after VT switch
On Wed, 2018-03-28 at 12:47 +0200, Michael Biebl wrote: > Control: tags -1 + moreinfo > > Am 09.03.2017 um 06:40 schrieb Michael Biebl: > > Hi Ben > > > > On Sat, 26 Dec 2015 22:44:45 + Ben Hutchings > > wrote: > > > Package: systemd > > > Version: 228-2 > > > Severity: important > > > > > > After switching between a text console (VT 1) and X (VT 7) a few > > > times, I found that keyboard and mouse input no longer worked in X. > > > The system log showed this: [...] > > Sorry for not replying earlier. This bug is rather old, do you still > > experience on an up-to-date stretch system? > > This went unanswered, so probably fell through the cracks. > Ben, do you still run into this issue with stretch and/or buster? I don't remember seeing this again. Ben. -- Ben Hutchings Unix is many things to many people, but it's never been everything to anybody. signature.asc Description: This is a digitally signed message part ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Re: Bug#827604: linux-image-4.6.0-1-amd64: Only mounts XFS drive as read-only
It looks like systemd is failing to remount David's filesystems as read/write on Linux 4.6, but not on 4.5. Can you suggest how to get a log that would help diagnose this? Ben. On Sat, 2016-06-18 at 09:44 -0500, David McMackins wrote: > Package: src:linux > Version: 4.6.2-1 > Severity: important > > Dear Maintainer, > > All of the releases of Linux 4.6 in Debian Sid so far have failed to > mount my primary disk in read-write mode. I have not tested my other XFS > disks, because failure to correctly mount all my OS partitions causes > numerous other daemons to fail to start (for instance, NetworkManager). > > I'm not really educated on managing the kernel, so I'm not sure what > logs I'm supposed to be providing here. It should be noted that I can > only look at historical logs (if they're even kept), because I can only > submit this report while falling back to Linux 4.5. > > Let me know what information I can provide to accelerate the resolution > of this big problem for me. -- Ben Hutchings Usenet is essentially a HUGE group of people passing notes in class. - Rachel Kadel, `A Quick Guide to Newsgroup Etiquette' signature.asc Description: This is a digitally signed message part ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
[Fwd: Bug#847991: initramfs-tools: upgrade to stretch in kvm image fails when trying to copy 70-persistent-net.rules]
ci_hcd usb_common 12440 1 usbcore libata177508 2 ata_generic,ata_piix scsi_mod 191405 1 libata -- /etc/initramfs-tools/modules -- /etc/kernel-img.conf # Kernel image management overrides # See kernel-img.conf(5) for details do_symlinks = yes do_bootloader = no do_initrd = yes link_in_boot = no -- /etc/initramfs-tools/initramfs.conf MODULES=most BUSYBOX=y KEYMAP=n COMPRESS=gzip DEVICE= NFSROOT=auto -- /etc/initramfs-tools/update-initramfs.conf update_initramfs=yes backup_initramfs=no -- mkinitramfs hooks /etc/initramfs-tools/hooks/: /usr/share/initramfs-tools/hooks: busybox dmsetup fsck keymap klibc-utils klibc^i-t kmod lvm2 resume thermal udev zz-busybox -- System Information: Debian Release: stretch/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages initramfs-tools depends on: ii busybox 1:1.22.0-9+deb8u1 ii cpio 2.11+dfsg-4.1+deb8u1 ii klibc-utils 2.0.4-9 ii kmod 18-3 ii udev 232-7 Versions of packages initramfs-tools recommends: ii busybox 1:1.22.0-9+deb8u1 Versions of packages initramfs-tools suggests: ii bash-completion 1:2.1-4.3 -- no debconf information -- Ben Hutchings If at first you don't succeed, you're doing about average. signature.asc Description: This is a digitally signed message part ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#753816: [systemd] Broken audio
On Sat, 2014-07-05 at 18:58 +0200, Michael Biebl wrote: > Am 05.07.2014 18:38, schrieb Antonio Marcos López Alonso: > > El 05/07/14 17:06, Michael Biebl escribió: > >> Am 05.07.2014 17:56, schrieb Antonio Marcos López Alonso: > >>> Just in case, have you noticed I'm using an ALSA-Jack loopback setting > >>> for audio? > >> Under sysvinit, udev (including udevadm settle) is started before the > >> kmod init script, which loads snd_aloop. > >> That means, snd_aloop is loaded after snd_hda_intel. > >> > >> Under systemd, it looks like the snd_aloop module is loaded about the > >> same time systemd-udevd is started. There might be a race here and > >> snd_aloop is loaded before snd_hda_intel. > >> > >> This *might* be the reason, but I'm no expert on this matter. > >> > >> Can you try removing snd_aloop from /etc/modules and test if that makes > >> a difference. > >> > > > > OK removed snd_aloop and audio is back. Then reloaded the module, > > restarted JACK and audio is still fine. So as you said there must be > > some race condition in there. Should I keep this ticket opened? > > > > Hm, not sure what to do about this. We could order > systemd-load-modules.service after systemd-udevd.service. But that > doesn't guarantee the loading order of the modules and it feels like > papering over the underlying issue. > > I'm no sound expert, but I'd say that the loading order should not > matter. Maybe we need some input from the kernel team or some alsa > experts here. I think this is due to ALSA userland (or maybe higher levels) being stupid about device selection. I think the default is to use sound device 0, which can be whichever driver won the race. > I took the liberty to CC the Debian kernel team and the maintainer of > the snd_aloop module. I hope they can help us here. > > For reference the complete bug report is at [1] > > > Michael > > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753816 I think the usual workaround is to add 'index=1' to the snd-aloop line in /etc/modules. It is probably possible to do something more sophisticated in an ALSA configuration file. Ben. -- Ben Hutchings The most exhausting thing in life is being insincere. - Anne Morrow Lindberg signature.asc Description: This is a digitally signed message part ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Re: Transition plan for changing the default init system
On Wed, 2014-07-16 at 23:22 +0200, Tollef Fog Heen wrote: [...] > New installations > = > The new "init" package will ensure that systemd-sysv is installed as > default init on Linux and by demoting the priority of sysvinit and > sysvinit-core to optional those packages will not be installed anymore. [...] Since sysvinit-core will conflict with a package of priority standard (I assume that's what systemd-sysv will be upgraded to), its priority should be extra on Linux. (Also, it should actually have a Conflicts header.) But I don't know whether dak allows priority to vary per-architecture. Ben. -- Ben Hutchings Kids! Bringing about Armageddon can be dangerous. Do not attempt it in your own home. - Terry Pratchett and Neil Gaiman, `Good Omens' signature.asc Description: This is a digitally signed message part ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#761257: systemd: disrupts hugepages support
On Fri, 2014-09-12 at 19:25 +0200, Marco d'Itri wrote: > On Sep 12, Cyril Soldani wrote: > > > 1) systemd *not* messing with the existing hugepages setup; > This will not happen: it would be too much complex and anyway the new > "standard" location is /dev/hugepages/ . > > > 2) being warned when installing systemd-sysv that systemd handles > >hugepages differently (especially when I have hugepages entries in my > >fstab). > But I think that we can add a preinst check, can you provide a simple > shell test case that checks for this condition? First we should establish whether there is an actual bug in the kernel. Ben. -- Ben Hutchings I'm always amazed by the number of people who take up solipsism because they heard someone else explain it. - E*Borg on alt.fan.pratchett signature.asc Description: This is a digitally signed message part ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#775447: Does not update or remove /var/log/dmesg
Package: systemd Version: 215-8 Severity: minor Since I switched to systemd as pid 1, /var/log/dmesg is no longer updated. I realise that it is not really needed because systemd captures kernel messages and feeds them to the syslog daemon via journald. However, /var/log/dmesg is not removed either, and it took me a little while to realise that I was looking at stale information from the last initscripts boot. Please arrange to either update or remove it when systemd is pid 1. Ben. -- Package-specific info: -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (x86_64) Foreign Architectures: amd64 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd depends on: ii acl 2.2.52-2 ii adduser 3.113+nmu3 ii initscripts 2.88dsf-58 ii libacl1 2.2.52-2 ii libaudit1 1:2.4-1+b1 ii libblkid1 2.25.2-4 ii libc6 2.19-13 ii libcap2 1:2.24-6 ii libcap2-bin 1:2.24-6 ii libcryptsetup4 2:1.6.6-4 ii libgcrypt20 1.6.2-4+b1 ii libkmod218-3 ii liblzma55.1.1alpha+20120614-2+b3 ii libpam0g1.1.8-3.1 ii libselinux1 2.3-2 ii libsystemd0 215-8 ii mount 2.25.2-4 ii sysv-rc 2.88dsf-58 ii udev215-8 ii util-linux 2.25.2-4 Versions of packages systemd recommends: ii dbus1.8.14-1 ii libpam-systemd 215-8 Versions of packages systemd suggests: pn systemd-ui -- no debconf information ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#775447: Does not update or remove /var/log/dmesg
On Thu, 2015-01-15 at 22:58 +0100, Michael Biebl wrote: > Hi Ben, > > Am 15.01.2015 um 20:41 schrieb Ben Hutchings: > > Since I switched to systemd as pid 1, /var/log/dmesg is no longer > > updated. I realise that it is not really needed because systemd > > captures kernel messages and feeds them to the syslog daemon via > > journald. Actually, now that I think about it, at least rsyslog can write the kernel boot messages to syslog by itself. I think /var/log/dmesg is redundant even with initscripts. > > However, /var/log/dmesg is not removed either, and it took me a > > little while to realise that I was looking at stale information > > from the last initscripts boot. > > > > Please arrange to either update or remove it when systemd is pid 1. > > I don't think we want to update /var/log/dmesg under systemd. As you > said, we have a much more elaborate solution with the journal. > > I also feel a bit uneasy about removing /var/log/dmesg within the > systemd package (either in the maintainer scripts or by other means), > since this log file is not owned by systemd. I'm pretty sure we would > get angry mails from admins if we removed their log files. > > We could maybe think about renaming /var/log/dmesg to something like > /var/log/dmesg-better-name-to-be-found. I forgot that multiple versions of /var/log/dmesg are saved. Looking at what /etc/init.d/bootlogs does, I think maybe the best thing to do is to rotate the old logs with the savelog command so there is no current version. > Then again, if someone boots again with sysvinit (via the > /lib/sysvinit/init fallback), this file would be re-created. So this > wouldn't be a complete solution either. > > Maybe the simplest solution is, to simply document this fact somewhere > (README.Debian, release notes, something else), along with other > sysvinit compat issues. Yes please. Ben. -- Ben Hutchings The world is coming to an end. Please log off. signature.asc Description: This is a digitally signed message part ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
