Bug#1070339: libata bug after resume from suspend

2024-05-10 Thread Phillip Susi
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

Bug#983357: Bug#988776: Bug#983357: Netinst crashes xen domU when loading kernel

2021-08-25 Thread Phillip Susi
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

Bug#983357: Bug#988776: Bug#983357: Netinst crashes xen domU when loading kernel

2021-08-24 Thread Phillip Susi
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

Bug#983357: Netinst crashes xen domU when loading kernel

2021-05-25 Thread Phillip Susi
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

Bug#983357: Netinst crashes xen domU when loading kernel

2021-05-19 Thread Phillip Susi
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

Bug#983357: Netinst crashes xen domU when loading kernel

2021-04-29 Thread Phillip Susi
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

Bug#983357: (no subject)

2021-04-29 Thread Phillip Susi
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

Bug#983357: #983357: Netinst crashes xen domU when loading kernel

2021-04-27 Thread Phillip Susi
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

Bug#983357: #983357: Netinst crashes xen domU when loading kernel

2021-04-27 Thread Phillip Susi
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 latest &g

Re: Processed: Re: Bug#805845: mount --move broken

2015-12-01 Thread Phillip Susi
-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

Bug#791754: initramfs-tools: / on LVM gets mounted by initrd with kernel device name /dev/dm-X instead of /dev/mapper/XXX name

2015-11-04 Thread Phillip Susi
-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

Bug#732117: loop no longer needs explicit device?

2014-02-04 Thread Phillip Susi
-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... strange..