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
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
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.
> >
> &g
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 wo
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 chro
[ 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
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++
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
>
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
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
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
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
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
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
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.
>
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:
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
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
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 ◈
19 matches
Mail list logo
