January 2024 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1218682] EFI aarch64 boot failure on honeycomb lx2
by bugzilla_noreply＠suse.com 23 Jan '24

23 Jan '24

https://bugzilla.suse.com/show_bug.cgi?id=1218682 https://bugzilla.suse.com/show_bug.cgi?id=1218682#c3 --- Comment #3 from Ivan Ivanov <ivan.ivanov(a)suse.com> --- Hi James, could you try suggestion from Stanimir? -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1219060] New: lxqt test
by bugzilla_noreply＠suse.com 23 Jan '24

23 Jan '24

https://bugzilla.suse.com/show_bug.cgi?id=1219060 Bug ID: 1219060 Summary: lxqt test Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: LXQt Assignee: lxqt-bugs(a)suse.de Reporter: mvetter(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Just a test for our new lxqt-bugs(a)suse.de list to confirm we all get the notification. -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1218864] grub2: error messages: 'not a correct XFS inode' shown many many times
by bugzilla_noreply＠suse.com 23 Jan '24

23 Jan '24

https://bugzilla.suse.com/show_bug.cgi?id=1218864 https://bugzilla.suse.com/show_bug.cgi?id=1218864#c31 --- Comment #31 from Michael Chang <mchang(a)suse.com> --- (In reply to Lorenz Hüdepohl from comment #29) > To chime in as a third party: On my tumbleweed installation with the latest > change, I can no longer boot kernels from my root XFS. I had problems before > that were fixed in > > https://build.opensuse.org/request/show/1138021 > > already before I could report them :) > > But with the newest > > https://build.opensuse.org/request/show/1138021 > > it no longer works, again. > > (A compounding factor seems to be the move of the kernels from /boot to > /usr/lib/modules/$kernelversion, as the rather small /boot directory can > always be parsed by grub in my tests so far, whereas the rather large /usr > metadata is probably stored somehow differently by XFS, triggering this > issue. This could blur the timeline of events, somewhat, not sure what came > when) > > Here are details about the currently installed package (which is not able to > boot): > > root@~> rpm -q grub2 --changelog | head > * Mi Jan 17 2024 Michael Chang <mchang(a)suse.com> > - Resolved XFS regression leading to the "not a correct XFS inode" error by > temporarily reverting the problematic commit (bsc#1218864) > * 0001-Revert-fs-xfs-Fix-XFS-directory-extent-parsing.patch > [...] > root@~> rpm -qi grub2 > Name : grub2 > Version : 2.12 > Release : 2.1 > Architecture: x86_64 > Install Date: Sa 20 Jan 2024 09:23:11 CET > Group : System/Boot > Size : 27941722 > License : GPL-3.0-or-later > Signature : RSA/SHA512, Mi 17 Jan 2024 23:54:16 CET, Key ID > 35a2f86e29b700a4 > Source RPM : grub2-2.12-2.1.src.rpm > Build Date : Mi 17 Jan 2024 23:53:48 CET > Build Host : i04-ch1d > Packager : https://bugs.opensuse.org > Vendor : openSUSE > URL : http://www.gnu.org/software/grub/ > Summary : Bootloader with support for Linux, Multiboot and more > Description : > This is the second version of the GRUB (Grand Unified Bootloader), a > highly configurable and customizable bootloader with modular > architecture. It support rich scale of kernel formats, file systems, > computer architectures and hardware devices. > > This package includes user space utlities to manage GRUB on your system. > Distribution: openSUSE Tumbleweed This can the consequence of reverting "fs/xfs: Fix XFS directory extent parsing" that caused the xfs error here ... Before a proper fix landing upstream, I think we may provide a band-aid fix by adding back the number of entries check to the "Fix XFS directory extent parsing" patch whereas the node is not single extent and hence filtering out those "unmapped blocks" globally. I will try to provide test package so that you can help to verify it on two different potential layouts. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1218864] grub2: error messages: 'not a correct XFS inode' shown many many times
by bugzilla_noreply＠suse.com 23 Jan '24

23 Jan '24

