http://bugzilla.opensuse.org/show_bug.cgi?id=1205261
Bug ID: 1205261
Summary: dracut/hooks/emergency...ESP's FAT serial number in
initrd halts boot in dracut emergency shell after
rsync migration to new GPT system disk
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: x86-64
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Basesystem
Assignee: screening-team-bugs(a)suse.de
Reporter: mrmazda(a)earthlink.net
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
Created attachment 862770
--> http://bugzilla.opensuse.org/attachment.cgi?id=862770&action=edit
rdsosreport.txt from TW boot attempt
Original Summary:
dracut/hooks/emergency...ESP's FAT serial number in initrd halts boot in dracut
emergency shell after rsync migration to new GPT system disk
Initial state:
1-configured booting & mounting are via LABELs (making UUIDs administratively
unimportant, and grub.cfg's own auto-generated stanzas uncommonly necessary or
desired), with /etc/grub.d/06_custom causing /boot/grub2/custom.cfg's vmlinuz &
initrd symlink stanzas to precede auto-generated entries at boot time. Example:
<https://forums.opensuse.org/showthread.php/533087-How-to-have-a-custom-UEFI…>
2-in /etc/default/grub: GRUB_DISTRIBUTOR="opensusetw" # TW20221008 last zypper
dup
3-multiboot of TW with Leap 15.1, 15.2, 15.3, 15.4, Debian 11 & 12, Ubuntu
20.04 & 22.04 on single NVME
4-only TW installation is configured to touch NVRAM or ESP for writing (e.g.,
other OSes' fstabs don't mount ESP, and/or they have no bootloader installed)
To reproduce:
1-GPT partition new NVME with ESP, swap, and / targets for TW, and / for at
least one additional distro
2-format new NVME's matching targets ESP FAT32, swap swap, and / EXT4 for TW
3-"rsync -rlptgoDHAX --exclude 'lost+found'" from old NVME's ESP and / to new
ESP and / filesystems for TW
4-appropriately edit volume LABELs on new NVME /boot/grub2/grub.cfg,
/boot/grub2/custom.cfg, /etc/fstab
5-repeat create/format/rsync/edit for additional distro(s)
6-remove original NVME
7-try to boot from new NVME
Actual behavior:
1-all other distro(s) boot normally (via TW's custom.cfg entries) as if nothing
had been changed
2-TW boot halts in dracut emergency shell because the original ESP's FAT serial
number cannot be found
(see attached rdsosreport.txt)
Expected behavior:
1-all distros boot normally (via custom.cfg entries) as if nothing had been
changed
Notes:
1-Boot is normal since rebuilding of initrds post-migration.
2-I looked for ESP FAT serial references in several non-TW initrds and found
none.
3-from lsinitrd of original initrd-5.19.13-default:
-rw-r--r-- 1 root root 92 Oct 9 23:10
usr/lib/dracut/hooks/emergency/80-\x2fdev\x2fdisk\x2fby-uuid\x2f20A0-1003.sh
4-# lsblk -f | grep vfat # (current state, not initial state)
������nvme1n1p1 vfat FAT16 PI3P01ESP 20A0-1003 (*original* ESP on 120G NVME)
������nvme0n1p1 vfat FAT32 PNY5P01ESP 4C58-8D7E 294.1M 8% /boot/efi (*new* ESP
on 500G NVME)
5-This issue complicates restoring from backups.
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1123960
Bug ID: 1123960
Summary: LibreOffice missing libreoffice-gtk3
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: x86-64
OS: openSUSE Factory
Status: NEW
Severity: Normal
Priority: P5 - None
Component: LibreOffice
Assignee: bnc-team-screening(a)forge.provo.novell.com
Reporter: knurpht(a)opensuse.org
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
After upgrading to TW 20190126, LO shows the Win95 like fallback interface.
Knowing it is a gtk based app, I ran 'zypper se -i -v libreoffice' I noticed
libreoffice-gtk3 was not installed, so as a try I installed that. LO back to
normal after doing so.
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1206572
Bug ID: 1206572
Summary: nVidia driver gfxG06 RPM doesn't install
Classification: openSUSE
Product: openSUSE Distribution
Version: Leap 15.4
Hardware: x86-64
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Kernel
Assignee: kernel-bugs(a)opensuse.org
Reporter: aaronw(a)doofus.org
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
After recent changes the nVidia driver
nvidia-gfxG06-kmp-default-525.60.11_k5.14.21_150400.22-lp154.15.2.x86_64 is
installing broken symlinks in
/lib/modules/5.14.21-150400.24.38-default/weak-updates/updates.
It is pointing to the old kernel
/lib/modules/5.14.21-150400.22-default/updates/nvidia-drm.ko which does not
exist. This is the RPMs.
I can manually install the drivers by going to the
/usr/src/kernel-modules/nvidia-525.60.11-default directory and running make
modules; make modules_innstall; depmod -a
The annoying part is I need to do this every single time there is a kernel
update.
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1194193
Bug ID: 1194193
Summary: Difficult login to bugzilla.opensuse.org
Classification: openSUSE
Product: openSUSE.org
Version: unspecified
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Bugzilla
Assignee: screening-team-bugs(a)suse.de
Reporter: noga.dany(a)gmail.com
QA Contact: novbugzilla-bugs(a)forge.provo.novell.com
Found By: ---
Blocker: ---
How to reproduce:
* Go to https://bugzilla.opensuse.org
* Click login
* Fill username and password
* Nothing happens
How to workaround:
* Go to https://bugzilla.suse.com/
* Login there
* Go to https://bugzilla.opensuse.org
* Login works
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1188949
Bug ID: 1188949
Summary: The wired connection stops connecting the next day
after installation
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: x86-64
OS: openSUSE Tumbleweed
Status: NEW
Severity: Critical
Priority: P5 - None
Component: Network
Assignee: screening-team-bugs(a)suse.de
Reporter: vladislavmil(a)mail.ru
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
Created attachment 851456
--> http://bugzilla.opensuse.org/attachment.cgi?id=851456&action=edit
NetworkManager logs, inxi-Fxz output, video and photo with error demonstration
After installation, the wired connection works correctly. The next day, it
stops connecting. There is a network connection that lasts indefinitely.
Creating new connections does not lead to any result, as does trying to
reconnect to an existing connection. It only helps to roll back the system to
the backup created immediately after installation. The bug manifests itself on
all DE and the next day after installation. During installation, the system
configures the wired connection itself and the installation takes place without
any errors. The problem manifests itself in openSUSE Leap and Tumbleweed, the
wired connection works correctly on other distributions. I tried to install the
r8168 driver, and add r8169 to the blacklist, but this does not help.
Installing a third-party custom kernel also does not fix the problem. IPv4,
IPv6, DNS and the default route disappear from the connection settings. I
looked at the Network Manager configs, but there is nothing suspicious there,
because of which the problem could manifest itself.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1206224
Bug ID: 1206224
Summary: Dell notebook drains battery during sleep
Classification: openSUSE
Product: openSUSE Distribution
Version: Leap 15.4
Hardware: Other
OS: Other
Status: NEW
Severity: Major
Priority: P5 - None
Component: Other
Assignee: screening-team-bugs(a)suse.de
Reporter: msvec(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
Just got Dell Latitude 7430 and it drains battery when in sleep,
if I leave it overnight, the battery is almost empty.
Some people have reported switching from RAID to AHCI in BIOS helped,
for me it didn't change the situation much (if at all).
The reason might be a lack of deep sleep support in the firmware, but
I wonder if there are any other workarounds/fixes we can do to prevent
the battery drain.
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1186027
Bug ID: 1186027
Summary: VUL-1:
CVE-2021-32917,CVE-2021-32918,CVE-2021-32919,CVE-2021-
32920,CVE-2021-32921: Prosody XMPP server advisory
2021-05-12 (multiple vulnerabilities)
Classification: openSUSE
Product: openSUSE Distribution
Version: Leap 15.2
Hardware: Other
URL: https://smash.suse.de/issue/284222/
OS: Other
Status: NEW
Severity: Minor
Priority: P5 - None
Component: Other
Assignee: mvetter(a)suse.com
Reporter: gianluca.gabrielli(a)suse.com
QA Contact: security-team(a)suse.de
Found By: Security Response Team
Blocker: ---
Prosody security advisory 2021-05-12
====================================
Project
: Prosody XMPP server
URL
: https://prosody.im/
Date
: 2021-05-12
This advisory details 5 new security vulnerabilities discovered in the
Prosody.im XMPP server software. All issues are fixed in the 0.11.9 release
default configuration.
**References**
- Release announcement: https://blog.prosody.im/prosody-0.11.9-released/
- Advisory (HTML): https://prosody.im/security/advisory_20210512/
- Advisory (text): https://prosody.im/security/advisory_20210512.txt
1/5: DoS via insufficient memory consumption controls
-----------------------------------------------------
CVE
: CVE-2021-32918
CVSS
: 7.0 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H/E:F/RL:O/RC:C)
CWEs
: CWE-400
Affected versions
: All versions prior to 0.11.9
Fixed versions
: 0.11.9, 0.11 nightly build 130, trunk nightly build 1434
**Description**
It was discovered that default settings leave Prosody susceptible to remote
unauthenticated denial-of-service (DoS) attacks via memory exhaustion when
running under Lua 5.2 or Lua 5.3. Lua 5.2 is the default and recommended Lua
version for Prosody 0.11.x series.
**Affected configurations**
The default configuration is susceptible to this issue.
Configurations with stricter settings for stanza size limits, rate limits and
garbage collection parameters are at decreased risk from this attack. For more
details please review the 'Mitigation' section for recommended values.
**Mitigation**
Mitigation is possible through configuration changes (on 0.11.7+). All the
configuration changes described in this section are applied by default in
Prosody 0.11.9.
1) Enable more aggressive garbage collection
On Lua 5.2 and 5.3, the garbage collector does not free unused memory fast
enough by default. This allowed Prosody's memory usage to grow excessively
during certain traffic patterns.
It is recommended to set a garbage collection speed of at least 500 in the
global section of your configuration file:
```
gc = {
speed = 500;
}
```
Be aware that this setting may increase CPU usage if the other mitigations
in this section are not applied.
2) Enable stricter stanza size limits
By default Prosody ships with extremely permissive stanza size limits (up
to 10MB). This value was introduced as a way to place a limit on memory
usage without affecting legitimate use of the server. However testing
demonstrates that the default limit is too high for most deployments.
Our recommendation (and the default in 0.11.9) is to adopt the same default
size limits that are already enforced by ejabberd, one of the other major
XMPP servers on the network.
To enable the new limits explicitly, add to the global section of your
configuration file the following options:
c2s_stanza_size_limit = 256 * 1024
s2s_stanza_size_limit = 512 * 1024
Be aware that reducing limits has the potential to introduce
interoperability issues with deployments that do not enforce the same size
limits. For example, remote contacts with large avatars.
3) Enable rate limits
By default Prosody does not enable any rate limits. However we recommend
enabling them for all production and public deployments to ensure fair
consumption of resources across all connections.
First, ensure that mod_limits is enabled by adding "limits" to your
global modules_enabled configuration option:
```
modules_enabled = {
...
"limits";
...
}
```
Next, configure the limits:
```
limits = {
c2s = {
rate = "10kb/s";
};
s2sin = {
rate = "30kb/s";
}
}
```
**Advice**
All public deployments should upgrade to 0.11.9 or apply the above
configuration changes.
Deployments using nightly builds should upgrade to the latest available
builds.
**Credits**
Many thanks to Travis Burtrum (moparisthebest) for discovering and reporting
this issue, and providing a test case.
**Commits**
- https://hg.prosody.im/trunk/rev/db8e41eb6eff
- https://hg.prosody.im/trunk/rev/b0d8920ed5e5
- https://hg.prosody.im/trunk/rev/929de6ade6b6
- https://hg.prosody.im/trunk/rev/63fd4c8465fb
- https://hg.prosody.im/trunk/rev/1937b3c3efb5
- https://hg.prosody.im/trunk/rev/3413fea9e6db
----------------------------------------------------------------------------
2/5: DoS via repeated TLS renegotiation causing excessive CPU consumption
----------------------------------------------------------------------------
CVE
: CVE-2021-32920
CVSS
: 5.1 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L/E:H/RL:O/RC:C)
CWEs
: CWE-400
Affected versions
: All versions prior to 0.11.9
Fixed versions
: 0.11.9, 0.11 nightly build 130, trunk nightly build 1434
**Description**
It was discovered that Prosody does not disable SSL/TLS renegotiation, even
though this is not used in XMPP. A malicious client may flood a connection
with renegotiation requests to consume excessive CPU resources on the server.
Support for disabling renegotiation depends on OpenSSL 1.1.1+ and LuaSec 0.7+.
**Affected configurations**
The default configuration is susceptible to this issue.
**Temporary mitigation**
Ensure you have OpenSSL 1.1.1 or higher and LuaSec 0.7 or higher, and set the
following ssl option (or add to your existing one if you have one):
```
ssl = {
options = {
no_renegotiation = true;
}
}
```
This configuration is applied by default in 0.11.9.
**Advice**
All public deployments should upgrade to 0.11.9 or apply the above
configuration changes.
Deployments using nightly builds should upgrade to the latest available
builds.
**Credits**
This flaw was discovered by Kim Alvefur, a member of the Prosody team.
**Commits**
- https://hg.prosody.im/trunk/rev/55ef50d6cf65
- https://hg.prosody.im/trunk/rev/5a484bd050a7
- https://hg.prosody.im/trunk/rev/aaf9c6b6d18d
-----------------------------------------------------------------------
3/5: Use of timing-dependent string comparison with sensitive values
-----------------------------------------------------------------------
CVE
: CVE-2021-32921
CVSS
: 4.7 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N/E:U/RL:O/RC:U)
CWEs
: CWE-1254
Affected versions
: All versions prior to 0.11.9
Fixed versions
: 0.11.9, 0.11 nightly build 130, trunk nightly build 1434
**Description**
It was discovered that Prosody does not use a constant-time algorithm for
comparing certain secret strings when running under Lua 5.2 or later. This can
potentially be used in a timing attack to reveal the contents of secret
strings to an attacker.
Lua 5.1 utilizes a technique called "string interning", which protected string
comparisons from timing attacks. In Lua 5.2 and later versions, strings over
40 bytes in length are excluded from interning.
With Prosody running under Lua 5.2, this makes any secret string over 40 bytes
in length vulnerable to potential discovery via timing attacks.
Note that if a secret string contains non-ASCII (unicode) characters, it may
be longer than 40 bytes when encoded as UTF-8 (Prosody's internal encoding)
even if it is fewer than 40 characters long.
It should be noted that to successfully perform a timing attack, a significant
number of failed attempts must typically be made to "guess" at the contents of
the secret string.
We are not aware of any attempts to exploit this vulnerability (which would
likely be noticeable), and no known proof-of-concept exploit exists.
**Affected configurations**
This flaw affects the following modules:
- mod_auth_internal_plain (disabled by default)
mod_auth_internal_plain performs a timing-dependent comparison to the
user's password if the user's password is longer than 40 bytes. This may
allow an attacker to discover a user's password via a timing attack.
We do not generally recommend mod_auth_internal_plain for new deployments,
and mod_auth_internal_hashed has been the default for Prosody 0.11.x.
- mod_muc (disabled by default)
mod_muc supports password-protection of MUCs. The password validity check
is performed using a timing-dependent comparison, which may allow an
attacker to discover the MUC password via a timing attack if the password
is longer than 40 bytes.
We do not generally recommend using password-protected MUCs. Instead use
affiliations to directly grant access to specific JIDs whenever possible.
- mod_auth_internal_hashed (enabled by default but not typically vulnerable)
mod_auth_internal_hashed has been updated for safety, but it is
not vulnerable in the default configuration of Lua 5.2 as the password
hashes it compares do not exceed 40 bytes.
- mod_dialback (enabled by default but not typically vulnerable)
mod_dialback has been updated for safety, but due to the single-use nature
of s2s dialback verification strings a timing attack on this module is not
believed to be possible, or to grant an attacker any advantage if it were.
**Temporary mitigation**
mod_auth_internal_plain: we recommend that people upgrade to
mod_auth_internal_hashed due to this and also to benefit from its other
security properties.
mod_muc: use affiliations to grant access to a MUC instead of passwords. If
passwords must be used, ensure they are shorter than 40 bytes.
Rate limits can greatly lengthen the amount of time required to successfully
complete a timing attack. Enable and configure mod_limits.
**Advice**
All deployments should upgrade to 0.11.9.
Deployments using nightly builds should upgrade to the latest available
builds.
**Credits**
This flaw was discovered by Matthew Wild, a member of the Prosody team. The
issue with MUC passwords was also previously identified by Robert Gr��sser.
**Commits**
- https://hg.prosody.im/trunk/rev/c98aebe601f9
- https://hg.prosody.im/trunk/rev/13b84682518e
- https://hg.prosody.im/trunk/rev/6f56170ea986
-------------------------------------------------------------------
4/5: Use of mod_proxy65 is unrestricted in default configuration
-------------------------------------------------------------------
CVE
: CVE-2021-32917
CVSS
: 5.1 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L/E:H/RL:O/RC:C)
CWEs
: CWE-862, CWE-400
Affected versions
: All versions prior to 0.11.9
Fixed versions
: 0.11.9, 0.11 nightly build 130, trunk nightly build 1434
**Description**
mod_proxy65 is a file transfer proxy provided with Prosody to facilitate the
transfer of files and other data between XMPP clients.
It was discovered that the proxy65 component of Prosody allows open access
by default, even if neither of the users have an XMPP account on the local
server, allowing unrestricted use of the server's bandwidth.
**Affected configurations**
The default configuration does not enable mod_proxy65 and is not affected.
With mod_proxy65 enabled, all configurations without a 'proxy65_acl' setting
configured are affected.
**Temporary mitigation**
Configure 'proxy65_acl' to a list of XMPP domains that should be allowed
to use the file transfer proxy.
**Advice**
All deployments should upgrade to 0.11.9 and/or configure a 'proxy65_acl' as
desired.
Deployments using nightly builds should upgrade to the latest available
builds.
The default behaviour in 0.11.9 allows all local clients to initiate a data
stream through the proxy if proxy65_acl is unconfigured.
**Credits**
This flaw was discovered by the Prosody team.
**Commits**
- https://hg.prosody.im/trunk/rev/65dcc175ef5b
--------------------------------------------------------------
5/5: Undocumented dialback-without-dialback option insecure
--------------------------------------------------------------
CVE
: CVE-2021-32919
Affected versions
: Prosody 0.10.x, Prosody 0.11.x prior to 0.11.9
Fixed versions
: 0.11.9, 0.11 nightly build 130, trunk nightly build 1434
**Description**
The undocumented option 'dialback_without_dialback' enabled an experimental
feature for server-to-server authentication. A flaw in this feature meant it
did not correctly authenticate remote servers, allowing a remote server to
impersonate another server when this option is enabled.
**Affected configurations**
The default configuration is not affected.
Configurations with the setting 'dialback_without_dialback' set to true are
affected.
**Temporary mitigation**
Remove or disable the 'dialback_without_dialback' option.
**Advice**
All deployments should upgrade to 0.11.9 or disable this feature.
Deployments using nightly builds should upgrade to the latest available
builds.
The affected feature has been removed in 0.11.9.
**Credits**
This flaw was discovered by the Prosody team.
**Commits**
- https://hg.prosody.im/trunk/rev/6be890ca492e
- https://hg.prosody.im/trunk/rev/d0e9ffccdef9
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1206674
Bug ID: 1206674
Summary: No network (wicked) after 23-12-2022 updates
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: x86-64
OS: openSUSE Tumbleweed
Status: NEW
Severity: Major
Priority: P5 - None
Component: Network
Assignee: screening-team-bugs(a)suse.de
Reporter: alessandro.sturniolo(a)gmail.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
Created attachment 863670
--> http://bugzilla.opensuse.org/attachment.cgi?id=863670&action=edit
Network related log files and configurations.
Today (23-12-2022) I have updated my system, and after reboot (there was a new
kernel version), network no longer worked.
After a while I realized that the interfaces remained down, so if I manually
bring them up (ip link set devName up), network came back to works.
Currently, after every system restart, I have to bring up manually my network
interfaces, to get the network to works.
Obviously before today updates, my network it always worked without problems
for years.
My network setup is based on wicked (no NetworkManager), has two network
interfaces (enp3s0 and enp4s0) configured as slaves of a bonding device
(bond0).
I followed these instructions
https://en.opensuse.org/index.php?title=openSUSE:Bugreport_wicked and I've
collected some files that I attach to this report.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1203748
Bug ID: 1203748
Summary: Laptop very slow in battery mode (Lenovo Thinkpad
T470)
Classification: openSUSE
Product: openSUSE Distribution
Version: Leap 15.4
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Kernel
Assignee: kernel-bugs(a)opensuse.org
Reporter: sndirsch(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
For some reason my laptop gets very slow in battery only mode. I notice this
when watching videos. It makes it rather unusable when not connecting it to
power. It looks like it goes into some deep powersave mode. I would like to
avoid this even if this would half the running time in battery mode. Which
information do you need?
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1202570
Bug ID: 1202570
Summary: steam deck - echo freeze | tee -a /sys/powerstate
glitches the screen
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: x86-64
OS: openSUSE Tumbleweed
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Kernel
Assignee: kernel-bugs(a)opensuse.org
Reporter: monkeyboyted(a)yahoo.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
Suspend seems to work in the latest kernel in kernel:HEAD repo. Software
suspends seems to glitch the screen upon re-initialization. Wifi and changing
to tty works.
lsb_release -a
LSB Version: n/a
Distributor ID: openSUSE
Description: openSUSE Tumbleweed
Release: 20220817
Codename: n/a
zypper info kernel-default
Loading repository data...
Reading installed packages...
Information for package kernel-default:
---------------------------------------
Repository : kernel-repo
Name : kernel-default
Version : 6.0~rc1-3.1.g7bd57d5
Arch : x86_64
Vendor : obs://build.opensuse.org/Kernel
Installed Size : 273.3 MiB
Installed : Yes
Status : up-to-date
Source package : kernel-default-6.0~rc1-3.1.g7bd57d5.nosrc
Upstream URL : https://www.kernel.org/
Summary : The Standard Kernel
Description :
The standard kernel for both uniprocessor and multiprocessor systems.
Source Timestamp: 2022-08-16 07:58:42 +0000
GIT Revision: 7bd57d59ba8c141be35bb5189487a899d04e76ec
GIT Branch: master
--
You are receiving this mail because:
You are on the CC list for the bug.