Please note that this mail was generated by a script. The described changes are computed based on the x86_64 DVD. The full online repo contains too many changes to be listed here.
Please check the known defects of this snapshot before upgrading: https://openqa.opensuse.org/tests/overview?distri=opensuse&groupid=1&...
Please do not reply to this email to report issues, rather file a bug on bugzilla.opensuse.org. For more information on filing bugs please see https://en.opensuse.org/openSUSE:Submitting_bug_reports
Packages changed: coreutils (9.1 -> 9.2) gnome-control-center (44.0+7 -> 44.0+20) gnome-shell (44.0+28 -> 44.0+42) gobject-introspection gstreamer-plugins-bad kernel-source (6.2.8 -> 6.2.9) ldb (2.7.1 -> 2.7.2) libgarcon (4.18.0 -> 4.18.1) libheif (1.15.1 -> 1.15.2) libxcrypt mutter (44.0+8 -> 44.0+18) nfs-utils samba (4.18.0+git.294.508b693e5c -> 4.18.1+git.298.4ccf830b2a4) snapper thunar-plugin-archive (0.5.0 -> 0.5.1) timezone (2023b -> 2023c) timezone-java (2023b -> 2023c) util-linux util-linux-systemd vim (9.0.1392 -> 9.0.1430) xen (4.17.0_04 -> 4.17.0_06) xfce4-panel (4.18.2 -> 4.18.3) xfce4-pulseaudio-plugin (0.4.5 -> 0.4.6) xfce4-session (4.18.1 -> 4.18.2)
=== Details ===
==== coreutils ==== Version update (9.1 -> 9.2) Subpackages: coreutils-lang
- update to 9.2: * cksum now accepts the --base64 (-b) option to print base64-encoded checksums. It also accepts/checks such checksums. * cksum now accepts the --raw option to output a raw binary checksum. No file name or other information is output in this mode. * cp, mv, and install now accept the --debug option to print details on how a file is being copied. * factor now accepts the --exponents (-h) option to print factors in the form p^e, rather than repeating the prime p, e times. * ls now supports the --time=modification option, to explicitly select the default mtime timestamp for display and sorting. * mv now supports the --no-copy option, which causes it to fail when asked to move a file to a different file system. * split now accepts options like '-n SIZE' that exceed machine integer range, when they can be implemented as if they were infinity. * split -n now accepts piped input even when not in round-robin mode, by first copying input to a temporary file to determine its size. * wc now accepts the --total={auto,never,always,only} option to give explicit control over when the total is output. * 'cp --reflink=always A B' no longer leaves behind a newly created empty file B merely because copy-on-write clones are not supported. * 'cp -n' and 'mv -n' now exit with nonzero status if they skip their action because the destination exists, and likewise for 'cp - i', 'ln -i', and 'mv -i' when the user declines. (POSIX specifies this for 'cp -i' and 'mv -i'.) * cp, mv, and install again read in multiples of the reported block size, to support unusual devices that may have this constraint. * du --apparent now counts apparent sizes only of regular files and symbolic links. POSIX does not specify the meaning of apparent sizes (i.e., st_size) for other file types, and counting those sizes could cause confusing and unwanted size mismatches. * 'ls -v' and 'sort -V' go back to sorting ".0" before ".A", reverting to the behavior in coreutils-9.0 and earlier. This behavior is now documented. * ls --color now matches a file extension case sensitively if there are different sequences defined for separate cases. * printf unicode \uNNNN, \UNNNNNNNN syntax, now supports all valid unicode code points. Previously is was restricted to the C universal character subset, which restricted most points <= 0x9F. * runcon now exits with status 125 for internal errors. Previously upon internal errors it would exit with status 1, which was less distinguishable from errors from the invoked command. * 'split -n N' now splits more evenly when the input size is not a multiple of N, by creating N output files whose sizes differ by at most 1 byte. Formerly, it did this only when the input size was less than N. * 'stat -c %s' now prints sizes as unsigned, consistent with 'ls'. * a long list of bugfixes, see included NEWS file for details - drop gnulib-simple-backup-fix.patch (upstream) - drop coreutils-tests-workaround-make-fdleak.patch (obsolete)
==== gnome-control-center ==== Version update (44.0+7 -> 44.0+20) Subpackages: gnome-control-center-color gnome-control-center-goa gnome-control-center-lang gnome-control-center-user-faces
- Update to version 44.0+20: + datetime: Fix NTP switch getting out of sync. + shell/style: Add workaround to make disabled pictures are painted as such. + illustrated-row, split-row: Add widget name and css class. + region: Fix label of formats for the login screen. + keyboard: Fix cancel button issue. + Updated translations.
==== gnome-shell ==== Version update (44.0+28 -> 44.0+42) Subpackages: gnome-extensions gnome-shell-calendar gnome-shell-lang
- Update to version 44.0+42: + appFavorite: - Add missing .desktop extension for simplescan - Rename simple-scan.desktop + style: Light variant fixes and accommodations + extensionDownloader: Check schemadir existence and type + status/network: Fix a11y names for VPN connection menu items + quickSettings: Fix icon-name construct property in menu toggles + screenshot: Fix broken GLib.Error.matches call + Updated translations.
==== gobject-introspection ==== Subpackages: girepository-1_0 libgirepository-1_0-1
- Run meson_test only on x86(_64) arches until upstream issue is fixed. https://gitlab.gnome.org/GNOME/gobject-introspection/-/issues/458
==== gstreamer-plugins-bad ==== Subpackages: gstreamer-plugins-bad-lang libgstadaptivedemux-1_0-0 libgstbadaudio-1_0-0 libgstbasecamerabinsrc-1_0-0 libgstcodecparsers-1_0-0 libgstcodecs-1_0-0 libgstcuda-1_0-0 libgstisoff-1_0-0 libgstmpegts-1_0-0 libgstphotography-1_0-0 libgstplay-1_0-0 libgstplayer-1_0-0 libgstsctp-1_0-0 libgsttranscoder-1_0-0 libgsturidownloader-1_0-0 libgstva-1_0-0 libgstvulkan-1_0-0 libgstwayland-1_0-0 libgstwebrtc-1_0-0 libgstwebrtcnice-1_0-0
- Move conditional pkgconfig(vo-amrwbenc) BuildRequires to main part of spec, now available in distro. Stop passing voamrwbenc=disabled to meson.
==== kernel-source ==== Version update (6.2.8 -> 6.2.9)
- Linux 6.2.9 (bsc#1012628). - interconnect: qcom: osm-l3: fix icc_onecell_data allocation (bsc#1012628). - interconnect: qcom: sm8450: switch to qcom_icc_rpmh_* function (bsc#1012628). - interconnect: qcom: qcm2290: Fix MASTER_SNOC_BIMC_NRT (bsc#1012628). - perf/core: Fix perf_output_begin parameter is incorrectly invoked in perf_event_bpf_output (bsc#1012628). - perf: fix perf_event_context->time (bsc#1012628). - tracing/hwlat: Replace sched_setaffinity with set_cpus_allowed_ptr (bsc#1012628). - drm/amd/display: fix k1 k2 divider programming for phantom streams (bsc#1012628). - drm/amd/display: Remove OTG DIV register write for Virtual signals (bsc#1012628). - drm/amd/display: Fix DP MST sinks removal issue (bsc#1012628). - arm64: dts: freescale: imx8-ss-lsio: Fix flexspi clock order (bsc#1012628). - arm64: dts: qcom: sc8280xp: Add label property to vadc channel nodes (bsc#1012628). - arm64: dts: qcom: sm6375: Add missing power-domain-named to CDSP (bsc#1012628). - arm64: dts: qcom: sm8450: correct WSA2 assigned clocks (bsc#1012628). - arm64: dts: qcom: sm8450: Mark UFS controller as cache coherent (bsc#1012628). - power: supply: bq24190: Fix use after free bug in bq24190_remove due to race condition (bsc#1012628). - power: supply: da9150: Fix use after free bug in da9150_charger_remove due to race condition (bsc#1012628). - wifi: mt76: do not run mt76_unregister_device() on unregistered hw (bsc#1012628). - wifi: mt76: connac: do not check WED status for non-mmio devices (bsc#1012628). - efi: earlycon: Reprobe after parsing config tables (bsc#1012628). - arm64: dts: imx8dxl-evk: Disable hibernation mode of AR8031 for EQOS (bsc#1012628). - arm64: dts: imx8dxl-evk: Fix eqos phy reset gpio (bsc#1012628). - ARM: dts: imx6sll: e70k02: fix usbotg1 pinctrl (bsc#1012628). - ARM: dts: imx6sll: e60k02: fix usbotg1 pinctrl (bsc#1012628). - ARM: dts: imx6sl: tolino-shine2hd: fix usbotg1 pinctrl (bsc#1012628). - arm64: dts: imx8mn: specify #sound-dai-cells for SAI nodes (bsc#1012628). - arm64: dts: imx93: add missing #address-cells and #size-cells to i2c nodes (bsc#1012628). - NFS: Fix /proc/PID/io read_bytes for buffered reads (bsc#1012628). - NFS: Correct timing for assigning access cache timestamp (bsc#1012628). - xsk: Add missing overflow check in xdp_umem_reg (bsc#1012628). - iavf: fix inverted Rx hash condition leading to disabled hash (bsc#1012628). - iavf: fix non-tunneled IPv6 UDP packet type and hashing (bsc#1012628). - iavf: do not track VLAN 0 filters (bsc#1012628). - intel/igbvf: free irq on the error path in igbvf_request_msix() (bsc#1012628). - igbvf: Regard vf reset nack as success (bsc#1012628). - igc: fix the validation logic for taprio's gate list (bsc#1012628). - i2c: imx-lpi2c: check only for enabled interrupt flags (bsc#1012628). - i2c: mxs: ensure that DMA buffers are safe for DMA (bsc#1012628). - i2c: hisi: Only use the completion interrupt to finish the transfer (bsc#1012628). - scsi: scsi_dh_alua: Fix memleak for 'qdata' in alua_activate() (bsc#1012628). - nfsd: don't replace page in rq_pages if it's a continuation of last page (bsc#1012628). - net: dsa: b53: mmap: fix device tree support (bsc#1012628). - net: usb: smsc95xx: Limit packet length to skb->len (bsc#1012628). - qed/qed_sriov: guard against NULL derefs from qed_iov_get_vf_info (bsc#1012628). - xirc2ps_cs: Fix use after free bug in xirc2ps_detach (bsc#1012628). - net: phy: Ensure state transitions are processed from phy_stop() (bsc#1012628). - net: mdio: fix owner field for mdio buses registered using device-tree (bsc#1012628). - net: mdio: fix owner field for mdio buses registered using ACPI (bsc#1012628). - net: stmmac: Fix for mismatched host/device DMA address width (bsc#1012628). - thermal/drivers/mellanox: Use generic thermal_zone_get_trip() function (bsc#1012628). - mlxsw: core_thermal: Fix fan speed in maximum cooling state (bsc#1012628). - drm/i915/fbdev: lock the fbdev obj before vma pin (bsc#1012628). - drm/i915/mtl: Disable MC6 for MTL A step (bsc#1012628). - drm/i915/guc: Rename GuC register state capture node to be more obvious (bsc#1012628). - drm/i915/guc: Fix missing ecodes (bsc#1012628). - drm/i915/gt: perform uc late init after probe error injection (bsc#1012628). ... changelog too long, skipping 340 lines ... - commit c9a94ac
==== ldb ==== Version update (2.7.1 -> 2.7.2) Subpackages: libldb2 libldb2-32bit python3-ldb
- CVE-2023-0614: Access controlled AD LDAP attributes can be discovered (bso#15270); (bsc#1209485).
==== libgarcon ==== Version update (4.18.0 -> 4.18.1) Subpackages: libgarcon-1-0 libgarcon-data libgarcon-lang
- Update to version 4.18.1 * garcon-gtk: Add missing lock when filling the GtkMenu * Wait for any async operation to finish before releasing locks * Use GIcons for menu icons instead of loading surfaces * Revert "garcon-gtk: Fix menu icon blurriness when UI scale factor != 1" * Revert "Load icons using icon theme scaling functions correctly" * garcon-gtk: Properly update GtkMenu is_populated state * Load icons using icon theme scaling functions correctly * Translation Updates
==== libheif ==== Version update (1.15.1 -> 1.15.2) Subpackages: gdk-pixbuf-loader-libheif libheif1
- update to 1.15.2 * Fixes an incompatibility with AOM v3.6.0. * A couple of smaller fixes.
==== libxcrypt ==== Subpackages: libcrypt1 libcrypt1-32bit libxcrypt-devel
- Enable LTO now (boo#1138833) and use FAT LTO objects for static libs.
==== mutter ==== Version update (44.0+8 -> 44.0+18) Subpackages: mutter-lang
- Update to version 44.0+18: + backends: Use meta_gamma_lut_new_sized() in a few more places + compositor: - Drop anchor_window_pos field from MetaWindowDrag - Use relative anchor coordinates for window drags - Avoid use of variable during resize + onscreen/native: Avoid freezing the frame clock on failed cursor commits + window-actor-x11: Check array bounds before accessing array + build: Don't disable checks in release builds + tests: Use a more interoperable path to bash + backend/nested: Ignore setting pointer constraint + Updated translations. - Clean up spec, drop old disabled and unneeded pkgconfig(gtk+-3.0) BuildRequires and move disabled patches to SLE.
==== nfs-utils ==== Subpackages: libnfsidmap1 nfs-client nfs-kernel-server
- Add 0007-mount.nfs-always-include-mountpoint-or-spec-if-error.patch boo#1157881 - Add 0008-nfsd.man-fix-typo-in-section-on-scope.patch bsc#1209859 - Allow scope to be sed in sysconfig: NFSD_SCOPE - Add explicit pkgconfig(libkeyutils) BuildRequires: nfs-utils requires this for nfsv4 and we should not rely on the devel package being brought in by other deps.
==== samba ==== Version update (4.18.0+git.294.508b693e5c -> 4.18.1+git.298.4ccf830b2a4) Subpackages: libsamba-policy0-python3 samba-ad-dc-libs samba-ad-dc-libs-32bit samba-client samba-client-32bit samba-client-libs samba-client-libs-32bit samba-gpupdate samba-ldb-ldap samba-libs samba-libs-32bit samba-libs-python3 samba-python3 samba-winbind samba-winbind-libs samba-winbind-libs-32bit
- Update to 4.18.1 * CVE-2023-0225: AD DC "dnsHostname" attribute can be deleted by unprivileged authenticated users. (bso#15276);(bsc#1209483). * CVE-2023-0614: Access controlled AD LDAP attributes can be discovered (bso#15270); (bsc#1209485). * CVE-2023-0922: Samba AD DC admin tool samba-tool sends passwords in cleartext(bso#15315);(bsc#1209481). * ldb wildcard matching makes excessive allocations; (bso#15331). * large_ldap test is inefficient; (bso#15332).
==== snapper ==== Subpackages: libsnapper6 snapper-zypp-plugin
- use xz compression instead of bzip2 for source tar (gh#openSUSE/snapper#277)
==== thunar-plugin-archive ==== Version update (0.5.0 -> 0.5.1) Subpackages: thunar-plugin-archive-lang
- Update to version 0.5.1 * Fix use-after-free crash in "tap_provider_child_watch_destroy" * build: Add GLib requirement * build: Fix autotools warnings * Use generic package icon name in dialog header * Translation Updates
==== timezone ==== Version update (2023b -> 2023c)
- timezone update 2023c: * Reverts changes for 2023 Lebanon DST change to 2023a data
==== timezone-java ==== Version update (2023b -> 2023c)
- timezone update 2023c: * Reverts changes for 2023 Lebanon DST change to 2023a data
==== util-linux ==== Subpackages: libblkid1 libblkid1-32bit libfdisk1 libmount1 libmount1-32bit libsmartcols1 libuuid1 libuuid1-32bit util-linux-lang
- login.pamd, remote.pamd: include postlogin-* rules - runuser.pamd, su.pamd: Include common-session-nonlogin instead of common-session
==== util-linux-systemd ====
- login.pamd, remote.pamd: include postlogin-* rules - runuser.pamd, su.pamd: Include common-session-nonlogin instead of common-session
==== vim ==== Version update (9.0.1392 -> 9.0.1430) Subpackages: vim-data vim-data-common
- Updated to version 9.0.1430, fixes the following problems * The included xdiff code is a bit outdated. * Lean files are not recognized. * Build failure because SIZE_MAX is not defined. * Nu files are not recognized. * Sage files are not recognized. * WebAssembly Interface Type files are not recognized. * Unused macros are defined. * "wat" and "wast" files are one filetype. * Indent wrong after "export namespace" in C++. * Warning for uninitialized variable. (Tony Mechelynck) * Cursor in wrong position when leaving insert mode. * Invalid memory access when ending insert mode. * Livebook files are not recognized. - Create a standalone package for xxd * This is used by non-vim tools too - Updated to version 9.0.1418, fixes the following problems - fixes CVE-2023-1355 * Using NULL pointer with nested :open command. * Cairo files are not recognized. * Unx Tal files are not recognized. * Odin files are not recognized. * sort(list, 'N') does not work in Vim9 script context. * Highlight for popupmenu kind and extra cannot be set. * Profile test repeats the headers many times. * Highlight test script has a few problems. * find_file_in_path() is not reentrant. * Condition is always true. * Crash when using null_class. * Unused variables and functions. * Compilation error with some compilers. * Missing check for out-of-memory. * ILE RPG files are not recognized. * TableGen files are not recognized. * QMLdir files are not recognized. * Racket files are recognized as scheme. * Accuracy of profiling is not optimal. * Pony files are not recognized. * Compiler warning for unused variable. * <M-S-x> in Kitty does not use the Shift modifier. * Crystal files are not recognized. * Crash when collection is modified when using filter(). * ESDL files are not recognized. * The included xdiff code is a bit outdated.
==== xen ==== Version update (4.17.0_04 -> 4.17.0_06) Subpackages: xen-libs xen-tools xen-tools-domU
- Upstream bug fixes (bsc#1027519) 63a03b73-VMX-VMExit-based-BusLock-detection.patch 63a03ba6-VMX-INTR_SHADOW_NMI-helper.patch 63a03bce-VMX-Notify-VMExit.patch 63e53ac9-x86-CPUID-leaves-7-1-ecx-edx.patch 63e53ac9-x86-disable-CET-SS-when-fractured-updates.patch 63f4d045-x86-ucode-AMD-apply-early-on-all-threads.patch 63fe06e0-x86-ucode-AMD-apply-late-on-all-threads.patch 641041e8-VT-d-constrain-IGD-check.patch 6419697d-AMD-IOMMU-no-XT-x2APIC-phys.patch - Use "proper" upstream backports: 640f3035-x86-altp2m-help-gcc13.patch 64104238-bunzip-gcc13.patch 64199e0c-x86-shadow-account-for-log-dirty-mode.patch 64199e0d-x86-HVM-bound-number-of-pca-regions.patch 64199e0e-x86-HVM-serialize-pca-list-manipulation.patch 64199e0f-x86-spec-ctrl-defer-CR4_PV32_RESTORE-for-CSTAR.patch - ... in place of: bunzip-gcc13.patch altp2m-gcc13.patch xsa427.patch xsa428-1.patch xsa428-2.patch xsa429.patch - bsc#1209245 - fix host-assisted kexec/kdump for HVM domUs libxl.fix-guest-kexec-skip-cpuid-policy.patch - bsc#1209017 - VUL-0: CVE-2022-42332: xen: x86 shadow plus log-dirty mode use-after-free (XSA-427) xsa427.patch - bsc#1209018 - VUL-0: CVE-2022-42333,CVE-2022-42334: xen: x86/HVM pinned cache attributes mis-handling (XSA-428) xsa428-1.patch xsa428-2.patch - bsc#1209019 - VUL-0: CVE-2022-42331: xen: x86: speculative vulnerability in 32bit SYSCALL path (XSA-429) xsa429.patch
==== xfce4-panel ==== Version update (4.18.2 -> 4.18.3) Subpackages: libxfce4panel-2_0-4 xfce4-panel-lang xfce4-panel-restore-defaults
- Update to version 4.18.3 * launcher: Show action menu also when there are several items * Fix memory management of vala generated plugins * panel: Rephrase "Don't reserve space on borders" (V2) * panel: Make property migration generic * launcher: Avoid "no trigger event" warning when showing the menu * launcher: Guard access to the plugin menu GdkWindow * libxfce4panel: Unregister menu also on GtkWidget::hide * panel: Do not reset output name if a monitor does not have a model name * libxfce4panel: Fix memory management of source for menu positioning * panel: Delay removal of ExternalPlugin to prevent use-after-free * systray: Cancel any async D-Bus operation in finalize() * tasklist: Do not try to resolve /proc/pid/exe to launch new instance * Translation Updates
==== xfce4-pulseaudio-plugin ==== Version update (0.4.5 -> 0.4.6) Subpackages: xfce4-pulseaudio-plugin-lang
- Update to version 0.4.6 * Fix changing default sink and source devices * Fix flickering mic icon when recording application is connected * Avoid critical from xfce4-notifyd if gauge_value > 100 * Display maximum volume of all channels instead of volume of left channel * Add recording base volume indicator * Control mic volume/mute when mouse cursor is over the mic icon * Lower warning level * Improve volume notifications settings * Show volume notifications from hotkeys according to comment * Don't set negative volume from hotkeys * Use correct variable for "volume-mic-changed" signal ID * Don't force set the default device * Set recording icon according to recording volume level * Show source monitor if it is a default source * Check for recording state on context ready * Allow volume step configuration in dialog (gxo#panel-plugins/xfce4-pulseaudio-plugin#28) * wnck: Add missing LIBS/CFLAGS in Makefile * wnck: Use Libxfce4windowing when available * wnck: Guard X11 code path to prevent crash on Wayland * wnck: Improve RaiseWnck a bit * Fix memory leak * cleanup: Fix formatting * Fix blurry media player icon from file when UI scale > 1 * Fix blurry icons in prefs dialog when UI scale factor > 1 * Use "logo-icon-name" instead of "logo" in about dialog * Do not override fatal log level * build: Bump GLib minimum required to 2.44 * Translation Updates
==== xfce4-session ==== Version update (4.18.1 -> 4.18.2) Subpackages: xfce4-session-lang
- Update to version 4.18.2 * manager: Fix GQueue memory management * Fix Xfconf memory management * Update bug report address * Fix suspend/hibernation bug on ConsoleKit2 (Fixes #164)
Hi there,
On Mon, 03 Apr 2023, 12:00:22 +0200, Dominique Leuenberger wrote:
[...] Packages changed: [...] kernel-source (6.2.8 -> 6.2.9)
does anybody also have problems booting the new kernel? It panics here on all my systems when swithing the root filesystem.
Common to all my systems is they are all Intel based and use an NVME boot disk. I'll try to capture the console logs next, but thought I'd check if anybody can confirm this failure.
FWIW, the kernel from Kernel:stable shows the same, while the same 6.2.9 kernel from Kernel:stable:Backport boots happily on Leap 15.4...
TIA, cheers.
l8er manfred
On 04.04.23 10:48, Manfred Hollstein wrote:
Hi there,
On Mon, 03 Apr 2023, 12:00:22 +0200, Dominique Leuenberger wrote:
[...] Packages changed: [...] kernel-source (6.2.8 -> 6.2.9)
does anybody also have problems booting the new kernel? It panics here on all my systems when swithing the root filesystem.
Common to all my systems is they are all Intel based and use an NVME boot disk. I'll try to capture the console logs next, but thought I'd check if anybody can confirm this failure.
snapshot 0401 or 0402? 0402 also contains an update for libnvme...
FWIW, the kernel from Kernel:stable shows the same, while the same 6.2.9 kernel from Kernel:stable:Backport boots happily on Leap 15.4...
...which does not have the libnvme update...
On Tue, 04 Apr 2023, 18:33:24 +0200, Stefan Seyfried via openSUSE Factory wrote:
On 04.04.23 10:48, Manfred Hollstein wrote:
Hi there,
On Mon, 03 Apr 2023, 12:00:22 +0200, Dominique Leuenberger wrote:
[...] Packages changed: [...] kernel-source (6.2.8 -> 6.2.9)
does anybody also have problems booting the new kernel? It panics here on all my systems when swithing the root filesystem.
Common to all my systems is they are all Intel based and use an NVME boot disk. I'll try to capture the console logs next, but thought I'd check if anybody can confirm this failure.
snapshot 0401 or 0402? 0402 also contains an update for libnvme...
Looking at /var/log/zypp/history I probably skipped 0401...
FWIW, the kernel from Kernel:stable shows the same, while the same 6.2.9 kernel from Kernel:stable:Backport boots happily on Leap 15.4...
...which does not have the libnvme update...
... which might explain the difference, indeed!
Stefan Seyfried
Cheers.
l8er manfred
On Tue, 2023-04-04 at 18:57 +0200, Manfred Hollstein wrote:
On Tue, 04 Apr 2023, 18:33:24 +0200, Stefan Seyfried via openSUSE Factory wrote:
On 04.04.23 10:48, Manfred Hollstein wrote:
Hi there,
On Mon, 03 Apr 2023, 12:00:22 +0200, Dominique Leuenberger wrote:
[...] Packages changed: [...] kernel-source (6.2.8 -> 6.2.9)
does anybody also have problems booting the new kernel? It panics here on all my systems when swithing the root filesystem.
Common to all my systems is they are all Intel based and use an NVME boot disk. I'll try to capture the console logs next, but thought I'd check if anybody can confirm this failure.
snapshot 0401 or 0402? 0402 also contains an update for libnvme...
Looking at /var/log/zypp/history I probably skipped 0401...
FWIW, the kernel from Kernel:stable shows the same, while the same 6.2.9 kernel from Kernel:stable:Backport boots happily on Leap 15.4...
...which does not have the libnvme update...
... which might explain the difference, indeed!
Hm, libnvme is not necessary to boot from NVMe/PCIe storage. I guess it's not impossible that some interaction between nvme-cli calls and the kernel could cause a kernel panic, but I doubt it would happen this early in the boot sequence (while switching root). A bug report with boot logs would be desirable.
Rerards Martin
On Tue, 04 Apr 2023, 23:09:15 +0200, Martin Wilck wrote:
On Tue, 2023-04-04 at 18:57 +0200, Manfred Hollstein wrote:
On Tue, 04 Apr 2023, 18:33:24 +0200, Stefan Seyfried via openSUSE Factory wrote:
On 04.04.23 10:48, Manfred Hollstein wrote:
Hi there,
On Mon, 03 Apr 2023, 12:00:22 +0200, Dominique Leuenberger wrote:
[...] Packages changed: [...] kernel-source (6.2.8 -> 6.2.9)
does anybody also have problems booting the new kernel? It panics here on all my systems when swithing the root filesystem.
Common to all my systems is they are all Intel based and use an NVME boot disk. I'll try to capture the console logs next, but thought I'd check if anybody can confirm this failure.
snapshot 0401 or 0402? 0402 also contains an update for libnvme...
Looking at /var/log/zypp/history I probably skipped 0401...
FWIW, the kernel from Kernel:stable shows the same, while the same 6.2.9 kernel from Kernel:stable:Backport boots happily on Leap 15.4...
...which does not have the libnvme update...
... which might explain the difference, indeed!
Hm, libnvme is not necessary to boot from NVMe/PCIe storage. I guess it's not impossible that some interaction between nvme-cli calls and the kernel could cause a kernel panic, but I doubt it would happen this early in the boot sequence (while switching root). A bug report with boot logs would be desirable.
I have a photo of it, do you think it would suffice? If not, how do I capture boot logs at this early stage?
Rerards Martin
Cheers.
l8er manfred
Manfred Hollstein composed on 2023-04-04 10:48 (UTC+0200):
On Mon, 03 Apr 2023, 12:00:22 +0200, Dominique Leuenberger wrote:
[...] Packages changed: [...] kernel-source (6.2.8 -> 6.2.9)
does anybody also have problems booting the new kernel? It panics here on all my systems when swithing the root filesystem.
Common to all my systems is they are all Intel based and use an NVME boot disk. I'll try to capture the console logs next, but thought I'd check if anybody can confirm this failure.
FWIW, the kernel from Kernel:stable shows the same, while the same 6.2.9 kernel from Kernel:stable:Backport boots happily on Leap 15.4...
I have 3 TW that boot from NVME. I just upgraded to 20230403 & 6.2.9 on the first to find no problem booting to multi-user:
# inxi -CSM System: Host: ab560 Kernel: 6.2.9-1-default arch: x86_64 bits: 64 Console: pty pts/0 Distro: openSUSE Tumbleweed 20230403 Machine: Type: Desktop System: ASUS product: N/A v: N/A serial: N/A Mobo: ASUSTeK model: PRIME B560M-A v: Rev 1.xx serial: 210787670000384 UEFI: American Megatrends v: 1601 date: 05/07/2022 CPU: Info: 6-core model: 11th Gen Intel Core i5-11400 bits: 64 type: MT MCP cache: L2: 3 MiB Speed (MHz): avg: 2600 min/max: 800/4400 cores: 1: 2600 2: 2600 3: 2600 4: 2600 5: 2600 6: 2600 7: 2600 8: 2600 9: 2600 10: 2600 11: 2600 12: 2600
Booting to graphical.target, however, takes too long to get started, with X running on /dev/dri/card1 instead of /dev/dri/card0: # systemd-analyze Startup finished in 12.553s (firmware) + 12.289s (loader) + 1.441s (kernel) + 1.935s (initrd) + 1min 30.849s (userspace) = 1min 59.068s graphical.target reached after 1min 30.778s in userspace. https://bugzilla.opensuse.org/show_bug.cgi?id=1206316
On Wed, 05 Apr 2023, 09:30:38 +0200, Manfred Hollstein wrote:
On Tue, 04 Apr 2023, 23:09:15 +0200, Martin Wilck wrote:
On Tue, 2023-04-04 at 18:57 +0200, Manfred Hollstein wrote:
On Tue, 04 Apr 2023, 18:33:24 +0200, Stefan Seyfried via openSUSE Factory wrote:
On 04.04.23 10:48, Manfred Hollstein wrote:
Hi there,
On Mon, 03 Apr 2023, 12:00:22 +0200, Dominique Leuenberger wrote:
[...] Packages changed: [...] kernel-source (6.2.8 -> 6.2.9)
does anybody also have problems booting the new kernel? It panics here on all my systems when swithing the root filesystem.
Common to all my systems is they are all Intel based and use an NVME boot disk. I'll try to capture the console logs next, but thought I'd check if anybody can confirm this failure.
snapshot 0401 or 0402? 0402 also contains an update for libnvme...
Looking at /var/log/zypp/history I probably skipped 0401...
FWIW, the kernel from Kernel:stable shows the same, while the same 6.2.9 kernel from Kernel:stable:Backport boots happily on Leap 15.4...
...which does not have the libnvme update...
... which might explain the difference, indeed!
Hm, libnvme is not necessary to boot from NVMe/PCIe storage. I guess it's not impossible that some interaction between nvme-cli calls and the kernel could cause a kernel panic, but I doubt it would happen this early in the boot sequence (while switching root). A bug report with boot logs would be desirable.
I have a photo of it, do you think it would suffice? If not, how do I capture boot logs at this early stage?
https://bugzilla.suse.com/show_bug.cgi?id=1210146
Rerards Martin
Cheers.
l8er manfred
On Wed, 05 Apr 2023, 11:06:53 +0200, Manfred Hollstein wrote:
This appears to be caused by having "retbleed=stuff" on the kernel command line. Up to 6.2.9 it never made any problems.
Cheers.
l8er manfred
On Wednesday, 5 April 2023 7:19:11 PM ACST Manfred Hollstein wrote:
On Wed, 05 Apr 2023, 11:06:53 +0200, Manfred Hollstein wrote:
[...]
This appears to be caused by having "retbleed=stuff" on the kernel command line. Up to 6.2.9 it never made any problems.
Cheers.
l8er manfred
I got a kernel panic on 6.2.9 even earlier than that, and I don't have retbleed parameters on my kernel command line.
My bootloader kernel command line is: idewait=10 plymouth.enable=0 splash quiet showopts nvidia-drm.modeset=1 elevator=cfq
I'm also not booting from NVMe but from a SATA SDD.
Crash details: ----- Kernel Panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,5) CPU:9 PID:1 Comm: Swapper/0 Not tainted 6.2.9-1-default #1 openSUSE Tumbleweed 72246ebc6bb73a9bec193bedaaaba1392d6fb332 Hardware name: System manufacturer System Product Name/PRIME X299-A, BIOS 3501 07/13/2021 Call Trace: <TASK> dump_stack_lvl+0x23/0x60 panic=0x346/0x350 mount_block_root=-x1f7/0x280 prepare_namespace=0xec/0x170 kernel_init_freeable= 0x411/0x450 ? __pfx_kernel_init=0x10/0x10 kernel_init=016/0x1c0 ret_from_fork=0x29/0x50 </TASK> Kernel Offset: 0x31e00000 from 0xffffffff81000000 (relocation range 0xffffffff80000000-0xffffffffbfffffff) Rebooting in 90 seconds.. -----
The system boots fine with 6.2.6-1-default.\
Regards,
On Wed, Apr 5, 2023 at 4:47 PM Rodney Baker rodney.baker@iinet.net.au wrote:
On Wednesday, 5 April 2023 7:19:11 PM ACST Manfred Hollstein wrote:
On Wed, 05 Apr 2023, 11:06:53 +0200, Manfred Hollstein wrote:
[...]
This appears to be caused by having "retbleed=stuff" on the kernel command line. Up to 6.2.9 it never made any problems.
Cheers.
l8er manfred
I got a kernel panic on 6.2.9 even earlier than that, and I don't have retbleed parameters on my kernel command line.
My bootloader kernel command line is: idewait=10 plymouth.enable=0 splash quiet showopts nvidia-drm.modeset=1 elevator=cfq
I'm also not booting from NVMe but from a SATA SDD.
Crash details:
Kernel Panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,5)
This is partition 5 of sda. Kernel should not even attempt to mount it as root. Is initrd present and not corrupted? Any errors from grub about loading initrd?
CPU:9 PID:1 Comm: Swapper/0 Not tainted 6.2.9-1-default #1 openSUSE Tumbleweed 72246ebc6bb73a9bec193bedaaaba1392d6fb332 Hardware name: System manufacturer System Product Name/PRIME X299-A, BIOS 3501 07/13/2021 Call Trace:
<TASK> dump_stack_lvl+0x23/0x60 panic=0x346/0x350 mount_block_root=-x1f7/0x280 prepare_namespace=0xec/0x170 kernel_init_freeable= 0x411/0x450 ? __pfx_kernel_init=0x10/0x10 kernel_init=016/0x1c0 ret_from_fork=0x29/0x50 </TASK> Kernel Offset: 0x31e00000 from 0xffffffff81000000 (relocation range 0xffffffff80000000-0xffffffffbfffffff) Rebooting in 90 seconds.. -----
The system boots fine with 6.2.6-1-default.\
Regards,
--
Rodney Baker rodney.baker@iinet.net.au ==================================================================================================================
On Wednesday, 5 April 2023 11:25:37 PM ACST Andrei Borzenkov wrote:
On Wed, Apr 5, 2023 at 4:47 PM Rodney Baker rodney.baker@iinet.net.au
wrote:
On Wednesday, 5 April 2023 7:19:11 PM ACST Manfred Hollstein wrote:
On Wed, 05 Apr 2023, 11:06:53 +0200, Manfred Hollstein wrote:
[...]
This appears to be caused by having "retbleed=stuff" on the kernel command line. Up to 6.2.9 it never made any problems.
Cheers.
l8er manfred
I got a kernel panic on 6.2.9 even earlier than that, and I don't have retbleed parameters on my kernel command line.
My bootloader kernel command line is: idewait=10 plymouth.enable=0 splash quiet showopts nvidia-drm.modeset=1 elevator=cfq
I'm also not booting from NVMe but from a SATA SDD.
Crash details:
Kernel Panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,5)
This is partition 5 of sda. Kernel should not even attempt to mount it as root. Is initrd present and not corrupted? Any errors from grub about loading initrd?
No, not that I can see. /dev/sda5 is the root partition (dev/sda1 is /boot). I think this is still using a traditional partition table (/dev/sda5 is on an extended partition), not GPT.
I do see that dracut is complaining about not being able to find the zfs module for initrd when building it. I tried to get zfs working a while back but failed - but I can't remember where to tell dracut not to try to load that module.
It's not a problem on kernel 6.2.6-1-default though - only on 6.2.9-1-default, and I've run dracut -fM --kver <kernel version> for both kernels manually with the same result.
CPU:9 PID:1 Comm: Swapper/0 Not tainted 6.2.9-1-default #1 openSUSE Tumbleweed 72246ebc6bb73a9bec193bedaaaba1392d6fb332 Hardware name: System manufacturer System Product Name/PRIME X299-A, BIOS 3501 07/13/2021
Call Trace:
<TASK> dump_stack_lvl+0x23/0x60 panic=0x346/0x350 mount_block_root=-x1f7/0x280 prepare_namespace=0xec/0x170 kernel_init_freeable= 0x411/0x450 ? __pfx_kernel_init=0x10/0x10 kernel_init=016/0x1c0 ret_from_fork=0x29/0x50 </TASK>
Kernel Offset: 0x31e00000 from 0xffffffff81000000 (relocation range 0xffffffff80000000-0xffffffffbfffffff) Rebooting in 90 seconds..
The system boots fine with 6.2.6-1-default.\
Regards,
--
======================================== Rodney Baker rodney.baker@iinet.net.au ========================================================================== ========================================
On Wed, Apr 5, 2023 at 5:09 PM Rodney Baker rodney.baker@iinet.net.au wrote:
On Wednesday, 5 April 2023 11:25:37 PM ACST Andrei Borzenkov wrote:
On Wed, Apr 5, 2023 at 4:47 PM Rodney Baker rodney.baker@iinet.net.au
wrote:
On Wednesday, 5 April 2023 7:19:11 PM ACST Manfred Hollstein wrote:
On Wed, 05 Apr 2023, 11:06:53 +0200, Manfred Hollstein wrote:
[...]
This appears to be caused by having "retbleed=stuff" on the kernel command line. Up to 6.2.9 it never made any problems.
Cheers.
l8er manfred
I got a kernel panic on 6.2.9 even earlier than that, and I don't have retbleed parameters on my kernel command line.
My bootloader kernel command line is: idewait=10 plymouth.enable=0 splash quiet showopts nvidia-drm.modeset=1 elevator=cfq
I'm also not booting from NVMe but from a SATA SDD.
Crash details:
Kernel Panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,5)
This is partition 5 of sda. Kernel should not even attempt to mount it as root. Is initrd present and not corrupted? Any errors from grub about loading initrd?
No, not that I can see. /dev/sda5 is the root partition (dev/sda1 is /boot). I think this is still using a traditional partition table (/dev/sda5 is on an extended partition), not GPT.
I do see that dracut is complaining about not being able to find the zfs module for initrd when building it. I tried to get zfs working a while back but failed - but I can't remember where to tell dracut not to try to load that module.
It's not a problem on kernel 6.2.6-1-default though - only on 6.2.9-1-default, and I've run dracut -fM --kver <kernel version> for both kernels manually with the same result.
Posting full output for both kernels may give some hints.
CPU:9 PID:1 Comm: Swapper/0 Not tainted 6.2.9-1-default #1 openSUSE Tumbleweed 72246ebc6bb73a9bec193bedaaaba1392d6fb332 Hardware name: System manufacturer System Product Name/PRIME X299-A, BIOS 3501 07/13/2021
Call Trace:
<TASK> dump_stack_lvl+0x23/0x60 panic=0x346/0x350 mount_block_root=-x1f7/0x280 prepare_namespace=0xec/0x170 kernel_init_freeable= 0x411/0x450 ? __pfx_kernel_init=0x10/0x10 kernel_init=016/0x1c0 ret_from_fork=0x29/0x50 </TASK>
Kernel Offset: 0x31e00000 from 0xffffffff81000000 (relocation range 0xffffffff80000000-0xffffffffbfffffff) Rebooting in 90 seconds..
The system boots fine with 6.2.6-1-default.\
Regards,
--
======================================== Rodney Baker rodney.baker@iinet.net.au ========================================================================== ========================================
--
Rodney Baker rodney.baker@iinet.net.au ==================================================================================================================
On Wednesday, 5 April 2023 11:42:02 PM ACST Andrei Borzenkov wrote:
On Wed, Apr 5, 2023 at 5:09 PM Rodney Baker rodney.baker@iinet.net.au
wrote:
On Wednesday, 5 April 2023 11:25:37 PM ACST Andrei Borzenkov wrote:
On Wed, Apr 5, 2023 at 4:47 PM Rodney Baker rodney.baker@iinet.net.au
wrote:
On Wednesday, 5 April 2023 7:19:11 PM ACST Manfred Hollstein wrote:
On Wed, 05 Apr 2023, 11:06:53 +0200, Manfred Hollstein wrote:
[...]
This appears to be caused by having "retbleed=stuff" on the kernel command line. Up to 6.2.9 it never made any problems.
Cheers.
l8er manfred
I got a kernel panic on 6.2.9 even earlier than that, and I don't have retbleed parameters on my kernel command line.
My bootloader kernel command line is: idewait=10 plymouth.enable=0 splash quiet showopts nvidia-drm.modeset=1 elevator=cfq
I'm also not booting from NVMe but from a SATA SDD.
Crash details:
Kernel Panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,5)
This is partition 5 of sda. Kernel should not even attempt to mount it as root. Is initrd present and not corrupted? Any errors from grub about loading initrd?
No, not that I can see. /dev/sda5 is the root partition (dev/sda1 is /boot). I think this is still using a traditional partition table (/dev/sda5 is on an extended partition), not GPT.
I do see that dracut is complaining about not being able to find the zfs module for initrd when building it. I tried to get zfs working a while back but failed - but I can't remember where to tell dracut not to try to load that module.
It's not a problem on kernel 6.2.6-1-default though - only on 6.2.9-1-default, and I've run dracut -fM --kver <kernel version> for both kernels manually with the same result.
Just installed missing zfs-kmp-default and dracut completed successfully for 6.2.6-1-default but not for 6.2.9-1-default. It looks like the zfs module hasn't yet been build against 6.2.9-1-default.
Posting full output for both kernels may give some hints.
CPU:9 PID:1 Comm: Swapper/0 Not tainted 6.2.9-1-default #1 openSUSE Tumbleweed 72246ebc6bb73a9bec193bedaaaba1392d6fb332 Hardware name: System manufacturer System Product Name/PRIME X299-A, BIOS 3501 07/13/2021
Call Trace:
<TASK> dump_stack_lvl+0x23/0x60 panic=0x346/0x350 mount_block_root=-x1f7/0x280 prepare_namespace=0xec/0x170 kernel_init_freeable= 0x411/0x450 ? __pfx_kernel_init=0x10/0x10 kernel_init=016/0x1c0 ret_from_fork=0x29/0x50 </TASK>
Kernel Offset: 0x31e00000 from 0xffffffff81000000 (relocation range 0xffffffff80000000-0xffffffffbfffffff) Rebooting in 90 seconds..
The system boots fine with 6.2.6-1-default.\
Regards,
--
==== ======================================== Rodney Baker rodney.baker@iinet.net.au ====================================================================== ==== ========================================
--
======================================== Rodney Baker rodney.baker@iinet.net.au ========================================================================== ========================================
On Wednesday, 5 April 2023 11:55:11 PM ACST Rodney Baker wrote:
On Wednesday, 5 April 2023 11:42:02 PM ACST Andrei Borzenkov wrote:
On Wed, Apr 5, 2023 at 5:09 PM Rodney Baker rodney.baker@iinet.net.au
wrote:
On Wednesday, 5 April 2023 11:25:37 PM ACST Andrei Borzenkov wrote:
On Wed, Apr 5, 2023 at 4:47 PM Rodney Baker rodney.baker@iinet.net.au
wrote:
On Wednesday, 5 April 2023 7:19:11 PM ACST Manfred Hollstein wrote:
On Wed, 05 Apr 2023, 11:06:53 +0200, Manfred Hollstein wrote: > [...] > > https://bugzilla.suse.com/show_bug.cgi?id=1210146
This appears to be caused by having "retbleed=stuff" on the kernel command line. Up to 6.2.9 it never made any problems.
Cheers.
l8er manfred
I got a kernel panic on 6.2.9 even earlier than that, and I don't have retbleed parameters on my kernel command line.
My bootloader kernel command line is: idewait=10 plymouth.enable=0 splash quiet showopts nvidia-drm.modeset=1 elevator=cfq
I'm also not booting from NVMe but from a SATA SDD.
Crash details:
Kernel Panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,5)
This is partition 5 of sda. Kernel should not even attempt to mount it as root. Is initrd present and not corrupted? Any errors from grub about loading initrd?
No, not that I can see. /dev/sda5 is the root partition (dev/sda1 is /boot). I think this is still using a traditional partition table (/dev/sda5 is on an extended partition), not GPT.
I do see that dracut is complaining about not being able to find the zfs module for initrd when building it. I tried to get zfs working a while back but failed - but I can't remember where to tell dracut not to try to load that module.
It's not a problem on kernel 6.2.6-1-default though - only on 6.2.9-1-default, and I've run dracut -fM --kver <kernel version> for both kernels manually with the same result.
Just installed missing zfs-kmp-default and dracut completed successfully for 6.2.6-1-default but not for 6.2.9-1-default. It looks like the zfs module hasn't yet been build against 6.2.9-1-default.
Sorry - I hit "send" before I was ready. After trying the above I deleted everything associated with zfs and tried dracut again - this time it completed successfully for both 6.2.6-1-default and 6.2.9-1-default (without complaining about zfs), but still got exactly the same result - kernel panic with 6.2.9-1-default at the same point.
Here's the output from dracut for both kernels:
dracut -fM --kver 6.2.6-1-default dracut: Executing: /usr/bin/dracut -fM --kver 6.2.6-1-default dracut: dracut module 'systemd-coredump' will not be installed, because command 'coredumpctl' could not be found! dracut: dracut module 'systemd-coredump' will not be installed, because command '/usr/lib/systemd/systemd-coredump' could not be found! dracut: dracut module 'systemd-pcrphase' will not be installed, because command '/usr/lib/systemd/systemd-pcrphase' could not be found! dracut: dracut module 'systemd-portabled' will not be installed, because command 'portablectl' could not be found! dracut: dracut module 'systemd-portabled' will not be installed, because command '/usr/lib/systemd/systemd-portabled' could not be found! dracut: dracut module 'systemd-repart' will not be installed, because command 'systemd-repart' could not be found! dracut: dracut module 'dbus-broker' will not be installed, because command 'dbus-broker' could not be found! dracut: dracut module 'rngd' will not be installed, because command 'rngd' could not be found! dracut: dracut module 'connman' will not be installed, because command 'connmand' could not be found! dracut: dracut module 'connman' will not be installed, because command 'connmanctl' could not be found! dracut: dracut module 'connman' will not be installed, because command 'connmand-wait-online' could not be found! dracut: dracut module 'btrfs' will not be installed, because command 'btrfs' could not be found! dracut: dracut module 'tpm2-tss' will not be installed, because command 'tpm2' could not be found! dracut: dracut module 'nvmf' will not be installed, because command 'nvme' could not be found! dracut: dracut module 'biosdevname' will not be installed, because command 'biosdevname' could not be found! dracut: dracut module 'memstrack' will not be installed, because command 'memstrack' could not be found! dracut: memstrack is not available dracut: If you need to use rd.memdebug>=4, please install memstrack and procps-ng dracut: dracut module 'squash' will not be installed, because command 'mksquashfs' could not be found! dracut: dracut module 'squash' will not be installed, because command 'unsquashfs' could not be found! dracut: dracut module 'systemd-coredump' will not be installed, because command 'coredumpctl' could not be found! dracut: dracut module 'systemd-coredump' will not be installed, because command '/usr/lib/systemd/systemd-coredump' could not be found! dracut: dracut module 'systemd-pcrphase' will not be installed, because command '/usr/lib/systemd/systemd-pcrphase' could not be found! dracut: dracut module 'systemd-portabled' will not be installed, because command 'portablectl' could not be found! dracut: dracut module 'systemd-portabled' will not be installed, because command '/usr/lib/systemd/systemd-portabled' could not be found! dracut: dracut module 'systemd-repart' will not be installed, because command 'systemd-repart' could not be found! dracut: dracut module 'dbus-broker' will not be installed, because command 'dbus-broker' could not be found! dracut: dracut module 'rngd' will not be installed, because command 'rngd' could not be found! dracut: dracut module 'connman' will not be installed, because command 'connmand' could not be found! dracut: dracut module 'connman' will not be installed, because command 'connmanctl' could not be found! dracut: dracut module 'connman' will not be installed, because command 'connmand-wait-online' could not be found! dracut: dracut module 'btrfs' will not be installed, because command 'btrfs' could not be found! dracut: dracut module 'tpm2-tss' will not be installed, because command 'tpm2' could not be found! dracut: dracut module 'nvmf' will not be installed, because command 'nvme' could not be found! dracut: dracut module 'memstrack' will not be installed, because command 'memstrack' could not be found! dracut: memstrack is not available dracut: If you need to use rd.memdebug>=4, please install memstrack and procps-ng dracut: dracut module 'squash' will not be installed, because command 'mksquashfs' could not be found! dracut: dracut module 'squash' will not be installed, because command 'unsquashfs' could not be found! systemd systemd-initrd i18n drm plymouth kernel-modules kernel-modules-extra nvdimm rootfs-block suse-xfs terminfo udev-rules dracut: Skipping udev rule: 40-redhat.rules dracut: Skipping udev rule: 50-firmware.rules dracut: Skipping udev rule: 50-udev.rules dracut: Skipping udev rule: 91-permissions.rules dracut: Skipping udev rule: 80-drivers-modprobe.rules dracut: Skipping udev rule: 70-persistent-net.rules dracut-systemd haveged ostree usrmount base fs-lib shutdown suse suse-initrd dracut: *** Including modules done *** dracut: *** Installing kernel module dependencies *** dracut: *** Installing kernel module dependencies done *** dracut: *** Resolving executable dependencies *** dracut: *** Resolving executable dependencies done *** dracut: *** Hardlinking files *** dracut: Mode: real dracut: Method: sha256 dracut: Files: 1107 dracut: Linked: 2 files dracut: Compared: 0 xattrs dracut: Compared: 119 files dracut: Saved: 352.16 KiB dracut: Duration: 0.006722 seconds dracut: *** Hardlinking files done *** dracut: *** Generating early-microcode cpio image *** dracut: *** Constructing GenuineIntel.bin *** dracut: *** Store current command line parameters *** dracut: Stored kernel commandline: dracut: root=UUID=93cda319-ba05-4170-a509-8f43ad15dc44 rootfstype=ext4 rootflags=rw,noatime dracut: *** Stripping files *** dracut: *** Stripping files done *** dracut: *** Creating image file '/boot/initrd-6.2.6-1-default' *** dracut: *** Creating initramfs image file '/boot/initrd-6.2.6-1-default' done ***
dracut -fM --kver 6.2.9-1-default dracut: Executing: /usr/bin/dracut -fM --kver 6.2.9-1-default dracut: dracut module 'systemd-coredump' will not be installed, because command 'coredumpctl' could not be found! dracut: dracut module 'systemd-coredump' will not be installed, because command '/usr/lib/systemd/systemd-coredump' could not be found! dracut: dracut module 'systemd-pcrphase' will not be installed, because command '/usr/lib/systemd/systemd-pcrphase' could not be found! dracut: dracut module 'systemd-portabled' will not be installed, because command 'portablectl' could not be found! dracut: dracut module 'systemd-portabled' will not be installed, because command '/usr/lib/systemd/systemd-portabled' could not be found! dracut: dracut module 'systemd-repart' will not be installed, because command 'systemd-repart' could not be found! dracut: dracut module 'dbus-broker' will not be installed, because command 'dbus-broker' could not be found! dracut: dracut module 'rngd' will not be installed, because command 'rngd' could not be found! dracut: dracut module 'connman' will not be installed, because command 'connmand' could not be found! dracut: dracut module 'connman' will not be installed, because command 'connmanctl' could not be found! dracut: dracut module 'connman' will not be installed, because command 'connmand-wait-online' could not be found! dracut: dracut module 'btrfs' will not be installed, because command 'btrfs' could not be found! dracut: dracut module 'tpm2-tss' will not be installed, because command 'tpm2' could not be found! dracut: dracut module 'nvmf' will not be installed, because command 'nvme' could not be found! dracut: dracut module 'biosdevname' will not be installed, because command 'biosdevname' could not be found! dracut: dracut module 'memstrack' will not be installed, because command 'memstrack' could not be found! dracut: memstrack is not available dracut: If you need to use rd.memdebug>=4, please install memstrack and procps-ng dracut: dracut module 'squash' will not be installed, because command 'mksquashfs' could not be found! dracut: dracut module 'squash' will not be installed, because command 'unsquashfs' could not be found! dracut: dracut module 'systemd-coredump' will not be installed, because command 'coredumpctl' could not be found! dracut: dracut module 'systemd-coredump' will not be installed, because command '/usr/lib/systemd/systemd-coredump' could not be found! dracut: dracut module 'systemd-pcrphase' will not be installed, because command '/usr/lib/systemd/systemd-pcrphase' could not be found! dracut: dracut module 'systemd-portabled' will not be installed, because command 'portablectl' could not be found! dracut: dracut module 'systemd-portabled' will not be installed, because command '/usr/lib/systemd/systemd-portabled' could not be found! dracut: dracut module 'systemd-repart' will not be installed, because command 'systemd-repart' could not be found! dracut: dracut module 'dbus-broker' will not be installed, because command 'dbus-broker' could not be found! dracut: dracut module 'rngd' will not be installed, because command 'rngd' could not be found! dracut: dracut module 'connman' will not be installed, because command 'connmand' could not be found! dracut: dracut module 'connman' will not be installed, because command 'connmanctl' could not be found! dracut: dracut module 'connman' will not be installed, because command 'connmand-wait-online' could not be found! dracut: dracut module 'btrfs' will not be installed, because command 'btrfs' could not be found! dracut: dracut module 'tpm2-tss' will not be installed, because command 'tpm2' could not be found! dracut: dracut module 'nvmf' will not be installed, because command 'nvme' could not be found! dracut: dracut module 'memstrack' will not be installed, because command 'memstrack' could not be found! dracut: memstrack is not available dracut: If you need to use rd.memdebug>=4, please install memstrack and procps-ng dracut: dracut module 'squash' will not be installed, because command 'mksquashfs' could not be found! dracut: dracut module 'squash' will not be installed, because command 'unsquashfs' could not be found! systemd systemd-initrd i18n drm plymouth kernel-modules kernel-modules-extra nvdimm rootfs-block suse-xfs terminfo udev-rules dracut: Skipping udev rule: 40-redhat.rules dracut: Skipping udev rule: 50-firmware.rules dracut: Skipping udev rule: 50-udev.rules dracut: Skipping udev rule: 91-permissions.rules dracut: Skipping udev rule: 80-drivers-modprobe.rules dracut: Skipping udev rule: 70-persistent-net.rules dracut-systemd haveged ostree usrmount base fs-lib shutdown suse suse-initrd dracut: *** Including modules done *** dracut: *** Installing kernel module dependencies *** dracut: *** Installing kernel module dependencies done *** dracut: *** Resolving executable dependencies *** dracut: *** Resolving executable dependencies done *** dracut: *** Hardlinking files *** dracut: Mode: real dracut: Method: sha256 dracut: Files: 1108 dracut: Linked: 2 files dracut: Compared: 0 xattrs dracut: Compared: 120 files dracut: Saved: 352.16 KiB dracut: Duration: 0.006601 seconds dracut: *** Hardlinking files done *** dracut: *** Generating early-microcode cpio image *** dracut: *** Constructing GenuineIntel.bin *** dracut: *** Store current command line parameters *** dracut: Stored kernel commandline: dracut: root=UUID=93cda319-ba05-4170-a509-8f43ad15dc44 rootfstype=ext4 rootflags=rw,noatime dracut: *** Stripping files *** dracut: *** Stripping files done *** dracut: *** Creating image file '/boot/initrd-6.2.9-1-default' *** dracut: *** Creating initramfs image file '/boot/initrd-6.2.9-1-default' done ***
Posting full output for both kernels may give some hints.
CPU:9 PID:1 Comm: Swapper/0 Not tainted 6.2.9-1-default #1 openSUSE Tumbleweed 72246ebc6bb73a9bec193bedaaaba1392d6fb332 Hardware name: System manufacturer System Product Name/PRIME X299-A, BIOS 3501 07/13/2021
Call Trace:
<TASK> dump_stack_lvl+0x23/0x60 panic=0x346/0x350 mount_block_root=-x1f7/0x280 prepare_namespace=0xec/0x170 kernel_init_freeable= 0x411/0x450 ? __pfx_kernel_init=0x10/0x10 kernel_init=016/0x1c0 ret_from_fork=0x29/0x50 </TASK>
Kernel Offset: 0x31e00000 from 0xffffffff81000000 (relocation range 0xffffffff80000000-0xffffffffbfffffff) Rebooting in 90 seconds..
The system boots fine with 6.2.6-1-default.\
Regards,
--
==
======================================== Rodney Baker rodney.baker@iinet.net.au ==================================================================== == ==== ========================================
--
== ======================================== Rodney Baker rodney.baker@iinet.net.au ======================================================================== == ========================================
Hi,
I use Tumbleweed with kernel 6.2.6-1-default Using zypper I installed gimp and inkscape. running gimp --> gimp: symbol lookup error: /lib64/libgegl-0.4.so.0: undefined symbol: g_string_free_and_steal running inkscape --> inkscape: symbol lookup error: /usr/bin/../lib64/inkscape/libinkscape_base.so: undefined symbol: g_string_free_and_steal Consulting Google makes me thinking it is related to glib2 --> installed glib2-devel 2.74.6-1.2
Can you give me a hint on how to get gimp / inkscape working? thanks
* anthony a@gc5.uk [04-05-23 16:09]:
Hi,
I use Tumbleweed with kernel 6.2.6-1-default Using zypper I installed gimp and inkscape. running gimp --> gimp: symbol lookup error: /lib64/libgegl-0.4.so.0: undefined symbol: g_string_free_and_steal
possible corruped version of libgegl-0_4-0-0.4.44-158.5.x86_64
zypper in --force libgegl-0_4-0-0.4.44-158.5.x86_64
running inkscape --> inkscape: symbol lookup error: /usr/bin/../lib64/inkscape/libinkscape_base.so: undefined symbol: g_string_free_and_steal Consulting Google makes me thinking it is related to glib2 --> installed glib2-devel 2.74.6-1.2
installing glib2-devel is not a solution.
possible corrupted install of inkscape
Can you give me a hint on how to get gimp / inkscape working? thanks
fwiw: I just installed inkscape on my Tw workstation and it runs w/o a problem and gimp has a still does run w/o a problem.
just guessing, but local corruption seems probable. you might also reinstall gimp.
zyppper in --force gimp zypper in --force inkscape
On 2023-04-05 13:07, anthony wrote:
running inkscape --> inkscape: symbol lookup error: /usr/bin/../lib64/inkscape/libinkscape_base.so: undefined symbol: g_string_free_and_steal Consulting Google makes me thinking it is related to glib2 --> installed glib2-devel 2.74.6-1.2
Can you give me a hint on how to get gimp / inkscape working?
I believe that you need at least glib2 2.76: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3219/diffs
(You don't need the devel package for this.)
The underlying problem is that for libraries that don't provide versioned symbols (most libraries), rpm doesn't currently build dependency information that includes a minor version of the ABI. While that is true, it is not safe to selectively apply updates or to install packages without also fully updating the system. So the safe thing to do is something like "zypper update && zypper install gimp". (I've started work to improve this situation in rpm, but it's not going to be ready soon.)
On Montag, 3. April 2023 12:00:22 CEST Dominique Leuenberger wrote:
==== coreutils ==== Version update (9.1 -> 9.2) Subpackages: coreutils-lang
[...]
- 'cp -n' and 'mv -n' now exit with nonzero status if they skip their action because the destination exists, and likewise for 'cp
- i', 'ln -i', and 'mv -i' when the user declines. (POSIX specifies this for 'cp -i' and 'mv -i'.)
[...]
be warned: This might break lots of Makefiles and other scripts. cp -n and mv -n return 1, if *any* file to copy or move exists in the destination. I'm not sure, why this was introduced, because using -n originally should avoid a non zero return status.
On 05/04/2023 23:03, Gordon Messmer wrote:
On 2023-04-05 13:07, anthony wrote:
running inkscape --> inkscape: symbol lookup error: /usr/bin/../lib64/inkscape/libinkscape_base.so: undefined symbol: g_string_free_and_steal Consulting Google makes me thinking it is related to glib2 --> installed glib2-devel 2.74.6-1.2
Can you give me a hint on how to get gimp / inkscape working?
I believe that you need at least glib2 2.76: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3219/diffs
(You don't need the devel package for this.)
The underlying problem is that for libraries that don't provide versioned symbols (most libraries), rpm doesn't currently build dependency information that includes a minor version of the ABI. While that is true, it is not safe to selectively apply updates or to install packages without also fully updating the system. So the safe thing to do is something like "zypper update && zypper install gimp". (I've started work to improve this situation in rpm, but it's not going to be ready soon.)
Thanks, you directed me in the right direction. after installing glib2-2.76.1-1.1.src.rpm both gimp and inkscape are working fine. just remarkable this package was not present or was corrupted. Anthony
On 2023-04-05 15:11, anthony wrote:
just remarkable this package was not present or was corrupted.
I don't think there's any evidence of corruption. Just a deficiency in rpm's ELF dependency generator that needs to be fixed. (Until it is: always apply all available updates when patching, and before installing any new packages.)
On Thursday 2023-04-06 01:53, Gordon Messmer wrote:
On 2023-04-05 15:11, anthony wrote:
just remarkable this package was not present or was corrupted.
I don't think there's any evidence of corruption. Just a deficiency in rpm's ELF dependency generator that needs to be fixed.
*ld.so* stumbled over it and would stumble over it even if rpm was not in the picture. It is really a deficiency in the symbol map (especially because the programmer did not write any), or, in a sense, a deficiency in the static linker which did not add a stand-in map.
On 2023-04-05 17:22, Jan Engelhardt wrote:
I don't think there's any evidence of corruption. Just a deficiency in rpm's ELF dependency generator that needs to be fixed.
*ld.so* stumbled over it and would stumble over it even if rpm was not in the picture. It is really a deficiency in the symbol map (especially because the programmer did not write any), or, in a sense, a deficiency in the static linker which did not add a stand-in map.
I think you're missing the point. Today, rpm's ELF dependency generator will automatically provide a requirement on "libglib-2.0.so.0()(64bit)" when gimp is built. When you install gimp, rpm determines that an installed package must provide a 64-bit version of "libglib-2.0.so.0", or else a package that provides that capability must be installed.
The problem is that the dependency on "libglib-2.0.so.0" only effectively communicates the major version of the library that is required, but in the case of this thread, the missing symbol was introduced in glib2 version 2.76. Without the minor version in the dependency data, rpm will mistakenly determine that the dependencies are satisfied. If glib2 used versioned symbols, then rpm would be able to actually determine the minimum version of glib2 that needs to be installed, but it doesn't. A better dependency generator (which I'm working on) would be able to provide enough information to indicate that at least version 2.76 of glib2 was required, so that it could be updated when an application that required it was installed.
On Thursday, 6 April 2023 12:03:52 AM ACST Rodney Baker wrote:
On Wednesday, 5 April 2023 11:55:11 PM ACST Rodney Baker wrote:
On Wednesday, 5 April 2023 11:42:02 PM ACST Andrei Borzenkov wrote:
On Wed, Apr 5, 2023 at 5:09 PM Rodney Baker rodney.baker@iinet.net.au
wrote:
On Wednesday, 5 April 2023 11:25:37 PM ACST Andrei Borzenkov wrote:
On Wed, Apr 5, 2023 at 4:47 PM Rodney Baker rodney.baker@iinet.net.au
wrote:
On Wednesday, 5 April 2023 7:19:11 PM ACST Manfred Hollstein
wrote:
> On Wed, 05 Apr 2023, 11:06:53 +0200, Manfred Hollstein wrote: > > [...] > > > > https://bugzilla.suse.com/show_bug.cgi?id=1210146 > > This appears to be caused by having "retbleed=stuff" on the > kernel > command line. Up to 6.2.9 it never made any problems. > > Cheers. > > l8er > manfred
I got a kernel panic on 6.2.9 even earlier than that, and I don't have retbleed parameters on my kernel command line.
My bootloader kernel command line is: idewait=10 plymouth.enable=0 splash quiet showopts nvidia-drm.modeset=1 elevator=cfq
I'm also not booting from NVMe but from a SATA SDD.
Crash details:
Kernel Panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,5)
This is partition 5 of sda. Kernel should not even attempt to mount it as root. Is initrd present and not corrupted? Any errors from grub about loading initrd?
No, not that I can see. /dev/sda5 is the root partition (dev/sda1 is /boot). I think this is still using a traditional partition table (/dev/sda5 is on an extended partition), not GPT.
I do see that dracut is complaining about not being able to find the zfs module for initrd when building it. I tried to get zfs working a while back but failed - but I can't remember where to tell dracut not to try to load that module.
It's not a problem on kernel 6.2.6-1-default though - only on 6.2.9-1-default, and I've run dracut -fM --kver <kernel version> for both kernels manually with the same result.
Just installed missing zfs-kmp-default and dracut completed successfully for 6.2.6-1-default but not for 6.2.9-1-default. It looks like the zfs module hasn't yet been build against 6.2.9-1-default.
Sorry - I hit "send" before I was ready. After trying the above I deleted everything associated with zfs and tried dracut again - this time it completed successfully for both 6.2.6-1-default and 6.2.9-1-default (without complaining about zfs), but still got exactly the same result - kernel panic with 6.2.9-1-default at the same point.
Here's the output from dracut for both kernels: [...]
Issue is now resolved for me. On advice from the openSUSE kernel team via bugzilla, ran dracut -f again for both working and non working kernels - that didn't fix the issue immediately.
Installed kernel 6.2.8-1-default, installed the nvidia modules via dkms for that kernel, re-ran dracut -f again and booted fine into 6.2.8-1-default. Rebooted into 6.2.9-1-default again and it now works.
Looks like it was initramfs that was corrupted or incomplete somehow. Anyway, regardless, everything is now happily running again on 6.2.9-1-default.
Regards, Rodney.
On 06.04.2023 01:11, anthony wrote:
after installing glib2-2.76.1-1.1.src.rpm both gimp and inkscape are working fine. > just remarkable this package was not present or was corrupted.
Because source packages are not needed and are not installed and are not even recorded in RPM database after "installation" and your problem was very unlikely fixed by "installing" *src*.rpm. More likely it caused zypper to pull in dependencies and one of them fixed it.
On Thursday 2023-04-06 02:51, Gordon Messmer wrote:
On 2023-04-05 17:22, Jan Engelhardt wrote:
gimp: symbol lookup error: /lib64/libgegl-0.4.so.0: undefined symbol: g_string_free_and_steal
I don't think there's any evidence of corruption. Just a deficiency in rpm's ELF dependency generator that needs to be fixed.
*ld.so* stumbled over it and would stumble over it even if rpm was not in the picture. It is really a deficiency in the symbol map (especially because the programmer did not write any), or, in a sense, a deficiency in the static linker which did not add a stand-in map.
I think you're missing the point. [...] The problem is that the dependency on "libglib-2.0.so.0" only effectively communicates the major version of the library that is required, but in the case of this thread, the missing symbol was introduced in glib2 version 2.76. Without the minor version in the dependency data, rpm will mistakenly determine that the dependencies are satisfied.
ld.so _also_ has a dependency checker (at least for versioned symbols). It compares a program X's ".gnu.version_r" with libfoo.so.XYZ's ".gnu.version_d" section. rpm is just _reimplementing_ the same check on another level; when building packages, it essentially copies every ELF version_r and version_d entry to make RPM "Requires" and "Provides" out of it.
If glib2 used versioned symbols, then rpm would be able to actually determine the minimum version of glib2 that needs to be installed, but it doesn't. A better dependency generator (which I'm working on) would be able to provide enough information to indicate that at least version 2.76 of glib2 was required
So you want to add more logic to RPM's find-provides and find-requires code to add extra dependencies to .rpm files. But as shown above, RPM copies (some) version information from ELF to RPM anyway, so why don't we add the (newly sought) information to ELF binaries as well?
(One issue I recognize is that ELF-level symbol versions are evaluated using strict equality; ld.so would need to gain recognition for a ">=" operator.)
On 2023-04-06 01:37, Jan Engelhardt wrote:
ld.so _also_ has a dependency checker (at least for versioned symbols). It compares a program X's ".gnu.version_r" with libfoo.so.XYZ's ".gnu.version_d" section. rpm is just _reimplementing_ the same check on another level; when building packages, it essentially copies every ELF version_r and version_d entry to make RPM "Requires" and "Provides" out of it.
As I pointed out before, the ELF data doesn't indicate a minor version for the dependency, only the major version. *That* is the root of the problem. For libraries that don't provide versioned symbols (including glib2), there's nothing that indicates that g_string_free_and_steal became available in 2.76, and that is the minimum version required. So we'd either need to change rpm to build a dependency and provide on *every single symbol* in addition to the soname, or we need to provide another mechanism to version dependencies.
(Or tell users to always update before installing a new package, and never selectively apply updates.)
So you want to add more logic to RPM's find-provides and find-requires code to add extra dependencies to .rpm files. But as shown above, RPM copies (some) version information from ELF to RPM anyway, so why don't we add the (newly sought) information to ELF binaries as well?
We don't need to add anything to the ELF binaries, they already have all of the information they need. That's why gimp and inkscape failed on launch and not later when they tried to use the missing function.
(One issue I recognize is that ELF-level symbol versions are evaluated using strict equality; ld.so would need to gain recognition for a ">=" operator.)
No, it doesn't. Versioned symbols work properly in both ELF and rpm's ELF dependency generator already. The problem affects libraries that don't provide versioned symbols (which is most of them).
On Thursday 2023-04-06 18:42, Gordon Messmer wrote:
On 2023-04-06 01:37, Jan Engelhardt wrote:
ld.so _also_ has a dependency checker (at least for versioned symbols). It compares a program X's ".gnu.version_r" with libfoo.so.XYZ's ".gnu.version_d" section. rpm is just _reimplementing_ the same check on another level; when building packages, it essentially copies every ELF version_r and version_d entry to make RPM "Requires" and "Provides" out of it.
As I pointed out before, the ELF data doesn't indicate a minor version for the dependency, only the major version. *That* is the root of the problem.
So if it can't be solved at the ELF level, what makes you think at can be solved at the RPM level? What does RPM know that RPM couldn't *also* inject into the glib2/inkscape ELFs? Why does it need to keep whatever information *its own* ecosystem?
On Thu, Apr 6, 2023 at 1:31 PM Jan Engelhardt jengelh@inai.de wrote:
On Thursday 2023-04-06 18:42, Gordon Messmer wrote:
On 2023-04-06 01:37, Jan Engelhardt wrote:
ld.so _also_ has a dependency checker (at least for versioned symbols). It compares a program X's ".gnu.version_r" with libfoo.so.XYZ's ".gnu.version_d" section. rpm is just _reimplementing_ the same check on another level; when building packages, it essentially copies every ELF version_r and version_d entry to make RPM "Requires" and "Provides" out of it.
As I pointed out before, the ELF data doesn't indicate a minor version for the dependency, only the major version. *That* is the root of the problem.
So if it can't be solved at the ELF level, what makes you think at can be solved at the RPM level? What does RPM know that RPM couldn't *also* inject into the glib2/inkscape ELFs? Why does it need to keep whatever information *its own* ecosystem?
In theory, you could, I guess? If Fedora's package notes thing[1] was extended for ELF loaders to do something with it, it could use that as a minimum version constraint.
[1]: https://fedoraproject.org/wiki/Changes/Package_information_on_ELF_objects
On 2023-04-06 10:31, Jan Engelhardt wrote:
As I pointed out before, the ELF data doesn't indicate a minor version for the dependency, only the major version.*That* is the root of the problem.
So if it can't be solved at the ELF level, what makes you think at can be solved at the RPM level?
Let me rephrase what I'm saying, because I am not saying that this can't be solved at the ELF level.
An ELF binary indicates both the soname required and the set of symbols required within shared objects. It's undesirable to copy both the soname and the individual symbols into rpm dependencies, because the size of the repo metadata and the CPU time and memory required on individual systems to resolve dependencies would massively inflate, so currently a subset of the ELF information is copied into rpm dependencies. For libraries with versioned symbols, that includes the soname and the versions in that library which are required by the packaged binary. For libraries without versioned symbols, it's just the soname. (and, technically, both may include a 64bit marker)
For libraries with versioned symbols, that's enough to reliably generate accurate dependency information, but for the majority of libraries (which don't provide versioned symbols), it isn't. For those libraries, rpm has less information available than the actual ELF binaries, and not enough to reliably update dependencies, leading to problems like the one that started this thread. For those libraries, we're discussing how best to add a version to the dependency information in order to enhance the information that rpm has, without massively inflating it.
On 4/5/23 23:16, mh@mike.franken.de wrote:
On Montag, 3. April 2023 12:00:22 CEST Dominique Leuenberger wrote:
==== coreutils ==== Version update (9.1 -> 9.2) Subpackages: coreutils-lang
[...]
- 'cp -n' and 'mv -n' now exit with nonzero status if they skip their action because the destination exists, and likewise for 'cp
- i', 'ln -i', and 'mv -i' when the user declines. (POSIX specifies this for 'cp -i' and 'mv -i'.)
[...]
be warned: This might break lots of Makefiles and other scripts. cp -n and mv -n return 1, if *any* file to copy or move exists in the destination. I'm not sure, why this was introduced, because using -n originally should avoid a non zero return status.
I don't see why would this break many Makefiles. Usually they're not using -n, but rather either nothing or -f, don't they?
The reasoning for the change is consistency/portability, see the discussion at: https://debbugs.gnu.org/61105
Have a nice day, Berny
On 4/6/23 23:05, Bernhard Voelker wrote:
The reasoning for the change is consistency/portability, see the discussion at: https://debbugs.gnu.org/61105
P.S. There's a follow-up discussion and proposed changes at: https://debbugs.gnu.org/62572
Have a nice day, Berny
On Donnerstag, 6. April 2023 23:05:33 CEST Bernhard Voelker wrote:
On 4/5/23 23:16, mh@mike.franken.de wrote:
On Montag, 3. April 2023 12:00:22 CEST Dominique Leuenberger wrote:
==== coreutils ==== Version update (9.1 -> 9.2) Subpackages: coreutils-lang
[...]
'cp -n' and 'mv -n' now exit with nonzero status if they skip
their action because the destination exists, and likewise for 'cp
i', 'ln -i', and 'mv -i' when the user declines. (POSIX
specifies this for 'cp -i' and 'mv -i'.)
[...]
be warned: This might break lots of Makefiles and other scripts. cp -n and mv -n return 1, if *any* file to copy or move exists in the destination. I'm not sure, why this was introduced, because using -n originally should avoid a non zero return status.
I don't see why would this break many Makefiles. Usually they're not using -n, but rather either nothing or -f, don't they?
Using -f forces overwriting existing files, -n should preserve them, if they exist. This is a different approach.
The reasoning for the change is consistency/portability, see the discussion at: https://debbugs.gnu.org/61105
Have a nice day, Berny
Bye. Michael.
On 4/7/23 12:48, mh@mike.franken.de wrote:
On Donnerstag, 6. April 2023 23:05:33 CEST Bernhard Voelker wrote:
On 4/5/23 23:16, mh@mike.franken.de wrote:
On Montag, 3. April 2023 12:00:22 CEST Dominique Leuenberger wrote: This might break lots of Makefiles and other scripts.
I don't see why would this break many Makefiles. Usually they're not using -n, but rather either nothing or -f, don't they?
Using -f forces overwriting existing files, -n should preserve them, if they exist.
Sure, but I wouldn't know a place in Makefiles where the latter would be used.
It would look a bit strange to me just to avoid the double writing of the destination file if various targets would copy the same content from different places to it. Otherwise, if the Makefile would instruct to copy the same file again and again (with or without overwriting), then this would be strange either. Finally, if the content of the source files was different, then I'd call it even a bit fishy for a build process to copy just the first one.
I don't say that -n is not useful in general or not used in scripts or interactively, but probably very seldom in Makefiles ... and if so, then that option could probably just be removed there.
Have a nice day, Berny
* On 4/8/23 18:40, Bernhard Voelker wrote:
On 4/7/23 12:48, mh@mike.franken.de wrote:
On Donnerstag, 6. April 2023 23:05:33 CEST Bernhard Voelker wrote:
On 4/5/23 23:16, mh@mike.franken.de wrote:
On Montag, 3. April 2023 12:00:22 CEST Dominique Leuenberger wrote: This might break lots of Makefiles and other scripts.
I don't see why would this break many Makefiles. Usually they're not using -n, but rather either nothing or -f, don't they?
Using -f forces overwriting existing files, -n should preserve them, if they exist.
Sure, but I wouldn't know a place in Makefiles where the latter would be used.
Configuration files, which you want to provide in case they don't exist and not overwrite them in case they do, come to mind as a scenario.
However, that naturally is only useful when not using a package manager (i.e., a pure install-from-source situation) and furthermore is easily replicated with a normal cp and a file existence test.
It can also be used a poor-man's rsync alternative, if you know that the content of files didn't change, but want to synchronize two directories in a more efficient manner than just blindly overwriting and re-transfering all data.
Mihai
On Samstag, 8. April 2023 18:40:01 CEST Bernhard Voelker wrote:
On 4/7/23 12:48, mh@mike.franken.de wrote:
[...]
Using -f forces overwriting existing files, -n should preserve them, if they exist.
Sure, but I wouldn't know a place in Makefiles where the latter would be used.
It would look a bit strange to me just to avoid the double writing of the destination file if various targets would copy the same content from different places to it. Otherwise, if the Makefile would instruct to copy the same file again and again (with or without overwriting), then this would be strange either. Finally, if the content of the source files was different, then I'd call it even a bit fishy for a build process to copy just the first one.
I don't say that -n is not useful in general or not used in scripts or interactively, but probably very seldom in Makefiles ... and if so, then that option could probably just be removed there.
It can be and is used for copying a first set of config files to a config directory. But if the files are still there and possibly modified you wouldn't want to overwrite them.
Have a nice day, Berny
Bye. Michael.
-
Andrei Borzenkov -
anthony -
Bernhard Voelker -
Dominique Leuenberger -
Felix Miata -
Gordon Messmer -
Jan Engelhardt -
Manfred Hollstein -
Martin Wilck -
mh＠mike.franken.de -
Mihai Moldovan -
Neal Gompa -
Patrick Shanahan -
Rodney Baker -
Stefan Seyfried