September 2020 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1175457] Missing "Package Groups" in the package manager - Yast search for similar packages is no longer possible
by bugzilla_noreply＠suse.com 01 Sep '20

01 Sep '20

https://bugzilla.suse.com/show_bug.cgi?id=1175457 https://bugzilla.suse.com/show_bug.cgi?id=1175457#c18 --- Comment #18 from Petr Mikulík <pkilukim(a)gmail.com> --- > Your assesment on provided groups is false. > So your quick check reports it as 'there are groups' yet they are mostly useless. Useless and false? What about actually checking the numbers: All packages: zgrep 'Group[ ]*:[ ]*' /var/lib/pin/ARCHIVES.gz | wc -l => 38571 Group unspecified packages: zgrep 'Group[ ]*:[ ]*' /var/lib/pin/ARCHIVES.gz | grep Unspecified | wc -l => 2161 Unspecified non some libs: zgrep 'Group[ ]*:[ ]*' /var/lib/pin/ARCHIVES.gz | grep Unspecified | egrep -iv '(python|devel|myspell|lib)' | wc -l => 742 Thus, there are 742 out of 38571. Looking manually to their list, I have found only these "user-friendly" packages without a group: fontforge, asciidoc, pandoc, rstudio You will probably find more. How many? Those other 738 looks like libraries, desktop support files etc. And this discussion has stated in the beginning that the Group classification is a great help for users and user-used software. Hm, I wonder why a user needs to persuade Yast/OpenSUSE maintainers how good the current system is. My wish is to keep it running until anything better is available. > Doing anything outside YaST doesn't make sense I guess. I wish I don't need to be root for having a GUI to browse OpenSUSE packages. Running /usr/sbin/yast2 sw_single without root privileges terminates with an error message. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1175455] wol-udev-rules: wrong eth name for wake on lan
by bugzilla_noreply＠suse.com 01 Sep '20

01 Sep '20

https://bugzilla.suse.com/show_bug.cgi?id=1175455 https://bugzilla.suse.com/show_bug.cgi?id=1175455#c6 --- Comment #6 from Petr Mikulík <pkilukim(a)gmail.com> --- Firstly, I think the config file should list wired devices. Secondly, I firstly search Yast where to enable WOL, but found nothing. Then I have found this package in the Package manager and I though WOL will work immediately. I was using WOL before reinstalling OpenSUSE 15.0 to 15.2; unfortunately I don't remember what I had to tweak to let it working. I don't know how to run wol via systemd. I think a Yast option/menu/icon to allow WOL would be the best user-friendly approach. Is it possible to add such a feature? -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1175268] [glibc2.32] kbuild build failure
by bugzilla_noreply＠suse.com 01 Sep '20

01 Sep '20

https://bugzilla.suse.com/show_bug.cgi?id=1175268 https://bugzilla.suse.com/show_bug.cgi?id=1175268#c7 --- Comment #7 from Dirk Mueller <dmueller(a)suse.com> --- sigh, I was naive in assuming the newest revision which includes the fix you need would also otherwise build. :( taking a look. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1175967] New: zypper dup from Tumbleweed 20200824 -> 20200826 fails
by bugzilla_noreply＠suse.com 01 Sep '20

01 Sep '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1175967 Bug ID: 1175967 Summary: zypper dup from Tumbleweed 20200824 -> 20200826 fails Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: i686 OS: openSUSE Tumbleweed Status: NEW Severity: Major Priority: P5 - None Component: libzypp Assignee: zypp-maintainers(a)suse.de Reporter: al13808(a)alte-leipziger.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- It is impossible to update or install packages in Tumbleweed anymore. Zypper fails with RPM failed: error: unpacking of archive failed: cpio: Bad magic If I try to install the package with rpm -U, rpm fails with rpmlib(PayloadIsZstd) <= 5.4.18-1 is needed by ... I found on the mailing list that "the payload compression is being changed to zstd" (https://lists.opensuse.org/opensuse-factory/2020-07/msg00422.html) Obviously my rpm command does not support zstd compression yet. -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1175126] New: KDE Wacom Tablet Segfault
by bugzilla_noreply＠suse.com 01 Sep '20

