Today I’ve migrated my data from my old zfs pool to a new bigger one, the rsync of 13.5TiB took roughly 18 hours. It’s slow spinning disks storage so that’s fine.
The second and third runs of the same rsync took like 5 seconds, blazing fast.
I’ve migrated petabytes from one GPFS file system to another. More than once, in fact. I’ve also migrated about 600TB of data from D3 tape format to 9940.
Do you mean you’re changing that file in /usr? Don’t do that, that is managed by the package manager and will get overwritten on updates. Awesomewm very likely has a way to run a command on startup, use that.
Don’t overwrite system files managed by pacman and it won’t break your setup.
Put your script in the corresponding place in /etc where it’ll be handled properly, or better yet, do it correctly and set it up directly in your xorg.conf config. Or just use localectl set-keymap dvorak which will do the same thing but also handle non-X11 use cases such as the virtual consoles and Wayland.
A bit of an extra tidbit of information, that’s why things like /usr/local exists: to keep things separate from the distro provided packages. A lot of things have directories in /etc for the sole purpose of isolating “what the distro provides” vs “what the user provides”. Often you can mask distro-provided settings by symlinking the same in /etc to /dev/null.
So it’s best to assume /usr is managed by your package manager and you shouldn’t touch it because it’ll be overwritten on next update. Or in the case of immutable distros, you can’t even write there yourself.
Plus when you do backups and restores, you can backup /etc, reinstall your distro, then restore your /etc and you should mostly end up back where you were.
I’ve had some suspend adventures too, but my experience is just on Intel laptops.
About a month ago, Debian Trixie had a regression that made my laptop wake up right after a suspend attempt. Afaict, it was not directly a kernel change, something in userland changed and triggered problems. This pm_async thing fixed it. Frankly, I don’t know why “async” power management is a thing anybody would want. Taking a whole extra millisecond to suspend in a more reliable way seems like a no-brainer.
echo 1 > /sys/power/pm_debug_messages # why would you ever want to not syslog it?? echo 0 > /sys/power/pm_async
Cat /sys/power/pm_wakeup_irq may tell you something about whomst is responsible for sleep failure. Anyways, suspend is the worst thing to diagnose good luck.
Thanks I tried the edited values but it does not seem to solve the issue, /sys/power/pm_wakeup_irq returned nothing when I checked. Idk if my system is broken or if it’s fedora using diff configs though
linux
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.