Re: Bug#872999: qemu image built by vmdebootstrap is unbootable due to bad root=/dev/mapper/loop0p1 kernel parameter

[Raphael Hertzog]

On Tue, 12 Sep 2017, Ben Hutchings wrote:
> > This is strange because schroot does bind-mount /dev in the default
> > profile that I used:
> 
> Then I don't know what's going wrong in your chroot environment.

Me neither.

> > 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.

I would have expected something like this too... but that does not seem
to be the case. At least it's not the reason why that call works here
because /run is not shared:
$ grep /run /etc/schroot/default/fstab
# It may be desirable to have access to /run, especially if you wish
#/run   /runnonerw,bind 0   0
#/run/lock  /run/lock   nonerw,bind 0   0
#/run/shm   /run/shmnonerw,bind 0   0

So maybe "udevadm trigger" is re-opening and re-closing the device
in write mode and this leads the kernel to emit a new uevent and
udev outside the chroot then reprocesses the device?

> It seems like maybe vmdebootstrap shouldn't be used in a chroot.

Or maybe update-grub should have a FORCE_USE_OF_UUID flag or something
like that. vmdebootstrap does not really care about the by-uuid symlink,
only grub insists on seeing it before accepting to use the UUID as
"root" kernel parameter.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

___
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

[Raphael Hertzog]

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)

> 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?

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!

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

___
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

[Raphael Hertzog]

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.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

___
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

[Raphael Hertzog]

On Thu, 07 Sep 2017, Raphael Hertzog wrote:
> Is there anything that can be done by vmdebootstrap to force-trigger the
> creation of that entry even when chrooted?

Yes, "udevadm trigger" or "udevadm trigger /dev/mapper/loop0p1" works
well for that. So we have a work-around at least (thanks to Felipe Sateler
for the suggestion, thanks also to Mantas Mikulėnas who taught me about
the kernel/udev interactions).

But I'm clearly not able to go further than that, debugging the kernel
would be too time-consuming for me since I'm not a kernel developer...
so I'll stop my investigations here.

(Somehow I wonder whether this is not the result of some kernel
hardening... limiting the impact of things done within a chroot
compared to the main host. schroot also uses private bind mounts, can this
be related?)

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

___
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

[Raphael Hertzog]

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. 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).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/
KERNEL[1303173.467860] change   /devices/virtual/block/loop0 (block)
ACTION=change
DEVNAME=/dev/loop0
DEVPATH=/devices/virtual/block/loop0
DEVTYPE=disk
MAJOR=7
MINOR=0
SEQNUM=4256
SUBSYSTEM=block

KERNEL[1303173.492386] add  /devices/virtual/bdi/254:4 (bdi)
ACTION=add
DEVPATH=/devices/virtual/bdi/254:4
SEQNUM=4257
SUBSYSTEM=bdi

KERNEL[1303173.492809] add  /devices/virtual/block/dm-4 (block)
ACTION=add
DEVNAME=/dev/dm-4
DEVPATH=/devices/virtual/block/dm-4
DEVTYPE=disk
MAJOR=254
MINOR=4
SEQNUM=4258
SUBSYSTEM=block

UDEV  [1303173.493320] add  /devices/virtual/bdi/254:4 (bdi)
ACTION=add
DEVPATH=/devices/virtual/bdi/254:4
SEQNUM=4257
SUBSYSTEM=bdi
USEC_INITIALIZED=1303173493269

UDEV  [1303173.495279] change   /devices/virtual/block/loop0 (block)
.ID_FS_TYPE_NEW=
ACTION=change
DEVNAME=/dev/loop0
DEVPATH=/devices/virtual/block/loop0
DEVTYPE=disk
ID_FS_TYPE=
ID_PART_TABLE_TYPE=dos
ID_PART_TABLE_UUID=91b643c6
MAJOR=7
MINOR=0
SEQNUM=4256
SUBSYSTEM=block
TAGS=:systemd:
USEC_INITIALIZED=13952290172

KERNEL[1303173.495444] change   /devices/virtual/block/dm-4 (block)
ACTION=change
DEVNAME=/dev/dm-4
DEVPATH=/devices/virtual/block/dm-4
DEVTYPE=disk
DM_COOKIE=4194304
MAJOR=254
MINOR=4
SEQNUM=4259
SUBSYSTEM=block

UDEV  [1303173.510693] add  /devices/virtual/block/dm-4 (block)
ACTION=add
DEVLINKS=/dev/disk/by-id/raid-loop0p1
DEVNAME=/dev/dm-4
DEVPATH=/devices/virtual/block/dm-4
DEVTYPE=disk
DM_NAME=loop0p1
DM_PART=1
DM_STATE=ACTIVE
DM_TABLE_STATE=LIVE
DM_TYPE=raid
DM_UDEV_DISABLE_DISK_RULES_FLAG=1
DM_UDEV_DISABLE_OTHER_RULES_FLAG=1
DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG=1
DM_UUID=part1-loop0
MAJOR=254
MINOR=4
SEQNUM=4258
SUBSYSTEM=block
SYSTEMD_READY=0
TAGS=:systemd:
USEC_INITIALIZED=1303173510442

