After updating to the -21 kerenl, I could not reproduce this anymore. I
went back and forth between -21 and -20 a few times, and found the exact
steps to reproduce it, but it only works under -20:
1) enable runtime PM on the disks
2) wait for runtime PM to suspend the disks
3) suspend the system
Chuck Zmudzinski writes:
> If it doesn't work, I am also willing to try approach a by patching
> the Linux kernel xen-kbdfront driver by removing the for loops that
> advertise those 654 keys. I tend to agree with Philip that this is
> totally unnecessary, but I suppose I could be wrong about th
Ben Hutchings writes:
> I think a proper fix would be one of:
>
> a. If the Xen virtual keyboard driver is advertising capabilities it
>doesn't have, stop it doing that.
> b. Change the implementation of modalias attributes to allow longer
>values.
>
> It's not clear to me whether the X
Michael Biebl writes:
> So this is a change in behaviour in the kernel?
Yes, this commit fixed the kernel to report the error instead of
silently failing:
commit df44b479654f62b478c18ee4d8bc4e9f897a9844
Author: Peter Rajnoha
Date: Wed Dec 5 12:27:44 2018 +0100
kobject: return error cod
The discussion upstream does not seem to be converging on a proper fix
in the kernel, so I'm going to clone this bug and suggest that
debian-installer patch the start-udev script to ignore the failure of
the udevadm trigger command.
To summarize: init ends up calling start-udev which calls udevadm
I dug down to the the -ENOMEM coming from the fact that the modalias is
over 2KB of crap so it won't fit in the environment block when the input
core tries to add it for the uevent. I don't see how it gets this way
though because the MODULE_ALIAS() statement in the code just says it
should be "xen
I bisected the problem to this commit:
commit df44b479654f62b478c18ee4d8bc4e9f897a9844
Author: Peter Rajnoha
Date: Wed Dec 5 12:27:44 2018 +0100
kobject: return error code if writing /sys/.../uevent fails
Propagate error code back to userspace if writing the /sys/.../uevent
fi
affects 983357 + debian-installer
severify 983357 serious
thanks
It appears that the root cause of this bug has been reported upstream
here:
https://bugzilla.kernel.org/show_bug.cgi?id=207695
It seems that there is an error trying to udev trigger the Xen virtual
keyboard, and this causes start-u
reopen 983357
thanks
I don't know what happened, but it is back to not working, even with the
install.amd/xen/ kernel.
Phillip Susi writes:
> The netinst image I had contained the -3 kernel. I rebuit the image
> with the current -6 kernel and it worked. I downloaded the late
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 11/28/2015 08:04 AM, Ben Hutchings wrote:
> This behaviour has been implemented (and documented) since at
> least Linux 2.6.15:
> https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt
>
> The change comes from systemd.
It took
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Found this on Ubuntu 15.10 as well:
http://launchpad.net/bugs/1513272
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBCgAGBQJWOq2ZAAoJEBB5UWFcu6UWpoUH/19pkbrkOTIjvpGN8Bs9IlR2
28hc3Q/XC8RmwWcMBloSf6j0AkEYrLCJhsAU0eddl5vymwIxApKo35252Xszlv5
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2/4/2014 3:51 PM, ael wrote:
> If just -o loop rather than -o loop=/dev/loop[1..n] is used, the
> problem seems to vanish, at least with the latest kernels.
>
> Thus this becomes a bug in the mount man page? Hence reasssigning
> back
Ahh... strang
12 matches
Mail list logo
