Processed: tagging 964494
Processing commands for cont...@bugs.debian.org: > tags 964494 - moreinfo Bug #964494 [src:linux] File system corruption with ext3 + kernel-4.19.0-9-amd64 Removed tag(s) moreinfo. > thanks Stopping processing here. Please contact me if you need assistance. -- 964494: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964494 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#964499: Also see bug # 964500
I need to combine reports # 964499 & # 964500 as they are the same report. It seems that the report I filed first was delayed to the point that it showed up after the report I filed second. In any case, I still have the same problem & look forward to adding logs/information as anyone needs.
Bug#964494: File system corruption with ext3 + kernel-4.19.0-9-amd64
On 7/7/20 8:13 PM, Ben Hutchings wrote: Control: reassign -1 src:linux Control: tag -1 moreinfo On Tue, 2020-07-07 at 17:30 -0700, Sarah Newman wrote: Package: linux-signed-amd64 Version: 4.19.0-9-amd64 We've had two separate reports now of debian buster users running 4.19.0-9-amd64 who experienced serious file system corruption. Which version? (I.e. what does "uname -v" or "dpkg -s linux-image-4.19.0-9-amd64" say?) One is version: 4.19.118-2+deb10u1 - Both were using ext3 - Both are running Xen HVM, but I do not have reason to believe this to be related I have no reason to assume that this is unrelated to the hypervisor, so please report the version of Xen and whatever provides the back-end block driver. For the failures there are two different Xen hypervisor versions involved, the most recent being 4.9.4.45.g8d2a6880, with various patches for security issues applied. For Linux, the base version is 4.9.197. That's missing the xen blockback patches "xen/blkback: Avoid unmapping unmapped grant pages" and "xen-blkback: prevent premature module unload" but I don't think either of those are relevant here based on the descriptions for those patches. Nothing in the backend has been updated within the last few weeks. We believe that we have positively identified around 90 VMs running Debian Buster under the same backend versions, though we can't say for certain what kernel version or file system. I would guess at least 15 of them to be running ext4 + linux-image-4.19.0-8-amd64/4.19.98-1 or later. Some of our own test systems on the exact same kernel and hypervisor as the ones with failures are running: 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5+deb10u2 (2019-08-08) x86_64 GNU/Linux 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u1 (2019-09-20) x86_64 GNU/Linux They are running on top of ext4, with file system options: rw,relatime,nobarrier,errors=remount-ro,stripe=XX They are not heavily loaded, so if load is related then they would not exhibit issues. What we don't have personal knowledge of is 4.19.0-9-amd64, either with or without ext3. Normally we would gather more data before making an upstream report, but given the severity I thought best to do this sooner rather than later. - Both are on distinct physical hosts - Both had upgraded from an older non 4.19 kernel within the last two or three weeks From which older versions? In one case: "the upgrade was from Debian 9 Stretch and the system was up to date before running the upgrade." For the other, linux-image-4.9.0-11-amd64. One user had the error: ext4-fs error (device xvda1): ext4_validate_block_bitmap:393: comm cat: bg 812: block 26607617: invalid block bitmap aborting journal on device xvda1-8 ext4-fs error (device xvda1): ext4_journal_check_start:61: Detected abnormal journal ext4-fs (xvda1): Remounting filesystem read-only ext4-fs (xvda1): Remounting filesystem read-only ext4-fs error (device xvda1) in ext4_orphan_add:2863: Journal has aborted And were there any other error messages, e.g. relating to I/O errors, around the same time? How about in the back-end domain? For the backend, I do not see errors around that time or for several weeks previous on either physical host. One user, the one who gave us that report, reports no other errors. They say: After the live recovery fsck completed, I was able to use the partition and it reported clean, but it was clearly still pretty damaged. Grub2 for example wouldn't install, insisting unknown filesystem. I copied all the data to a new ext4 filesystem and was able to boot into that, but later saw there was pretty significant file corruption, including files that had not been modified in weeks or months. PHP files had random strings inserted in them. Debsums reported probably 10% of packages having invalid sumchecks in some of the installed files. And a few mysql database tables had corruption. I was able to restore the database and replace pretty much everything else from backups that had been made about 10 minutes prior to the filesystem corruption, and then re-installed every package. So far things seem to be working fine, since I've more or less replaced every file. The other user I am not sure about. The other gave us the output of tune2fs -l: [...] Looks like a fairly ordinary ext3 filesystem. It doesn't tell us anything about what went wrong. In general I would advise against continued use of the ext3 format. It should continue to be supported by the ext4 code, but it is inevitably going to be less well-tested than the ext4 format. So far as I can remember, it is easy to upgrade in-place. Thank you. One user has already converted to ext4 and the other plans to. --Sarah
Arch qualification for buster: call for DSA, Security, toolchain concerns
Hi, [Note, this e-mail may look familiar as it is mostly copied over from the buster call, not much has changed, AFAICT]. As part of the interim architecture qualification for bullseye, we request that DSA, the security team, Wanna build, and the toolchain maintainers review and update their list of known concerns for bullseye release architectures. Summary of the current concerns and issues: * DSA have announced a blocking issue for armel and armhf (see below) * Concerns from DSA about ppc64el and s390x have been carried over from (stretch and) buster. * Concerns from the GCC maintainers about i386, armel, armhf, mips64el and mipsel have been carried over from (stretch and) buster. If the issues and concerns from you or your team are not up to date, then please follow up to this email (keeping debian-release@l.d.o in CC to ensure we are notified). Whilst porters remain ultimately responsible for ensuring the architectures are ready for release, we do expect that you / your team are willing to assist with clarifications of the concerns and to apply patches/changes in a timely manner to resolve the concerns. List of blocking issues by architecture === The following is a summary from the current architecture qualification table. armel/armhf: * Undesirable to keep the hardware running beyond 2020. armhf VM support uncertain. (DSA) - Source: [DSA Sprint report] - I was under the impression that this issue has been resolved (at least for armhf) by now, but we like a fresh statement on this. [DSA Sprint report]: https://lists.debian.org/debian-project/2018/02/msg4.html List of concerns for architectures == The following is a summary from the current architecture qualification table. * Concern for ppc64el and s390x: we are dependent on sponsors for hardware. (Raised by DSA; carried over from stretch and buster) * Concern for armel and armhf: only secondary upstream support in GCC (Raised by the GCC maintainer; carried over from stretch and buster) * Concern for mips, mips64el, mipsel and ppc64el: no upstream support in GCC; Debian carries patches in binutils and GCC that haven't been integrated upstream even after a long time. (Raised by the GCC maintainer; carried over from stretch and buster) Architecture status === These are the architectures currently being built for bullseye: * Intel/AMD-based: amd64, i386 * ARM-based: arm64, armel, armhf * MIPS-based: mipsel, mips64el * Other: ppc64el, s390x If the blocking issues cannot be resolved, affected architectures are at risk of removal from testing before bullseye is frozen. We are currently unaware of any new architectures likely to be ready in time for inclusion in bullseye. On behalf of the release team, Paul Gevers signature.asc Description: OpenPGP digital signature
Bug#964153: Problem connecting wireless in new version Kernel
Hello, Same problem reported in 964480. I tested forcemerge as a non maintainer, as it turns out, it doesn't work, believe that this resource is destined for just for maintainers. If you are the maintainer and want to merge the reports, it would be interesting. I had no information about it and it was a test. Reference about this: https://www.debian.org/Bugs/server-control Bug report in Debian BTS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964480 Bugzilla Kernel bug report: https://bugzilla.kernel.org/show_bug.cgi?id=208251 Greetings, Leandro Cunha
Bug#964480: linux: ath9k (USB) broken in upstresm linux 5.7.3 after commit 6602f080cb
Hi, I had previously reported this problem. I tried to merge with 964153 the reports but apparently without success, believe that this function is only for maintainers of the package. Greetings, Leandro Cunha
Bug#964153: Problem connecting wireless in new version Kernel
forcemerge 964480 Em qua., 8 de jul. de 2020 às 10:11, Leandro Cunha < leandrocunha...@gmail.com> escreveu: > forcemerge #964480 > > Em sex., 3 de jul. de 2020 às 05:23, Leandro Cunha < > leandrocunha...@gmail.com> escreveu: > >> The second log is generated with cat /var/log/syslog | grep ath9k. >> >> --- >> Jul 3 03:17:59 debian-pc kernel: [ 20.741602] usb 1-1.4: ath9k_htc: >> Firmware ath9k_htc/htc_9271-1.4.0.fw requested >> Jul 3 03:17:59 debian-pc kernel: [ 20.741760] usbcore: registered new >> interface driver ath9k_htc >> Jul 3 03:17:59 debian-pc kernel: [ 20.895652] usb 1-1.4: firmware: >> direct-loading firmware ath9k_htc/htc_9271-1.4.0.fw >> Jul 3 03:17:59 debian-pc kernel: [ 20.925095] Modules linked in: >> uvcvideo(+) ath9k_htc ath9k_common videobuf2_vmalloc videobuf2_memops >> videobuf2_v4l2 ath9k_hw ath videobuf2_common mac80211 snd_hda_codec_realtek >> videodev cfg80211 snd_hda_codec_generic snd_hda_codec_hdmi ledtrig_audio >> snd_hda_intel rfkill snd_intel_dspcfg intel_powerclamp libarc4 mc >> snd_hda_codec coretemp snd_hda_core snd_hwdep kvm_intel snd_pcm kvm >> snd_timer mei_me irqbypass snd soundcore mei intel_cstate iTCO_wdt >> intel_uncore lg_laptop intel_ips pcspkr iTCO_vendor_support wmi_bmof joydev >> watchdog sg sparse_keymap evdev acpi_cpufreq ac serio_raw nf_log_ipv6 >> ip6t_REJECT nf_reject_ipv6 xt_hl ip6_tables ip6t_rt nf_log_ipv4 >> nf_log_common ipt_REJECT nf_reject_ipv4 xt_LOG nft_limit xt_limit >> xt_addrtype xt_tcpudp xt_conntrack nf_conntrack nf_defrag_ipv6 squashfs >> zstd_decompress nf_defrag_ipv4 libcrc32c loop nft_compat nft_counter >> nf_tables nfnetlink parport_pc ppdev lp parport ip_tables x_tables autofs4 >> ext4 crc16 mbcache jbd2 crc32c_generic ums_realtek uas >> Jul 3 03:17:59 debian-pc kernel: [ 21.183144] usb 1-1.4: ath9k_htc: >> Transferred FW: ath9k_htc/htc_9271-1.4.0.fw, size: 51008 >> Jul 3 03:17:59 debian-pc kernel: [ 21.434170] ath9k_htc 1-1.4:1.0: >> ath9k_htc: HTC initialized with 33 credits >> Jul 3 03:19:27 debian-pc kernel: [ 113.635781] ath9k_htc: Failed to >> initialize the device >> Jul 3 03:19:27 debian-pc kernel: [ 113.635864] usb 1-1.4: ath9k_htc: >> USB layer deinitialized >> Jul 3 03:32:20 debian-pc kernel: [ 886.238374] Modules linked in: >> rndis_host cdc_ether usbnet mii vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) >> uvcvideo ath9k_htc ath9k_common videobuf2_vmalloc videobuf2_memops >> videobuf2_v4l2 ath9k_hw ath videobuf2_common mac80211 snd_hda_codec_realtek >> videodev cfg80211 snd_hda_codec_generic snd_hda_codec_hdmi ledtrig_audio >> snd_hda_intel rfkill snd_intel_dspcfg intel_powerclamp libarc4 mc >> snd_hda_codec coretemp snd_hda_core snd_hwdep kvm_intel snd_pcm kvm >> snd_timer mei_me irqbypass snd soundcore mei intel_cstate iTCO_wdt >> intel_uncore lg_laptop intel_ips pcspkr iTCO_vendor_support wmi_bmof joydev >> watchdog sg sparse_keymap evdev acpi_cpufreq ac serio_raw nf_log_ipv6 >> ip6t_REJECT nf_reject_ipv6 xt_hl ip6_tables ip6t_rt nf_log_ipv4 >> nf_log_common ipt_REJECT nf_reject_ipv4 xt_LOG nft_limit xt_limit >> xt_addrtype xt_tcpudp xt_conntrack nf_conntrack nf_defrag_ipv6 squashfs >> zstd_decompress nf_defrag_ipv4 libcrc32c loop nft_compat nft_counter >> nf_tables nfnetlink parport_pc ppdev lp parport ip_tables >> Jul 3 03:32:20 debian-pc kernel: [ 886.239035] Modules linked in: >> rndis_host cdc_ether usbnet mii vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) >> uvcvideo ath9k_htc ath9k_common videobuf2_vmalloc videobuf2_memops >> videobuf2_v4l2 ath9k_hw ath videobuf2_common mac80211 snd_hda_codec_realtek >> videodev cfg80211 snd_hda_codec_generic snd_hda_codec_hdmi ledtrig_audio >> snd_hda_intel rfkill snd_intel_dspcfg intel_powerclamp libarc4 mc >> snd_hda_codec coretemp snd_hda_core snd_hwdep kvm_intel snd_pcm kvm >> snd_timer mei_me irqbypass snd soundcore mei intel_cstate iTCO_wdt >> intel_uncore lg_laptop intel_ips pcspkr iTCO_vendor_support wmi_bmof joydev >> watchdog sg sparse_keymap evdev acpi_cpufreq ac serio_raw nf_log_ipv6 >> ip6t_REJECT nf_reject_ipv6 xt_hl ip6_tables ip6t_rt nf_log_ipv4 >> nf_log_common ipt_REJECT nf_reject_ipv4 xt_LOG nft_limit xt_limit >> xt_addrtype xt_tcpudp xt_conntrack nf_conntrack nf_defrag_ipv6 squashfs >> zstd_decompress nf_defrag_ipv4 libcrc32c loop nft_compat nft_counter >> nf_tables nfnetlink parport_pc ppdev lp parport ip_tables >> Jul 3 04:42:06 debian-pc kernel: [ 924.452129] usb 1-1.4: ath9k_htc: >> Firmware ath9k_htc/htc_9271-1.4.0.fw requested >> Jul 3 04:42:06 debian-pc kernel: [ 924.452369] usbcore: registered new >> interface driver ath9k_htc >> Jul 3 04:42:06 debian-pc kernel: [ 924.473031] usb 1-1.4: firmware: >> direct-loading firmware ath9k_htc/htc_9271-1.4.0.fw >> Jul 3 04:42:06 debian-pc kernel: [ 924.759624] usb 1-1.4: ath9k_htc: >> Transferred FW: ath9k_htc/htc_9271-1.4.0.fw, size: 51008 >> Jul 3 04:42:06 debian-pc kernel: [ 925.010587] ath9k_htc 1-1.4:1.0: >> ath9k_htc: HTC initialized with 33 credits >> Jul 3 04:42:52 debian-pc
Bug#964153: Problem connecting wireless in new version Kernel
forcemerge #964480 Em sex., 3 de jul. de 2020 às 05:23, Leandro Cunha < leandrocunha...@gmail.com> escreveu: > The second log is generated with cat /var/log/syslog | grep ath9k. > > --- > Jul 3 03:17:59 debian-pc kernel: [ 20.741602] usb 1-1.4: ath9k_htc: > Firmware ath9k_htc/htc_9271-1.4.0.fw requested > Jul 3 03:17:59 debian-pc kernel: [ 20.741760] usbcore: registered new > interface driver ath9k_htc > Jul 3 03:17:59 debian-pc kernel: [ 20.895652] usb 1-1.4: firmware: > direct-loading firmware ath9k_htc/htc_9271-1.4.0.fw > Jul 3 03:17:59 debian-pc kernel: [ 20.925095] Modules linked in: > uvcvideo(+) ath9k_htc ath9k_common videobuf2_vmalloc videobuf2_memops > videobuf2_v4l2 ath9k_hw ath videobuf2_common mac80211 snd_hda_codec_realtek > videodev cfg80211 snd_hda_codec_generic snd_hda_codec_hdmi ledtrig_audio > snd_hda_intel rfkill snd_intel_dspcfg intel_powerclamp libarc4 mc > snd_hda_codec coretemp snd_hda_core snd_hwdep kvm_intel snd_pcm kvm > snd_timer mei_me irqbypass snd soundcore mei intel_cstate iTCO_wdt > intel_uncore lg_laptop intel_ips pcspkr iTCO_vendor_support wmi_bmof joydev > watchdog sg sparse_keymap evdev acpi_cpufreq ac serio_raw nf_log_ipv6 > ip6t_REJECT nf_reject_ipv6 xt_hl ip6_tables ip6t_rt nf_log_ipv4 > nf_log_common ipt_REJECT nf_reject_ipv4 xt_LOG nft_limit xt_limit > xt_addrtype xt_tcpudp xt_conntrack nf_conntrack nf_defrag_ipv6 squashfs > zstd_decompress nf_defrag_ipv4 libcrc32c loop nft_compat nft_counter > nf_tables nfnetlink parport_pc ppdev lp parport ip_tables x_tables autofs4 > ext4 crc16 mbcache jbd2 crc32c_generic ums_realtek uas > Jul 3 03:17:59 debian-pc kernel: [ 21.183144] usb 1-1.4: ath9k_htc: > Transferred FW: ath9k_htc/htc_9271-1.4.0.fw, size: 51008 > Jul 3 03:17:59 debian-pc kernel: [ 21.434170] ath9k_htc 1-1.4:1.0: > ath9k_htc: HTC initialized with 33 credits > Jul 3 03:19:27 debian-pc kernel: [ 113.635781] ath9k_htc: Failed to > initialize the device > Jul 3 03:19:27 debian-pc kernel: [ 113.635864] usb 1-1.4: ath9k_htc: USB > layer deinitialized > Jul 3 03:32:20 debian-pc kernel: [ 886.238374] Modules linked in: > rndis_host cdc_ether usbnet mii vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) > uvcvideo ath9k_htc ath9k_common videobuf2_vmalloc videobuf2_memops > videobuf2_v4l2 ath9k_hw ath videobuf2_common mac80211 snd_hda_codec_realtek > videodev cfg80211 snd_hda_codec_generic snd_hda_codec_hdmi ledtrig_audio > snd_hda_intel rfkill snd_intel_dspcfg intel_powerclamp libarc4 mc > snd_hda_codec coretemp snd_hda_core snd_hwdep kvm_intel snd_pcm kvm > snd_timer mei_me irqbypass snd soundcore mei intel_cstate iTCO_wdt > intel_uncore lg_laptop intel_ips pcspkr iTCO_vendor_support wmi_bmof joydev > watchdog sg sparse_keymap evdev acpi_cpufreq ac serio_raw nf_log_ipv6 > ip6t_REJECT nf_reject_ipv6 xt_hl ip6_tables ip6t_rt nf_log_ipv4 > nf_log_common ipt_REJECT nf_reject_ipv4 xt_LOG nft_limit xt_limit > xt_addrtype xt_tcpudp xt_conntrack nf_conntrack nf_defrag_ipv6 squashfs > zstd_decompress nf_defrag_ipv4 libcrc32c loop nft_compat nft_counter > nf_tables nfnetlink parport_pc ppdev lp parport ip_tables > Jul 3 03:32:20 debian-pc kernel: [ 886.239035] Modules linked in: > rndis_host cdc_ether usbnet mii vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) > uvcvideo ath9k_htc ath9k_common videobuf2_vmalloc videobuf2_memops > videobuf2_v4l2 ath9k_hw ath videobuf2_common mac80211 snd_hda_codec_realtek > videodev cfg80211 snd_hda_codec_generic snd_hda_codec_hdmi ledtrig_audio > snd_hda_intel rfkill snd_intel_dspcfg intel_powerclamp libarc4 mc > snd_hda_codec coretemp snd_hda_core snd_hwdep kvm_intel snd_pcm kvm > snd_timer mei_me irqbypass snd soundcore mei intel_cstate iTCO_wdt > intel_uncore lg_laptop intel_ips pcspkr iTCO_vendor_support wmi_bmof joydev > watchdog sg sparse_keymap evdev acpi_cpufreq ac serio_raw nf_log_ipv6 > ip6t_REJECT nf_reject_ipv6 xt_hl ip6_tables ip6t_rt nf_log_ipv4 > nf_log_common ipt_REJECT nf_reject_ipv4 xt_LOG nft_limit xt_limit > xt_addrtype xt_tcpudp xt_conntrack nf_conntrack nf_defrag_ipv6 squashfs > zstd_decompress nf_defrag_ipv4 libcrc32c loop nft_compat nft_counter > nf_tables nfnetlink parport_pc ppdev lp parport ip_tables > Jul 3 04:42:06 debian-pc kernel: [ 924.452129] usb 1-1.4: ath9k_htc: > Firmware ath9k_htc/htc_9271-1.4.0.fw requested > Jul 3 04:42:06 debian-pc kernel: [ 924.452369] usbcore: registered new > interface driver ath9k_htc > Jul 3 04:42:06 debian-pc kernel: [ 924.473031] usb 1-1.4: firmware: > direct-loading firmware ath9k_htc/htc_9271-1.4.0.fw > Jul 3 04:42:06 debian-pc kernel: [ 924.759624] usb 1-1.4: ath9k_htc: > Transferred FW: ath9k_htc/htc_9271-1.4.0.fw, size: 51008 > Jul 3 04:42:06 debian-pc kernel: [ 925.010587] ath9k_htc 1-1.4:1.0: > ath9k_htc: HTC initialized with 33 credits > Jul 3 04:42:52 debian-pc kernel: [ 971.047570] ath9k_htc: Failed to > initialize the device > Jul 3 04:42:52 debian-pc kernel: [ 971.047604] usb 1-1.4: ath9k_htc: USB > layer deinitialized > Jul 3 04:43:18
Re: Initramfs-tools boot issue with bad console
Thanks a lot Mika! I'll try to add patches to BTS and Salsa, I think this way is more easy for maintainers, to choose what they prefer heheh Cheers, Guilherme
Bug#964480: linux: ath9k (USB) broken in upstresm linux 5.7.3 after commit 6602f080cb
Juergen writes: > In 5.7 reverting 6602f080cb is known to fix the problem, but it hasn't yet > been > analyzed by an expert, therefore I'd like to report my findings to perhaps get > an expert interested:-) > > At least one problem is in function ath9k_hif_usb_reg_in_cb(). In the call to > usb_fill_int_urb() it should be rx_buf instead of nskb as penultimate > parameter. Yes, that's an obvious killer bug. That patch should definitely be reverted, and replaced with a proper and tested fix. IMHO, it would be much safer and simpler to validate the expected descriptors when probing these devices instead of allocating new helper structs and making changes all over the place. There is no reason to add support for the syzbot simulated device. Returning -ENODEV on probe is fine, and is much less likely to add new and critical bugs. And it's not like the fix actually took care of all the hard coded well known descriptor values in this driver anyway. We still have stuff like usb_sndintpipe(hif_dev->udev, USB_REG_OUT_PIPE) and usb_sndbulkpipe(hif_dev->udev, USB_WLAN_TX_PIPE) These will not crash the driver, but are still solid indications that the driver is written for a very specific USB device configuration. It will not work with arbitrary descriptors. I assume the "0" interface is just as fixed as those endpoints, so that simply validating the values in ath9k_hif_usb_probe() is a perfectly fine and safe solution. Without the need to mess up the rest of the driver. Bjørn
Re: Initramfs-tools boot issue with bad console
Hi, * Guilherme Piccoli [Fri Jul 03, 2020 at 05:29:52PM -0300]: > Thanks for your +1 there Michael! Do you know if there's a way to get > that merged? I'd like to follow the proper process and fix that on > Debian before Ubuntu. I'm not sure if Ben is watching/noticing Salsa MRs, Ben? Guilherme, you already added the patch to #962545 (excellent and thanks :)), that's where Ben should notice it for sure. :) > Also, just for my knowledge for future submissions: is it better to > send a patch via email, as an attachment in a bug report message, than > a merge request in salsa? I'd like to follow the procedure that is > preferred by the maintainers. > Thanks, I'm no longer active in the initramfs-tools maintenance, so I'll leave that answer to Ben (and possible further/upcoming maintainers of i-t). regards -mika- signature.asc Description: Digital signature