UDEV  [1303173.527433] change   /devices/virtual/block/dm-4 (block)
.ID_FS_TYPE_NEW=
ACTION=change
DEVLINKS=/dev/disk/by-partuuid/91b643c6-01 /dev/mapper/loop0p1 
/dev/disk/by-id/raid-loop0p1 /dev/disk/by-id/dm-uuid-part1-loop0 
/dev/disk/by-id/dm-name-loop0p1
DEVNAME=/dev/dm-4
DEVPATH=/devices/virtual/block/dm-4
DEVTYPE=disk
DM_ACTIVATION=1
DM_COOKIE=4194304
DM_NAME=loop0p1
DM_PART=1
DM_STATE=ACTIVE
DM_SUSPENDED=0
DM_TABLE_STATE=LIVE
DM_TYPE=raid
DM_UDEV_PRIMARY_SOURCE_FLAG=1
DM_UDEV_RULES=1
DM_UUID=part1-loop0
ID_FS_TYPE=
ID_PART_ENTRY_DISK=7:0
ID_PART_ENTRY_FLAGS=0x80
ID_PART_ENTRY_NUMBER=1
ID_PART_ENTRY_OFFSET=2048
ID_PART_ENTRY_SCHEME=dos
ID_PART_ENTRY_SIZE=19527680
ID_PART_ENTRY_TYPE=0x83
ID_PART_ENTRY_UUID=91b643c6-01
MAJOR=254
MINOR=4
SEQNUM=4259
SUBSYSTEM=block
TAGS=:systemd:
USEC_INITIALIZED=1303173510442

--- debootstrap ---

KERNEL[1303301.063685] change   /devices/virtual/block/loop0 (block)
ACTION=change
DEVNAME=/dev/loop0
DEVPATH=/devices/virtual/block/loop0
DEVTYPE=disk
MAJOR=7
MINOR=0
SEQNUM=4260
SUBSYSTEM=block

UDEV  [1303301.069592] change   /devices/virtual/block/loop0 (block)
.ID_FS_TYPE_NEW=
ACTION=change
DEVNAME=/dev/loop0
DEVPATH=/devices/virtual/block/loop0
DEVTYPE=disk
ID_FS_TYPE=
ID_PART_TABLE_TYPE=dos
ID_PART_TABLE_UUID=91b643c6
MAJOR=7
MINOR=0
SEQNUM=4260
SUBSYSTEM=block
TAGS=:systemd:
USEC_INITIALIZED=13952290172

KERNEL[1303303.480902] remove   /devices/virtual/block/dm-4 (block)
ACTION=remove
DEVNAME=/dev/dm-4
DEVPATH=/devices/virtual/block/dm-4
DEVTYPE=disk
DM_COOKIE=6291456
MAJOR=254
MINOR=4
SEQNUM=4261
SUBSYSTEM=block

UDEV  [1303303.497202] remove   /devices/virtual/block/dm-4 (block)
.ID_FS_TYPE_NEW=
ACTION=remove
DEVLINKS=/dev/mapper/loop0p1 /dev/disk/by-partuuid/91b643c6-01 
/dev/disk/by-id/raid-loop0p1 /dev/disk/by-id/dm-uuid-part1-loop0 
/dev/disk/by-id/dm-name-loop0p1
DEVNAME=/dev/dm-4
DEVPATH=/devices/virtual/block/dm-4
DEVTYPE=disk
DM_ACTIVATION=1
DM_COOKIE=6291456
DM_NAME=loop0p1
DM_PART=1
DM_STATE=ACTIVE
DM_SUSPENDED=0
DM_TABLE_STATE=LIVE
DM_TYPE=raid
DM_UDEV_DISABLE_LIBRARY_FALLBACK_FLAG=1
DM_UDEV_PRIMARY_SOURCE_FLAG=1
DM_UDEV_RULES=1
DM_UUID=part1-loop0
ID_FS_TYPE=
ID_PART_ENTRY_DISK=7:0
ID_PART_ENTRY_FLAGS=0x80
ID_PART_ENTRY_NUMBER=1
ID_PART_ENTRY_OFFSET=2048
ID_PART_ENTRY_SCHEME=dos
ID_PART_ENTRY_SIZE=19527680
ID_PART_ENTRY_TYPE=0x83
ID_PART_ENTRY_UUID=91b643c6-01
MAJOR=254
MINOR=4
SEQNUM=4261
SUBSYSTEM=b

Re: Bug#872999: qemu image built by vmdebootstrap is unbootable due to bad root=/dev/mapper/loop0p1 kernel parameter

[Raphael Hertzog]