01 Sep '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1175126 Bug ID: 1175126 Summary: KDE Wacom Tablet Segfault Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: KDE Workspace (Plasma) Assignee: opensuse-kde-bugs(a)opensuse.org Reporter: dev(a)cubiclenate.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Since I don't use the tablet every day, I am not sure when the Wacom tablet stopped working. The tablet powers up but the cursor cannot be manipulated with the tablet at all. dmesg output: [ 8035.691849] usb 2-2: new full-speed USB device number 7 using xhci_hcd [ 8035.844925] usb 2-2: New USB device found, idVendor=5543, idProduct=0081, bcdDevice= 0.00 [ 8035.844929] usb 2-2: New USB device strings: Mfr=5, Product=6, SerialNumber=0 [ 8035.844931] usb 2-2: Product: ugee-1000L [ 8035.844933] usb 2-2: Manufacturer: UC-LOGIC [ 8035.848264] input: UC-LOGIC ugee-1000L as /devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2:1.0/0003:5543:0081.0003/input/input27 [ 8035.848616] input: UC-LOGIC ugee-1000L Mouse as /devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2:1.0/0003:5543:0081.0003/input/input28 [ 8035.848858] hid-generic 0003:5543:0081.0003: input,hidraw2: USB HID v1.11 Mouse [UC-LOGIC ugee-1000L] on usb-0000:00:14.0-2/input0 [ 8035.850051] input: UC-LOGIC ugee-1000L Mouse as /devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2:1.1/0003:5543:0081.0004/input/input29 [ 8035.850394] hid-generic 0003:5543:0081.0004: input,hiddev96,hidraw3: USB HID v1.11 Mouse [UC-LOGIC ugee-1000L] on usb-0000:00:14.0-2/input1 [ 8035.851762] input: UC-LOGIC ugee-1000L Keyboard as /devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2:1.2/0003:5543:0081.0005/input/input30 [ 8035.908091] input: UC-LOGIC ugee-1000L Consumer Control as /devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2:1.2/0003:5543:0081.0005/input/input31 [ 8035.908231] input: UC-LOGIC ugee-1000L System Control as /devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2:1.2/0003:5543:0081.0005/input/input32 [ 8035.908388] hid-generic 0003:5543:0081.0005: input,hidraw4: USB HID v1.11 Keyboard [UC-LOGIC ugee-1000L] on usb-0000:00:14.0-2/input2 [ 8036.709604] input: UC-LOGIC ugee-1000L Pen as /devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2:1.0/0003:5543:0081.0003/input/input33 [ 8036.709844] input: UC-LOGIC ugee-1000L Pad as /devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2:1.0/0003:5543:0081.0003/input/input34 [ 8036.710139] uclogic 0003:5543:0081.0003: input,hidraw2: USB HID v1.11 Keypad [UC-LOGIC ugee-1000L] on usb-0000:00:14.0-2/input0 [ 8036.752488] input: UC-LOGIC ugee-1000L Mouse as /devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2:1.1/0003:5543:0081.0004/input/input35 [ 8036.752975] uclogic 0003:5543:0081.0004: input,hiddev96,hidraw3: USB HID v1.11 Mouse [UC-LOGIC ugee-1000L] on usb-0000:00:14.0-2/input1 [ 8036.932784] input: UC-LOGIC ugee-1000L Keyboard as /devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2:1.2/0003:5543:0081.0005/input/input36 [ 8036.992111] input: UC-LOGIC ugee-1000L Consumer Control as /devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2:1.2/0003:5543:0081.0005/input/input37 [ 8036.992365] input: UC-LOGIC ugee-1000L System Control as /devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2:1.2/0003:5543:0081.0005/input/input38 [ 8036.992513] uclogic 0003:5543:0081.0005: input,hidraw4: USB HID v1.11 Keyboard [UC-LOGIC ugee-1000L] on usb-0000:00:14.0-2/input2 [ 8186.506537] show_signal_msg: 8 callbacks suppressed [ 8186.506542] kde_wacom_table[21840]: segfault at 0 ip 000055dd7c37cb5c sp 00007ffdd37b8ea0 error 4 in kde_wacom_tabletfinder[55dd7c379000+e000] [ 8186.506556] Code: 29 c2 48 85 d2 7f 07 48 83 c4 08 5b 5d c3 48 83 c4 08 5b 5d e9 65 ca ff ff 90 0f 1f 40 00 55 48 89 f5 53 48 89 fb 48 83 ec 08 <8b> 06 48 8b 56 08 89 07 48 89 57 08 8b 02 83 c0 01 83 f8 01 0f 87 -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1175857] VUL-0: CVE-2020-24654: ark: maliciously crafted TAR archive can install files outside the extraction directory
by bugzilla_noreply＠suse.com 01 Sep '20