https://bugzilla.suse.com/show_bug.cgi?id=1218864 https://bugzilla.suse.com/show_bug.cgi?id=1218864#c30 --- Comment #30 from Michael Chang <mchang(a)suse.com> --- (In reply to Giacomo Comes from comment #28) > The original author of the patch causing the current problem has made some > comment on the fedora bugzilla entry. See comment 57,59,61. > I think what he says is consistent with that Michael found. Thanks. And yes that seemed to coincide with my finding. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1212462] RAID Resync on every reboot with latest mdadm-4.1-150300.24.27.1 update
by bugzilla_noreply＠suse.com 22 Jan '24

22 Jan '24

https://bugzilla.suse.com/show_bug.cgi?id=1212462 https://bugzilla.suse.com/show_bug.cgi?id=1212462#c5 Santiago Zarate <santiago.zarate(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |santiago.zarate(a)suse.com --- Comment #5 from Santiago Zarate <santiago.zarate(a)suse.com> --- I wonder if this is related also to: https://bugzilla.suse.com/show_bug.cgi?id=1216381 -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1212462] RAID Resync on every reboot with latest mdadm-4.1-150300.24.27.1 update
by bugzilla_noreply＠suse.com 22 Jan '24

22 Jan '24

https://bugzilla.suse.com/show_bug.cgi?id=1212462 https://bugzilla.suse.com/show_bug.cgi?id=1212462#c4 --- Comment #4 from Björn Voigt <bjoernv(a)arcor.de> --- (In reply to Coly Li from comment #3) > Can I ask that after upgrading to latest mdadm package and openSUSE Leap > kernel, does this issue still happen? > > I am not able to tell exactly what happened to the original report, if the > latest openSUSE Leap 15.5 kernel and mdadm package don't help, let me try to > see what happens... I happened last time at end of November 2023 after I upgraded this machine from openSUSE Leap 15.4 to 15.5. Unfortunately it's a production machine. Rebuilding the RAID5 array takes around 8 hours and makes the machine unusably slow. So it's difficult to find a good time for testing again with the latest openSUSE Leap 15.5 kernel and mdadm packages. Do you think, that the newest mdadm package will only work reliable with the openSUSE patched kernels? I use a self-compiled vanilla LTS 6.1.x kernel (currently 6.1.74) mostly for security reasons. The kernel configuration .config is a nearly 1:1 copy of the previous openSUSE Tumbleweed 6.1.x kernel. If I find a good time for testing, please say, which information do you need. I had the problem, that the initrd SystemD boot scripts can fail (probably because of a timeout), if mdadm from Initrd starts a RAID5 rebuild. The hint from Initrd on the display to copy a /run/*/*log* file for later analysis is not so easy to fulfill. The RAID5 array is not ready for mounting at this stage and a VFAT formatted USB device is not recognized (missing codepage 437 or similar error). -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1217613] Leap 15.6 not reviving from suspend on '12 MacPro w/nvidia card
by bugzilla_noreply＠suse.com 22 Jan '24

22 Jan '24

https://bugzilla.suse.com/show_bug.cgi?id=1217613 https://bugzilla.suse.com/show_bug.cgi?id=1217613#c18 --- Comment #18 from Fritz Hudnut <non.space.1(a)gmail.com> --- Just a head's up to say that I did get the hwinfo data copied and pasted out of the console this morning and into a .txt document . . . took a fair bit of time to highlight that much data, manually. : - 0 I ran out of time on it before I could upload it here . . . "629 pages" or 1.3MB of data, similar to the TW item. I'll upload it when I get back to Leap 15.6. I watched the dmesg data spin by this morning . . . all "OK," no "errors" showing on it. If it is quick n dirty to copy paste the dmesg I will try that, but if it's another literally 15 mins of holding the mouse button to get the hwinfo copied, that I think will be "too much" . . . ???? I again tried the # hwinfo > hwinfo.txt move and it took a few seconds for the cursor to return, as though something was "happening," but once again, nothing did . . . whereas it did in TW . . . . -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1168644] smartd service failure on boot
by bugzilla_noreply＠suse.com 22 Jan '24

22 Jan '24

