January 2021 - openSUSE Kubic Bugs - openSUSE Mailing Lists

[Bug 1175850] MicroOS Desktop can't reboot?
by bugzilla_noreply＠suse.com 12 Jan '21

12 Jan '21

https://bugzilla.suse.com/show_bug.cgi?id=1175850 https://bugzilla.suse.com/show_bug.cgi?id=1175850#c19 --- Comment #19 from Fabian Vogt <fvogt(a)suse.com> --- (In reply to Franck Bui from comment #18) > (In reply to Fabian Vogt from comment #17) > > It's about shutdown. udevd needs /etc and /etc needs /var. Somehow > > unmounting /var triggers udev to start: > > [ OK ] Stopped Rule-based Manager for Device Events and Files. > > ... > > [ OK ] Unmounted /etc. > > ... > > Unmounting /var... > > Again both /etc and /var are setup in initrd so both shouldn't be unmounted > by PID1 during shutdown. If 'x-initrd.mount' option is specified for both, > this sequence should not happen. So is that a systemd bug? > > I'm not getting any log output from that though: > > With "debug console=ttyS0" options in the kernel command line, I can see the > logs: For unlocking through the usb keyboard I had to specify both consoles, so it probably wrote to the wrong one. I switched over to serial over socat and I get this: [ 67.699353] systemd-shutdown[1]: Sending SIGTERM to remaining processes... [ 67.706055] systemd-shutdown[1]: Sending SIGKILL to remaining processes... [ 67.707994] systemd-shutdown[1]: Process 157 (haveged) has been marked to be excluded from killing. It is running from the root file system, and thus likely to block re-mounting of the root file system to read-only. Please consider moving it into an initrd file system instead. [ 67.712326] systemd-shutdown[1]: Unmounting file systems. [ 67.713663] systemd-shutdown[1]: Successfully forked off '(sd-remount)' as PID 2369. [ 67.714012] [2369]: Remounting '/' read-only in with options 'space_cache,subvolid=267,subvol=/(a)/.snapshots/1/snapshot'. [ 67.717475] BTRFS info (device dm-1): disk space caching is enabled [ 67.777923] systemd-shutdown[1]: All filesystems unmounted. [ 67.779707] systemd-shutdown[1]: Deactivating swaps. [ 67.781239] systemd-shutdown[1]: All swaps deactivated. [ 67.782804] systemd-shutdown[1]: Detaching loop devices. [ 67.784375] systemd-shutdown[1]: sd-device-enumerator: Scan all dirs [ 67.786272] systemd-shutdown[1]: sd-device-enumerator: Scanning /sys/bus [ 67.788220] systemd-shutdown[1]: sd-device-enumerator: Scanning /sys/class [ 67.788994] systemd-shutdown[1]: All loop devices detached. [ 67.789581] systemd-shutdown[1]: Detaching DM devices. [ 67.790140] systemd-shutdown[1]: sd-device-enumerator: Scan all dirs [ 67.790810] systemd-shutdown[1]: sd-device-enumerator: Scanning /sys/bus [ 67.791516] systemd-shutdown[1]: sd-device-enumerator: Scanning /sys/class [ 67.792545] systemd-shutdown[1]: Detaching DM /dev/dm-0 (254:0). [ 67.806188] systemd-shutdown[1]: Not all DM devices detached, 1 left. [ 67.807314] systemd-shutdown[1]: Couldn't finalize remaining DM devices, trying again. [ 67.809246] systemd-shutdown[1]: Detaching DM devices. [ 67.810335] systemd-shutdown[1]: sd-device-enumerator: Scan all dirs [ 67.811638] systemd-shutdown[1]: sd-device-enumerator: Scanning /sys/bus [ 67.813034] systemd-shutdown[1]: sd-device-enumerator: Scanning /sys/class [ 67.814653] systemd-shutdown[1]: Not all DM devices detached, 1 left. [ 67.816156] systemd-shutdown[1]: Detaching DM devices. [ 67.817216] systemd-shutdown[1]: sd-device-enumerator: Scan all dirs [ 67.818263] systemd-shutdown[1]: sd-device-enumerator: Scanning /sys/bus [ 67.819188] systemd-shutdown[1]: sd-device-enumerator: Scanning /sys/class [ 67.820292] systemd-shutdown[1]: Not all DM devices detached, 1 left. [ 67.821183] systemd-shutdown[1]: Cannot finalize remaining DM devices, continuing. [ 67.822380] systemd-shutdown[1]: Successfully forked off '(sd-executor)' as PID 2370. [ 67.823453] systemd-shutdown[1]: (sd-executor) succeeded. [ 67.824193] systemd-shutdown[1]: Failed to finalize DM devices, ignoring. [ 67.825249] systemd-shutdown[1]: Successfully forked off '(sd-sync)' as PID 2371. [ 67.826269] systemd-shutdown[1]: Syncing filesystems and block devices. [ 67.827169] systemd-shutdown[1]: Rebooting. [ 67.854207] reboot: Restarting system [ 67.854659] reboot: machine restart I got rid of haveged, but it still fails. It seems to finalize cr_var properly though, so it's working as expected? -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1175850] MicroOS Desktop can't reboot?
by bugzilla_noreply＠suse.com 12 Jan '21

12 Jan '21

https://bugzilla.suse.com/show_bug.cgi?id=1175850 https://bugzilla.suse.com/show_bug.cgi?id=1175850#c18 --- Comment #18 from Franck Bui <fbui(a)suse.com> --- (In reply to Fabian Vogt from comment #17) > It's about shutdown. udevd needs /etc and /etc needs /var. Somehow > unmounting /var triggers udev to start: > [ OK ] Stopped Rule-based Manager for Device Events and Files. > ... > [ OK ] Unmounted /etc. > ... > Unmounting /var... Again both /etc and /var are setup in initrd so both shouldn't be unmounted by PID1 during shutdown. If 'x-initrd.mount' option is specified for both, this sequence should not happen. > > I'm not getting any log output from that though: > With "debug console=ttyS0" options in the kernel command line, I can see the logs: > [ 37.852886] systemd-shutdown[1]: Found cgroup2 on /sys/fs/cgroup/unified, unified hierarchy for systemd controller > [ 37.855838] systemd-shutdown[1]: Successfully forked off '(sd-sync)' as PID 1534. > [ 37.856985] systemd-shutdown[1]: Syncing filesystems and block devices. > [ 37.868560] systemd-shutdown[1]: binfmt_misc is not mounted, not detaching entries. > [ 37.869442] systemd-shutdown[1]: Sending SIGTERM to remaining processes... > [ 37.887328] systemd-shutdown[1]: Sending SIGKILL to remaining processes... -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1180808] New: transactional-update: /usr needs newer timestamp than /etc
by bugzilla_noreply＠suse.com 12 Jan '21

12 Jan '21

https://bugzilla.suse.com/show_bug.cgi?id=1180808 Bug ID: 1180808 Summary: transactional-update: /usr needs newer timestamp than /etc Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Major Priority: P5 - None Component: MicroOS Assignee: kubic-bugs(a)opensuse.org Reporter: kukuk(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- According to bsc#1180549, we need to make sure after an transactional-update that /usr has a newer timestamp than /etc at the next boot -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 1175850] MicroOS Desktop can't reboot?
by bugzilla_noreply＠suse.com 11 Jan '21

11 Jan '21

https://bugzilla.suse.com/show_bug.cgi?id=1175850 https://bugzilla.suse.com/show_bug.cgi?id=1175850#c17 --- Comment #17 from Fabian Vogt <fvogt(a)suse.com> --- (In reply to Franck Bui from comment #16) > (In reply to Fabian Vogt from comment #15) > > (In reply to Fabian Vogt from comment #14) > > > Created attachment 844939 [details] > > > systemd debug logs > > > > > > (In reply to Franck Bui from comment #13) > > > > In reply to Fabian Vogt from comment #11) > > > > > So if unmounting /var needs udev, there's a cycle... > > > > > Apparently cryptsetup@ units don't set a dependency on udev, so that's why > > > > > it fails that way. > > > > > > > > > > On boot there's no cycle, because /var and /etc are mounted from the initrd > > > > > using the initrd's udev. > > > > > > > > Then both /var and /etc are supposed to be unmounted in initrd, no ? > > > > > > AFAICT the initrd is not used during shutdown currently. > > > > I can trigger that manually by touching /run/initramfs/.need_shutdown only. > > > > > > What do /etc/{fstab,crypttab} look like on the affected systems ? > > > > > > I just installed MicroOS with encrypted / and /var partitions and was able > > > to reproduce the problem. > > > > > > f224:~ # cat /etc/crypttab > > > cr_root UUID=1621a42e-c635-4b81-88a7-475267426692 none x-initrd.attach > > > cr_var UUID=1d90dc3a-c9e2-4971-b8da-4751351c94a5 > > > > I can't reproduce the issue anymore with "none x-initrd.attach" added to the > > cr_var entry here. > > Can you confirm that? > > yes, see man crypttab: > > All other encrypted block devices that contain file systems mounted in the > initramfs should use this option. > > > The /var+systemd-udevd cycle still exists > > Why ? if both /var and /etc are setup in initrd, there shouldn't be any > cycle with udevd (running in the host at least). It's about shutdown. udevd needs /etc and /etc needs /var. Somehow unmounting /var triggers udev to start: [ OK ] Stopped Rule-based Manager for Device Events and Files. ... [ OK ] Unmounted /etc. ... Unmounting /var... ... shutdown.target: starting held back, waiting for: systemd-remount-fs.service umount.target: starting held back, waiting for: var.mount systemd-udevd-kernel.socket: Incoming traffic systemd-udevd.service: Trying to enqueue job systemd-udevd.service/start/replace ... Requested transaction contradicts existing jobs: Transaction for systemd-udevd.service/start is destructive (systemd-reboot.service has 'start' job queued, but 'stop' is included in transaction). systemd-udevd-kernel.socket: Failed to queue service startup job (Maybe the service file is missing or not a non-template unit?): Transaction for systemd-udevd.service/start is destructive (systemd-reboot.service has 'start' job queued, but 'stop' is included in transaction). ... [ OK ] Unmounted /var. > > Your commit introducing the x-initrd.attach option > > (https://github.com/systemd/systemd/commit/ > > 1dc85eff1d0dff18aaeaae530c91bf53f34b726e) implies that the initrd is entered > > again on shutdown, but that doesn't seem to be triggered. Maybe the presence > > of x-initrd.attach should do that? It's not clear to me whether the device > > is still getting detached properly on shutdown. > > Actually it's done by /usr/lib/systemd/systemd-shutdown, this binary will > try to unmount all remaining file systems, disable all remaining swap > devices, detach all remaining storage devices and kill all remaining > processes, see man systemd-shutdown. I'm not getting any log output from that though: [ OK ] Finished Reboot. Forcibly rebooting: unit systemd-reboot.service succeeded reboot.target changed dead -> active reboot.target: Job 567 reboot.target/start finished, result=done [ OK ] Reached target Reboot. Shutting down. systemd-journald.service: Releasing resources. systemd-journald.service: Releasing all stored fds [ 75.194224] BTRFS info (device dm-1): disk space caching is enabled [ 75.295280] reboot: Restarting system [ 75.298847] reboot: machine restart -- You are receiving this mail because: You are on the CC list for the bug.

1 0

Your Bugzilla bug list needs attention.
by bugzilla_noreply＠suse.com 10 Jan '21

10 Jan '21