01 Sep '20

https://bugzilla.suse.com/show_bug.cgi?id=1175857 https://bugzilla.suse.com/show_bug.cgi?id=1175857#c3 --- Comment #3 from Swamp Workflow Management <swamp(a)suse.de> --- openSUSE-SU-2020:1310-1: An update that fixes one vulnerability is now available. Category: security (moderate) Bug References: 1175857 CVE References: CVE-2020-24654 JIRA References: Sources used: openSUSE Leap 15.2 (src): ark-20.04.2-lp152.2.6.1 openSUSE Leap 15.1 (src): ark-18.12.3-lp151.2.7.1 openSUSE Backports SLE-15-SP1 (src): ark-18.12.3-bp151.3.6.1 -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1175967] zypper dup from Tumbleweed 20200824 -> 20200826 fails
by bugzilla_noreply＠suse.com 01 Sep '20

01 Sep '20

https://bugzilla.suse.com/show_bug.cgi?id=1175967 https://bugzilla.suse.com/show_bug.cgi?id=1175967#c4 --- Comment #4 from Fabian Vogt <fvogt(a)suse.com> --- Ok, that confirms that you never updated rpm to anything newer than the version you installed TW with. Now the question is why. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1068647] New: btrfs send bails out on orphan inode
by bugzilla_noreply＠novell.com 01 Sep '20

01 Sep '20