[ Ccing grub, udev, linux maintainers for the questions at the end,
  I want to understand why some /dev/disk/by-uuid/ entries are not
  properly created ]

Hello,

On Wed, 23 Aug 2017, Raphaël Hertzog wrote:
> Hello, I'm trying to update my qemu image used for autopkgtest, so I
> followed the instructions from man autopkgtest-virt-qemu to create the
> image but the resulting image does not boot and thus does not work
> for autopkgtest either.
> 
> I believe that the root cause is this error shown in the vmdebootstrap
> output:
> 
> /usr/sbin/grub-probe: error: cannot find a device for / (is /dev 
> mounted?).
> WARNING: update-grub failed!
> 
> Maybe the behaviour of update-grub changed recently... vmdebootstrap

So this is not the root cause. This is just a problem in the customize
script which should mount /dev and /proc just like vmdebootstrap already
does when it calls update-grub. Or it should probably get rid of it
entirely as vmdebootstrap mostly overwrites the grub configuration anyway.

> When I inspect /boot/grub/grub.cfg it does indeed contain
> root=/dev/mapper/loop0p1 which we don't want.

After a discussion on #debian-cloud, I narrowed the problem a bit more
closely. In fact vmdebootstrap works properly when I run it unchrooted
on my system, but when I run it in "schroot" (with a default profile
which shares with the host the mount for /dev, /proc, /sys and more) then
I get this problem.

So it looks like that update-grub is behaving differently in each situation.

I have added "set -x" to the grub-mkconfig and it looks like grub is perfectly
able to find out the UUID associated to device:
$ virt-cat -a sid.raw /tmp/update-grub-log |grep -i uuid
+ /usr/sbin/grub-probe --device /dev/mapper/loop0p1 --target=fs_uuid
+ GRUB_DEVICE_UUID=600ae34d-dceb-4250-a832-f07fa0c932db
+ /usr/sbin/grub-probe --device /dev/mapper/loop0p1 --target=fs_uuid
+ GRUB_DEVICE_BOOT_UUID=600ae34d-dceb-4250-a832-f07fa0c932db
[...]

Then I added "set -x" to /etc/grub.d/10_linux to find out why this script
decided to not use the UUID even though it was available in the
environment. It boils down to
/dev/disk/by-uuid/600ae34d-dceb-4250-a832-f07fa0c932db does not exist.

The loop partition device is /dev/dm-4 and at the time when the customize
script runs, I have this output (it exists in by-partuuid, but not in by-uuid):

$ ls -al /dev/disk/by-uuid/
total 0
drwxr-xr-x 2 root root 140 sept.  5 15:42 .
drwxr-xr-x 7 root root 140 août  23 08:34 ..
lrwxrwxrwx 1 root root  10 sept.  1 08:54 51d0-3c3e-49f5-adf6-6d53e7c0a8d6 
-> ../../dm-0
lrwxrwxrwx 1 root root  10 sept.  1 08:54 5b668fa1-c4c5-44f7-bbec-ed5edfc33c0d 
-> ../../dm-3
lrwxrwxrwx 1 root root  10 sept.  1 08:54 92a990ff-52c2-4766-b865-a78cceb7e293 
-> ../../dm-2
lrwxrwxrwx 1 root root  10 sept.  1 08:54 b3816590-a760-4815-9f43-0c2f4a362abc 
-> ../../sda2
lrwxrwxrwx 1 root root  10 sept.  1 08:54 BF87-23E5 -> ../../sda1

$ ls -al /dev/disk/by-partuuid/
total 0
drwxr-xr-x 2 root root 200 sept.  7 09:04 .
drwxr-xr-x 7 root root 140 août  23 08:34 ..
lrwxrwxrwx 1 root root  10 sept.  1 08:54 01f46df3-eb66-47b9-b0ea-a667e4a02020 
-> ../../sda5
lrwxrwxrwx 1 root root  10 sept.  1 08:54 1dd56def-bfb8-423e-8ea5-d03ca1f2ff75 
-> ../../sda6
lrwxrwxrwx 1 root root  10 sept.  7 09:04 3dfece35-01 -> ../../dm-4
lrwxrwxrwx 1 root root  10 sept.  1 08:54 426ccd8e-0ccd-4864-9152-31fc831ae98a 
-> ../../sda4
lrwxrwxrwx 1 root root  10 sept.  1 08:54 525345f4-e509-4283-8489-a6c1e7625975 
-> ../../sda3
lrwxrwxrwx 1 root root  10 sept.  1 08:54 6ce3844f-39e8-4a7f-8e37-05b6bb9efe2f 
-> ../../sda1
lrwxrwxrwx 1 root root  10 sept.  1 08:54 caff8cf5-b264-498e-b6be-e6160fcf2085 
-> ../../sda7
lrwxrwxrwx 1 root root  10 sept.  1 08:54 d67d853a-592f-4e21-9ed7-5992359aaa7d 
-> ../../sda2

