June 2020 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1172273] snapper rollback considered harmful
by bugzilla_noreply＠suse.com 03 Jun '20

03 Jun '20

http://bugzilla.suse.com/show_bug.cgi?id=1172273 http://bugzilla.suse.com/show_bug.cgi?id=1172273#c4 Thorsten Kukuk <kukuk(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(kukuk(a)suse.com) | --- Comment #4 from Thorsten Kukuk <kukuk(a)suse.com> --- transactional-update has two rollback options: rollback [<number>] Set the current or given snapshot as default snapshot rollback last Set the last working snapshot as default snapshot The first option is compatible with snapper, the last one would be something we would need to teach snapper about, I think we can ignore that for now. The existing additional options for "snapper rollback <number>", which handle the additional snapshots, can be ignored and should only issue a warning, that they are ignored. As Ignaz wrote: we can assume that a system is using transactional-updates, if the root filesystem is read-only. So, if the root filesystem is read-only and snapper rollback is called, map the given snapshot number or the current snapshot number to a btrfs ID and make it the new default: btrfs subvolume set-default $BTRFS_ID /.snapshots afterwards, remove any cleaning algorithm from that snapshot: snapper ${SNAPPER_NO_DBUS} modify -c '' ${ROLLBACK_SNAPSHOT} -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1169815] MySQL/MariaDB error in version 10.2.31 (not in 10.2.29)
by bugzilla_noreply＠suse.com 03 Jun '20

03 Jun '20

http://bugzilla.suse.com/show_bug.cgi?id=1169815 http://bugzilla.suse.com/show_bug.cgi?id=1169815#c4 --- Comment #4 from Kristyna Streitova <kstreitova(a)suse.com> --- Thanks for the logs but there is nothing suspicious in it. But I saw that you asked on openSUSE forum [1] as well. In comment #7 you mentioned that you have your db in /home. This can be a problem as we recently enabled ProtectHome=true systemd option in the mariadb.service which prevents from accessing /home. Does ProtectHome=false make any change for you? [1] https://forums.opensuse.org/showthread.php/539869-MySQL-Mariadb-ERROR-1030-… -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1168390] Update disables kubelet again
by bugzilla_noreply＠suse.com 03 Jun '20

03 Jun '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1168390 http://bugzilla.opensuse.org/show_bug.cgi?id=1168390#c6 Richard Brown <rbrown(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Richard Brown <rbrown(a)suse.com> --- Fixed, thanks! -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1172413] ignition: better handling of missing config
by bugzilla_noreply＠suse.com 03 Jun '20

03 Jun '20

http://bugzilla.suse.com/show_bug.cgi?id=1172413 http://bugzilla.suse.com/show_bug.cgi?id=1172413#c6 --- Comment #6 from Ludwig Nussel <lnussel(a)suse.com> --- so ignition tries the providers in order and file is the first? What's the last provider? -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1149701] New: Ignition needs to autodetect the platform
by bugzilla_noreply＠novell.com 03 Jun '20

03 Jun '20

http://bugzilla.suse.com/show_bug.cgi?id=1149701 Bug ID: 1149701 Summary: Ignition needs to autodetect the platform Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kubic Assignee: iforster(a)suse.com Reporter: fvogt(a)suse.com QA Contact: qa-bugs(a)suse.de CC: kubic-bugs(a)opensuse.org Found By: --- Blocker: --- Currently the platform ignition runs on has to be specified manually on the kernel cmdline with ignition.platform.id and not specifying it at all breaks booting completely. What needs to happen instead is that if ignition.platform.id is not specified by ignition is supposed to run, it makes some educated guesses which platform it is running on (vmware, qemu, openstack, gce, etc.) and uses metal as fallback. ds-identify from cloud-init can serve as inspiration: https://github.com/cloud-init/cloud-init/blob/master/tools/ds-identify -- You are receiving this mail because: You are on the CC list for the bug.

2 3

[Bug 1172302] The Mesa-libGL-devel-32bit package is missing
by bugzilla_noreply＠suse.com 03 Jun '20

03 Jun '20

http://bugzilla.suse.com/show_bug.cgi?id=1172302 Stefan Dirsch <sndirsch(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P3 - Medium Status|NEW |CONFIRMED -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1172273] New: snapper rollback considered harmful
by bugzilla_noreply＠suse.com 03 Jun '20

03 Jun '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1172273 Bug ID: 1172273 Summary: snapper rollback considered harmful Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: MicroOS Assignee: kubic-bugs(a)opensuse.org Reporter: lnussel(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Not sure where to raise this. In a discussion with Ignatz yesterday I found out that one is not supposed to use snapper rollback in a transactional installation. snapper rollback would create a new snapshot of the btrfs filesystem and set that one as new default. Since snapper does not know about the overlay on /etc it does not modify /etc/fstab either. So the new snapshot would reuse the overlay fs of the current snapshot. In contrast transactional-update rollback only sets the specified number as new default. Ie doesn't create a clone. So that kind of rollback will just boot the old snapshot and continue on the overlayfs of that snapshot. That kind of behavior is quite surprising. Obvious solutions would be 1. have snapper recognize transactional mode and make rollback behave differently 2. make snapper rollback a noop with message, similar to how zypper refuses when in transactional mode. -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1172446] VUL-1: CVE-2020-13775: znc: allows attackers to trigger an application crash (NULL pointer dereference) if echo-message is not enabled and there is no network
by bugzilla_noreply＠suse.com 03 Jun '20

03 Jun '20

http://bugzilla.suse.com/show_bug.cgi?id=1172446 Maintenance Robot <maint-coord+maintenance_robot(a)suse.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P4 - Low -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1172449] New: network connection very slow after standby
by bugzilla_noreply＠suse.com 03 Jun '20

03 Jun '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1172449 Bug ID: 1172449 Summary: network connection very slow after standby Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Network Assignee: screening-team-bugs(a)suse.de Reporter: f4tmike(a)web.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- In the office I mounted a Windows drive. After a standby the network connection works very slowly. It does not matter if I copy via Dolphin or command line. I also disconnected and reconnected the network connection. Is any information required? dmesg, var/log?.. Operating System: openSUSE Tumbleweed 20200528 KDE Plasma Version: 5.18.5 KDE Frameworks Version: 5.70.0 Qt Version: 5.14.1 Kernel Version: 5.6.14-1-default OS Type: 64-bit Processors: 4 × Intel® Core™ i5-4590 CPU @ 3.30GHz Memory: 15,5 GiB -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1165739] New: [MicroOS] 9p modules are not in initrd, systems where cloud-init defines 9p mounts in fstab will stuck on reboot
by bugzilla_noreply＠novell.com 03 Jun '20

03 Jun '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1165739 Bug ID: 1165739 Summary: [MicroOS] 9p modules are not in initrd, systems where cloud-init defines 9p mounts in fstab will stuck on reboot Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kubic Assignee: kubic-bugs(a)opensuse.org Reporter: jobbara.artalmatlan(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Hello Team, In my installation attempts I used cloud-init to deploy MicroOS-20200214 system. I use virt-install to setup a KVM virtual machine and add host local paths to the VM as virtio / 9p filesystems. Here is the virt-install command to define the VM and the relevan part from user-data file. ############# virt-install --import --connect qemu:///system --name microos --ram 2048 --vcpus 1 --disk size=20,backing_store=/var/lib/libvirt/images/openSUSE-MicroOS.x86_64-ContainerHost-kvm-and-xen.qcow2,bus=virtio --disk /var/lib/libvirt/images/testing-cidata.iso,device=cdrom --os-variant=opensusetumbleweed --network bridge=virbr0,model=virtio --noautoconsole --filesystem type=mount,mode=mapped,source=/var/lib/container_volumes,target=containervolumes ############# ############# mounts: - [ containervolumes, /opt/foo/bar/volumes, 9p, "trans=virtio", "0", "0" ] ############# The first boot is successful, however after reboot the system will stuck in boot as filesystems from /etc/fstab require relevant modules exist in initrd. I see that virtio_net, virtio_blk, virtio_scsi is already included but the filesystem modules for 9p and 9pnet_virtio do not. After manually adding them to dracut.conf and running "transactional-update initrd" it works. ############## filesystems+="9p nfs" add_drivers+="9pnet_virtio" ############## ps: recovering from stuck boot is only possible by using a SPICE remote access to VM's graphical interface so one could pick the previous snapshot from Grub. Do you have any advice how to accomplish the same from serial console (virsh console)? Should you have any questions please let me know. Thank you, -- You are receiving this mail because: You are on the CC list for the bug.

2 6