http://bugzilla.suse.com/show_bug.cgi?id=1068647 Bug ID: 1068647 Summary: btrfs send bails out on orphan inode Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-maintainers(a)forge.provo.novell.com Reporter: martin.wilck(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- I can't create backups of my currently active subvolume with btrfs send any more. It proceeeds for several minutes, than bails out with the error message ERROR: send ioctl failed with -2: No such file or directory This situation has persisted throughout several reboots, remounts, and kernel updates. This first occured while I was doing lots of experiments with btrfs-send, working on my "btrfs-clone" utility (https://github.com/mwilck/btrfs-clone) and testing the efficiency of various cloning strategies within this tool. I made several successful snapshots, until suddenly the described situation came to pass which makes it impossible to do any more snapshots of the "main" subvol. Thus it's possible that the situation was caused by btrfs-send. I admit I did this while the subvolume was mounted. Of course I'd always set the cloned subvolume and its parent to read-only mode while ran btrfs-send (it will abort otherwise). Except for the btrfs-send, no other problems have been observed so far. All other tools (btrfs image, btrfs scrub, btrfs inspect-internal dump-tree) silently ignored this situation. I've traced the error down to the following call stack: > send_subvol() > full_send_tree() > changed_cb [btrfs]() > finish_inode_if_needed [btrfs]() > get_inode_info.constprop.48 [btrfs]() > apply_children_dir_moves [btrfs]() > send_utimes [btrfs]() > get_cur_path [btrfs]() > __get_cur_name_and_parent [btrfs]() > is_inode_existent.part.15 [btrfs]() > get_first_ref [btrfs]() get_first_ref() returns with -ENOENT. I used some instrumentation to find out what was causing this problem, and found the following situation in the file system tree: root tree 28090400768(level 0) / 28058992640(1) - subvol @/.subvols/1/snapshot is item 89 at 28061384704 > root tree > node 28058992640 level 1 items 5 free 488 generation 188885 owner 1 > fs uuid ad544c37-37f9-44a4-9798-d29d3cb5db44 > chunk uuid bb2d5d7b-6b0b-4f2d-9677-097711ef8572 > key (EXTENT_TREE ROOT_ITEM 0) block 28090400768 (1714502) gen 188885 > > leaf 28090400768 items 98 free space 6117 generation 188885 owner 1 > leaf 28090400768 flags 0x1(WRITTEN) backref revision 1 > fs uuid ad544c37-37f9-44a4-9798-d29d3cb5db44 > chunk uuid bb2d5d7b-6b0b-4f2d-9677-097711ef8572 > > item 5 key (ROOT_TREE_DIR INODE_ITEM 0) itemoff 14770 itemsize 160 > generation 3 transid 0 size 0 nbytes 16384 > block group 0 mode 40755 links 1 uid 0 gid 0 rdev 0 > sequence 0 flags 0x0(none) > atime 1493728330.0 (2017-05-02 14:32:10) > ctime 1493728330.0 (2017-05-02 14:32:10) > mtime 1493728330.0 (2017-05-02 14:32:10) > otime 1493728330.0 (2017-05-02 14:32:10) > > item 12 key (257 ROOT_ITEM 0) itemoff 13191 itemsize 439 > generation 180352 root_dirid 256 bytenr 36967874560 level 0 refs 1 > lastsnap 12 byte_limit 0 bytes_used 16384 flags 0x0(none) > uuid d4ad4958-2cc1-004e-934d-f223ef4c5f2a > ctransid 180352 otransid 8 stransid 0 rtransid 0 > drop key (0 UNKNOWN.0 0) level 0 > item 13 key (257 ROOT_BACKREF 5) itemoff 13172 itemsize 19 > root backref key dirid 256 sequence 2 name @ > > item 33 key (258 ROOT_ITEM 0) itemoff 12290 itemsize 439 > generation 188511 root_dirid 256 bytenr 17933533184 level 1 refs 1 > lastsnap 0 byte_limit 0 bytes_used 163840 flags 0x0(none) > uuid e99de79b-c494-9445-812b-d08389f82947 > ctransid 188511 otransid 11 stransid 0 rtransid 0 > drop key (0 UNKNOWN.0 0) level 0 > item 34 key (258 ROOT_BACKREF 257) itemoff 12262 itemsize 28 > root backref key dirid 256 sequence 3 name .snapshots > > item 89 key (259 ROOT_ITEM 12) itemoff 10419 itemsize 439 > generation 188884 root_dirid 256 bytenr 28061384704 level 2 refs 1 > lastsnap 186971 byte_limit 0 bytes_used 259981312 flags 0x0(none) > uuid 17c54832-5028-694c-9f97-1be0a1df8757 > parent_uuid d4ad4958-2cc1-004e-934d-f223ef4c5f2a > ctransid 188884 otransid 12 stransid 0 rtransid 0 > drop key (0 UNKNOWN.0 0) level 0 > item 90 key (259 ROOT_BACKREF 258) itemoff 10393 itemsize 26 > root backref key dirid 257 sequence 2 name snapshot File system tree 28061384704 - btrfs path 28052832256(level 0) / 28045197312(1) / 28061384704(2) - item 8 (1746132 INODE_ITEM 0) has "links 0" and no ref - item 86 is an ORPHAN node linking to item 8. > file tree key (259 ROOT_ITEM 12) > node 28061384704 level 2 items 56 free 437 generation 188884 owner 259 > fs uuid ad544c37-37f9-44a4-9798-d29d3cb5db44 > chunk uuid bb2d5d7b-6b0b-4f2d-9677-097711ef8572 > > key (1732417 INODE_REF 830626) block 28045197312 (1711743) gen 188860 > > node 28045197312 level 1 items 341 free 152 generation 188860 owner 259 > fs uuid ad544c37-37f9-44a4-9798-d29d3cb5db44 > chunk uuid bb2d5d7b-6b0b-4f2d-9677-097711ef8572 > ... > key (1746122 INODE_ITEM 0) block 28052832256 (1712209) gen 188821 > > leaf 28052832256 items 66 free space 8146 generation 188821 owner 259 > leaf 28052832256 flags 0x1(WRITTEN) backref revision 1 > fs uuid ad544c37-37f9-44a4-9798-d29d3cb5db44 > chunk uuid bb2d5d7b-6b0b-4f2d-9677-097711ef8572 > ... > item 7 key (1746123 EXTENT_DATA 4096) itemoff 15701 itemsize 53 > generation 188295 type 1 (regular) > extent data disk byte 470392832 nr 4096 > extent data offset 0 nr 4096 ram 4096 > extent compression 0 (none) > item 8 key (1746132 INODE_ITEM 0) itemoff 15541 itemsize 160 > generation 188295 transid 188472 size 940 nbytes 4096 > block group 0 mode 100644 links 0 uid 465 gid 464 rdev 0 > sequence 16 flags 0x6(PREALLOC) > atime 1510830949.715375999 (2017-11-16 12:15:49) > ctime 1510838729.976180731 (2017-11-16 14:25:29) > mtime 1510830949.687375946 (2017-11-16 12:15:49) > otime 1510830949.687375946 (2017-11-16 12:15:49) > item 9 key (1746132 EXTENT_DATA 0) itemoff 15488 itemsize 53 > generation 188295 type 1 (regular) > extent data disk byte 470614016 nr 4096 > extent data offset 0 nr 4096 ram 4096 > extent compression 0 (none) > item 10 key (1746213 INODE_ITEM 0) itemoff 15328 itemsize 160 > generation 188342 transid 188819 size 6498 nbytes 8192 > block group 0 mode 100600 links 1 uid 0 gid 0 rdev 0 > sequence 0 flags 0x4(none) > atime 1510849204.24960545 (2017-11-16 17:20:04) > ctime 1510833103.94629539 (2017-11-16 12:51:43) > mtime 1510833103.86629524 (2017-11-16 12:51:43) > otime 1510833037.158509427 (2017-11-16 12:50:37) > ... > item 85 key (1746369 EXTENT_DATA 0) itemoff 7030 itemsize 53 > generation 188860 type 1 (regular) > extent data disk byte 368373760 nr 4096 > extent data offset 0 nr 4096 ram 4096 > extent compression 0 (none) > item 86 key (ORPHAN ORPHAN_ITEM 1746132) itemoff 7030 itemsize 0 > orphan item So, while trying to process inode 1746213, btrfs send runs finish_inode_if_needed() on 1746132, and fails to send the utimes for this inode because it can't figure out the path. The way I'm reading the btrfs code, it seems that btrfs-send assumes that all orphans have been cleaned up when it starts running. Indeed, btrfs should have got rid of orphan nodes by running btrfs_orphan_cleanup() via btrfs_cleanup_fs_roots() at mount time, but that doesn't seem to be the case. In fact, I've run btrfs-debug tree on this file system two times with different FS generations, and found that the orphan inode hat changed its position (inode number) in the tree. Unfortunately I didn't keep the output of the first debug run, but I'm positive that the inode number of the failing inode was in the 1743xxx range first, and is now 1746132. Therefore I'm filing this as a kernel bug. The problem was first seen with kernel 4.13.11-1.1.g0526da3 now I'm running 4.14.0-1.1.gab9e909. There are 3 aspects to this problem: 1) how did it come to pass? 2) why doesn't the kernel clean up the orphan at boot time? Why does the orphan change inode number? Or is the orphan actually cleaned, but a new one is generated instead? 3) how do I recover? I'd really love to get rid of this broken inode. I could simply switch to a different snapshot of the file system, but AFAICS as long as I don't delete the offending subvolume, the situation would persist. Anyway, as long as 1) and 2) are open, I guess I'd rather keep the subvolume around to facilitate further debugging. I'm unsure if this is easily reproducible. -- You are receiving this mail because: You are on the CC list for the bug.