$ ls -al /dev/mapper/loop0p1
brw-rw 1 root disk 254, 4 sept.  7 09:04 /dev/mapper/loop0p1


And when I run it outside from my schroot, then I have the entry
in /dev/disk/by-uuid/. What is responsible of creating that entry?

I guess it's udev. udev is not running in the chroot, obviously.
But the underlying device (and the mount point) is seen by the host so I wonder
why it's not created.

What informs udev about the new filesystem?

Is there anything that can be done by vmdebootstrap to force-trigger the
creation of that entry even when chrooted?

Should update-grub not try to be too smart and just trust the value
obtained by grub-probe instead even if /dev/disk/by-uuid/$foo does not
exist?

Or is this a bug in the kernel really?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

___
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#872598: udev-udeb: no input in graphical installer

[Raphael Hertzog]

Hi,

On Thu, 24 Aug 2017, Cyril Brulebois wrote:
> > The attached patch seems to do the trick, will upload after a full build
> > inside sbuild, then open a bug report as you suggested on IRC, so that
> > you think about reverting this when the gcc-7 bug is fixed.
> 
> I initially meant to add g++ and CXX and should have, but it seemed
> not to be needed… until it failed on buildds since there are checks
> building in c++ mode; which I didn't catch locally because the wrong
> chroot has been used while build testing… Sorry for that.

I had a similar problem for shiboken and Adrian Bunk pointed out on
#debian-mips that this also works around the failure:
DEB_CXXFLAGS_MAINT_APPEND = -mno-lra
DEB_CFLAGS_MAINT_APPEND = -mno-lra

Apparently that's the broken feature in gcc-7 on mips64el.

For the record, when updating systemd, I also had other tests failures on
armel in Kali due to test-hash failing... but that test is skipped in
Debian due to the kernel not supporting the feature apparently. But with a
kernel provided by my hosting provider (scaleway.com), it did fail. I
built my package somewhere else to work around this.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

___
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#854400: systemd: FTBFS if /tmp is an overlayfs

[Raphael Hertzog]

Control: forwarded -1 https://github.com/systemd/systemd/pull/6656

On Mon, 06 Feb 2017, James Cowgill wrote:
> > I think this is a bug in overlayfs.
> 
> Well it's the documented behavior of overlayfs which others have
> probably relied on, so I think it's very unlikely overlayfs will be
> changed now.

Actually it seems to have changed in Linux 4.12 and the uptsream
documentation at
https://www.kernel.org/doc/Documentation/filesystems/overlayfs.txt now
also says this:

| In the special case of all overlay layers on the same underlying
| filesystem, all objects will report an st_dev from the overlay
| filesystem and st_ino from the underlying filesystem.  This will
| make the overlay mount more compliant with filesystem scanners and
| overlay objects will be distinguishable from the corresponding
| objects in the original filesystem.

That said this bug is still rather annoying and I would like to see
it fixed, so I created a pull request upstream:
https://github.com/systemd/systemd/pull/6656

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

___
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#872598: udev-udeb: no input in graphical installer

[Raphael Hertzog]

Hello,

On Sat, 19 Aug 2017, Cyril Brulebois wrote:
> I've only quickly glanced at the contents of both packages, and debdiff
> mentions no obvious issues (file lists are the same).

I believe this is precisely the problem. The new udev-udeb should
include a new file:
diff --git a/debian/udev-udeb.install b/debian/udev-udeb.install
index 6a8e2108f..6758fef06 100644
--- a/debian/udev-udeb.install
+++ b/debian/udev-udeb.install
@@ -5,6 +5,7 @@ lib/udev/ata_id
 lib/udev/scsi_id
 lib/udev/cdrom_id
 lib/udev/rules.d/50-udev-default.rules
+lib/udev/rules.d/60-input-id.rules
 lib/udev/rules.d/60-cdrom_id.rules
 lib/udev/rules.d/60-persistent-input.rules
 lib/udev/rules.d/60-persistent-storage.rules

I won't have the time to test this now but I believe it's the problem.
I see this in the upstream change between both versions:
--- a/rules/50-udev-default.rules
+++ b/rules/50-udev-default.rules.in
@@ -11,7 +11,6 @@ SUBSYSTEM=="rtc", ATTR{hctosys}=="1", SYMLINK+="rtc"
 SUBSYSTEM=="rtc", KERNEL=="rtc0", SYMLINK+="rtc", OPTIONS+="link_priority=-100"
 
 SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", IMPORT{builtin}="usb_id", 
IMPORT{builtin}="hwdb --subsyste
m=usb"
-SUBSYSTEM=="input", ENV{ID_INPUT}=="", IMPORT{builtin}="input_id"
 ENV{MODALIAS}!="", IMPORT{builtin}="hwdb --subsystem=$env{SUBSYSTEM}"
 
 ACTION!="add", GOTO="default_end"
[...]
--- /dev/null
+++ b/rules/60-input-id.rules
@@ -0,0 +1,7 @@
+# do not edit this file, it will be overwritten on update
+
+ACTION=="remove", GOTO="id_input_end"
+
+SUBSYSTEM=="input", ENV{ID_INPUT}=="", IMPORT{builtin}="input_id"
+
+LABEL="id_input_end"

It would be nice to have a fixed udev soon. Thank you Cyril for the
investigation!

I wonder if it would be possible to have autopkgtest tests covering
udev-udeb...

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

___
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#822670: dh-systemd should be merged into debhelper

[Raphael Hertzog]

Hi,

On Tue, 12 Jul 2016, Michael Biebl wrote:
> With todays upload of src:init-system-helpers, the move from
> dh_systemd_* from dh-systemd to debhelper has been completed.
> Do you think we should do a MBF for getting the reverse
> build-dependencies updated to use a versioned b-dep on debhelper (>=
> 9.20160709) instead of dh-systemd? Or should we add a lintian check for now?

Both are fine I would say. But I would not file bugs until a debhelper
newer than 9.20160709 is in jessie-backports.

A lintian check helps people to not introduce the mistake in new packages
as well whereas a bug report only helps already existing packages (but
will greatly help the conversion while lintian will not have that much
of an impact).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

___
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#824025: udev: Please split rule for MAC-based name of USB network interface out of 73-special-net-names.rules

[Raphael Hertzog]

On Wed, 11 May 2016, Martin Pitt wrote:
> Done: 
> http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=b72e3d3b

Thanks!

> I also changed the rule to be inert when "net.ifnames=0" is given on
> the kernel command line, to be consistent with the *.link files:

Excellent idea. I even wanted to use this at some point but we lack a good
way to inject kernel boot parameters through packages IIRC.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/


___
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#824025: udev: Please split rule for MAC-based name of USB network interface out of 73-special-net-names.rules

[Raphael Hertzog]

Package: udev
Version: 229-5
Severity: wishlist
User: de...@kali.org
Usertags: origin-kali

Kali opted to revert the new names of network interfaces and as such
we used to run the following command in our live image:
ln -sf /dev/null /etc/systemd/network/90-mac-for-usb.link
ln -sf /dev/null /etc/systemd/network/99-default.link

But the 90-mac-for-usb.link has now been obsoleted by a single udev
rule in /lib/udev/rules.d/73-special-net-names.rules. To disable that
rule only, I have to provide /etc/udev/rules.d/73-special-net-names.rules
with all the other rules except that one.

I would really prefer if that rule could be split into its own file
so that it can be disabled in the same way with a single symlink instead
of having to maintain a forked version of 73-special-net-names.rules.

Thank you for considering my request!

-- Package-specific info:

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 
'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.5.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages udev depends on:
ii  adduser  3.114
ii  dpkg 1.18.7
ii  libacl1  2.2.52-3
ii  libblkid12.28-5
ii  libc62.22-7
ii  libkmod2 22-1.1
ii  libselinux1  2.5-2
ii  libudev1 229-5
ii  lsb-base 9.20160110
ii  procps   2:3.3.11-3
ii  util-linux   2.28-5

udev recommends no packages.

udev suggests no packages.

Versions of packages udev is related to:
ii  systemd  229-5

-- debconf information excluded

-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/


___
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#772555: untested hacky attempt at using systemctl preset

[Raphael Hertzog]

Hi Martin,

On Sun, 13 Mar 2016, Martin Pitt wrote:
> Many thanks for working on this!
> 
> However, this breaks the test suite left and right:
> 
>   http://paste.ubuntu.com/15378313/
> 
> on a lot of "No such file or directory" or "unable to read
> footest.service" errors?

Duh, I missed the existence of this test suite.

Please find attached a patch fixing the test suite. To be applied on top
of my former patch (although it should work without it, too).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/
>From 5cc97b272d7c9d76536c2930ed8c59d06d87cdfb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Hertzog?= 
Date: Tue, 15 Mar 2016 18:15:40 +0100
Subject: [PATCH] Fix test suite after changes to use systemctl preset

There are multiple problems:

1/ first the behaviour of "dsh enable" is no longer the same when
   the service was already installed or not... and as such the test suite
   must be fixed in multiple places to ensure that the metadata
   in /var/lib/systemd/ is properly purged before calling "enable" again
   and expecting it to do its job.

2/ "systemctl preset" does collaborate with the running systemd to do its
   job but the test suite uses its own filesystem namespace which is not
   shared with the running systemd... and hence we get errors about
   service files not existing in the systemd namespace even though they
   exist in the testsuite namespace.

   To work around this I modified the DEP-8 test to not use a separate
   namespace... and marked the test as breaking the system so that it
   does not get run on a real system. This has some consequences on some
   other tests that assume that the /{lib,etc}/systemd/ directories are
   empty. Those tests have been fixed along the way.