https://bugzilla.suse.com/show_bug.cgi?id=1168644 https://bugzilla.suse.com/show_bug.cgi?id=1168644#c1 Stanislav Brabec <sbrabec(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |UPSTREAM --- Comment #1 from Stanislav Brabec <sbrabec(a)suse.com> --- Sorry for late reply. The Type=notify is not source of the problems. It just unhides problems that probably appeared before. The real problem probably comes from elsewhere: Your eMMC does not support S.M.A.R.T. As there is no way to detect this situation, the correct fix is currently: disable smartd.service This has been discussed before. Current smartmontools does not support PnP. There are only bad solutions: - Keep smartd running and consuming resources, even if there are no devices to monitor. - Terminate smartd without reporting error, hiding the fact that it fails to do anything. - Terminate smartd with reporting error, confusing people with a hardware without S.M.A.R.T. support. SUSE selected the third one. The real solution could come only from the upstream: - Completely reimplement the device management. Instead of device scan on start, implement udev connector that will analyze each attached disk in the moment, when kernel/udev discovers it. - Reimplement device check loop to co-operate with the udev connector. I am afraid that it will not happen anytimes soon. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1211571] nmap non-OSI approved "Nmap Public Source License" NPSL
by bugzilla_noreply＠suse.com 22 Jan '24

22 Jan '24

https://bugzilla.suse.com/show_bug.cgi?id=1211571 https://bugzilla.suse.com/show_bug.cgi?id=1211571#c7 Andreas Stieger <Andreas.Stieger(a)gmx.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|ciaran.farrell(a)suse.com |Andreas.Stieger(a)gmx.de CC| |ciaran.farrell(a)suse.com --- Comment #7 from Andreas Stieger <Andreas.Stieger(a)gmx.de> --- assuming tests need to run w/o nmap, these need fixing: https://github.com/search?q=repo%3Aos-autoinst%2Fos-autoinst-distri-opensus… -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1217417] Realtek RTL-8126 Network Driver
by bugzilla_noreply＠suse.com 22 Jan '24

22 Jan '24

https://bugzilla.suse.com/show_bug.cgi?id=1217417 https://bugzilla.suse.com/show_bug.cgi?id=1217417#c19 --- Comment #19 from Joe S <jmscdba(a)gmail.com> --- (In reply to Takashi Iwai from comment #17) > I'm not sure what went wrong, as there seems no proper error message. > > For avoiding the misconfiguration or such, I'm building a test kernel with a > patch that just adds the PCI entry for 8126 to TW kernel. > The 6.7.x kernel is being built in OBS home:tiwai:bsc1217417 repo. Once > after the build finishes (takes an hour or so), it'll appear at > http://download.opensuse.org/repositories/home:/tiwai:/bsc1217417/standard/ > > Please give it a try later, and give the dmesg output after the boot. > I don't expect this working, but it's still worth to try. That's for doing that, I appreciate it ! I downloaded and installed these 3 packages kernel-default-6.7.0-1.1.g898b843.x86_64.rpm kernel-default-devel-6.7.0-1.1.g898b843.x86_64.rpm kernel-devel-6.7.0-1.1.g898b843.noarch.rpm NOTE: I installed the dev packages too because if it worked I was planning to recompile the vmware modules which I use. lsmod | grep r8169 r8169 114688 0 mdio_devres 12288 1 r8169 libphy 245760 3 r8169,mdio_devres,realtek Shows that the r8169 module is now loading with the new 6.7 kernel but ip a does not list the network adapter 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host noprefixroute valid_lft forever preferred_lft forever 2: wlo1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether f2:98:ea:e6:3c:ff brd ff:ff:ff:ff:ff:ff permaddr 90:65:84:fe:d1:b1 altname wlp4s0f0 I also ran lspci -vvv and am including the output for the realtek 8126 which shows that r8169 module loaded too 05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. Device 8126 (rev 01) Subsystem: ASUSTeK Computer Inc. Device 88ac Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Interrupt: pin A routed to IRQ 19 IOMMU group: 18 Region 0: I/O ports at 4000 [size=256] Region 2: Memory at 77400000 (64-bit, non-prefetchable) [size=64K] Region 4: Memory at 77410000 (64-bit, non-prefetchable) [size=16K] Capabilities: [40] Power Management version 3 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+ Address: 0000000000000000 Data: 0000 Masking: 00000000 Pending: 00000000 Capabilities: [70] Express (v2) Endpoint, MSI 01 DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 10W DevCtl: CorrErr+ NonFatalErr+ FatalErr+ UnsupReq+ RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 256 bytes, MaxReadReq 512 bytes DevSta: CorrErr+ NonFatalErr- FatalErr- UnsupReq+ AuxPwr+ TransPend- LnkCap: Port #0, Speed 8GT/s, Width x1, ASPM L0s L1, Exit Latency L0s unlimited, L1 <64us ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp+ LnkCtl: ASPM L1 Enabled; RCB 64 bytes, Disabled- CommClk+ ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt- LnkSta: Speed 8GT/s, Width x1 TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- DevCap2: Completion Timeout: Range ABCD, TimeoutDis+ NROPrPrP- LTR+ 10BitTagComp- 10BitTagReq- OBFF Via message/WAKE#, ExtFmt- EETLPPrefix- EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit- FRS- TPHComp+ ExtTPHComp- AtomicOpsCap: 32bit- 64bit- 128bitCAS- DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LTR+ 10BitTagReq- OBFF Disabled, AtomicOpsCtl: ReqEn- LnkCap2: Supported Link Speeds: 2.5-8GT/s, Crosslink- Retimer- 2Retimers- DRS- LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis- Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance Preset/De-emphasis: -6dB de-emphasis, 0dB preshoot LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete+ EqualizationPhase1+ EqualizationPhase2+ EqualizationPhase3+ LinkEqualizationRequest- Retimer- 2Retimers- CrosslinkRes: unsupported Capabilities: [b0] MSI-X: Enable- Count=32 Masked- Vector table: BAR=4 offset=00000000 PBA: BAR=4 offset=00000800 Capabilities: [d0] Vital Product Data Not readable Capabilities: [100 v2] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr- CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+ AERCap: First Error Pointer: 00, ECRCGenCap+ ECRCGenEn- ECRCChkCap+ ECRCChkEn- MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap- HeaderLog: 00000000 00000000 00000000 00000000 Capabilities: [148 v1] Virtual Channel Caps: LPEVC=0 RefClk=100ns PATEntryBits=1 Arb: Fixed- WRR32- WRR64- WRR128- Ctrl: ArbSelect=Fixed Status: InProgress- VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans- Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256- Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff Status: NegoPending- InProgress- Capabilities: [170 v1] Device Serial Number 01-00-00-00-68-4c-e0-00 Capabilities: [180 v1] Secondary PCI Express LnkCtl3: LnkEquIntrruptEn- PerformEqu- LaneErrStat: 0 Capabilities: [190 v1] Transaction Processing Hints No steering table available Capabilities: [21c v1] Latency Tolerance Reporting Max snoop latency: 3145728ns Max no snoop latency: 3145728ns Capabilities: [224 v1] L1 PM Substates L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+ PortCommonModeRestoreTime=150us PortTPowerOnTime=150us L1SubCtl1: PCI-PM_L1.2- PCI-PM_L1.1- ASPM_L1.2- ASPM_L1.1- T_CommonMode=0us LTR1.2_Threshold=317440ns L1SubCtl2: T_PwrOn=150us Capabilities: [234 v1] Vendor Specific Information: ID=0002 Rev=4 Len=100 <?> Kernel modules: r8169 NOTE: I can send the full lscpi -vvv output if you want to see it. I created 6.7.dmesg.log as you requested and have attached it. The only 2 lines that reference the r8169 in the dmesg log are these 2 lines: [ 3.237151] r8169 0000:05:00.0: enabling device (0000 -> 0003) [ 3.237289] r8169 0000:05:00.0: error -ENODEV: unknown chip XID 649, contact r8169 maintainers (see MAINTAINERS file) The 2nd line looks like it is the issue. -- You are receiving this mail because: You are on the CC list for the bug.

1 0