2 21

[Bug 1175967] zypper dup from Tumbleweed 20200824 -> 20200826 fails
by bugzilla_noreply＠suse.com 01 Sep '20

01 Sep '20

https://bugzilla.suse.com/show_bug.cgi?id=1175967 https://bugzilla.suse.com/show_bug.cgi?id=1175967#c3 --- Comment #3 from Dirk S. <al13808(a)alte-leipziger.de> --- # rpm -qi rpm Name : rpm Version : 4.14.2.1 Release : 5.1 Architecture: i586 Install Date: Do 09 Jul 2020 16:59:09 CEST Group : System/Packages Size : 5270991 License : GPL-2.0-or-later Signature : RSA/SHA256, Fr 03 Mai 2019 22:44:43 CEST, Key ID b88b2fd43dbdc284 Source RPM : rpm-4.14.2.1-5.1.src.rpm Build Date : Fr 03 Mai 2019 22:44:02 CEST Build Host : cloud101 Relocations : (not relocatable) Packager : https://bugs.opensuse.org Vendor : openSUSE Summary : The RPM Package Manager Description : RPM Package Manager is the main tool for managing the software packages of the SUSE Linux distribution. RPM can be used to install and remove software packages. With rpm, it is easy to update packages. RPM keeps track of all these manipulations in a central database. This way it is possible to get an overview of all installed packages. RPM also supports database queries. Distribution: openSUSE Tumbleweed I'll post the zypper logs later. # zypper lr Repository priorities are without effect. All enabled repositories share the same priority. # | Alias | Name | Enabled | GPG Check | Refresh --+---------------------+-----------------------------+---------+-----------+-------- 1 | openSUSE-20190512-0 | openSUSE-20190512-0 | No | ---- | ---- 2 | openSUSE_20190512-0 | openSUSE-20190512-0 | Yes | (r ) Yes | No 3 | repo-debug | openSUSE-Tumbleweed-Debug | Yes | (r ) Yes | No 4 | repo-non-oss | openSUSE-Tumbleweed-Non-Oss | Yes | (r ) Yes | No 5 | repo-oss | openSUSE-Tumbleweed-Oss | Yes | (r ) Yes | No 6 | repo-source | openSUSE-Tumbleweed-Source | Yes | (r ) Yes | No 7 | repo-update | openSUSE-Tumbleweed-Update | Yes | (r ) Yes | No -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1175947] New: [Build 20200825] openQA test fails in zdup from Leap 15.0 to Tumbleweed - cannot stat '/mnt/boot/vmlinuz'
by bugzilla_noreply＠suse.com 01 Sep '20

01 Sep '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1175947 Bug ID: 1175947 Summary: [Build 20200825] openQA test fails in zdup from Leap 15.0 to Tumbleweed - cannot stat '/mnt/boot/vmlinuz' Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: aarch64 URL: https://openqa.opensuse.org/tests/1377991/modules/zdup /steps/362 OS: Other Status: NEW Severity: Major Priority: P5 - None Component: Bootloader Assignee: screening-team-bugs(a)suse.de Reporter: guillaume.gardet(a)arm.com QA Contact: qa-bugs(a)suse.de CC: afaerber(a)suse.com, dmueller(a)suse.com Found By: --- Blocker: --- ## Observation openQA test in scenario opensuse-Tumbleweed-DVD-aarch64-zdup-Leap-15.0-gnome@aarch64 fails in [zdup](https://openqa.opensuse.org/tests/1377991/modules/zdup/steps/362) It fails with: ********** [Ruby] bootloader/kexec.rb:110 Copy kernel and initrd failed, output: {"exit"=>1, "stderr"=>"/bin/cp: cannot stat '/mnt/boot/vmlinuz': No such file or directory\n", "stdout"=>""} ********** ## Test suite description 202000407 - ggardet - DO NOT INCLUDE QEMUVGA=cirrus - https://progress.opensuse.org/issues/65265 ## Reproducible Fails since (at least) Build [20200825](https://openqa.opensuse.org/tests/1375209) ## Expected result Last good: [20200824](https://openqa.opensuse.org/tests/1372254) (or more recent) ## Further details Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=aarch64&distri=opensu… -- You are receiving this mail because: You are on the CC list for the bug.

1 4