---
 debian/tests/control   |  2 +-
 debian/tests/t |  2 ++
 t/001-deb-systemd-helper.t | 24 ++--
 t/002-deb-systemd-helper-update.t  |  8 +---
 t/003-deb-systemd-helper-complex.t | 18 --
 5 files changed, 38 insertions(+), 16 deletions(-)

diff --git a/debian/tests/control b/debian/tests/control
index ae8d2bc..d85b9f4 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -2,4 +2,4 @@ Tests: t
 Depends: @,
   cpanminus,
   build-essential
-Restrictions: needs-root, allow-stderr, isolation-container
+Restrictions: needs-root, breaks-testbed, allow-stderr, isolation-container
diff --git a/debian/tests/t b/debian/tests/t
index 9b518bb..29e4b66 100644
--- a/debian/tests/t
+++ b/debian/tests/t
@@ -4,6 +4,8 @@ set -eu
 mount --make-rprivate /
 cpanm Linux::Clone
 
+export TEST_ON_REAL_SYSTEM=1
+
 for test in t/*.t; do
 echo " $(basename $test) ==="
 perl $test
diff --git a/t/001-deb-systemd-helper.t b/t/001-deb-systemd-helper.t
index 6def515..64332e3 100644
--- a/t/001-deb-systemd-helper.t
+++ b/t/001-deb-systemd-helper.t
@@ -44,9 +44,11 @@ sub bind_mount_tmp {
 return $tmp;
 }
 
-my $etc_systemd = bind_mount_tmp('/etc/systemd');
-my $lib_systemd = bind_mount_tmp('/lib/systemd');
-my $var_lib_systemd = bind_mount_tmp('/var/lib/systemd');
+unless ($ENV{'TEST_ON_REAL_SYSTEM'}) {
+my $etc_systemd = bind_mount_tmp('/etc/systemd');
+my $lib_systemd = bind_mount_tmp('/lib/systemd');
+my $var_lib_systemd = bind_mount_tmp('/var/lib/systemd');
+}
 
 # ┏━━━┓
 # ┃ Verify “is-enabled” is not true for a random, non-existing unit file. ┃
@@ -88,8 +90,11 @@ isnt_debian_installed($random_unit);
 # ┃ Verify “enable” creates the requested symlinks.   ┃
 # ┗━━━┛
 
-ok(! -d '/etc/systemd/system/multi-user.target.wants',
-'multi-user.target.wants does not exist yet');
+unless ($ENV{'TEST_ON_REAL_SYSTEM'}) {
+# This might exist if we don't start from a fresh directory
+ok(! -d '/etc/systemd/system/multi-user.target.wants',
+   'multi-user.target.wants does not exist yet');
+}
 
 $retval = system("DPKG_MAINTSCRIPT_PACKAGE=test $dsh enable $random_unit");
 is($retval, 0, "enable command succeeded");
@@ -176,6 +181,7 @@ $retval = system("DPKG_MAINTSCRIPT_PACKAGE=test $dsh purge $random_unit");
 is($retval, 0, "purge command succeeded");
 
 isnt_enabled($random_unit);
+isnt_debian_installed($random_unit);
 
 # ┏━━━┓
 # ┃ Verify “enable” after purging does re-create the symlinks.┃
@@ -284,6 +290,9 @@ unlink($mask_path);
 # ┃ Verify Alias= handling.   ┃
 # ┗━━━┛
 
+$retval = system("DPKG_MAINTSCRIPT_PACKAGE=test $dsh purge $random_unit");
+is($retval, 0, "purge command 

Bug#772555: untested hacky attempt at using systemctl preset

[Raphael Hertzog]

Hi,

On Fri, 04 Mar 2016, Felipe Sateler wrote:
> This is only needed when creating links manually. As noted above, when
> invoking via systemctl it does the reload automatically.

Ok. So here's the final patch that I'm now using in Kali. It seems to work
from the quick tests that I did.

And I believe that it does the right thing given the contstraint.

It would be even better if we changed all maintainer scripts to call a true
"preset" action but I believe that's out of scope for now.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/
diff --git a/script/deb-systemd-helper b/script/deb-systemd-helper
index 2a87cb4..07521a8 100755
--- a/script/deb-systemd-helper
+++ b/script/deb-systemd-helper
@@ -98,6 +98,7 @@ my $masked_state_dir = 
'/var/lib/systemd/deb-systemd-helper-masked';
 # Globals are bad, but in this specific case, it really makes things much
 # easier to write and understand.
 my $changed_sth;
+my $has_systemctl = -x "/bin/systemctl";
 
 sub error {
 print STDERR "$0: error: @_\n";
@@ -218,8 +219,49 @@ sub get_link_closure {
 return @links;
 }
 
-sub make_systemd_links {
+sub all_links_installed {
+my ($scriptname, $service_path) = @_;
+
+my @links = get_link_closure($scriptname, $service_path);
+my @missing_links = grep { ! -l $_->{src} } @links;
+
+return (@missing_links == 0);
+}
+
+sub no_link_installed {
+my ($scriptname, $service_path) = @_;
+
+my @links = get_link_closure($scriptname, $service_path);
+my @existing_links = grep { -l $_->{src} } @links;
+
+return (@existing_links == 0);
+}
+
+sub enable {
 my ($scriptname, $service_path) = @_;
+if ($has_systemctl) {
+# We use systemctl preset on the initial installation only
+# On upgrade, we manually add the missing symlinks only if
+# the service already has some links installed.
+my $create_links = 0;
+if (debian_installed($scriptname)) {
+$create_links = 1 unless no_link_installed($scriptname, 
$service_path);
+} else {
+debug "Using systemctl preset to enable $scriptname";
+system("/bin/systemctl", "--preset-mode=enable-only",
+"preset", $scriptname) == 0 or
+error("systemctl preset failed on $scriptname: $!");
+}
+make_systemd_links($scriptname, $service_path, create_links => 
$create_links);
+} else {
+# We create all the symlinks ourselves
+make_systemd_links($scriptname, $service_path);
+}
+}
+
+sub make_systemd_links {
+my ($scriptname, $service_path, %opts) = @_;
+$opts{'create_links'} //= 1;
 
 my $dsh_state = dsh_state_path($scriptname);
 
@@ -234,7 +276,7 @@ sub make_systemd_links {
 $statefile =~ s,^/etc/systemd/system/,$enabled_state_dir/,;
 next if -e $statefile;
 
-if (! -l $service_link) {
+if ($opts{'create_links'} && ! -l $service_link) {
 make_path(dirname($service_link));
 symlink($service_path, $service_link) or
 error("unable to link $service_link to $service_path: $!");
@@ -472,9 +514,7 @@ for my $scriptname (@ARGV) {
 debug "action = $action, scriptname = $scriptname, service_path = 
$service_path";
 
 if ($action eq 'is-enabled') {
-my @links = get_link_closure($scriptname, $service_path);
-my @missing_links = grep { ! -l $_->{src} } @links;
-my $enabled = (@missing_links == 0);
+my $enabled = all_links_installed($scriptname, $service_path);
 print STDERR ($enabled ? "enabled\n" : "disabled\n") unless $quiet;
 $rc = 0 if $enabled;
 }
@@ -520,7 +560,7 @@ for my $scriptname (@ARGV) {
 }
 
 if ($action eq 'enable') {
-make_systemd_links($scriptname, $service_path);
+enable($scriptname, $service_path);
 }
 
 if ($action eq 'mask') {
___
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#772555: untested hacky attempt at using systemctl preset

[Raphael Hertzog]

Hello Andreas,

thanks for working on this patch!

I want to test your patch in Kali and make it ready for inclusion. But
there are things that I don't really understand...

On Wed, 02 Mar 2016, Andreas Henriksson wrote:
> Please note that perl warns about the smartmatch being experimental.
> Someone should probably replace that part with a better check

So I have read about what smartmatch does... but basically I think it
does not do what you wanted to do. So can you tell me what you wanted
to test?

I assume you wanted to compare both data structures and just know whether
they contain the same thing or not. But the structure is an array of
hashes. So the smart match compares each hash individually, but the hash
comparison only ensures that both hashes have the same keys (and does
not check the values). So basically the smart match will always return
true.

But I also don't understand why you compare the result of two consecutive
get_link_closure() calls. It reads (possibly recursively) the unit file
given in parameter and builds a structure ouf of it. If the underlying
unit file has not changed, the two calls should return the same value...
Even if "systemctl preset" has been called in between, that should not
have affected files in /lib/systemd/system/

So I need some explanations on what you tried to do here...

Still I replaced the smartmatch with a dedicated comparison function
in case you need it:

diff --git a/script/deb-systemd-helper b/script/deb-systemd-helper
index a8aa834..153bed0 100755
--- a/script/deb-systemd-helper
+++ b/script/deb-systemd-helper
@@ -227,6 +227,18 @@ sub is_enabled {
 return (@missing_links == 0);
 }
 
+sub are_link_closures_different {
+my ($list_a, $list_b) = @_;
+my $len_a = scalar(@$list_a);
+return 1 if $len_a != scalar(@$list_b);
+for(my $i = 0; $i < $len_a; $i++) {
+my ($hash_a, $hash_b) = ($list_a->[$i], $list_b->[$i]);
+return 1 if $hash_a->{'dest'} ne $hash_b->{'dest'};
+return 1 if $hash_a->{'src'} ne $hash_b->{'src'};
+}
+return 0;
+}
+
 sub make_systemd_links {
 my ($scriptname, $service_path) = @_;
 
@@ -251,7 +263,7 @@ sub make_systemd_links {
 #$changed_sth = ($prev_enabled != $now_enabled);
 # N.B. Trying a "Smart Matching operator" posing like I actually
 # know perl or if this even does the right thing.
-$changed_sth = !(@prev_links ~~ @links);
+$changed_sth = are_link_closures_different(\@prev_links, \@links);
 # FIXME: We should really update statefile here when we still
 # know something about the changed links instead of badly
 # piggy-backing on the fallback which has no idea.


Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

___
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#772555: untested hacky attempt at using systemctl preset

[Raphael Hertzog]

Hi,

On Fri, 04 Mar 2016, Andreas Henriksson wrote:
> > So I have read about what smartmatch does... but basically I think it
> > does not do what you wanted to do. So can you tell me what you wanted
> > to test?
> 
> The end result is only used for "changed something" (or not).
> 
> See: $changed_sth = ...

Yes, but it also impacts the "return unless $changed_sth" and thus
whether we will run the fallback code or not. I think we should always
run the fallback code...

> I left the inital attempt commented out which might help clarify this a
> bit. See the commented "is_enabled" calls and comparison.
> I realised that simple comparison is not correct since the unit you're
> operating on could possibly be unchanged status while something else
> changed (eg. an underlying unit which got pulled in via Also=).

Yes, but you need to compare the list of existing symlinks in that case.
And get_link_closure() doesn't tell you this information.

> Example: unit foo.service contains Also=bar.service, foo.service is already
> enabled (because previous versions did not have the Also=bar.service?)
> while bar.service is not. Running "systemctl preset foo.service" (via
> updating the foo-package containing foo.service) will lead
> to bar.service becoming enabled while foo.service status is unchanged.

So this shows an other actual problem... we should probably not rerun "systemctl
preset" on package upgrade, do we? Otherwise we will overwrite any change
made by the local administrator...

Currently the code creating the symlinks are protected by a check on the
state file and the call to "systemctl preset" should be similarly
protected.

> $changed_sth = 1;
> 
> This seems to just lead to a "systemctl daemon-reload" which shouldn't
> be the end of the world if it runs even when not needed.
> 
> Making a really convoluted solution just for correctness seems like
> a bad idea...

Ack.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

___
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#772555: init-system-helpers: deb-systemd-helper does not respect systemd Preset files

[Raphael Hertzog]

Hello Andreas and debhelper maintainers,

I saw the move of update-rc.d to init-system-helpers in 805487 and the bug
mentioned some plans for further changes to move dh_systemd_enable and
related functionality to debhelper... I would like to draw the attention
of people interested in that to the wishlist below: we should be able to
use systemd preset files but we can't because initial installation doesn't
call "systemctl preset" in deb-systemd-helper...

I would very much like to see this fixed in stretch and while it's
relatively straightforward, when I try to think about the details, I
always get lost on how it should be done... I have troubles with the
init-system-helpers codebase and its interactions with the various
init systems. Andreas, given your recent involvment in
init-system-helpers, is it something that you'd be willing to tackle?

If it can help, Kali is willing to sponsor the work to get this feature
done... get in touch with me if you are interested.

Cheers,

On Mon, 08 Dec 2014, Raphaël Hertzog wrote:
> Package: init-system-helpers
> Version: 1.22
> Severity: wishlist
> User: de...@kali.org
> Usertags: origin-kali
> 
> Filing a bug following this IRC conversation:
> 15:32  * buxy finds out http://freedesktop.org/wiki/Software/systemd/Preset/ 
> 15:32  is this usable in Debian?
> 15:33  looking at deb-systemd-helper, I don't see anything implying
> that "systemctl preset" would be used...
> 15:34  this is a bit of a pity since it means that no derivative can
> implement a different default policy
> 15:53  buxy: yes, but for stretch I think that we can just update
> deb-systemd-helper to support this
> 
> It would be nice if we could make use of systemd Presets to disable some
> services by default, and to let derivatives make different choices than
> Debian.
> 
> systemd upstream expects distributions to call "systemctl preset
> foo.service" when the package gets installed to initially enable/disable
> the service.
> 
> deb-systemd-helper doesn't do this currently.
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

___
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: broken mount behaviour on jessie

[Raphael Hertzog]

Hi,

On Mon, 01 Feb 2016, Brian May wrote:
> I see two patches here - one patch applies easy enough to schroot -
> 1.6-schroot-mount-make-bind-mounts-private.patch
> 
> I am not sure what the
> master-libexec-mount-make-bind-mounts-private.patch is for, it seems to
> patch files not in schroot but has references to schroot files.
> 
> Do I need the 2nd patch or is the 1st one sufficient?

Both patches are the same but for two different schroot branches (1.7.x is
in experimental, 1.6.x in unstable).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

___
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: sysv-rc: [patch] much improved update-rc.d integration w/ systemd

[Raphael Hertzog]

Control: severity -1 serious

On Sat, 21 Mar 2015, Florian Schlichting wrote:
 I think the severity should be raised - the working of update-rc.d ought
 to be improved for jessie.

Done now. I will file a separate bug on openbsd-inetd for the problem I
encountered.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers