Bug#926903: Installation-report addition
On Thu, 2019-05-02 at 12:00 +1000, Tom Thekathyil wrote: > Hi Ben, > > I ran 'update-initramfs -u' and got several lines saying > > 'W: Possible missing firmware /lib/firmware/amdgpu/vega20_ xxx for > module a[off screen here]pu' where xxx refers to different items. > > Regards, Tom Thekathyil Yes, that's expected at the moment but those shouldn't be needed on your system. I should have said, you need to reboot after this. Ben. -- Ben Hutchings It is easier to write an incorrect program than to understand a correct one. signature.asc Description: This is a digitally signed message part
Bug#926903: Installation-report addition
On Thu, 2019-05-02 at 07:32 +1000, Tom Thekathyil wrote: > Hi Ben, > > Thanks for trying to help. You will note from my original report as > well as the follow-up on 28 April that I had installed the > 'firmware-amd-graphics' package and still get the error message. Ah, sorry. > # apt search firmware-amd-graphics > > firmware-amd-graphics/testing, now 201901 14-1 all [installed] > > # whereis firmware-amd-graphics > > firmware-amd-graphics: > > Despite above response I am able to install and remove the package > easily. But it makes no visible difference to the graphics or to > dmesg error message. [...] All the amdgpu driver is doing at that point is checking that /lib/firmware/amdgpu exists - which it certainly does in the main system. But perhaps the driver has been included in the initramfs without the firmware. (I can check this but it will take a while.) Does running "update-initramfs -u" fix the problem for you? Ben. -- Ben Hutchings Anthony's Law of Force: Don't force it, get a larger hammer. signature.asc Description: This is a digitally signed message part
Bug#925496: Fix available upstream
Control: tag -1 pending On Wed, 2019-05-01 at 14:04 +0100, Mike Crowe wrote: > Control: tags -1 + fixed-upstream > > The workaround is included in upstream v4.19.35 onwards: > b787544dc5e707fec86161b881391eb9342806e6. This will be in the next update, as we've already rebased on 4.19.37. Ben. -- Ben Hutchings Anthony's Law of Force: Don't force it, get a larger hammer. signature.asc Description: This is a digitally signed message part
Bug#710709: debootstrap: consider creating (dangling) /etc/mtab symlink
On Wed, 2019-05-01 at 05:01 +0900, Hideki Yamane wrote:
> control: tags -1 +patch
>
> revised patch
>
> > From 55c21c166959a93b961c572d5f366d35d054ce24 Mon Sep 17 00:00:00 2001
> From: Hideki Yamane
> Date: Wed, 1 May 2019 04:24:43 +0900
> Subject: [PATCH] create symlink from /proc/self/mounts to /etc/mtab
>
> With old kernel version, there is /proc/mounts instead of
> /proc/self/mounts, so check whether /proc/self exists
This is silly, /proc/self has existed since Linux 0.99 and
/proc/self/mounts since Linux 2.5.1.2.
Ben.
> ---
> functions | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/functions b/functions
> index 24f0357..46ebceb 100644
> --- a/functions
> +++ b/functions
> @@ -1176,6 +1176,13 @@ setup_proc () {
> in_target mount -t sysfs sysfs /sys || true
> umount_on_exit /sys
> fi
> + if [ ! -f "$TARGET/etc/mtab" ]; then
> + if [ -L "$TARGET/proc/self" ]; then
> + cd "$TARGET/etc" && ln -s ../proc/self/mounts
> mtab
> + elif [ -f "$TARGET/proc/mounts" ]; then
> + cd "$TARGET/etc" && ln -s ../proc/mounts mtab
> + fi
> + fi
> on_exit clear_mtab
> ;;
> esac
--
Ben Hutchings
Anthony's Law of Force: Don't force it, get a larger hammer.
signature.asc
Description: This is a digitally signed message part
Bug#926903: Installation-report addition
On Tue, 2019-04-30 at 10:51 +1000, Tom Thekathyil wrote: > Hi Geert, > > Thank you so much for your prompt reply. > > Your suggestion it could be a monitor problem provided the clue it > could be the 11-year old model used (Acer X223w) that was causing the > problem. Swapped for a more current unit (Dell U2414H) and screen is > nicely centered now. > > That still leaves the problem why dmesg shows > '[ 1.349124] [drm:amdgpu_pci_probe [amdgpu]] *ERROR* amdgpu >requires firmware installed]' > Which firmware? [...] The firmware-amd-graphics package. Ben. -- Ben Hutchings Teamwork is essential - it allows you to blame someone else. signature.asc Description: This is a digitally signed message part
Bug#925766: linux: ftbfs with GCC-9
The compiler error messages are not shown in the report, so to save others the trouble of looking through the log, here they are: usbip_network.c: In function ‘usbip_net_pack_usb_device’: usbip_network.c:91:32: error: taking address of packed member of ‘struct usbip_usb_device’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 91 | usbip_net_pack_uint32_t(pack, >busnum); |^ usbip_network.c:92:32: error: taking address of packed member of ‘struct usbip_usb_device’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 92 | usbip_net_pack_uint32_t(pack, >devnum); |^ usbip_network.c:93:32: error: taking address of packed member of ‘struct usbip_usb_device’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 93 | usbip_net_pack_uint32_t(pack, >speed); |^~~~ usbip_network.c:95:32: error: taking address of packed member of ‘struct usbip_usb_device’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 95 | usbip_net_pack_uint16_t(pack, >idVendor); |^~~ usbip_network.c:96:32: error: taking address of packed member of ‘struct usbip_usb_device’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 96 | usbip_net_pack_uint16_t(pack, >idProduct); |^~~~ usbip_network.c:97:32: error: taking address of packed member of ‘struct usbip_usb_device’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 97 | usbip_net_pack_uint16_t(pack, >bcdDevice); |^~~~ ld -r -o /<>/debian/build/build-tools/tools/perf/plugin_cfg80211-in.o /<>/debian/build/build-tools/tools/perf/plugin_cfg80211.o In file included from usbip_network.c:33: usbip_network.c: In function ‘usbip_net_send_op_common’: usbip_network.h:36:32: error: taking address of packed member of ‘struct op_common’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 36 | usbip_net_pack_uint16_t(pack, &(op_common)->version);\ |^ usbip_network.c:155:2: note: in expansion of macro ‘PACK_OP_COMMON’ 155 | PACK_OP_COMMON(1, _common); | ^~ usbip_network.h:37:32: error: taking address of packed member of ‘struct op_common’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 37 | usbip_net_pack_uint16_t(pack, &(op_common)->code);\ |^~ usbip_network.c:155:2: note: in expansion of macro ‘PACK_OP_COMMON’ 155 | PACK_OP_COMMON(1, _common); | ^~ usbip_network.h:38:32: error: taking address of packed member of ‘struct op_common’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 38 | usbip_net_pack_uint32_t(pack, &(op_common)->status);\ |^~~~ usbip_network.c:155:2: note: in expansion of macro ‘PACK_OP_COMMON’ 155 | PACK_OP_COMMON(1, _common); | ^~ usbip_network.c: In function ‘usbip_net_recv_op_common’: usbip_network.h:36:32: error: taking address of packed member of ‘struct op_common’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 36 | usbip_net_pack_uint16_t(pack, &(op_common)->version);\ |^ usbip_network.c:179:2: note: in expansion of macro ‘PACK_OP_COMMON’ 179 | PACK_OP_COMMON(0, _common); | ^~ usbip_network.h:37:32: error: taking address of packed member of ‘struct op_common’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 37 | usbip_net_pack_uint16_t(pack, &(op_common)->code);\ |^~ usbip_network.c:179:2: note: in expansion of macro ‘PACK_OP_COMMON’ 179 | PACK_OP_COMMON(0, _common); | ^~ usbip_network.h:38:32: error: taking address of packed member of ‘struct op_common’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 38 | usbip_net_pack_uint32_t(pack, &(op_common)->status);\ |^~~~ usbip_network.c:179:2: note: in expansion of macro ‘PACK_OP_COMMON’ 179 | PACK_OP_COMMON(0, _common); | ^~ -- Ben Hutchings Power corrupts. Absolute power is kind of neat. - John Lehman signature.asc Description: This is a digitally signed message part
Bug#927972: jitterentropy_rng.ko never loads
Control: reassign -1 jitterentropy-rngd Control: severity -1 wishlist There is no dependency between the user-space daemon and the kernel module. And I don't see any kernel bug here, but this might be a wishlist item for the user-space package. Ben. -- Ben Hutchings Horngren's Observation: Among economists, the real world is often a special case. signature.asc Description: This is a digitally signed message part
Bug#925971: release-notes: should mention secure boot in d-i
On Fri, 2019-03-29 at 16:45 +0100, Paul Gevers wrote: > Package: release-notes > X-Debbugs-CC: debian-b...@lists.debian.org > > As now discussion on the RT sprint, the release notes should probably > say something about the work on secure boot. > > I wouldn't know what to put in, so proposals are welcome. Until that > time, I file this bug to not forget. I don't have a complete proposed text, but I think the key points to include are: * Secure Boot is a feature enabled on most PCs that prevents loading unsigned code, protecting against some kinds of bootkit and rootkit. * Debian can now be installed and run on most PCs with Secure Boot enabled. * It is possible to enable Secure Boot on a system that has an existing Debian installation, if it already boots using UEFI. Before doing this, it's necessary to install shim-signed, grub-efi-amd64-signed or grub-efi-ia32-signed, and a Linux kernel package from buster. * Some features of GRUB and Linux are restricted in Secure Boot mode, to prevent modifications to their code. * More information can be found on the Debian wiki at <https://wiki.debian.org/SecureBoot>. Ben. -- Ben Hutchings It is easier to write an incorrect program than to understand a correct one. signature.asc Description: This is a digitally signed message part
Bug#927368: irqbalance: Should be Multi-Arch: foreign
Package: irqbalance Version: 1.5.0-3 Severity: normal 15:05 < Diziet> Starting SMP IRQ Balancer: irqbalancestart-stop-daemon: unable to start /usr/sbin/irqbalance (Exec format error) 15:06 < Diziet> What fun, if you install linux-image-amd64 on an i386 host it pulls in irqbalance:amd64 and then refuses to start ? 15:06 < Diziet> Oh I've booted the i386 kernel This error would have been avoided if irqbalance's control file declared "Multi-Arch: foreign", as dpkg would then favour the primary architecture. (linux-image packages will stop recommending irqbalance soon as it doesn't seem to be generally useful any more, so this isn't a high priority.) Ben. -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages irqbalance depends on: ii debconf [debconf-2.0] 1.5.71 ii libc6 2.28-8 ii libcap-ng0 0.7.9-2 ii libglib2.0-0 2.58.3-1 ii libncursesw6 6.1+20181013-2 ii libnuma1 2.0.12-1 ii libsystemd0241-2 ii libtinfo6 6.1+20181013-2 ii lsb-base 10.2019031300 ii runit-helper 2.8.6 irqbalance recommends no packages. irqbalance suggests no packages. -- debconf information: irqbalance/enable: true irqbalance/oneshot: false
Bug#925379: linux-base: linux-version vmlinuz/vmlinux dichotomy, breaks at least m68k
On Wed, 2019-04-17 at 14:30 +0200, John Paul Adrian Glaubitz wrote:
> Hi!
>
> On 3/24/19 1:28 AM, Thorsten Glaser wrote:
> > This is because /usr/share/perl5/DebianLinux.pm was not updated
> > accordingly:
> >
> > # Find kernel image name stem for this architecture
> > my $image_stem;
> > if ((uname())[4] =~ /^(?:mips|parisc|powerpc|ppc)/) {
> > $image_stem = 'vmlinux';
> > } else {
> > $image_stem = 'vmlinuz';
> > }
> Just as a heads-up: I'm going to switch sparc and sparc64 over to an
> uncompressed kernel as well since compressed kernels are not
> officially
> supported and actually don't work with GRUB 2.04~rc1 when I tested
> on sparc64 [1].
It might be worth adding a versioned dependency on linux-base for the
affected architectures.
Ben.
--
Ben Hutchings
Make three consecutive correct guesses and you will be considered
an expert.
signature.asc
Description: This is a digitally signed message part
Bug#923675: debian-installer: consider using haveged to gather entropy
On Tue, 2019-04-16 at 23:45 +0200, Cyril Brulebois wrote: [...] > My initial thought would be to launch it on demand when one is about to > get to wget calls that needs HTTPS; but we could probably benefit from > it in case HTTP is requested but redirections to HTTPS happens… There > are also the obvious keypair generations mentioned above. But then over > time maybe some other operations could be needing entropy (the > cryptsetup case is discussed in a separate thread[1]). > > 1. https://lists.debian.org/debian-boot/2019/04/msg00153.html > > So it might be best to start it unconditionally at start-up? Ideally it would only be used if there isn't a hardware RNG available. Currently we don't include any hardware RNG modules in udebs, but that can be changed. So please first check that: * /sys/devices/virtual/misc/hw_random/rng_current is absent or contains "none" * (x86 only) /proc/cpuinfo does not mention rdrand (I can't find an arch-independent way to check for this, and Linux doesn't yet support an equivalent feature on any other architecture) Something like this should work: if [ "$(cat /sys/devices/virtual/misc/hw_random/rng_current 2>/dev/null || echo none)" = none ] \ && ! grep -q '^flags\b.*\brdrand\b' /proc/cpuinfo; then # use software entropy daemon fi Ben. -- Ben Hutchings Make three consecutive correct guesses and you will be considered an expert. signature.asc Description: This is a digitally signed message part
Bug#923675: Add related bug #916690 info
On Tue, 2019-04-16 at 13:57 +0200, Petter Reinholdtsen wrote: > [Ben Hutchings] > > This is a pretty terrible approach. Especially as the world has moved > > on to SSDs and they provide very little entropy from interrupts. > > Absolutely. But it has solved the problem with too little entropy since > 2011. > Do you have any better ways to force the kernel to add some entropy when > running > low? haveged or jitterentropy-rngd are likely to be better. Ben. -- Ben Hutchings Make three consecutive correct guesses and you will be considered an expert. signature.asc Description: This is a digitally signed message part
Bug#926539: rootskel: steal-ctty no longer works on at least sparc64
On Tue, 2019-04-16 at 11:47 +0200, John Paul Adrian Glaubitz wrote: > Hi Ben! > > On 4/7/19 1:53 AM, Ben Hutchings wrote: > > > root@landau:~# cat /proc/consoles > > > ttyHV0 -W- (EC p )4:64 > > > tty0 -WU (E )4:1 > > > root@landau:~# readlink /sys/dev/char/4:64 > > > ../../devices/root/f0299a70/f029b788/tty/ttyS0 > > > > The inconsistent name seems like a kernel bug... > > Yes. I'm trying to convince Dave Miller to fix this. > > Do you think we could carry a patch in src:linux for the time being? [...] I would rather not do that until it's accepted, as if it that doesn't happen we either have to switch back or carry it forever. Ben. -- Ben Hutchings Make three consecutive correct guesses and you will be considered an expert. signature.asc Description: This is a digitally signed message part
Bug#923675: Add related bug #916690 info
On Tue, 2019-04-16 at 12:19 +0200, Petter Reinholdtsen wrote: > Debian Edu ran into this problem when installing Kerberos as a server from > d-i, > and solved it by running a process in the background to monitor the entropy > level, > and when it was running low, it would flush the file buffers and run 'find > /target' to force some IO operations that would add entropy to the kernel. [...] This is a pretty terrible approach. Especially as the world has moved on to SSDs and they provide very little entropy from interrupts. Ben. -- Ben Hutchings Make three consecutive correct guesses and you will be considered an expert. signature.asc Description: This is a digitally signed message part
Bug#820036: Debian does not run on systems with Secure Boot enabled
Control: summary -1 GRUB and Linux images are now signed by the production key trusted by shim-signed. Debian-installer apparently installs the signed packages, but other installation systems are not yet ready. Ben. -- Ben Hutchings Quantity is no substitute for quality, but it's the only one we've got. signature.asc Description: This is a digitally signed message part
Bug#821088: vmdebootstrap: Missing UEFI Secure Boot support
Control: found 1.11-1 I can confirm that this still doesn't work. Ben. -- Ben Hutchings Quantity is no substitute for quality, but it's the only one we've got. signature.asc Description: This is a digitally signed message part
Bug#821051: Need support for uploading and signing EFI executables
On Fri, 03 Aug 2018 21:49:19 +0800 Ben Hutchings wrote: > Control: retitle -1 ftp.debian.org: Get signing service running > > At the Secure Boot sprint > <https://lists.debian.org/debian-project/2018/04/msg00071.html> a new > architecture for code signing was agreed, and the implementation now > exists at <https://salsa.debian.org/ftp-team/code-signing>;. > > This bug should stay open until the signing service is in production. The signing service is in production, with a production key. However, signing currently has to be approved manually, whereas in the long term it's intended to be automatic. Ben. -- Ben Hutchings Quantity is no substitute for quality, but it's the only one we've got. signature.asc Description: This is a digitally signed message part
Bug#926794: linux-image-4.19.0.0-bpo.4-amd64: Please enable FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER in kernel config
On Wed, 10 Apr 2019 15:58:07 +0200 Frantisek Novak < novak.franti...@atlas.cz> wrote: > Package: linux-image-4.19.0.0-bpo.4-amd64 > Version: linux-image-4.19.0-0-bpo.4-amd64 > Severity: wishlist > > Dear Maintainer, > > please enable FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER in kernel configuration to prevent clearing of the framebuffer when the console starts during the boot. I tried it a few months back and I don't think we should do this in the kernel in isolation. We would also need to make the boot loader silent by default, and we might need to update themes as well. If you want this to happen, please propose those changes in the other packages after the buster release. 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
Bug#926875: initramfs-tools backward compatibility removal
Control: reassign -1 dropbear-initramfs 2018.76-5 Control: severity -1 minor On Thu, 2019-04-11 at 19:04 +0200, Florian Strankowski wrote: > Package: initramfs-tools > Version: 0.130 > > When ifdown is invoked, it still checks for IFDOWN beeing supplied > within /conf/initramfs.conf. Due to the nature of evolution, this has > been moved to /etc/dropbear-initramfs/config within the release of stretch. [...] This is part of dropbear-initramfs and not initramfs-tools itself. Ben. -- Ben Hutchings Never attribute to conspiracy what can adequately be explained by stupidity. signature.asc Description: This is a digitally signed message part
Bug#914517: linux-image-4.19.0-4-amd64: System freezes with nomodeset set and boots in a loop without
On Wed, 2019-04-10 at 17:26 +0200, Robert Pommrich wrote: > Hi, > > I really don't understand why the severity of this bug was lowered. > Plus, this was the only action taken on this bug beside my actions. [...] The phrase "renders package unusable" means that the package is unusable in general, or on a large proportion of Debian systems. I don't believe that that is the case for this bug. Ben. -- Ben Hutchings Never attribute to conspiracy what can adequately be explained by stupidity. signature.asc Description: This is a digitally signed message part
Bug#925411: kernel-package: Not suitable for release
On Mon, 2019-04-08 at 00:20 -0400, Nicholas D Steeves wrote: [...] > Ah, yes, thank you! :-) Regarding documentation, should > Debian-specific bits go on our wiki or be forwarded upstream? The bindeb-pkg target is part of the upstream build system, not something patched in by Debian, so the primary place to document it should be upstream. [...] > Should users who track a 4.19.x-based branch use buster's > linux-libc-dev headers, or install the ones that correspond to their > custom kernel? [...] No, the only reason to install a custom linux-libc-dev package would be to provide definitions for new UAPI added in a new kernel version. Ben. -- Ben Hutchings Never attribute to conspiracy what can adequately be explained by stupidity. signature.asc Description: This is a digitally signed message part
Bug#852323: Problem: UUIDs not being used everywhere for disks in stretch
On Sat, 2019-04-06 at 16:54 +0100, Steve McIntyre wrote: > Actually... > > On Sat, Apr 06, 2019 at 04:36:59PM +0100, Steve McIntyre wrote: > > We need to run update-dev *after* the filesystem creation scripts and > > this fixes things. I've just copiet it to 99update-dev locally while > > testing and that made all the difference. It could probably also just > > be moved instead of copied - at this point I'm not sure if anything in > > the other scripts also depend on the udev updates for their > > functionality. Fundamentally, it's a fairly harmless thing to run > > repeatedly so I'm tempted to just run it twice. Thoughts? > > I think we're definitely going to need this, actually - new device > entries may not show up otherwise. > > I'm also seeing in my testing that I *do* need to force a "udevadm > trigger" in the second script. Fundametally, it you don't get new > kernel events when a mkfs happens so udev will never notice. Closing a block device that is opened for writing should trigger a change event. I tested this now with Linux 4.19.28 and it still seems to happen. Ben. -- Ben Hutchings This sentence contradicts itself - no actually it doesn't. signature.asc Description: This is a digitally signed message part
Bug#926539: rootskel: steal-ctty no longer works on at least sparc64
On Sat, 2019-04-06 at 21:33 +0200, John Paul Adrian Glaubitz wrote:
> On 4/6/19 6:46 PM, John Paul Adrian Glaubitz wrote:
> > My suspicion is that the support multiple consoles in parallel [2]
> > introduced
> > this particular regression. I haven't done any debugging yet though as I'm
> > not sure where to start, I haven't touched the rootskel package before and
> > therefore would be interested in any pointers how to debug this.
>
> The problem seems to be the fact that the sparc64 kernel uses different names
> for /proc/console and the actual console name:
>
> root@landau:~# cat /proc/consoles
> ttyHV0 -W- (EC p )4:64
> tty0 -WU (E )4:1
> root@landau:~# readlink /sys/dev/char/4:64
> ../../devices/root/f0299a70/f029b788/tty/ttyS0
The inconsistent name seems like a kernel bug...
> root@landau:~#
>
> And this is what used to make it work [1]:
>
> *) # >= 2.6.38
> console_major_minor="$(get-real-console-linux)"
> console_raw="$(readlink "/sys/dev/char/${console_major_minor}")"
> console="${console_raw##*/}"
> ;;
So maybe rootskel should use that again, but applied to each console's
char device number.
(Though directly using the symlinks under /dev/char seems cleaner than
poking in sysfs.)
Ben.
--
Ben Hutchings
This sentence contradicts itself - no actually it doesn't.
signature.asc
Description: This is a digitally signed message part
Bug#926149: AMD: Add nomodeset kernel parameter to avoid black screen
On Thu, 2019-04-04 at 09:22 +0800, 積丹尼 Dan Jacobson wrote:
> > > > > > "BH" == Ben Hutchings writes:
>
> BH> The installer normally uses a dumb framebuffer driver (probably efifb
> BH> on this system) that is built into the kernel. This is too low-
> BH> performance for a proper desktop.
>
> OK, the installer could first double check that the framebuffer driver
> it intends to write to the installation really will work, by telling the
> user:
>
> "5 seconds please, while we test your framebuffer ability."
>
> During which it could launch its proposed framebuffer,
> see if /proc/sys/.../{voltage or number of lit pixels, etc.} has
> suddenly dropped to zero, indicating a black screen, and then back out
> of that choice. Or simply ask the user "in a moment you will be asked if
> you saw a black screen".
[...]
There is generally no way to back out of changing the framebuffer
driver, other than to reboot. So we would have to implement some
ability for the installer to checkpoint its progress and then continue
after a reboot. I suspect that that would require a pretty major
architectural change and is unlikely to happen any time soon.
However it might be reasonable to add "nomodeset" to the command line
in GRUB's "recovery" boot menu items.
Ben.
--
Ben Hutchings
Any smoothly functioning technology is indistinguishable
from a rigged demo.
signature.asc
Description: This is a digitally signed message part
Bug#926261: closed by Ben Hutchings (Re: Bug#926261: linux-image-4.19.0-4-amd64: fan continiously spinning above 6900 RPM after resume on lenovo carbon x1 thinkpad with isa adap
On Wed, 2019-04-03 at 20:08 +, Karol Szkudlarek wrote: > > It has been closed by Ben Hutchings b...@decadent.org.uk. > > > > Their explanation is attached below along with your original > > report. > > If this explanation is unsatisfactory and you have not received a > > better one in a separate message then please contact Ben Hutchings > > b...@decadent.org.uk by > > > > replying to this email. > > > > > > - > > > > Linux doesn't control the fan, that's done by the system firmware. > > > > Ben. > > System firmware is a part of Linux. [...] The system firmware (sometimes called the "BIOS") is what came with the hardware. Ben. -- Ben Hutchings Q. Which is the greater problem in the world today, ignorance or apathy? A. I don't know and I couldn't care less. signature.asc Description: This is a digitally signed message part
Bug#926149: AMD: Add nomodeset kernel parameter to avoid black screen
On Wed, 2019-04-03 at 10:14 +0800, 積丹尼 Dan Jacobson wrote: > So the question becomes why does that installer ISO know how to properly deal > with the > > BH> 00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. > [AMD/ATI] Carrizo [1002:9874] (rev e6) > BH> Subsystem: ASUSTeK Computer Inc. Device [1043:8719] > > giving nice splash screens, a snappy graphical install interface, crisp > non-graphical rescue shells etc. ... but then the system that it > installs oddly cannot deal with that hardware anymore? (Black screen.) The installer normally uses a dumb framebuffer driver (probably efifb on this system) that is built into the kernel. This is too low- performance for a proper desktop. Ben. > Note the whole experiment was done offline as to reduce outside > interference in isolating the problem. -- Ben Hutchings Q. Which is the greater problem in the world today, ignorance or apathy? A. I don't know and I couldn't care less. signature.asc Description: This is a digitally signed message part
Bug#926149: AMD: Add nomodeset kernel parameter to avoid black screen
Control: tag -1 - moreinfo On Tue, 2019-04-02 at 22:41 +0800, 積丹尼 Dan Jacobson wrote: > BH> Please send the output of "lspci -vnn" for the system that shows this > BH> problem. > > Would lspci -knn be good enough for now?: > https://bugs.debian.org/cgi-bin/bugreport.cgi?att=0;bug=925556;filename=logs.gz;msg=50 I wish you would just provide the information inline, but anyway that does answer the question: 00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Carrizo [1002:9874] (rev e6) Subsystem: ASUSTeK Computer Inc. Device [1043:8719] Ben. -- Ben Hutchings Klipstein's 4th Law of Prototyping and Production: A fail-safe circuit will destroy others. signature.asc Description: This is a digitally signed message part
Bug#926149: AMD: Add nomodeset kernel parameter to avoid black screen
Control: reopen -1 Control: reassign -1 src:linux 4.9.144-3 On Tue, 2019-04-02 at 21:48 +0800, 積丹尼 Dan Jacobson wrote: > All I know is I researched what ISO I could put on a USB stick > and take to my mountain for a minimal install with no network. > > It worked fine, after I added that nomodeset line. > > It is a shame if officially debian no longer can be installed without a > network. It can, but you will generally need a "DVD" image (which is actually limited to 4GB in size) for a usable desktop installation. *However* I have re-checked and the netinst images do contain the necessary firmware packages, not just firmware for network adapters in the installer itself. So I think that the amdgpu firmware did get installed, and the driver is failing for some other reason. Please send the output of "lspci -vnn" for the system that shows this problem. Ben. -- Ben Hutchings Klipstein's 4th Law of Prototyping and Production: A fail-safe circuit will destroy others. signature.asc Description: This is a digitally signed message part
Bug#849509: Logs show popularity-contest installation indeed occurs after user says no
On Tue, 2019-04-02 at 21:21 +0800, 積丹尼 Dan Jacobson wrote: > Actually try this: > When you get to the popularity-contest question, wait a few moments, > then answer "no". > > Later examine the logs. > You will see actual installation (and then removal) indeed occurs > *after* the user has answered "no". > > So the user's eyes didn't fool him after all. I understand that this can be confusing and may lead to users mistrusting Debian, and it would be good to avoid that. But please don't try to tell us how the installer works. The question is part of popularity-contest, so the package has to be installed in order to ask the question. Ben. -- Ben Hutchings Klipstein's 4th Law of Prototyping and Production: A fail-safe circuit will destroy others. signature.asc Description: This is a digitally signed message part
Bug#926149: AMD: Add nomodeset kernel parameter to avoid black screen
Control: tag -1 moreinfo On Mon, 2019-04-01 at 15:59 +0800, 積丹尼 Dan Jacobson wrote: > Package: installation-reports > > With the latest AMD CPUs the kernel will attempt to use the AMDGPU > kernel driver. Alas this will result in a black screen on the minimal > system installed by the installer. The installer should not do this. If the necessary firmware is installed, the amdgpu driver should work, of course. If the firmware is not installed, the driver is supposed to bail out early (this is a Debian-specific patch). Was the firmware (firmware-amd-graphics package) installed on your test system? Ben. -- Ben Hutchings Life is what happens to you while you're busy making other plans. - John Lennon signature.asc Description: This is a digitally signed message part
Bug#925979: busybox-udeb: breaks user-params, rescue mode, etc.
On Sat, 2019-03-30 at 13:33 +0100, Cyril Brulebois wrote: > Heya, > > Chris Boot (2019-03-30): [...] > > I've also had a thought, and I can't remember if we've considered it > > already: do the environment variables get preserved in > > /proc/1/environ, even if busybox ash can't grok them? Could d-i be > > modified to pull them from there? > > Indeed, /proc/1/environ seems to have everyone! Please note that /proc/$pid/environ is a live view of the region of a process's virtual memory where the kernel originally wrote its environment strings. The process is free to overwrite or even unmap this memory at any time. (Even if it doesn't do that, any additions to its environment will necessarily be outside that region.) So I don't recommend using /proc/1/environ if you can avoid it. Ben. -- Ben Hutchings Design a system any fool can use, and only a fool will want to use it. signature.asc Description: This is a digitally signed message part
Bug#925919: RFT: linux with fix for VMware regression
I've uploaded a new version of linux to: https://people.debian.org/~benh/packages/jessie-security/ which I believe will fix this regression (bug #925919). Please let me know whether it works for you. I only included the amd64 linux-image package and sources there, but can add i386 linux-image packages if needed. Ben. -- Ben Hutchings Design a system any fool can use, and only a fool will want to use it. signature.asc Description: This is a digitally signed message part
Bug#901193: Bug#901003: There is no standard way of removing transitional / dummy packages
On Wed, 2019-03-27 at 22:52 +, vincent.mcint...@csiro.au wrote: [...] > I agree with everything you've said about this text but as regards > the patch I think some mention of tracking packages should be kept. > Something like: > > One class of dummy package that are not intended to be removed > are tracking packages, which are used to keep > track of the current available version of a program over time. > A common case is linux-image--. Why do you want to introduce the term "tracking package" when we already have the term "metapackage"? Ben. -- Ben Hutchings I say we take off; nuke the site from orbit. It's the only way to be sure. signature.asc Description: This is a digitally signed message part
Bug#925482: stretch-pu: package firmware-nonfree/20161130-5
Package: release.debian.org Severity: normal Tags: stretch User: release.debian@packages.debian.org Usertags: pu This update fixes CVE-2018-5383 in firmware for some Bluetooth adapters. The security team already triaged this as not requiring a DSA. Ben. -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#925441: unblock: linux/4.19.28-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package linux * Upstream stable fixes for security, stability, and regressions * Various other important fixes * Enable additional hardware support * Make more drivers available for use in the installer * Enable RANDOM_TRUST_CPU to improve entropy availability * Update trusted certificates and signing metadata to work with production signing service * Fixes for build profiles and cross-builds * [x86] Disable a.out support as it's obsolete and a security liability * [x86] Drop fix for #865303, which no longer affects Debian's OpenJDK * [ppc64el] Disable PCMCIA, as it was never available on this platform The diff is too big to include, sorry. unblock linux/4.19.28-2 -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#925411: kernel-package: Not suitable for release
Control: severity -1 serious On Sun, 2019-03-24 at 16:19 -0600, Nicholas D Steeves wrote: > Control: severity -1 important > Justification: essential package that works flawlessly for me This was agreed with the maintainer, so you should not override it. The discussion is here: https://lore.kernel.org/lkml/1551888035-13329-1-git-send-email-yamada.masah...@socionext.com/ but unfortunately Manoj's message didn't get archived there for some reason. [...] > The new style kernel packaging is hard to learn how to use, and builds > take much longer for some reason (generation of more packages?). [...] It sounds like you're looking at the linux source package. I would certainly not suggest using that for local custom packages; it's meant for distributions. The simple alternative is already included in the kernel tree itself: make bindeb-pkg It does generate some extra packages (linux-headers and linux-libc-dev) but that doesn't take very long. The generated packages don't support /etc/kernel-img.conf but they do support hooks in /etc/kernel. > 13.018+nmu1 on buster works like it always has for me--flawlessly. I > built upstream vanilla 4.19.31 two days ago. Bug #890817 also looks like it may be a big problem for current kernel versions, but apparently you have avoided it. Ben. -- Ben Hutchings Larkinson's Law: All laws are basically false. signature.asc Description: This is a digitally signed message part
Bug#925415: linux-update-symlinks(1) refers to man page that won't be in buster
Package: linux-base Version: 4.5 Severity: important kernel-img.conf(5) is part of kernel-common, built from kernel-package. However kernel-package is not in a state to be released in buster (see #925411). Ben. -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages linux-base depends on: ii debconf [debconf-2.0] 1.5.71 linux-base recommends no packages. linux-base suggests no packages. -- debconf-show failed
Bug#925411: kernel-package: Not suitable for release
Package: kernel-package Version: 13.018+nmu1 Severity: serious I discussed the state of kernel-package with Manoj and we agreed (see below) that it is not currently in a state suitable for release. Ben. --- From: Manoj Srivastava Date: Thu, 7 Mar 2019 23:15:30 -0800 Message-ID: To: Masahiro Yamada Cc: Ben Hutchings , Linux Kbuild mailing list , Liz Zhang , Lili Deng , Riku Voipio , Michal Marek , Linux Kernel Mailing List Subject: Re: [PATCH] kbuild: add workaround for Debian make-kpkg Hi, Well, if there are users, then I'll file the return bug, but I'll take a look to see how but rooted this is, and perhaps even try building personal imaged Deb packages again (I stopped doing that) If should not go into buster in it's current state. It should be killed dead of it can't be brought back to a working state. Manoj On Thu, Mar 7, 2019, 10:43 PM Masahiro Yamada wrote: > On Fri, Mar 8, 2019 at 6:56 AM Ben Hutchings wrote: > > > > On Wed, 2019-03-06 at 22:48 -0800, Manoj Srivastava wrote: > > > Hi, > > > > > > Does this have any users? > > Recently, I received a regression report. > So, yes. There are users. > > > > > I can take a stand at making it work, but I am > > > unsure of there are enough people interested in make-kpkg anymore to > make > > > it worthwhile. > > > > > > There is a man pager that might be of minor interest, but that can be > > > taken over by the kernel team if they want > > I do not want to maintain the dying package. > > > > > [...] > > > > I assume you're referring to kernel-img.conf. I would be happy to add > > that to linux-base, with some clarification of which settings are > > understood by which packages. > > > > I take it that you don't want kernel-package to be included in buster, > > so can you open an RC bug to say so? > > Also, could you make sure it won't come back to bullseye or later ? > > How about Ubuntu? Is it out of your control? > > > > > Ben. > > > > -- > > Ben Hutchings > > friends: People who know you well, but like you anyway. > > > > > > > -- > Best Regards > Masahiro Yamada > -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages kernel-package depends on: ii bc 1.07.1-2+b1 ii binutils 2.31.1-15 ii build-essential 12.6 ii bzip21.0.6-9 ii dpkg-dev 1.19.5 ii file 1:5.35-4 ii gettext 0.19.8.1-9 ii kmod 26-1 ii lzma 9.22-2.1 ii po-debconf 1.0.21 ii xmlto0.0.28-2.1 ii xz-utils [lzma] 5.2.4-1 Versions of packages kernel-package recommends: ii cpio 2.12+dfsg-6 pn docbook-utils ii kernel-common 13.018+nmu1 pn uboot-mkimage Versions of packages kernel-package suggests: ii libncurses-dev 6.1+20181013-2 pn linux-source -- debconf-show failed
Bug#785065: [PATCH] powerpc: vdso: Make vdso32 installation conditional in vdso_install
The 32-bit vDSO is not needed and not normally built for 64-bit
little-endian configurations. However, the vdso_install target still
builds and installs it. Add the same config condition as is normally
used for the build.
Fixes: e0d005916994 ("powerpc/vdso: Disable building the 32-bit VDSO ...")
Signed-off-by: Ben Hutchings
---
arch/powerpc/Makefile | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 488c9edffa58..3def265cf1cf 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -406,7 +406,9 @@ endef
ifdef CONFIG_PPC64
$(Q)$(MAKE) $(build)=arch/$(ARCH)/kernel/vdso64 $@
endif
+ifdef CONFIG_VDSO32
$(Q)$(MAKE) $(build)=arch/$(ARCH)/kernel/vdso32 $@
+endif
archclean:
$(Q)$(MAKE) $(clean)=$(boot)
signature.asc
Description: PGP signature
Bug#925266: two different versions for Jessie install media (8.11.1 for LTS, 8.11.0 for the rest)
On Fri, 2019-03-22 at 00:28 +0100, Laura Arjona Reina wrote: > Package: www.debian.org > User: www.debian@packages.debian.org > Usertag: content lts > Severity: normal > X-Debbugs-CC: debian-...@lists.debian.org > > Hi all > Install media version 8.11.1 has been created for Jessie LTS > architectures only, so we need to keep on offering 8.11.0 images for the > non-LTS arches (currently we have broken links for mips, mipsel, > powerpc, ppc64el and s390x because they point to non-existent 8.11.1 > images). [...] Sorry about that. I don't think we should continue to link to unsupported images, but I now see that we still have installer pages for all releases that used d-i. In my commit 0a388832cb4a7e9dfe1265fa04d1c441e9730e23 I intended to remove the non- LTS arches from the page, but that obviously didn't work. Ben. -- Ben Hutchings Make three consecutive correct guesses and you will be considered an expert. signature.asc Description: This is a digitally signed message part
Bug#785065: #785065: is this still relevant ?
On Wed, 2019-03-20 at 15:51 +0100, Frédéric Bonnard wrote: > Hi Ben, > > I was told that there is no 32b bootstrap code involved, only BE. > I understand this problem does not happen on current kernels. > May we close this bug? or for more details we can ping Michael. Looking at the build log, I can still see command lines using "-m32". But this seems to be due to a bug in the vdso_install target, which should be easy enough to fix. Ben. -- Ben Hutchings Make three consecutive correct guesses and you will be considered an expert. signature.asc Description: This is a digitally signed message part
Bug#920286: gcc-8: Missing conflict/break with binutils-x86-64-linux-gnu:i386 can lead to broken compiler
On Tue, 2019-03-19 at 15:41 +0100, Helmut Grohne wrote: [...] > src:linux Build-Depends binutils-. The binutils patch will > render these dependencies cross-unsatisfiable. They will need to be > switched to binutils-for-host or annotated with :any (after checking > that it doesn't use plugins). Maintainers Cced. We only do that for hppa, as the standard gcc-8 & binutils packages only support 32-bit code and we need to build 64-bit kernels there. We don't use plugins for binutils. Ben. > So the attached patch will break cross building of gcc and linux. It > won't break any native stuff and it'll fix the bug at hand. > > Helmut -- Ben Hutchings The first rule of tautology club is the first rule of tautology club. signature.asc Description: This is a digitally signed message part
Bug#924581: lintian: license-problem-gfdl-invariants false positive in src:linux's fdl-appendix.rst
On Thu, 2019-03-14 at 11:49 -0400, Chris Lamb wrote: > Package: lintian > Version: 2.9.1~bpo9+1 > Severity: normal > X-Debbugs-CC: ans...@debian.org, b...@decadent.org.uk, > ftpmas...@ftp-master.debian.org> > > Ansgar wrote: > > > Ben Hutchings writes: > > > On Wed, 2019-03-13 at 12:07 +, Debian FTP Masters wrote: > > > > linux source: lintian output: 'license-problem-gfdl-invariants > > > > Documentation/media/uapi/fdl-appendix.rst invariant part is: > > > > published by the free software .. foundation, with no invariant > > > > sections, no front-cover texts .. and no back-cover texts', > > > > automatically rejected package. > > > > linux source: If you have a good reason, you may override this lintian > > > > tag. > > > > > > We keep getting false positives for this, because lintian doesn't > > > recognise the "no invariant sections" part with markup. This should > > > not be an auto-reject. > > > > I've removed it from the list of auto-rejects for now[1]. Also CC'ed > > the lintian maintainers to make them aware of the problem (if they > > aren't already). > > > > Ansgar > > > > [1] > > https://salsa.debian.org/ftp-team/dak/commit/44fe84b9e24c59ac932f303cd25f1df3b8a20e82 > > (We were not aware.) Filing bug so this doesn't get lost… I don't think it is practicable for lintian to recognise arbitrary markup within the sentence, which is why I previously overrode the warning for other files rather than opening a bug. So my complaint was not that lintian warned at all, but that this was treated as being a sufficiently reliable check as to trigger an auto-reject. Ben. -- Ben Hutchings Make three consecutive correct guesses and you will be considered an expert. signature.asc Description: This is a digitally signed message part
Bug#924499: libgeocode-glib0: Segfault in _geocode_create_place_from_attributes
Package: libgeocode-glib0 Version: 3.20.1-2 Severity: important A location search for "middle" in GNOME Maps consistently causes it to crash (SIGSEGV signal), with the following call stack: (gdb) bt #0 0x767b7cf5 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x7fffe96752b8 in _geocode_create_place_from_attributes () from /usr/lib/x86_64-linux-gnu/libgeocode-glib.so.0 #2 0x7fffe9675794 in _geocode_parse_search_json () from /usr/lib/x86_64-linux-gnu/libgeocode-glib.so.0 #3 0x7fffe9675ae6 in ?? () from /usr/lib/x86_64-linux-gnu/libgeocode-glib.so.0 #4 0x7fffe91d45be in ?? () from /usr/lib/x86_64-linux-gnu/libsoup-2.4.so.1 #5 0x7fffe91d4f42 in ?? () from /usr/lib/x86_64-linux-gnu/libsoup-2.4.so.1 #6 0x7fffe91d4ff6 in ?? () from /usr/lib/x86_64-linux-gnu/libsoup-2.4.so.1 #7 0x778bc6aa in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #8 0x778bca60 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #9 0x778bcb0c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #10 0x740ce72d in g_application_run () from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0 #11 0x7657e038 in ffi_call_unix64 () from /usr/lib/x86_64-linux-gnu/libffi.so.6 #12 0x7657da9a in ffi_call () from /usr/lib/x86_64-linux-gnu/libffi.so.6 #13 0x7760b301 in ?? () from /usr/lib/libgjs.so.0 #14 0x7760ca7f in ?? () from /usr/lib/libgjs.so.0 #15 0x7396d8fc in ?? () from /usr/lib/x86_64-linux-gnu/libmozjs-24.so.0 #16 0x7396e918 in ?? () from /usr/lib/x86_64-linux-gnu/libmozjs-24.so.0 #17 0x73976e78 in ?? () from /usr/lib/x86_64-linux-gnu/libmozjs-24.so.0 #18 0x73977ffa in ?? () from /usr/lib/x86_64-linux-gnu/libmozjs-24.so.0 #19 0x73a239ed in JS::Evaluate(JSContext*, JS::Handle, JS::CompileOptions, unsigned short const*, unsigned long, JS::Value*) () from /usr/lib/x86_64-linux-gnu/libmozjs-24.so.0 #20 0x73a23afe in JS::Evaluate(JSContext*, JS::Handle, JS::CompileOptions, char const*, unsigned long, JS::Value*) () from /usr/lib/x86_64-linux-gnu/libmozjs-24.so.0 #21 0x775fe6f6 in gjs_eval_with_scope () from /usr/lib/libgjs.so.0 #22 0x775f7263 in gjs_context_eval () from /usr/lib/libgjs.so.0 #23 0x53e8 in main () -- System Information: Debian Release: 9.8 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libgeocode-glib0 depends on: ii libc6 2.24-11+deb9u4 ii libglib2.0-02.50.3-2 ii libjson-glib-1.0-0 1.2.6-1 ii libsoup2.4-12.56.0-2+deb9u2 libgeocode-glib0 recommends no packages. libgeocode-glib0 suggests no packages. -- no debconf information -- Ben Hutchings, Software Developer Codethink Ltd https://www.codethink.co.uk/ Dale House, 35 Dale Street Manchester, M1 2HF, United Kingdom
Bug#895131: linux-perf: Add libopencsd support to perf
Control: notforwarded -1 On Wed, 2019-03-13 at 05:01 +0100, John Paul Adrian Glaubitz wrote: > Package: src:linux > Followup-For: Bug #895131 > User: debian-sp...@lists.debian.org > Usertags: sparc64 > > Hello! > > This change made src:linux BD-Uninstallable on sparc64 [1] as > the package libopencsd doesn't build there [2]. > > Since this library is ARM-specific anyway, wouldn't it make > more sense to have this build-dependency on ARM targets only? Please open a *new* bug for this. Ben. -- Ben Hutchings Make three consecutive correct guesses and you will be considered an expert. signature.asc Description: This is a digitally signed message part
Bug#923988: /boot/vmlinuz-4.19.0-2-arm64: dmidecode causes kernel panic (puma-rk3399)
On Tue, 2019-03-12 at 19:04 +0100, Christoph Müllner wrote: > I've been able to reproduce and analyse this issue. > > The security error seems to be valid. [...] I don't see a security issue here. The kernel does not and should not stop root breaking the system with direct access to /dev/mem, *unless* Secure Boot / lockdown is active - and in that case access to /dev/mem is blocked completely. Ben. -- Ben Hutchings Larkinson's Law: All laws are basically false. signature.asc Description: This is a digitally signed message part
Bug#890950: Bug#902416: Bug#890950: RE: Bug#902416: systemd: systemctl hibernate: unable to resume after upgrade
On Mon, 2019-03-11 at 00:20 +0100, Michael Biebl wrote: > Hi Ben > > Am 10.03.19 um 23:17 schrieb Ben Hutchings: > > I think it would make sense for systemd to only set the hibernation > > device if it's not already set (i.e. if /sys/power/resume contains > > "0:0\n"). > > I get $ cat /sys/power/resume > 8:4 > > which part is responsible for setting that? initramfs-tools, or any alternative that implements resume from hibernation. This is because writing to /sys/power/resume is the way to resume from hibernation, as well as the way to set the device for the next hibernation. (systemd writes the number of an active swap device, so it won't cause an immediate resume.) Ben. -- Ben Hutchings The program is absolutely right; therefore, the computer must be wrong. signature.asc Description: This is a digitally signed message part
Bug#890950: RE: Bug#902416: systemd: systemctl hibernate: unable to resume after upgrade
On Sun, 2019-03-10 at 19:25 +0100, Michael Biebl wrote: > Hi Mario, > > > On Fri, 6 Jul 2018 12:41:37 + wrote: [...] > > Yes I could see two swap partitions causing the wrong one to be picked. > > It's trying to select the bigger of the two. > > > > If they don't match the one you're putting in > > /etc/initramfs-tools/conf.d/resume > > then that would cause problems. Please do confirm if you switch what's in > > initramfs conf.d/resume that the problem is fixed. > > > > Really matching code is needed for the initramfs-tools. I submitted some > > patches > > that may help here. You can refer to them at the end of this bug report: > > > > Somehow we dropped the ball here. > What's the state regarding those initramfs-tools patches? > Is there a chance to get them into buster? > If not, should we revert commit > https://github.com/systemd/systemd/commit/17c40b3a8fbfb797110c88d749bd5 > > What do you suggest? The current situation doesn't seem ideal. I think it would make sense for systemd to only set the hibernation device if it's not already set (i.e. if /sys/power/resume contains "0:0\n"). Ben. -- Ben Hutchings The program is absolutely right; therefore, the computer must be wrong. signature.asc Description: This is a digitally signed message part
Bug#922028: Can not start on Thinkpad X1 Carbon 5th (can not find its PCIe SSD?)
Control: severity -1 important Control: tag -1 moreinfo On Mon, 11 Feb 2019 20:25:04 +0800 gulfstream wrote: > Package: src:linux > Version: 4.19.16-1 > Severity: critical > > > Since I upgrade the kenel to 4.19, it does not work. For the version > 4.19.0.2-2, it may not find the PCIe SSD harddisk when mount file > system. Try running this command as root: update-initramfs -u -k 4.19.0-2-amd64 Does that print any error or warning messages? If not, does that fix the problem (i.e. can you then reboot into the new kernel version)? If that doesn't work: - Select the "recovery mode" entry for 4.19 on the boot menu, and take a picture of the output. - Run this command as root: mkinitramfs -v -o $(mktemp) 4.19.0-2-amd64 > mkinitramfs.log 2>&1 - Reply with the picture and mkinitramfs.log as attachments. Ben. -- Ben Hutchings Knowledge is power. France is bacon. signature.asc Description: This is a digitally signed message part
Bug#712953: sysvinit: System Restarts Instead of Powering Off
Control: tag -1 moreinfo On Fri, 21 Jun 2013 09:13:19 +0100 "Alan Chandler" < a...@chandlerfamily.org.uk> wrote: > Package: sysvinit > Version: 2.88dsf-41 > Severity: normal > > Dear Maintainer, > > When I attempt to power off the machine (either logging out of gnome3, or via > shutdown now typed in at a terminal) > the system goes through the shutdown sequence (it does seem to pause after > telling all processes to terminate and > then reports that some processes are still running). It finally reports it is > about to power off. > > But the computer then restarts and reboots. > > If I load up Debian Wheezy and shut that down, the computer powers off > properly. Sorry this report took so long to get assigned properly. Is this still happening in a current Debian version? Ben. -- Ben Hutchings Knowledge is power. France is bacon. signature.asc Description: This is a digitally signed message part
Bug#833500: kernel-package: CONFIG_STACK_VALIDATION needs tools/objtool/objtool along headers
Control: severity -1 important Control: forcemerge -1 919270 This is at least important, if not RC, as it seems to prevent building out-of-tree modules on amd64. Ben. -- Ben Hutchings friends: People who know you well, but like you anyway. signature.asc Description: This is a digitally signed message part
Bug#658759: [kirkwood] squeeze-backports kernel fails to boot on SheevaPlug
On Mon, 2019-03-04 at 20:35 +0100, Paul Gevers wrote: > Hi all, > > On Fri, 24 Aug 2012 09:44:47 +0100 Ian Campbell wrote: > > On Fri, 2012-08-24 at 00:31 -0700, Jonathan Nieder wrote: > > > Any ideas for how to word a hint about this for > > > the wheezy release-notes? > > > > Hrm, how about: > > > > The version of u-boot shipped from the factory on many > > kirkwood(???) devices, as well as u-boot shipped in versions of > > Debian prior to Wheezy, contain a bug (#658759) which renders > > them unable to boot kernel versions 3.2(???) or newer. This > > includes the kernel in Wheezy. > > > > Users are advised to upgrade u-boot before upgrading their > > kernel. XXX link to suitable documentation? > > http://www.cyrius.com/debian/kirkwood/sheevaplug/uboot-upgrade.html > > and similar? > > > > (??? fact needs checking). > > This bug is marked as affecting the release-notes. I don't think this is > relevant for stretch or buster anymore? If not, I'll like to remove the > "affects", to not clutter the release-notes bug list. Again, it should have been mentioned and I don't believe the kernel has a workaround for this, but it would probably be pointless to mention now. Ben. -- Ben Hutchings A free society is one where it is safe to be unpopular. - Adlai Stevenson signature.asc Description: This is a digitally signed message part
Bug#697029: [ilk] using GNOME 3 makes computer sluggish after a few minutes
On Mon, 2019-03-04 at 20:45 +0100, Paul Gevers wrote: > Hi, > > On Sun, 24 Feb 2013 07:08:14 + Ben Hutchings > wrote: > > > "Graphics rendering may be very slow on Intel 'Ironlake M' GPUs (PCI > > ID 8086:0046) when an IOMMU (VT-d) is enabled. The IOMMU > > functionality can be disabled for the GPU by adding the kernel > > parameter 'intel_iommu=igfx_off'." > > This bug is marked as affecting the release-notes. I don't think this is > still relevant for stretch or buster? If not, I'll like to remove the > "affects", to not clutter the release-notes bug list. This should have been included in release notes, and I don't think the issue has been solved, but at this point it's probably pointless to mention it. Ben. -- Ben Hutchings A free society is one where it is safe to be unpopular. - Adlai Stevenson signature.asc Description: This is a digitally signed message part
Bug#923522: Upgrading `linux-image-4.9.0-8-amd64` breaks loading kernel modules
Control: severity -1 minor On Fri, 2019-03-01 at 12:07 +0100, riccardo.mu...@gmail.com wrote: > Package: linux-image-4.9.0-8-amd64 > Version: 4.9.144-3.1 > > As of March 1, 2019, running `apt upgrade` on a recent Debian 9 official > cloud image, results in package `linux-image-4.9.0-8-amd64` being > upgraded: > > $ apt list --upgradable > [...] > linux-image-4.9.0-8-amd64/stable-updates 4.9.144-3.1 amd64 [upgradable > from: 4.9.130-2] > [...] > > However, after the upgrade, kernel modules are no longer loadable; here > is an example triggered by `ip6tables-restore`: > > # tail /var/log/syslog > Mar 1 10:11:08 stretch kernel: [ 502.887305] nf_defrag_ipv6: disagrees > about version of symbol inet_frags_fini > Mar 1 10:11:08 stretch kernel: [ 502.887894] nf_defrag_ipv6: Unknown > symbol inet_frags_fini (err -22) > Mar 1 10:11:08 stretch kernel: [ 502.888985] nf_defrag_ipv6: disagrees > about version of symbol inet_frag_find > Mar 1 10:11:08 stretch kernel: [ 502.889712] nf_defrag_ipv6: Unknown > symbol inet_frag_find (err -22) > Mar 1 10:11:08 stretch kernel: [ 502.890386] nf_defrag_ipv6: disagrees > about version of symbol ip6_expire_frag_queue > Mar 1 10:11:08 stretch kernel: [ 502.891048] nf_defrag_ipv6: Unknown > symbol ip6_expire_frag_queue (err -22) > Mar 1 10:11:08 stretch kernel: [ 502.891885] nf_defrag_ipv6: Unknown > symbol pskb_trim_rcsum_slow (err 0) > Mar 1 10:11:08 stretch kernel: [ 502.893030] nf_defrag_ipv6: disagrees > about version of symbol inet_frag_kill > Mar 1 10:11:08 stretch kernel: [ 502.893688] nf_defrag_ipv6: Unknown > symbol inet_frag_kill (err -22) > Mar 1 10:11:08 stretch kernel: [ 502.894594] xt_conntrack: cannot load > conntrack support for proto=10 > > The problem is that both packages install kernel modules in the same > directory `/lib/modules/4.9.0-8-amd64` although they are not binary > compatible. This is a known issue with upgrades that we don't currently plan to fix. > Needless to say, the issue with loading kernel modules is corrected by a > reboot, but I think that the larger issue here is that upgrading a > kernel package, on the *stable* distribution and *keeping the same > (nominal) kernel version*, can break a running system -- all while that a > solution for this problem has been known for many years now... > > Thanks for any help! Normally all required modules would be loaded during boot, so there's no breakage. Ben. -- Ben Hutchings Tomorrow will be cancelled due to lack of interest. signature.asc Description: This is a digitally signed message part
Bug#923400: initramfs-tools: failure inside chroot: W: Couldn't identify type of root file system for fsck hook
Control: severity -1 wishlist Control: retitle -1 Add option to override filesystem type detection On Wed, 2019-02-27 at 18:38 +0100, Jonas Smedegaard wrote: > Quoting Jonas Smedegaard (2019-02-27 17:45:33) > > Building a system image using multistrap, > > including generating an initial ramdisk, > > worked fine recently. > > > > Now it fails with this error message: > > > > W: Couldn't identify type of root file system for fsck hook > > > > It seems to me that git commit a8ed874 intended to extend the code > > operating on "auto" mounted filesystems to cover all _except_ root disk, > > but that the logic is flipped around so that now it _only_ extends that > > to include root disk: This commit went into version 0.123, before stretch, so if your use case "worked fine recently" then this is not the change that broke it. > Please ignore my guess above: I think I understand now that it was > intentional to check root disk (I got confused by the comment talking > about ignoring root and then processing root not skipping it). > > Let me clarify my use case: I generate a system image on a fast amd64 > system targeted a slower real device (that's the reason having initramfs > generated is important). > > fstab now unconditionally being distrusted for root disk makes it more > difficult to build on a different host than intended for target boot. > > Would it perhaps make sense to support passing pre-resolved root > filesystem fstype as an environment variable, taking precedence over > probing? I don't think this should be an environment variable but it does seem like a useful option. 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
Bug#922815: insserv FATAL while updating as mountkernfs has to be enabled to use service udev
On Wed, 2019-02-27 at 03:01 +, Dmitry Bogatov wrote: > [2019-02-25 05:45] shirish शिरीष > > On 24/02/2019, Dmitry Bogatov wrote: > > > > > > > > > Interesting, you seems somehow got mountkernfs.sh script removed from > > > runlevel S. > > > > > > Can you please invoke as root > > > > > > # update-rc.d mountkernfs.sh enable S > > > > > > and then retry your upgrade. > > > > When I try the command you shared, it says - > > > > root@debian:~# update-rc.d mountkernfs.sh enable S > > update-rc.d: error: cannot find a LSB script for mountkernfs.sh > > Seems there is no /etc/init.d/mountkernfs.sh on your system. > > Since your init system is systemd, I question, why do you need insserv > in first place. Do you have bin:initscripts installed? > > My guess is that update-initramfs invokes insserv /if/ it is available, > and since you have insserv installed, but no initscripts, we get this > bug. It does not. Ben. > Adding initramfs-tools maintainer into loop. If my guess is correct, > this issue should be resolved on initramfs side, since making insserv > depending on initscripts is not nice to user. -- 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
Bug#376925: initramfs-tools: init should say 'Will now load...'!
Control: severity -1 wishlist Control: tag -1 wontfix On Thu, 21 Feb 2019 17:54:57 + Dmitry Bogatov wrote: > > control: reassign -1 initramfs-tools > > Not sure, whether this issue is still present in initramfs-tools, but > initscripts /do/ say 'Will now', so bug do not apply to initscripts. > Reassigning. This message no longer appears when the "quiet" parameter is present (default behaviour when using GRUB). I don't intend to remove it completely. 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
Bug#922628: ITP: dt -- DNS tool - display information about your domain
On Mon, 2019-02-18 at 10:52 -0500, Antoine Beaupré wrote: > Package: wnpp > Severity: wishlist > Owner: Antoine Beaupré > > * Package name: dt > Version : 0.0.9 > Upstream Author : Wim > * URL : https://github.com/42wim/dt > * License : Apache-2.0 > Programming Lang: Go > Description : DNS tool - display information about your domain > > dt a DNS tool that displays information about your domain. > . > Features > • common records scanning (use -scan) > • validate DNSSEC chain (use -debug to see more info) > • change query speed for scanning (default 10 queries per second) > * diagnostic of your domain (similar to intodns.com, dnsspy.io) > > > > This is a great tool. I worked on packaging a similar tool (dnsdiag, > #824670) for Debian, but it stopped where dt begun: > > https://github.com/farrokhi/dnsdiag/issues/16 > > So I would love to see this in Debian. As usual, I would co-maintain > this in the golang team. This command name is very short, and in fact we already have a dt command (in the ditrack package). I suggest you try to convince upstream to pick a unique command name. 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
Bug#922072: linux-image-4.9.0-3-686-pae: A Hauppauge PVR-150 fails obtain any image when a camera is conneted to the composite video input.
Control: tag -1 moreinfo The current kernel version in stable is 4.9.130-2, while you are running a much older version. Please install the available updates and re-test. Note that "apt-get upgrade" does *not* install all available updates; you must use the --with-new-pkgs option. Ben. -- Ben Hutchings The world is coming to an end. Please log off. signature.asc Description: This is a digitally signed message part
Bug#916696: initramfs-tools: search for nonexistent resume device
Control: tag -1 - moreinfo Control: tag -1 patch On Sun, 2019-02-10 at 23:35 +0100, Trek wrote: [...] > my fix is to reset the resume_auto variable if the device is ephemeral, > thus removing the need to check the ephemeral variable in the two > if-construct after the for-loop > > $ephemeral || break # exit the for-loop if ephemeral=true > resume_auto=# otherwise empty resume_auto > > > that's it :) > thanks again for your time > ciao! OK, I understand now, thanks. Ben. -- Ben Hutchings The world is coming to an end. Please log off. signature.asc Description: This is a digitally signed message part
Bug#916696: initramfs-tools: search for nonexistent resume device
On Sun, 2019-02-10 at 06:31 +0100, Trek wrote: > On Wed, 06 Feb 2019 21:21:57 + > Ben Hutchings wrote: > > > The RESUME variable doesn't have to be set in any particular file. > > Please check with: > > > > grep -rw RESUME /etc/initramfs-tools/initramfs.conf \ > > /etc/initramfs-tools/conf.d \ > > /usr/share/initramfs-tools/conf.d/ > > it's empty > > > > If it's definitely not set, then please: > > > > 1. Upgrade to initramfs-tools version 0.133 (I just uploaded this so > >you will have to wait a few hours for it to be available) > > 2. Run "update-initramfs -u -v >initramfs.log 2>&1" > > 3. Look in initramfs.log for "Calling hook resume" and send the > >messages after that > > thanks for your help, now I've managed to debug and fix the resume hook: > when all the swaps are ephemeral, it finishes the for-loop, but the > last if-construct doesn't check the ephemeral variable > > I include a patch, tested with and without an ephemeral swap: > - the second block (-79,9 +83,10) is the actual fix If you would actually send me the log messages I might understand this fix, but as it is I don't. I do need to understand it before I will apply it. Ben. > - the first one (-63,9 +63,13) is only to be safer, as it > checks /dev/random too and it stops searching /etc/crypttab when the > device is found > > ciao! -- Ben Hutchings The world is coming to an end. Please log off. signature.asc Description: This is a digitally signed message part
Bug#921951: debian-installer: Remove beep-udeb
On Sun, 2019-02-10 at 14:42 +0100, Hilko Bengen wrote: > Package: debian-installer > Severity: normal > > Dear Maintainers, > > as of now the beep package is still going to be shipped with buster > despite having CVE-worthy bugs with no maintainer activity in several > months. The only apparent reason for this is that it is included by d-i > on one specific armel[1] flavor -- I am not even sure if it would > actually be needed (or even used) there. > > Please consider removing the package from the installer. Thank you. > > Cheers, > -Hilko > > [1] > debian-installer-20190118/build/pkg-lists/netboot/network-console/armel/ixp4xx.cfg This configuration is no longer used as we already dropped support for this platform in stretch. Please go ahead with removal of beep. Ben. -- Ben Hutchings The world is coming to an end. Please log off. signature.asc Description: This is a digitally signed message part
Bug#866122: slapd-mtread crash on ppc64{,el} in stretch/sid
On Tue, 3 Jul 2018 18:51:49 -0700 Ryan Tandy wrote: > Control: found -1 4.17.3-1 > > Hi, > > On Mon, Jul 02, 2018 at 08:42:45PM -0700, Ryan Tandy wrote: > >However it looks like it might be resolved with the kernel in > >unstable. I will run some more iterations and let you know. > > The issue still reproduces with stretch userland and the current > unstable kernel. > > It cannot be reproduced with buster's glibc because lock elision was > disabled in #878071, citing this issue. This bug has been open for over 18 months with no sign of a solution, which is really not acceptable for a release architecture. I propose to disable CONFIG_PPC_TRANSACTIONAL_MEMORY in both stretch and unstable, until a fix is available for TM. Ben. -- Ben Hutchings The world is coming to an end. Please log off. signature.asc Description: This is a digitally signed message part
Bug#910069: linux-image-4.18.0-1-amd64: NVME quirk needed for Intel 760p + Thinkpad T480
Control: tag -1 moreinfo On Tue, 02 Oct 2018 05:44:23 -0400 Chris Chiappa wrote: [...] > # nvme id-ctrl /dev/nvme0 > NVME Identify Controller: > vid : 0x8086 > ssvid : 0x8086 > sn: BTHH82260487512D > mn: INTEL SSDPEKKW512G8 > fr: 001C [...] According to the release notes for the Intel SSD Firmware Update Tool <https://downloadmirror.intel.com/28174/eng/Intel_SSD_Firmware_Update_Tool_3_0_6_Release_Notes-328292-029US.pdf> there is a firmware update (version 004C) and the description suggests it may address this problem. Please upgrade the firmware (but make sure you have a backup of the drive) and check whether that fixes the problem. Ben. -- Ben Hutchings The world is coming to an end. Please log off. signature.asc Description: This is a digitally signed message part
Bug#921542: tc qdisc kernel crash
Control: tag -1 confirmed upstream Control: found -1 4.20-1~exp1 Adrian (cc'd) reported (https://bugs.debian.org/921542) that a script using tc could trigger a kernel crash. I've simplified the script he provided down to: --- BEGIN --- #!/bin/sh -ex modprobe ifb while true; do tc qdisc add dev ifb0 root handle 2:0 prio bands 5 tc qdisc add dev ifb0 parent 2:5 sfq tc filter add dev ifb0 parent 2:0 protocol ip prio 5 handle 0 tcindex mask 0 classid 2:5 pass_on tc qdisc del dev ifb0 root || true done --- END --- The crash is still reproducible in 4.20 and 5.0-rc5. KASan shows a use-after-free: + modprobe ifb + true + tc qdisc add dev ifb0 root handle 2:0 prio bands 5 + tc qdisc add dev ifb0 parent 2:5 sfq + tc filter add dev ifb0 parent 2:0 protocol ip prio 5 handle 0 tcindex mask 0 classid 2:5 pass_on + tc qdisc del dev ifb0 root + true + tc qdisc add dev ifb0 root handle 2:0 prio bands 5 [ 63.926983] == [ 63.929429] BUG: KASAN: use-after-free in worker_thread+0x327/0x5b0 [ 63.931489] Read of size 8 at addr 88804fd22130 by task kworker/u8:1/32 [ 63.933766] [ 63.934397] CPU: 0 PID: 32 Comm: kworker/u8:1 Not tainted 5.0.0-rc5 #3 [ 63.936629] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 [ 63.939537] Workqueue:(null) (events_unbound) [ 63.942039] Call Trace: [ 63.943187] dump_stack+0x71/0xa0 [ 63.944386] ? worker_thread+0x327/0x5b0 [ 63.945881] print_address_description+0x65/0x22e [ 63.947980] ? worker_thread+0x327/0x5b0 [ 63.949588] ? worker_thread+0x327/0x5b0 [ 63.951254] kasan_report.cold.3+0x1a/0x40 [ 63.953036] ? worker_thread+0x327/0x5b0 [ 63.954692] worker_thread+0x327/0x5b0 [ 63.956236] ? flush_rcu_work+0x40/0x40 [ 63.957722] kthread+0x1ae/0x1d0 [ 63.959067] ? __kthread_parkme+0x90/0x90 [ 63.960451] ret_from_fork+0x35/0x40 [ 63.962020] [ 63.962817] Allocated by task 757: [ 63.964465] __kasan_kmalloc.constprop.13+0xc1/0xd0 [ 63.966670] tcindex_alloc_perfect_hash+0x37/0x150 [cls_tcindex] [ 63.969287] tcindex_set_parms+0xb38/0xd30 [cls_tcindex] [ 63.972539] tcindex_change+0x13d/0x1c2 [cls_tcindex] [ 63.974796] tc_new_tfilter+0x7ec/0xaf0 [ 63.976546] rtnetlink_rcv_msg+0x35c/0x490 [ 63.978302] netlink_rcv_skb+0xc6/0x1f0 [ 63.980050] netlink_unicast+0x309/0x3d0 [ 63.981990] netlink_sendmsg+0x37d/0x5e0 [ 63.983849] sock_sendmsg+0x6d/0x80 [ 63.985538] ___sys_sendmsg+0x46a/0x4e0 [ 63.987328] __sys_sendmsg+0xd3/0x160 [ 63.988974] do_syscall_64+0x73/0x140 [ 63.990616] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 63.992538] [ 63.993430] Freed by task 9: [ 63.994660] __kasan_slab_free+0x125/0x170 [ 63.996239] kfree+0x90/0x1d0 [ 63.997496] __tcindex_destroy+0x1f/0x40 [cls_tcindex] [ 63.999316] rcu_process_callbacks+0x3cb/0x650 [ 64.000889] __do_softirq+0x115/0x3b4 [ 64.003254] [ 64.004138] The buggy address belongs to the object at 88804fd22100 [ 64.004138] which belongs to the cache kmalloc-8k of size 8192 [ 64.009001] The buggy address is located 48 bytes inside of [ 64.009001] 8192-byte region [88804fd22100, 88804fd24100) [ 64.013752] The buggy address belongs to the page: [ 64.015906] page:ea00013f4800 count:1 mapcount:0 mapping:888051002700 index:0x0 compound_mapcount: 0 [ 64.020237] flags: 0xc10200(slab|head) [ 64.022176] raw: 00c10200 dead0100 dead0200 888051002700 [ 64.025247] raw: 80030003 0001 [ 64.028847] page dumped because: kasan: bad access detected [ 64.031367] [ 64.033285] Memory state around the buggy address: [ 64.035276] 88804fd22000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 64.037741] 88804fd22080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 64.040138] >88804fd22100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 64.042717] ^ [ 64.044794] 88804fd22180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 64.047431] 88804fd22200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 64.049993] == Ben. -- Ben Hutchings The world is coming to an end. Please log off. signature.asc Description: This is a digitally signed message part
Bug#916898: linux-image-4.18.0-3-amd64: kernel oops and gdm fails to start
Control: forcemerge 914495 -1 On Wed, 19 Dec 2018 20:35:14 -0600 "Brent S. Elmer" wrote: > Package: src:linux > Version: 4.18.20-2 > Severity: critical > Justification: breaks the whole system > > I upgraded to linux-image-4.18.0-3-amd64 and gdm fails to start. I can get > into the system remotely and get to the journal. There is a kernel oops in > the > journal. [...] This looks like a bug that was fixed in 4.19. Let us know if you're still seeing the problem. Ben. -- Ben Hutchings The world is coming to an end. Please log off. signature.asc Description: This is a digitally signed message part
Bug#883413: src:linux: Still reproducible with linux-image-4.15.0-rc8-amd64
Control: severity -1 important Control: tag -1 moreinfo On Mon, 29 Jan 2018 15:05:00 + Chris Boot wrote: > Package: src:linux > Followup-For: Bug #883413 > > Hi Ben, > > Unfortunately I can still reproduce this problem on 4.15-rc8 from > experimental. > > The cmdline for this boot was: > > BOOT_IMAGE=/boot/vmlinuz-4.15.0-rc8-amd64 > root=/dev/mapper/vg_tarquin-rootfs ro intel_iommu=on vsyscall=emulate > scsi_mod.use_blk_mq=Y dm_mod.use_blk_mq=Y intel_pstate=passive > i915.disable_display=Y i915.enable_gvt=Y apparmor=0 > systemd.unified_cgroup_hierarchy=1 console=ttyS1,115200n8 console=tty0 > > This triggers with DefaultMemoryAccounting=yes enabled in > /etc/systemd/system.conf, and NUT seems to regularly be involved in the > crash on my system. Sadly the systemd unit is very simple indeed, and > because my UPS is network-connected I'm not even doing dodgy things like > USB from within NUT. > > Quite how the kernel thinks that nut-server.service is using 16 ZiB of > memory is beyond me; presumably this is a slightly negative 64-bit int > bring cast unsigned. The following also feels like a smoking gun: > > [ 2982.158622] percpu ref (css_release) <= 0 (-197) after switching to atomic [...] Sorry for leaving this unanswered so long. Are you still seeing this? I found some apparently related reports on the Red Hat Bugzilla but not on anything newer than 4.17. Ben. -- Ben Hutchings The world is coming to an end. Please log off. signature.asc Description: This is a digitally signed message part
Bug#898743: breaks when #included after
Control: reassign -1 libc6-dev Control: severity -1 normal On Tue, 15 May 2018 16:57:57 +0200 Helmut Grohne wrote: > Package: linux-libc-dev,libc6-dev > Severity: serious > Justification: makes systemd ftbfs > User: helm...@debian.org > Usertags: rebootstrap > Control: affects -1 + src:systemd libmount-dev > > systemd FTBFS here, because compiling load-fragment.c fails. I spent a while > minimizing that file and it boils down to: > > $ cat test.c > #include > #include > $ gcc -c test.c > In file included from test.c:1:0: > /usr/include/x86_64-linux-gnu/sys/mount.h:35:3: error: expected identifier > before numeric constant >MS_RDONLY = 1, /* Mount read-only. */ >^ > $ > > linux/fs.h #defines MS_RDONLY and then sys/mount.h tries to create an > enum containing MS_RDONLY. That's a problem. [...] has defined MS_RDONLY as a macro since before version 1.0, so this is a wontfix on the kernel side. was already defining MS_RDONLY as both enumerator and macro in jessie, so this doesn't seem to be a regression. Downgrading and reassigning to just libc6-dev, but I fully expect this to be wontfix on that side as well. Ben. -- Ben Hutchings The world is coming to an end. Please log off. signature.asc Description: This is a digitally signed message part
Bug#895131: (linux-perf-4.16: Add libopencsd support to perf)
On Fri, 8 Feb 2019 04:04:13 + Wookey wrote: [...] > Hmm. Looks like there has been a revamp of the templates for > tools. Now the extra build-dep needs to go in > debian/templates/control.tools-versioned.in now. For some reason all > these build-deps seem to have lost their build-profile info (except > for asciidoc). I don't understand why that would be so. We don't want those > extra build-deps in stage1? [...] The single list of Build-Depends was getting hard to manage. So I changed debian/bin/gencontrol.py to extract Build-Depends from each binary package template, qualify them with the architectures and build- profiles specified for that binary package, and append them to Build- Depends-Arch or -Indep as appropriate. So in a binary package template you only need to specify architecture or profile qualifications for a build-dependency if the binary package should sometimes be built without it. Ben. -- Ben Hutchings Logic doesn't apply to the real world. - Marvin Minsky signature.asc Description: This is a digitally signed message part
Bug#916696: initramfs-tools: search for nonexistent resume device
Control: tag -1 moreinfo On Mon, 17 Dec 2018 15:48:12 +0100 Trek wrote: > Package: initramfs-tools > Version: 0.132 > > at boot, initramfs blocks searching for a resume device > > Begin: Waiting for suspend/resume device ... > Begin: Running /scripts/local-block ... done. > > > I'm using sysvinit and two encrypted swap partitions > > the file /etc/initramfs-tools/conf.d/resume does not exist > > the contents of /etc/crypttab are: > > sda5_crypt /dev/disk/by-id/ata-XX-XX_-part5 /dev/urandom > cipher=aes-xts-plain64,size=256,swap > sdb5_crypt /dev/disk/by-id/ata-XX-XX_-part5 /dev/urandom > cipher=aes-xts-plain64,size=256,swap > > > if I disable swap (swapoff -a) and rebuild the initrd, the problem > disappears > > > can I do something to further investigate the issue? The RESUME variable doesn't have to be set in any particular file. Please check with: grep -rw RESUME /etc/initramfs-tools/initramfs.conf \ /etc/initramfs-tools/conf.d \ /usr/share/initramfs-tools/conf.d/ If it's definitely not set, then please: 1. Upgrade to initramfs-tools version 0.133 (I just uploaded this so you will have to wait a few hours for it to be available) 2. Run "update-initramfs -u -v >initramfs.log 2>&1" 3. Look in initramfs.log for "Calling hook resume" and send the messages after that Ben. -- Ben Hutchings Man invented language to satisfy his deep need to complain. - Lily Tomlin signature.asc Description: This is a digitally signed message part
Bug#921518: flash-kernel: [PATCHv2] Adding-definition-of-Raspberry-Pi-Family
On Wed, 2019-02-06 at 13:45 +0100, Alexandre GRIVEAUX wrote: > Package: flash-kernel > Version: 3.79 > Severity: normal > Tags: patch > > Adding definition according to: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts?h=v4.20 > https://packages.debian.org/stretch/armhf/linux-image-4.9.0-8-armmp/filelist > https://packages.debian.org/stretch/arm64/linux-image-4.9.0-8-arm64/filelist > > With adding correction of Raspberry pi 1 to use ARMEL flavour from feedback. [...] "armel" is the name of the Debian architecture that can run on the Pi 0/1, not the name of a kernel flavour. We do not yet have any kernel flavour for these yet, and it is unlikely to be "armel". We tend to use the architecture name as a kernel flavour name only if it can support most hardware for that architecture. Ben. -- Ben Hutchings Man invented language to satisfy his deep need to complain. - Lily Tomlin signature.asc Description: This is a digitally signed message part
Bug#887159: initramfs-tools can use busybox as complete replacement for klibc
Control: block -1 with 921556 Currently an initramfs built with both busybox and klibc-utils installed has these executables in /bin from klibc-utils: chroot losetup pivot_root run-init fstype minips poweroff haltnfsmountreboot ipconfignukeresume Several of these are already redundant with the busybox versions installed in /sbin: chroot losetup poweroff haltpivot_r oot reboot The next upload of klibc will stop installing these commands when they are redundant. As Denys said, busybox 1.28.0 added replacements for some commands which we can enable when we update the busybox package: ipconfig [CONFIG_IPCONFIG] nuke [CONFIG_NUKE] resume[CONFIG_RESUME] run-init [CONFIG_RUN_INIT] I opened bug #921540 for the new upstream version and bug #921556 for the configuration change. That still leaves these without a drop-in replacement in busybox: fstypemight be replaceable with blkid minipsnot needed by initramfs-tools, but used by live-boot because busybox ps does not support "h" or "-C" options nfsmount should be replaceable with mount Ben. -- Ben Hutchings Man invented language to satisfy his deep need to complain. - Lily Tomlin signature.asc Description: This is a digitally signed message part
Bug#921556: busybox: Enable more applets to support initramfs-tools
Package: busybox Version: 1:1.27.2-3 Severity: wishlist Once we have busybox 1.28.0, we could enable these extra applets on Linux: ipconfig [CONFIG_IPCONFIG] nuke [CONFIG_NUKE] resume[CONFIG_RESUME] run-init [CONFIG_RUN_INIT] Ben. -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages busybox depends on: ii libc6 2.28-5 busybox recommends no packages. busybox suggests no packages. -- no debconf information
Bug#921540: busybox: New upstream release (1.28.0)
Control: retitle -1 busybox: New upstream release (1.30.0) On Wed, 2019-02-06 at 16:27 +, Ben Hutchings wrote: > Package: busybox > Version: 1:1.27.2-3 > Severity: wishlist > > busybox version 1.28.0 was released in August 2017 and we should > rebase on it. In fact the latest upstream version is 1.30.0. Ben. -- Ben Hutchings Man invented language to satisfy his deep need to complain. - Lily Tomlin signature.asc Description: This is a digitally signed message part
Bug#921540: busybox: New upstream release (1.28.0)
Package: busybox Version: 1:1.27.2-3 Severity: wishlist busybox version 1.28.0 was released in August 2017 and we should rebase on it. Ben. -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages busybox depends on: ii libc6 2.28-5 busybox recommends no packages. busybox suggests no packages. -- no debconf information
Bug#921402: plymouth hide-message does not work
Package: plymouth Version: 0.9.4-1 Severity: normal Tags: upstream "plymouth hide-message --text=" has no effect when using a framebuffer. I assume it has no effect in text mode either. Ben. -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages plymouth depends on: ii init-system-helpers 1.56+nmu1 ii initramfs-tools 0.133~1.gbp35238c ii libc62.28-5 ii libdrm2 2.4.97-1 ii libplymouth4 0.9.4-1 ii lsb-base 10.2018112800 ii systemd 240-4 ii udev 240-4 plymouth recommends no packages. Versions of packages plymouth suggests: ii desktop-base 9.0.7 ii plymouth-themes 0.9.4-1 -- Configuration Files: /etc/plymouth/plymouthd.conf changed [not included] -- no debconf information
Bug#657707: [initramfs-tools] modules for initrd are not stripped
On Sat, 28 Jan 2012 08:34:31 +0100 =?utf-8?q?Micha=C5=82_Miros=C5=82aw?= wrote: > Package: initramfs-tools > Version: 0.99 > Severity: normal > > --- Please enter the report below this line. --- > > Please add an option (possibly defaulted to on) to strip kernel modules and > binaries put in initrd. When using kernel with debugging enables the > unstripped modules are available in /lib/modules. Unneeded copy of the > symbols > in initrd image take over 80% of its size. [...] We must not do this by default because stripping will destroy module signatures. I'm open to adding an option but won't work on it myself. Ben. -- 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
Bug#909643: closed by Ben Hutchings (Re: doing a dist-upgrade from debian7 to debian8 ended with a non bootable system)
On Mon, 2019-02-04 at 10:43 +0900, Stephane Tranchemer wrote: > Hi, > You are right Ben, this was the culprit. > > The bottom line is, in a previous version of the debian distribution the > busybox package was called "busybox-cvs-static". > > But at a time it just gone to "busybox-static", so when doing the normal > procedure of > apt-update > apt-upgrade > apt-distupgrade > > it is not replaced by the newer version... Yes, and it obviously should have been. > Quite a nasty pitfall. > > Thanks for your time. It appears that busybox-cvs was only uploaded once and only included in the Debian 3.1 "sarge" release. It was then obsoleted by newer versions of busybox, but that didn't build the transitional packages needed to cause an automatic upgrade. But I think it is now much to late to do anything about this. Ben. -- 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
Bug#894294: Comment in the source of unmkinitramfs is ambiguous
On Wed, 28 Mar 2018 21:18:54 +0900 Osamu Aoki wrote: > Source: initramfs-tools > Version: 0.130 > Severity: wishlist > > The line 56-59 of unmkinitramfs goes: > > # There may be a prepended uncompressed archive. cpio > # won't tell us the true size of this so we have to > # parse the headers and padding ourselves. This is > # very roughly based on linux/lib/earlycpio.c > > The claim "cpio won't tell us the true size of this ..." doesn't have > any explicit reference to substantiate its claim while my uneducated > simple use of cpio telling me the true file size without the tailing > garbage ;-) > > For example: > > $ cpio -i -t /dev/null > 48 blocks > > So the uncompressed cpio file size is 512*48 BYTES. With some simple > experimentation with cpio, I realize cpio always create file size in > multiple of 512 bytes and it treat 512 bytes as a block. I can extract > tailing basic initrd image file as subinitrd.img with: > > $ dd if=/initrd.img of=subinitrd.img bs=512 skip=48 > > At least on my recent Debian system, this subinitrd.img is a nicely > extracted gzipped cpio archive. [...] This code started life in bug #717805 and you can see there that various people found different behaviour. Ben. -- 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
Bug#917524: initramfs-tools: Upgrade from initramfs-tools package fails
Control: tag -1 moreinfo On Sat, 29 Dec 2018 03:33:54 +0100 =?UTF-8?B?SsO8cmdlbiBHw7ZyaWNrZQ==?= wrote: > Hello Ben, > > I already installed udev 240-2, but the bug in the initramfs-tools package > still exists. > This is not surprising, because udev was installed a few days ago without any > errors. > Only by installing the package "initramfs-tools" (version: 0.132: all) the > installation error occurred. > > Can you please check again where exactly the error is? > Thanks a lot! [...] Please check again with udev 240-4 as the bug I am thinking of was only partly fixed in 240-2. Ben. -- Ben Hutchings Horngren's Observation: Among economists, the real world is often a special case. signature.asc Description: This is a digitally signed message part
Bug#918818: Additional info
On Fri, 11 Jan 2019 15:20:04 +0600 Tech Knowledge < discover...@gmail.com> wrote: > Just added the information as requested. This might be the same as bug #917607 which was fixed in udev 240-4. Can you check whether upgrading udev fixes this? Ben. -- Ben Hutchings Horngren's Observation: Among economists, the real world is often a special case. signature.asc Description: This is a digitally signed message part
Bug#920664: unable to decrypt drive from grub after alpha4 setup)
On Sat, 2019-02-02 at 22:56 -0800, Ross Boylan wrote: > I am able to decrypt the partition outside of a VM without the rescue > "CD". Since I can also decrypt using the installer CD as rescue, this > means the failure is specific to booting via grub and initrd. > > This seems to indicate the installer created the encrypted partition > properly but the boot environment it created is either handling the > pass-phrase incorrectly (e.g., include \n) or is missing some other part of > the machinery necessary. The most obvious candidate is from the error > message > > Check that kernel supports aes-xts-plain64 cipher > > I don't know how to check that, but looking in config-4.19.0-1-amd64 on the > boot partition, I see some partial matches that might be relevant: > CONFIG_CRYPTO_AES=y > # CONFIG_CRYPTO_AES_TI is not set > CONFIG_CRYPTO_AES_X86_64=m > CONFIG_CRYPTO_AES_NI_INTEL=m > > CONFIG_CRYPTO_XTS=m > > I don't see anything that looks like plain. You can't easily map crypto modes to config options like this. But if you are using the standard kernel, I can assure that it supports full disk encryption. > The buster system created by the installer includes aesni-intel.ko, but the > initrd does not. cryptsetup-initramfs should have been installed, and it would add the crypto modules (and other necessary files) to the initramfs. Is it installed? Ben. -- Ben Hutchings Horngren's Observation: Among economists, the real world is often a special case. signature.asc Description: This is a digitally signed message part
Bug#921114: no display on GL applications
On Sat, 2019-02-02 at 13:23 +0100, at46 wrote: > Hi Jean-Dominique, > > are you mixing stable and testing? As far as I can see > Firmware-nonfree/20190114-1 isn't available for stable/stretch. Maybe > you also need to use a newer kernel. The Debian changelog > (https://tracker.debian.org/media/packages/f/firmware-nonfree/changelog-20190114-1) > > mention "Update to linux-support 4.19.0-1". The binary packages built from firmware-nonfree intentionally do not have any relations to kernel versions. Whenever there is an ABI- incompatible change in firmware, the firmware should be given a new filename. It is not an error to use a new firmware package with an old kernel. Ben. -- Ben Hutchings Knowledge is power. France is bacon. signature.asc Description: This is a digitally signed message part
Bug#791609: Error on restoring ledger buffer from desktop file
On Fri, 2019-02-01 at 02:59 +, Ben Hutchings wrote: [...] > I've just tested using emacs-gtk version 1:26.1+1-3. ...and ledger version 3.1.2~pre1+g3a00e1c+dfsg1-5+b3. > I can't reproduce > the bug with either a freshly created desktop file or with the desktop > entry quoted in my original report. Ben. -- Ben Hutchings Life is what happens to you while you're busy making other plans. - John Lennon signature.asc Description: This is a digitally signed message part
Bug#791609: Error on restoring ledger buffer from desktop file
On Sat, 2019-01-26 at 13:31 -0300, Martin Michlmayr wrote: > * David Bremner [2015-07-10 20:58]: > > > Thanks for the report. Here is how I tried, and failed, to > > > reproduce this: > > > > > > emacs -q foo.lgr My bug report relates to ledger-mode, but this command sequence doesn't activate ledger-mode... > > > M-x desktop-save > > > C-x C-c > > > emacs -q > > > M-x desktop-read > > > > > > I'm using emacs24.4 still, so maybe this is 24.5 specific. > > > > > > Cheers, > > > > I tried the same recipe with 24.5, but still did not reproduce the > > failure. > > Ben, it seems like David cannot reproduce your issue. Can you check > again? I've just tested using emacs-gtk version 1:26.1+1-3. I can't reproduce the bug with either a freshly created desktop file or with the desktop entry quoted in my original report. Ben. -- Ben Hutchings Life is what happens to you while you're busy making other plans. - John Lennon signature.asc Description: This is a digitally signed message part
Bug#917864: closed by Gianfranco Costamagna (Re: Fails to build for non-current kernel version)
On Wed, 2019-01-30 at 16:03 +0100, Gianfranco Costamagna wrote: > Hello Ben, > > The bug is in the makefile you provide to module-assistant. > > I'm sorry but I have no clue about how to fix it... > Can you please help me in fixing the issue? In debian/virtualbox-guest-source.files/rules/, you call the kernel build system like this: $(MAKE) -C $(KSRC) M=$(CURDIR) But in the clean rule, you call the upstream Makefiles directly, and they try to use the kernel build scripts for the running kernel. You should probably use something like: $(MAKE) -C $(KSRC) M=$(CURDIR) clean Ben. -- Ben Hutchings The two most common things in the universe are hydrogen and stupidity. signature.asc Description: This is a digitally signed message part
Bug#920919: ITP: xoreos-tools -- collection of tools around BioWare's Aurora engine games
On Wed, 2019-01-30 at 16:22 +0100, Eike wrote: [...] > I'm unsure about the section this should go in. While it is > all free software, in the greater scheme of things the tools > only make sense when used with BioWare's non-free data. > So we might put it into contrib. I think "contrib" is right. > The section itself is also not clear to me. It's all about games, > lintian tells me though that packages in the section games must > provide binaries under /usr/games/... I think reverse-engineering would fall under "devel". Ben. -- Ben Hutchings The two most common things in the universe are hydrogen and stupidity. signature.asc Description: This is a digitally signed message part
Bug#920740: Should crda be shipped in buster?
Control: severity -1 wishlist Control: tag -1 - buster sid On Mon, 2019-01-28 at 18:49 +0200, Adrian Bunk wrote: > Package: crda > Severity: serious > Tags: buster sid > > Since commit 007f6c5e6eb45 the kernel supports regdb loading > without crda. > > crda could be removed from buster after: > - supporting kernel direct loading in wireless-regdb (#892229) > - replace the Recommends: crda in iw and network-manager with > versioned recommends on wireless-regdb > - remove the Suggests from wireless-regdb > > wireless-regdb in bullseye could then drop the regdb for crda > and add a Breaks: crda. This is all wrong, we don't enable direct loading yet. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus signature.asc Description: This is a digitally signed message part
Bug#920547: Crashes every few hours
Control: tag -1 moreinfo On Sat, 26 Jan 2019 20:03:49 + Toni wrote: > Package: src:linux > Version: 4.19.16-1 > Severity: critical > File: linux-image-4.19.0-2-amd64 Is this a new problem with version 4.19.16-1? Or did it happen with earlier versions as well? > my laptop lasts a few hours at most until becoming unresponsive, hot, > and refuses to do normal things. Eg. trying to create this bug report > and using sudo to read the kernel logs after about one hour of total > uptime, with two suspend/resume cycles in between, made the system > crash. "Crash" means that, in such a situation, I can only press the > power button until the system is completely off, but after that, I am > forced to immediately turn the system back on, so that the fans can do > their work, because otherwise, the CPU overheats. Pressing > Ctrl-Alt-Delete has no effect. > > Justification for "grave": I've experienced data loss in such > situations, and of course, having the entire system going down, with > potential hardware damage (sans human intervention) is probably as bad > as it can be. When you say "data loss", are you talking about data in memory or corruption of files that were saved and sync'd to disk? On x86 laptops thermal management is (by default) done by the system firmware (BIOS and management engine code). If you didn't override that, and yet the CPU overheats, this is the manufacturer's fault. Ben. > I've attached the dmesg from boot and some kernel logs for your perusal, > cleansed from private data. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus signature.asc Description: This is a digitally signed message part
Bug#920498: [Fwd: Re: Bug#920498: os-prober generates jessy entry with bad UUID]
Forwarded Message From: Joachim Schmidt To: Ben Hutchings Subject: Re: Bug#920498: os-prober generates jessy entry with bad UUID Date: Sat, 26 Jan 2019 18:42:29 +0100 Message-Id: <2f9387ca-3fa6-63ae-9353-2d18be286...@arcor.de> Hi Ben, > In the jessie installation, what does /etc/fstab say is the root > device? here it is: # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # proc/proc procdefaults0 0 # / was on /dev/sda5 during installation #UUID=d4c01c5a-d679-4725-bde1-bd56bc592d0e / ext4 errors=remount-ro 0 1 UUID=28cc3074-3d74-4a0f-87b6-e0898d2a1e15 /ext4errors=remount-ro 0 1 #/dev/sdb6 / ext3errors=remount-ro 0 1 # /home was on /dev/sda7 during installation UUID=105c5810-518e-4a69-a6f4-bba8a978a327/home ext4defaults 0 2 # swap was on /dev/sda6 during installation #UUID=519b5df4-8fa9-46e9-8fab-2470193bbbd1 none swapsw00 LABEL=swap noneswapsw 0 0 # #UUID=F2B48F68B48F2E63 /media/System ntfs-3g defaults,locale=de_DE.UTF-8,umask=000 0 0 LABEL=System/media/System ntfs-3g defaults,locale=de_DE.UTF-8,umask=000 0 0 #UUID=58E098AFE09894BA /media/Datenntfs-3g defaults,locale=de_DE.UTF-8 0 0 LABEL=Daten /media/Daten ntfs-3g defaults,locale=de_DE.UTF-8 0 0 LABEL=arch_home /media/arch_homeext4defaults0 2 #UUID=75d3cc98-3d8b-4030-86df-d5552f055fa7 /media/w-test ext4 defaults0 2 #/dev/sdc0 /media/cdrom0 udf,iso9660 user,noauto 0 0 I saved the jessie partition to update to stretch and after that I changed the UUID of jessie partition to a new one. os-prober still uses this old no more existing UUID. Joachim -- Ben Hutchings I'm not a reverse psychological virus. Please don't copy me into your signature.
Bug#920498: os-prober generates jessy entry with bad UUID
On Sat, 2019-01-26 at 11:21 +0100, Joachim Schmidt wrote:
> Package: os-prober
> Version: 1.76~deb9u1
> Severity: important
>
> Dear Maintainer,
>
> os-prober generates an incorrect entry for old debian (jessie) partition.
> UUID 28cc... is OK
> UUID d4c0... is bad - with blkid there is no such UUID on my system
>
> menuentry 'Debian GNU/Linux 8 (jessie) (auf /dev/sdb4)' --class debian --class
> gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-
> simple-28cc3074-3d74-4a0f-87b6-e0898d2a1e15' {
> insmod part_gpt
> insmod ext2
> set root='hd1,gpt4'
> if [ x$feature_platform_search_hint = xy ]; then
> search --no-floppy --fs-uuid --set=root --hint-bios=hd1,gpt4 --hint-
> efi=hd1,gpt4 --hint-baremetal=ahci1,gpt4 --hint='hd1,gpt4'
> 28cc3074-3d74-4a0f-87b6-e0898d2a1e15
> else
> search --no-floppy --fs-uuid --set=root
> 28cc3074-3d74-4a0f-87b6-e0898d2a1e15
> fi
> linux /boot/vmlinuz-3.16.0-4-amd64
> root=UUID=d4c01c5a-d679-4725-bde1-bd56bc592d0e ro quiet
> initrd /boot/initrd.img-3.16.0-4-amd64
> }
>
> I run update-grub some times with always the same result.
> If I change the UUID in the linux line to 28cc.. then I can boot.
[...]
In the jessie installation, what does /etc/fstab say is the root
device?
Ben.
--
Ben Hutchings
I'm not a reverse psychological virus.
Please don't copy me into your signature.
signature.asc
Description: This is a digitally signed message part
Bug#920437: ITP: displaylink -- Proprietary driver for DisplayLink devices
On Fri, 2019-01-25 at 14:21 -0500, Hanno Stock wrote: > Am Fr, 25. Jan 2019, um 17:03, schrieb Ben Hutchings: > > Please consider choosing a more specific package name. Since we > > have > > free drivers for some DisplayLink devices, we should encourage > > users to > > use those where possible. > > Ok, I see. What about displaylink-nonfree ? One could also append to > the long description a hint which package to > use for devices supported by the free drivers. That seems sensible. Ben. -- Ben Hutchings I'm not a reverse psychological virus. Please don't copy me into your signature. signature.asc Description: This is a digitally signed message part
Bug#920437: ITP: displaylink -- Proprietary driver for DisplayLink devices
On Fri, 2019-01-25 at 14:22 +0100, Hanno Stock wrote: > Package: wnpp > Severity: wishlist > Owner: Hanno Stock > > * Package name: displaylink > Version : 4.4 > Upstream Author : DisplayLink (UK) Ltd. > * URL : https://www.displaylink.com/downloads > * License : proprietary > Programming Lang: binary > Description : Proprietary driver for DisplayLink devices > > This is the proprietary binary component of the driver for DisplayLink > devices. It communicates via libusb with the DisplayLink device and uses > the opensource evdi kernel module for presenting a virtual graphics > device to the system. [...] Please consider choosing a more specific package name. Since we have free drivers for some DisplayLink devices, we should encourage users to use those where possible. Ben. -- Ben Hutchings Always try to do things in chronological order; it's less confusing that way. signature.asc Description: This is a digitally signed message part
Bug#900918: debian-installer: Please make the generated images reproducible
On Tue, 2019-01-22 at 10:53 +0100, Philipp Kern wrote: > On 1/22/2019 7:08 AM, Cyril Brulebois wrote: > > > Alternatively, we could make pigz a strict build requirement but > > > that sounds a little antisocial. > > Right. > In what way do you consider this antisocial and what's speaking > against > doing that? If it's about CPU time, then maybe it should obey the > parallelization setting of the build process. [...] The general way to communicate this is by wrapping the build in "taskset", and pigz will surely follow that. Ben. -- Ben Hutchings Power corrupts. Absolute power is kind of neat. - John Lehman signature.asc Description: This is a digitally signed message part
Bug#920034: linux-image-4.9.0-3-amd64: system freeze
Control: tag -1 moreinfo You are using a kernel version that over a year out of date. We will not investigate bugs in that version. You need to upgrade to the current version in Debian 9 "stretch", which is 4.9.110-3+deb9u6. If the problem is reproducible with the current version, you need to send us the kernel log including the first WARNING and/or BUG messages, not the last ones. Ben. -- Ben Hutchings Klipstein's 4th Law of Prototyping and Production: A fail-safe circuit will destroy others. signature.asc Description: This is a digitally signed message part
Bug#919652: ath10k - QCA6174 - Surface Go - missing board data - fix .bin included extracted form official .msi
Do not send firmware files to the bug tracking system, as this may be a copyright infringement. All additions to the firmware packages need to come with a clear license from the copyright holder that allows us to redistribute them. Ben. -- Ben Hutchings Klipstein's 4th Law of Prototyping and Production: A fail-safe circuit will destroy others. signature.asc Description: This is a digitally signed message part
Bug#920032: qemu-user uses wrong struct timeval on sparc
Package: qemu-user
Version: 1:3.1+dfsg-2
Severity: important
Tags: patch
On sparc (only) Linux defines timeval::tv_usec with type int, not
long. However qemu-user's definition of struct target_timeval uses
abi_long unconditionally. This results in the syscall translation
layer effectively multiplying tv_usec by 2**32. All sparc syscalls
passing non-zero values for this field fail with -EINVAL. The
following patch seems to fix this.
Ben.
--- a/linux-user/syscall_defs.h
+++ b/linux-user/syscall_defs.h
@@ -210,7 +210,11 @@ struct target_linger {
struct target_timeval {
abi_long tv_sec;
+#if defined (TARGET_SPARC)
+abi_int tv_usec;
+#else
abi_long tv_usec;
+#endif
};
struct target_timespec {
--- END ---
-- System Information:
Debian Release: buster/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500,
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages qemu-user depends on:
ii libc6 2.28-3
ii libcapstone3 3.0.5-3
ii libgcc1 1:8.2.0-13
ii libglib2.0-0 2.58.1-2
ii libstdc++68.2.0-13
ii zlib1g1:1.2.11.dfsg-1
Versions of packages qemu-user recommends:
ii qemu-user-static [qemu-user-binfmt] 1:3.1+dfsg-2
Versions of packages qemu-user suggests:
ii sudo 1.8.26-2
-- no debconf information
Bug#917864: closed by Gianfranco Costamagna (Re: Fails to build for non-current kernel version)
On Mon, 2019-01-21 at 07:55 +, Gianfranco Costamagna wrote: > Hello, so it didn't build correctly?do you have a build log? It was in my last message. > I'm failing to understand why this can't be a m-a bug...I'm not an > user of m-a myself, but I usually create a deb file and then dpkg -i > it. The bug is in the makefile you provide to module-assistant. Ben. -- Ben Hutchings Klipstein's 4th Law of Prototyping and Production: A fail-safe circuit will destroy others. signature.asc Description: This is a digitally signed message part
Bug#919855: s390x executables crash
Control: severity -1 grave On Sun, 2019-01-20 at 06:39 +, Ben Hutchings wrote: > Source: klibc > Version: 2.0.5-1 > Severity: serious > > While investigating some test failures on klibc upstream, I found that > the new Debian version crashes on s390x. It looks like this is due to > an address collision between the build ID in the shared library and > the code in the executables. The addition of build IDs is not (yet) > part of an upstream release. In fact all architectures except mips and x86 seem to be broken. Ben. -- Ben Hutchings You can't have everything. Where would you put it? signature.asc Description: This is a digitally signed message part
Bug#919921: qemu-user Linux ELF loader fails to handle pure BSS segments
Package: qemu-user
Version: 1:3.1+dfsg-2
Severity: normal
Tags: patch
I've been building and testing klibc across many architectures using
qemu-user, and I found that qemu-user fails to load a few programs on
a few architectures, reporting an EINVAL error code. Here's the
"readelf -l" output for one such program:
Elf file type is EXEC (Executable file)
Entry point 0x1100
There are 5 program headers, starting at offset 52
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
PHDR 0x34 0x1034 0x1034 0x000a0 0x000a0 R 0x4
INTERP 0xd4 0x10d4 0x10d4 0x0002a 0x0002a R 0x1
[Requesting program interpreter:
/lib/klibc-R7FVdnsTBUFpWPgCV6FR07b-mf8.so]
LOAD 0x00 0x1000 0x1000 0x002f8 0x002f8 R E 0x1
LOAD 0x01 0x1002 0x1002 0x0 0x08000 RW 0x1
GNU_STACK 0x00 0x 0x 0x0 0x0 RWE 0x10
Section to Segment mapping:
Segment Sections...
00
01 .interp
02 .interp .text .rodata .eh_frame
03 .bss
04
The unusual feature of this program, and all the others that failed,
is that there is a LOAD segment with a file-size of 0 (i.e. only BSS,
no initialised data). load_elf_image() will try to mmap() initialised
data for this section even though there is none and a length of 0 is
invalid.
The change that seems to fix this is to skip the mmap() in this case:
--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -2316,11 +2316,13 @@ static void load_elf_image(const char *i
vaddr_ps = TARGET_ELF_PAGESTART(vaddr);
vaddr_len = TARGET_ELF_PAGELENGTH(eppnt->p_filesz + vaddr_po);
-error = target_mmap(vaddr_ps, vaddr_len,
-elf_prot, MAP_PRIVATE | MAP_FIXED,
-image_fd, eppnt->p_offset - vaddr_po);
-if (error == -1) {
-goto exit_perror;
+if (vaddr_len != 0) {
+error = target_mmap(vaddr_ps, vaddr_len,
+elf_prot, MAP_PRIVATE | MAP_FIXED,
+image_fd, eppnt->p_offset - vaddr_po);
+if (error == -1) {
+goto exit_perror;
+}
}
vaddr_ef = vaddr + eppnt->p_filesz;
--- END ---
-- System Information:
Debian Release: buster/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500,
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages qemu-user depends on:
ii libc6 2.28-3
ii libcapstone3 3.0.5-3
ii libgcc1 1:8.2.0-13
ii libglib2.0-0 2.58.1-2
ii libstdc++68.2.0-13
ii zlib1g1:1.2.11.dfsg-1
Versions of packages qemu-user recommends:
ii qemu-user-static [qemu-user-binfmt] 1:3.1+dfsg-2
Versions of packages qemu-user suggests:
ii sudo 1.8.26-2
-- no debconf information