[This e-mail has been automatically generated.] You have one or more bugs assigned to you in the Bugzilla bug tracking system (http://bugzilla.suse.com/) that require attention. All of these bugs are in either the CONFIRMED, NEW, or REOPENED state, and have not been touched in 7 days or more. You need to take a look at them, and decide on an initial action. Generally, this means one of three things: (1) You decide this bug is really quick to deal with (like, it's INVALID), and so you get rid of it immediately. (2) You decide the bug doesn't belong to you, and you reassign it to someone else. (Hint: if you don't know who to reassign it to, make sure that the Component field seems reasonable, and then use the "Reset Assignee to default" option.) (3) You decide the bug belongs to you, but you can't solve it this moment. Ignore this email until you are actively working on this bug, when you should set the status to IN_PROGRESS. To get a list of all affected bugs, you can use this URL (bookmark it if you like!): http://bugzilla.suse.com/buglist.cgi?bug_status=CONFIRMED&bug_status=NEW&bu… Or, you can use the general query page, at http://bugzilla.suse.com/query.cgi Appended below are the individual URLs to get to all of your affected bugs that haven't been touched for 7 days or more. You will get this message once a week until you've dealt with these bugs! security enhancement: no setuid -> http://bugzilla.suse.com/show_bug.cgi?id=1171174 live-add-yast-repos: uses openSUSE-release -> http://bugzilla.suse.com/show_bug.cgi?id=1172100 transactional-update: warn about reboot etc. -> http://bugzilla.suse.com/show_bug.cgi?id=1173261 transactional-update: Notification on failing update -> http://bugzilla.suse.com/show_bug.cgi?id=1176882 cockpit-ws image is unusable -> http://bugzilla.suse.com/show_bug.cgi?id=1177487 [Build 51.1_15.3][MicroOS] Unknown group 'render' in 50-udev-default.rules -> http://bugzilla.suse.com/show_bug.cgi?id=1179453

1 0

[Bug 1175850] MicroOS Desktop can't reboot?
by bugzilla_noreply＠suse.com 08 Jan '21

08 Jan '21

https://bugzilla.suse.com/show_bug.cgi?id=1175850 https://bugzilla.suse.com/show_bug.cgi?id=1175850#c16 Franck Bui <fbui(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(fbui(a)suse.com) | --- Comment #16 from Franck Bui <fbui(a)suse.com> --- (In reply to Fabian Vogt from comment #15) > (In reply to Fabian Vogt from comment #14) > > Created attachment 844939 [details] > > systemd debug logs > > > > (In reply to Franck Bui from comment #13) > > > In reply to Fabian Vogt from comment #11) > > > > So if unmounting /var needs udev, there's a cycle... > > > > Apparently cryptsetup@ units don't set a dependency on udev, so that's why > > > > it fails that way. > > > > > > > > On boot there's no cycle, because /var and /etc are mounted from the initrd > > > > using the initrd's udev. > > > > > > Then both /var and /etc are supposed to be unmounted in initrd, no ? > > > > AFAICT the initrd is not used during shutdown currently. > > I can trigger that manually by touching /run/initramfs/.need_shutdown only. > > > > What do /etc/{fstab,crypttab} look like on the affected systems ? > > > > I just installed MicroOS with encrypted / and /var partitions and was able > > to reproduce the problem. > > > > f224:~ # cat /etc/crypttab > > cr_root UUID=1621a42e-c635-4b81-88a7-475267426692 none x-initrd.attach > > cr_var UUID=1d90dc3a-c9e2-4971-b8da-4751351c94a5 > > I can't reproduce the issue anymore with "none x-initrd.attach" added to the > cr_var entry here. > Can you confirm that? yes, see man crypttab: All other encrypted block devices that contain file systems mounted in the initramfs should use this option. > The /var+systemd-udevd cycle still exists Why ? if both /var and /etc are setup in initrd, there shouldn't be any cycle with udevd (running in the host at least). > Your commit introducing the x-initrd.attach option > (https://github.com/systemd/systemd/commit/ > 1dc85eff1d0dff18aaeaae530c91bf53f34b726e) implies that the initrd is entered > again on shutdown, but that doesn't seem to be triggered. Maybe the presence > of x-initrd.attach should do that? It's not clear to me whether the device > is still getting detached properly on shutdown. Actually it's done by /usr/lib/systemd/systemd-shutdown, this binary will try to unmount all remaining file systems, disable all remaining swap devices, detach all remaining storage devices and kill all remaining processes, see man systemd-shutdown. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1175850] MicroOS Desktop can't reboot?
by bugzilla_noreply＠suse.com 08 Jan '21

08 Jan '21

https://bugzilla.suse.com/show_bug.cgi?id=1175850 https://bugzilla.suse.com/show_bug.cgi?id=1175850#c15 Fabian Vogt <fvogt(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(mike(a)flingtoad.co | |m), | |needinfo?(fbui(a)suse.com) --- Comment #15 from Fabian Vogt <fvogt(a)suse.com> --- (In reply to Fabian Vogt from comment #14) > Created attachment 844939 [details] > systemd debug logs > > (In reply to Franck Bui from comment #13) > > In reply to Fabian Vogt from comment #11) > > > So if unmounting /var needs udev, there's a cycle... > > > Apparently cryptsetup@ units don't set a dependency on udev, so that's why > > > it fails that way. > > > > > > On boot there's no cycle, because /var and /etc are mounted from the initrd > > > using the initrd's udev. > > > > Then both /var and /etc are supposed to be unmounted in initrd, no ? > > AFAICT the initrd is not used during shutdown currently. I can trigger that manually by touching /run/initramfs/.need_shutdown only. > > What do /etc/{fstab,crypttab} look like on the affected systems ? > > I just installed MicroOS with encrypted / and /var partitions and was able > to reproduce the problem. > > f224:~ # cat /etc/crypttab > cr_root UUID=1621a42e-c635-4b81-88a7-475267426692 none x-initrd.attach > cr_var UUID=1d90dc3a-c9e2-4971-b8da-4751351c94a5 I can't reproduce the issue anymore with "none x-initrd.attach" added to the cr_var entry here. Can you confirm that? The /var+systemd-udevd cycle still exists, but there's no attempt to detach cr_var. Your commit introducing the x-initrd.attach option (https://github.com/systemd/systemd/commit/1dc85eff1d0dff18aaeaae530c91bf53f…) implies that the initrd is entered again on shutdown, but that doesn't seem to be triggered. Maybe the presence of x-initrd.attach should do that? It's not clear to me whether the device is still getting detached properly on shutdown. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1175850] MicroOS Desktop can't reboot?
by bugzilla_noreply＠suse.com 08 Jan '21

08 Jan '21

https://bugzilla.suse.com/show_bug.cgi?id=1175850 https://bugzilla.suse.com/show_bug.cgi?id=1175850#c14 --- Comment #14 from Fabian Vogt <fvogt(a)suse.com> --- Created attachment 844939 --> https://bugzilla.suse.com/attachment.cgi?id=844939&action=edit systemd debug logs (In reply to Franck Bui from comment #13) > In reply to Fabian Vogt from comment #11) > > So if unmounting /var needs udev, there's a cycle... > > Apparently cryptsetup@ units don't set a dependency on udev, so that's why > > it fails that way. > > > > On boot there's no cycle, because /var and /etc are mounted from the initrd > > using the initrd's udev. > > Then both /var and /etc are supposed to be unmounted in initrd, no ? AFAICT the initrd is not used during shutdown currently. > What do /etc/{fstab,crypttab} look like on the affected systems ? I just installed MicroOS with encrypted / and /var partitions and was able to reproduce the problem. f224:~ # cat /etc/crypttab cr_root UUID=1621a42e-c635-4b81-88a7-475267426692 none x-initrd.attach cr_var UUID=1d90dc3a-c9e2-4971-b8da-4751351c94a5 f224:~ # cat /etc/fstab UUID=e8d1cd5b-6020-4cad-9d9d-15d547cc2b2c / btrfs ro 0 0 UUID=e8d1cd5b-6020-4cad-9d9d-15d547cc2b2c /usr/local btrfs subvol=/@/usr/local 0 0 UUID=e8d1cd5b-6020-4cad-9d9d-15d547cc2b2c /srv btrfs subvol=/@/srv 0 0 UUID=e8d1cd5b-6020-4cad-9d9d-15d547cc2b2c /root btrfs subvol=/(a)/root,x-initrd.mount 0 0 UUID=e8d1cd5b-6020-4cad-9d9d-15d547cc2b2c /opt btrfs subvol=/@/opt 0 0 UUID=e8d1cd5b-6020-4cad-9d9d-15d547cc2b2c /home btrfs subvol=/@/home 0 0 UUID=e8d1cd5b-6020-4cad-9d9d-15d547cc2b2c /boot/writable btrfs subvol=/@/boot/writable 0 0 UUID=e8d1cd5b-6020-4cad-9d9d-15d547cc2b2c /boot/grub2/x86_64-efi btrfs subvol=/@/boot/grub2/x86_64-efi 0 0 UUID=e8d1cd5b-6020-4cad-9d9d-15d547cc2b2c /boot/grub2/i386-pc btrfs subvol=/@/boot/grub2/i386-pc 0 0 UUID=e8d1cd5b-6020-4cad-9d9d-15d547cc2b2c /.snapshots btrfs subvol=/(a)/.snapshots 0 0 UUID=72a8d278-c003-4fb8-96dc-bdbf29dcd37a /var btrfs defaults,x-initrd.mount 0 0 overlay /etc overlay defaults,lowerdir=/sysroot/etc,upperdir=/sysroot/var/lib/overlay/1/etc,workdir=/sysroot/var/lib/overlay/work-etc,x-systemd.requires-mounts-for=/var,x-systemd.requires-mounts-for=/sysroot/var,x-initrd.mount 0 0 Logs of the full boot and shutdown with systemd.log_level=debug are attached. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1180689] New: MicroOS defaults to using the SUSE NTP pool
by bugzilla_noreply＠suse.com 08 Jan '21

08 Jan '21

https://bugzilla.suse.com/show_bug.cgi?id=1180689 Bug ID: 1180689 Summary: MicroOS defaults to using the SUSE NTP pool Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other URL: https://openqa.opensuse.org/tests/1545137/modules/ntp_ config_settings/steps/1 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: MicroOS Assignee: kubic-bugs(a)opensuse.org Reporter: fvogt(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: openQA Blocker: Yes It has to use the opensuse pool instead. Kubic is affected as well: https://openqa.opensuse.org/tests/1545143#step/ntp_config_settings/1 Plain Tumbleweed seems to be fine. ## Observation openQA test in scenario microos-Tumbleweed-DVD-x86_64-microos@64bit fails in [ntp_config_settings](https://openqa.opensuse.org/tests/1545137/modules/ntp_… ## Further details Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=microos… -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 1175850] MicroOS Desktop can't reboot?
by bugzilla_noreply＠suse.com 07 Jan '21

07 Jan '21

https://bugzilla.suse.com/show_bug.cgi?id=1175850 https://bugzilla.suse.com/show_bug.cgi?id=1175850#c13 Franck Bui <fbui(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fbui(a)suse.com --- Comment #13 from Franck Bui <fbui(a)suse.com> --- In reply to Fabian Vogt from comment #11) > So if unmounting /var needs udev, there's a cycle... > Apparently cryptsetup@ units don't set a dependency on udev, so that's why > it fails that way. > > On boot there's no cycle, because /var and /etc are mounted from the initrd > using the initrd's udev. Then both /var and /etc are supposed to be unmounted in initrd, no ? What do /etc/{fstab,crypttab} look like on the affected systems ? -- You are receiving this mail because: You are on the CC list for the bug.

1 0