New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RDRAND on AMD CPUs does not work #11810
Comments
These failures almost surely are kernel or driver issues. Please contact your downstream distro about this first, and let them escalate issues to us if they are sure this is a systemd issue, which however I think is unlikely. Also, when you file a bug here, please fill in the form supplied, i.e. provide the systemd version and such. We put that form up for a reason. Thank you for understanding. |
@poettering Someone has reported this in #systemd IRC before. The key thing here is that after the first sleep, systemd returns -EEXIST for unit_set_invocation_id (which uses hashmap operations entirely). It might still not be a systemd bug, but the upshot is units end up failing due to this error, so neither does suspend work for the reporter, nor shutdown, in particular, their logs said that multiple jobs failed due to the "Failed to set invocation ID for unit: File exists". In their case, writing the value to the sysfs file would work, but making systemd start the target up wouldn't. |
@poettering Some bug reports in other distributions which were filed very recently: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921267 https://bbs.archlinux.org/viewtopic.php?id=244399 Looks it broke after upgrading to a newer systemd for them... |
ok |
Facing a similar issue, downgrading systemd to v239 solves the problem. The same reappears on v240 & v241. Tested with Manjaro and Debian sid. |
@Experimenter Yes I did that now its resolved. |
I'm also facing this problem all the time, on a fresh Arch Linux install, on a laptop with an AMD CPU. I have another laptop and desktop, each with Intel CPUs and neither face this problem. Any chance that this specifically happens on AMD CPUs? |
Yep I am on AMD too I tried on Intel CPU worked flawlessly. |
For me too only the AMD CPUs have been effected. My machines with AMD A8
& A6 have a problem while the intel one runs fine. After suspend every
service I try to startup using systemctl pops up the same error: Failed
to setinvocation IDforunit: Fileexists
|
Also got AMD CPU and experienced the same problem after latest Arch upgrade. |
got this issue on Fedora 30 with kernel 5.0.6 on "AMD E1-6010 APU with AMD Radeon R2 Graphics". systemd version systemd-241-4.gitcbf14c9.fc30.x86_64. After suspend any and all services fail to start with "Failed to set invocation ID for unit: File exists" and the machine is essentially unusable. Tried using both radeon and amdgpu for the gpu part of the machines apu, that makes no difference. I'm not sure where to begin figuring out why systemd breaks after return from suspend. Let me know if/how I can provide more information. |
I have this issue on my laptop with "AMD A6-6310 APU with AMD Radeon R4 Graphics", but not on my desktop with an AMD CPU and an nVidia GPU, so it's probably something on the GPU end. |
Just a little detail, suspend to disk doesn't have this problem on my machine - just suspend to RAM. Thus, using suspend to disk instead is a somewhat acceptable workaround. |
In my case, the problem occurs not only with suspend but also after restarting any of the systemd services. For e.g., running the following:
causes any subsequent attempts to start/restart a service to fail. |
Even v142 has the same issue. So for the time being, downgrading to v139 seems to be the only work-around. |
Apparently, this issue is easy to trigger, if you have the right hardware (and unfortunately none of the developers seem to have those). |
Triggering this really is super-easy on the AMD E1-6010, it's one of those happens-every-time bugs. Doing a git bisect on a 1.4 GHz dual-core isn't very tempting, though. That's the only hardware I have where this happens, Ryzen+RX570 doesn't have this problem. I could do if nobody else with hardware that doesn't spend days compiling systemd (or anything) does it. |
@oyvinds That would be great, thanks! If the AMD E1-6010 is indeed that slow, I would consider compiling it on your faster Ryzen system and copying the binaries/rpm over. |
I haven't used that problematic system recently, will see if I can still reproduce, and if yes then I will try bisecting. |
Hello everyone.
|
I guess at this point we don't need further "me too's", as this doesn't really help us to find the root cause. Instead we need someone with the appropriate hardware to find the first faulty commit. |
@mbiebl, I am currently bisecting between v239 and v240. Using I thought of using |
@madhur4127 You'll need to run systemd no bare-metal and not inside a systemd-nspawn container. You can't suspend a container via |
I was trying to compile systemd to do a git bisect, but I went to an error during |
@jimy-byerley In my experience it's simpler to just modify the meson.build file where the libmount >= 2.30 dependency is specified. However Debian stable's version of Meson is also too old for the systemd meson.build syntax, so I also have a newer Meson version built from source in /usr/local. With those two changes systemd builds on Debian stable for me, unless I'm forgetting other things it needed. |
Well, it's how uuids are generated these days. Pretty much everyone just uses type 4 uuids (i.e. randomized ones). If you think that the likeliness of collision is too high, by all means, fix the whole stack, but please start with the linux kernel, which for example generates uuids this way via /proc/sys/kernel/random/uuid or /proc/sys/kernel/random/boot_id. I am pretty sure we are fine with this mode of operation as long as the Linux kernel is. And no, the other ways to generate uuids don#t really work: maintaining global counters is either unsafe (because we need uuids in all kinds of processes, and we can't share state safely if they run with different privileges and shall not be able to trigger collisions easily). And things like uuidd doesn't work during early boot either.
We don't use glibc rand() for generating uuids, and that's expressly documented in our comments.
Yes, but already discussed to length: Thing though is that a) we don't trust RDRAND for generating cryptographic keys. When we do that we go to /dev/urandom like everyone should. b) we trust it enough for generating uuids, which are not cryptographic key material, where RDRAND should be fine and c) The linux kernel on various prominent distros actually does trust RDRAND now, and will fill /dev/urandom with it crediting it for full entropy, so that we'll actually end up using RDRAND after all in the end... i.e. check this:
(that's from Fedora) So, yes, in systemd we are not going to make the decision to rely on RDRAND for key generation, but your distro might have configured to /dev/urandom like that, so we might ultimately after all. systemd uses RDRAND directly only for generating UUIDs, seeding hash tables, temporary file name starting seeds, unix UID acquisition statring seeds, where things generally don't matter that much.
Yeah, sure, for cryptographic stuff we use /dev/urandom, read the sources and its comments, it makes that clear.
uh? callback functions? what's that supposed to do? also, anything with such callback functions probably makes things harder to read, not simpler. (I know, because I spend 90% of my days reviewing code, do you?) |
BTW, AMD is preparing a firmware update now that fixes RDRAND for them (not sure of just one new Ryzen or on old Ryzen too): (sorry, German only) |
The Linux kernel uses a (mostly) sane construction: It seeds an entropy pool and uses a cryptographic hard (chacha20-based) PRNG to emit a stream of randomness. With 16 bytes out of a chacha20-based PRNG with a central entropy pool (so no way to read the same value twice; there's a central counter besides the entropy pool), collision is clearly low enough to be tolerable. Remaining sanity problems: The kernel uses rdrand() in some places (get_random_u64(), e.g. used as random ID for seccomp stuff; this is probably arcane enough). What it should do is using get_random_bytes() that does not block when there's not enough entropy in the pool. This still delivers a stream of cryptographic hard stream of randomness that is to some extend predictable (not enough entropy in the pool), but certainly won't provide collisions. This is something the Linux kernel only partly delivers to userland, but is worth having. Implementation would be straight-forward, just another flag to getrandom() which returns a bunch of pseudo-random bytes without blocking, even when the pool is not yet filled with trustworthy entropy, but only with the non-trustworthy RDSEED entropy. This would relieve the systemd's problem that it needs entropy very early in the boot sequence. Essentially, it's a one-line patch of random.c, line 2135: -if (!crng_ready()) { BTW: Directly reading from /dev/urandom has the same effect, as unlike getrandom() it does never block, only warn when there's no entropy. The point is that when you want collision-free stuff, you have about four options: a) use a known cryptographic hard random source that has central entropy pool+state (entropy doesn't matter much, it matters that reads always give non-overlapping parts of the output stream) If you want to scale, and not rely on a centralized pool or state, you can use construct a) with per-process/thread PRBG (pseudo-random; if you a block cipher with a counter as tweak, a per-thread guaranteed non-overlapping starting point of the counter is sufficient); the seed for that can come from something like randombytes(), or you use construct d) with per-core entropy sources (non-deterministic NRBG). The thing that is no option is a entropy source that is not either monitored for quality or by audit known good. The failure modes of hardware are not necessarily the ones you think they are. “Don't matter that much” assumes maybe a well-hidden backdoor (indistinguishable from randomness unless you have the key), not a rather hard failure mode, e.g. entropy source not powered up. You don't trust RDRAND for cryptography, but you do trust it for non-collision. That works for the Intel case, where RDRAND is the output of a stream cipher (AES in counter mode with the key coming from the entropy source — if the entropy source fails, the key stream still will look indistinguishable from proper random). That doesn't work for the AMD case, where a failing entropy source also causes RDRAND to fail the same way as RDSEED. A dubious quality random number source where you can know when it is failing (by simply analyzing it) is probably one of the better deals you can get in this situation. It helps if you can only destroy it, but can't make it predictable by someone who knows a secret. BTW: You missed the main point in the last part: have separate functions for separate purposes, and clearly specify what they should deliver. The callback for checking for collisions was an example. The main thing is that you properly specify what you need, and then you can evaluate whether you call the right function. Linux has generate_random_uuid(), which calls get_random_bytes(), which warns only if the entropy is insufficient, but delivers a collision-unlikely PRNG output nonetheless. This is something that is quite straight-forward to audit, even when it lacks comments. Anyways: with the exception of two or three cases where get_random_u64 is used in the Linux kernel, and the lack of a pseudo-random fallback mode for getrandom(), there's almost nothing to complain there: This uses a state of the art construction with entropy source+predictable expansion. The code there has clearly been written by someone who knows what he was doing, and has changed completely after 2013 (for good). |
Of course this doesn't work for Intel either. The key stream will look random on it's own but it would be indistinguishable from an earlier generated stream that uses the same seed material. Maybe that won't wrong-foot the mentioned systemd, but it would break any other system that relies on it to not collide with a previous stream. For instance, let's assume that you start by generating UUIDs: these are supposed to be unique across systems, not just the booting system. |
So that's not quite rigth. RDRAND is fine for creating random cryptographic keys; it is NIST SP 800-90A complaint. However, if you need to seed another cryptographic generator, you should use RDSEED. For more details, see [1] [1] https://software.intel.com/en-us/blogs/2012/11/17/the-difference-between-rdrand-and-rdseed All of this is of course if you trust Intel, of course. Of course, I'd probably trust Intel much more than I would trust an ARM chip manufactured by Huawei --- but someone working for the Ministry of State Security or the Chinese People's Liberation Army might have an opposite point of view on that score. As far as GRND_PREMATURE is concerned, it is something I've considered, although it would probably be something like GRND_I_SOLEMNLY_SWEAR_I_UNDERSTAND_THIS_IS_INSECURE. Ultimately, it's about how much do you trust application programmers, and whether someone (perhaps a less sophisticated distribution packager/maintainer) might blindly apply a patch that adds GRND_PREMATURE to "fix" a hang during early boot problem, when it's being used to create long-term public/private keypairs. One could argue that silly/stupid programmers like that might very well use /dev/urandom, and that's a fair point. My preference would be to simply tell people if you really need something which is unique, but not necessarily cryptographically secure, to simply read a UUID from /proc/sys/kernel/random/uuid. Yes, today it will potentially issue a warning to dmesg since it calls get_random_bytes(), but I'd much rather fix the kernel to suppress a warning if someone fetches a UUID via /proc/sys/kernel/random/uuid than to add a new GRND_WATCH_ME_GET_ABUSED_BY_A_CLUELESS APPLICATION_PROGRAMMER flag. Because I can guarantee it will happen, and probably it will get baked into some trashy IOT device.... |
hmmm, but with a totally not initialized pool on a system that is entropy starved (i.e. no rdrand, no hwrng of any form), generating a uuid from /proc/sys/kernel/random/uuid wouldn't be solving our problem either, would it? i mean, if there's really no entropy than pulling a uuid from that would result in basically a constant value, which defeats the purpose of uuids... |
It'll be at least as good as using /dev/urandom, and you're OK with that, right? We will seed the entropy pool with the hardware TOD clock, and with the ethernet addresses for any device drivers that are loaded (although if they are all modules, that'll be an ordering issue), etc. So if you're going for uniqueness but not necessarily cryptographically secure, in most cases it will hopefully be good enough. Now if the there is no hardware TOD clock (no batteries, and you're utterly reliant on ntp), and all of your networking devices are modules loaded very late in the boot process, this might no be all that helpful --- but then you're screwed if you use /dev/urandom. Again, /proc/sys/kernel/random/uuid is no worse than /dev/urandom. And today it will issue a kernel warnings, but that is something I'll suppress in the future, especially if we can advertise that the only safe things people should be using is /proc/sys/kernel/random/uuid or getrandom(2), and there may be times when the uuid won't be unique, but ultimately, if you're using crap designed hardware, we can't manufacture uniqueness (or randomness) where there is none..... |
Am 24. Juli 2019 01:57:54 GMT+08:00 schrieb tytso <notifications@github.com>:
So that's not quite rigth. RDRAND is fine for creating random
cryptographic keys; it is NIST SP 800-90A complaint.
The assumption was that the entropy source fails.
However, if you
need to seed another cryptographic generator, you should use RDSEED.
For more details, see [1]
[1]
https://software.intel.com/en-us/blogs/2012/11/17/the-difference-between-rdrand-and-rdseed
All of this is of course if you trust Intel, of course. Of course,
I'd probably trust Intel much more than I would trust an ARM chip
manufactured by Huawei --- but someone working for the Ministry of
State Security or the Chinese People's Liberation Army might have an
opposite point of view on that score.
The PLA would have performed an audit of the Huawei device, and can't do the same with Intel. OK, maybe they can (by hacking into Intel's EDA computers ;-)…
As far as GRND_PREMATURE is concerned, it is something I've considered,
although it would probably be something like
GRND_I_SOLEMNLY_SWEAR_I_UNDERSTAND_THIS_IS_INSECURE.
Haha, fine with me. I thought about GRND_TRUST_CPU_ENTROPY_SOURCE, similar to the kernel compilation switch. Or GRND_JUST_GIVE_ME_UUIDS_QUICK_PLEASE
Ultimately, it's
about how much do you trust application programmers, and whether
someone (perhaps a less sophisticated distribution packager/maintainer)
might blindly apply a patch that adds GRND_PREMATURE to "fix" a hang
during early boot problem, when it's being used to create long-term
public/private keypairs.
I'd expect them to use the nonblock option, and ignore the error code, maybe filling the memory block with time+MAC before. People resort to desperate means when they need to get a crappy product out into production tomorrow. Filling in the requested memory with the chacha20 stream anyways for nonblockig requests could be a good idea; the returned EAGAIN then means that it is not seeded properly.
One could argue that silly/stupid
programmers like that might very well use /dev/urandom, and that's a
fair point. My preference would be to simply tell people if you
really need something which is unique, but not necessarily
cryptographically secure, to simply read a UUID from
/proc/sys/kernel/random/uuid. Yes, today it will potentially issue a
warning to dmesg since it calls get_random_bytes(), but I'd much rather
fix the kernel to suppress a warning if someone fetches a UUID via
/proc/sys/kernel/random/uuid than to add a new
GRND_WATCH_ME_GET_ABUSED_BY_A_CLUELESS APPLICATION_PROGRAMMER flag.
Because I can guarantee it will happen, and probably it will get backed
into some trashy IOT device....
If the purpose is getting an UUID, it's OK. File interfaces are problematic, as they might not be mounted (e.g. early in the boot sequence, or in a jailed environment). That was the original point of providing a kernel call for this function.
…--
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/
|
No, we do not use /dev/urandom for UUID generation (at least not on systems that support getrandom() that is, on older stuff we do, simply because we don't have anything better and then use /dev/urandom as replacement for getrandom()). On modern systems, for UUID generation we'll try RDRAND first, and synchronous getrandom(flags=0) second, and that's where the story ends.
Typical general purpose systems are usually not linking ethernet drivers in, which leaves the clock as only source, but if you start multiple systems at once (which is likely enough in virtualized environments) there's a good chance they then all generate the same series of uuids, which we don't want...
I would prefer if the warning would stay for /proc/sys/kernel/random/uuid too... In virtualized environments the chance is too high that on general purpose distros this will generate a non-unique stream of uuids. (BTW, related to this, in #13137 I prepped a PR that makes systemd credit entropy with data stored in a specific EFI variable to the kernel pool if its set, very early on. It also contains work that systemd-boot (which is an EFI boot loader included in our tree) reads a random seed file from the ESP, then generates two new seeds from it with SHA256 counter mode, rewriting the random seed file with one, and writing the other into the EFI variable. This should then give us a full pool from earliest userspace on, at least on EFI systems that use systemd-boot, and if the random seed file in the ESP was initialized with good entropy first. It takes inspiration from NetBSD's boot loader random seed stuff, but is a bit more careful to never reuse the same unmodified seed in multiple boots on the same or on different systems. Ideally the kernel would already read that EFI variable itself btw, and unset it. And ideally there'd be a non-EFI mechanism for this too.) |
Nah, systemd runs as PID 1, it always mounts /proc as first thing, and the first uuid it needs afterwards. We are totally OK with use /proc if we need to. That said, we don't want to generate uuids from an uninitialized pool, since the chance is too high for it not resulting in unique ids. |
An ugly, ugly work-around for systemd#11810. And no, we shouldn't have to do this. This is something for AMD, the firmware or the kernel to fix/work-around, not us. But nonetheless, this should do it for now. Fixes: systemd#11810
An ugly, ugly work-around for systemd#11810. And no, we shouldn't have to do this. This is something for AMD, the firmware or the kernel to fix/work-around, not us. But nonetheless, this should do it for now. Fixes: systemd#11810
An ugly, ugly work-around for systemd#11810. And no, we shouldn't have to do this. This is something for AMD, the firmware or the kernel to fix/work-around, not us. But nonetheless, this should do it for now. Fixes: systemd#11810
Just to mention this: it appears AMD admits to the borkage now, and now posted this: https://lore.kernel.org/patchwork/patch/1115413/ In times of most big distros defaulting to CONFIG_RANDOM_TRUST_CPU=y this sounds like a big CVE-worthy security vuln, but apparently noone cares enough for AMD CPUs? Also, I put together this: https://systemd.io/RANDOM_SEEDS That document explains systemd logic behind random seed initialization and RDRAND usage. |
In case someone is interested in picking up a test rig... The dell inspiron 3180 is a 15h machine (cpu_family = 21) and should have the buggy instruction. A used one costs about $90 USD. |
AMD provides a secure RNG library at RNG Library. It was last updated Jan 15, 2020. The latest secure RNG code is available in
Looking at the source code in It is not clear (to me) if all that is needed is to check the carry flag. However, the release notes skip 15h and 16h processors, and moves on to 17h processors:
It is a pretty shitty way to do things... don't discuss the bug, and don't tell folks how to use the instruction safely. |
We check the carry flag. Checking the carry flag is documented, and hence we do it. However, on the affected AMD CPU flag they set the carry flag incorrectly and hand us constant data with no indication that it is rubbish |
An ugly, ugly work-around for systemd#11810. And no, we shouldn't have to do this. This is something for AMD, the firmware or the kernel to fix/work-around, not us. But nonetheless, this should do it for now. Fixes: systemd#11810 (cherry picked from commit 1c53d4a)
AMD/Ryzen users: was this ever resolved? |
Your problem most likely has nothing to do with RDRAND, you should debug and find out why exactly it's happening. I believe systemd did create a workaround to check the output of RDRAND and discard it if it's buggy. AMD did also release corrected AGESA code, and a few motherboard manufacturers have released UEFI updates that include the updated AGESA. You should make sure to have the latest UEFI updates installed, and confirm with your motherboard manufacturer that they have released a fix with the relevant or newer AGESA version. |
My guy, I don't even know what is RDRAND, I'm just a "regular user" that happens to own AMD Ryzen APU. |
Well in that case, this is not the appropriate place to ask about suspend issues, since it's not RDRAND related. What you need to do is file a bug report in your distro's bug tracker and go from there. And maybe ask for help on some tech support forums. |
If you need to know about RdRand, ask me.
…On Sun, Dec 6, 2020, 11:52 AM Sandeep ***@***.***> wrote:
My guy, I don't even know what is RDRAND, I'm just a "regular user" that
happens to own AMD Ryzen APU.
I just noticed there was a bunch of AMD users here, so I thought "Looks
like a nice place to ask questions to fellow AMD owners and AMD regular
users"
I'm just asking this question (this is not a bug report or request):
Do you use AMD Ryzen? If Yes, are you able to suspend your Linux OS to
RAM, like worked on older versions?
That's all.
I just want to know if this was ever resolved (things preventing suspend
to work) because from what I've read in other places this was never
properly addressed. The only thing that happened is a bunch of people
saying things like "I never suspend to ram anyway, just suspend to disk
instead" I'm not interested in cop-outs.
Well in that case, this is not the appropriate place to ask about suspend
issues, since it's not RDRAND related. What you need to do is file a bug
report in your distro's bug tracker and go from there. And maybe ask for
help on some tech support forums.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#11810 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABYMCGL6ROOPORQPHP26ZYTSTPOIZANCNFSM4GZXWCEA>
.
|
Just not here, if you may. |
After suspending the system once can't suspend again. Shutdown gives unmount failed errors and can't shutdown too.
System info
System: Host: Capsparrow Kernel: 4.20.10-1-MANJARO x86_64 bits: 64 compiler: gcc v: 8.2.1 Desktop: KDE Plasma 5.15.0 Distro: Manjaro Linux Machine: Type: Laptop System: HP product: HP 245 G4 Notebook PC v: Type1ProductConfigId serial: <filter> Mobo: HP model: 80C7 v: KBC Version 98.0E serial: <filter> UEFI: Insyde v: F.1C date: 10/29/2015 Battery: ID-1: BAT0 charge: 38.8 Wh condition: 39.7/39.7 Wh (100%) model: Hewlett-Packard Primary status: Charging CPU: Topology: Quad Core model: AMD A8-7410 APU with AMD Radeon R5 Graphics bits: 64 type: MCP arch: Puma rev: 1 L2 cache: 2048 KiB flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm bogomips: 17572 Speed: 998 MHz min/max: 1000/2200 MHz Core speeds (MHz): 1: 1006 2: 1087 3: 1177 4: 1288 Graphics: Device-1: AMD Mullins [Radeon R4/R5 Graphics] vendor: Hewlett-Packard driver: radeon v: kernel bus ID: 00:01.0 Display: x11 server: X.Org 1.20.3 driver: ati,radeon unloaded: modesetting resolution: 1366x768~60Hz OpenGL: renderer: AMD MULLINS (DRM 2.50.0 4.20.10-1-MANJARO LLVM 7.0.1) v: 4.5 Mesa 18.3.3 direct render: Yes Audio: Device-1: AMD Kabini HDMI/DP Audio vendor: Hewlett-Packard driver: snd_hda_intel v: kernel bus ID: 00:01.1 Device-2: AMD FCH Azalia vendor: Hewlett-Packard driver: snd_hda_intel v: kernel bus ID: 00:14.2 Sound Server: ALSA v: k4.20.10-1-MANJARO Network: Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet vendor: Hewlett-Packard driver: r8168 v: 8.045.08-NAPI port: 2000 bus ID: 01:00.0 IF: eno1 state: down mac: <filter> Device-2: Broadcom and subsidiaries BCM43142 802.11b/g/n vendor: Hewlett-Packard driver: wl v: kernel port: 2000 bus ID: 05:00.0 Drives: Local Storage: total: 465.76 GiB used: 68.75 GiB (14.8%) ID-1: /dev/sda vendor: Toshiba model: MQ01ABF050 size: 465.76 GiB Partition: ID-1: / size: 147.39 GiB used: 14.49 GiB (9.8%) fs: ext4 dev: /dev/sda1 ID-2: /home size: 294.29 GiB used: 54.26 GiB (18.4%) fs: ext4 dev: /dev/sda2 ID-3: swap-1 size: 4.00 GiB used: 0 KiB (0.0%) fs: swap dev: /dev/sda3 Sensors: System Temperatures: cpu: 52.9 C mobo: 0.0 C gpu: radeon temp: 54 C Fan Speeds (RPM): N/A Info: Processes: 176 Uptime: 1h 07m Memory: 3.32 GiB used: 1.74 GiB (52.3%) Init: systemd Compilers: gcc: 8.2.1 Shell: zsh v: 5.7.1 inxi: 3.0.30
Journalctl :
`➜ ~ journalctl -xe -p3 -b
-- Subject: A start job for unit network-suspend.service has failed
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- A start job for unit network-suspend.service has finished with a failure.
-- The job identifier is 1544 and the job result is failed.
Feb 22 20:06:49 Capsparrow systemd[1]: sleep.target: Failed to set invocation ID for unit: File exists
Feb 22 20:06:49 Capsparrow systemd[1]: Failed to start Sleep.
-- Subject: A start job for unit sleep.target has failed
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- A start job for unit sleep.target has finished with a failure.
-- The job identifier is 1543 and the job result is failed.
Feb 22 20:06:49 Capsparrow systemd[1]: network-resume.service: Failed to set invocation ID for unit: Fi>
Feb 22 20:06:49 Capsparrow systemd[1]: Failed to start Network resume service.
-- Subject: A start job for unit network-resume.service has failed
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- A start job for unit network-resume.service has finished with a failure.
-- The job identifier is 1628 and the job result is failed.`
The text was updated successfully, but these errors were encountered: