packages
packages copied to clipboard
getsolus
Testing the /usr merge
This issue tracks the testing phase of the /usr merge (#293). Read on if you are brave enough to potentially brick your system.
Testing the /usr merge
It is possible to opt-in to test the /usr merge. Before doing so, take note of the following:
- The requisite packages are available on stable and unstable, but it is recommended to use unstable for testing.
- ~~For users on stable only the python3 version of eopkg (
eopkg.bin) will work. Regulareopkgor Software Centre might break your system.~~ All package managers support the usr-merge. - Ensure you have proper backups. While we're fairly sure that nothing should break, this is not guaranteed at this point.
- While the /usr merge is an exciting step for Solus, it is also very boring. You should notice absolutely no differences in how your system works after performing it.
Opt-in by editing /etc/sysconfig/usr-merge with the following value:
USR_MERGE_CHANCE=256
Your system will be merged on the next reboot. To see if the process succeeded, you can check:
systemctl status usr-merge, which should includecode=exited, status=0/SUCCESS.ls -l /, which should include the following (with different timestamps):lrwxrwxrwx 1 root root 7 25 aug 14:52 bin -> usr/bin lrwxrwxrwx 1 root root 7 25 aug 14:52 lib -> usr/lib lrwxrwxrwx 1 root root 9 25 aug 14:52 lib32 -> usr/lib32 lrwxrwxrwx 1 root root 9 25 aug 14:52 lib64 -> usr/lib64 lrwxrwxrwx 1 root root 8 25 aug 14:52 sbin -> usr/sbin
Please report the following:
- The output of
systemctl status usr-merge --lines=0 - The output of
systemd-analyze blame | grep usr-merge - The output of
find /var/solus/usr-merge - The output of
ls -l /bin /lib /lib32 /lib64 /sbin
Testing on a VM on unstable that was last updated 25-April was not successful
- Opted-in to the /usr merge and rebooted
- Ran an update with eopkg.bin
The process was not successful
~ ❯❯❯ systemctl status usr-merge
Unit usr-merge.service could not be found.
~ ❯❯❯ ls -l / |rg "bin|lib"
drwxr-xr-x 2 root root 4096 Sep 3 20:53 bin
lrwxrwxrwx 1 root root 5 Sep 3 20:49 lib -> lib64
drwxr-xr-x 2 root root 4096 Sep 3 20:52 lib32
drwxr-xr-x 5 root root 4096 Sep 3 20:53 lib64
drwxr-xr-x 2 root root 4096 Sep 3 20:54 sbin
~ ❯❯❯ systemd-analyze blame | grep usr-merge
~ ❯❯❯
~ ❯❯❯ ls -l /var/solus/usr-merge/orphaned-files ✘ 1
ls: cannot access '/var/solus/usr-merge/orphaned-files': No such file or directory
Disabled local repo. Fixed broken packages, did
@TraceyC77 this is still blocked by #3670. Your system will merge when that has landed in unstable. I've updated the issue description to reflect this.
This can now be tested on unstable! (edit: and on stable if you feel particularly adventurous)
Test results on GNOME desktop
- Output of
systemd-analyze blame | grep usr-merge48.715s usr-merge.service - Output of
ls -l /var/solus/usr-merge/orphaned-filesls: cannot access '/var/solus/usr-merge/orphaned-files': No such file or directory
Just tested usr-merge script on my machine. It works flawlessly
$ systemd-analyze blame | grep usr-merge
1.423s usr-merge.service
$ ls -l /var/solus/usr-merge/orphaned-files
ls: cannot access '/var/solus/usr-merge/orphaned-files': No such file or directory
Desktop Budgie Stable
systemd-analyze blame | grep usr-merge
40ms usr-merge.service
ls -l /var/solus/usr-merge/orphaned-files
ls: cannot access '/var/solus/usr-merge/orphaned-files': No such file or directory
Well it seemed to failed for me. This is on Budgie stable.
× usr-merge.service - Perform the usr-merge
Loaded: loaded (/usr/lib/systemd/system/usr-merge.service; disabled; preset: enabled)
Drop-In: /usr/lib64/systemd/system/service.d
└─10-timeout-abort.conf
Active: failed (Result: exit-code) since Tue 2024-09-10 08:05:07 CEST; 1min 24s ago
Process: 656 ExecStart=/usr/lib64/usysconf/usr-merge.sh (code=exited, status=1/FAILURE)
Main PID: 656 (code=exited, status=1/FAILURE)
CPU: 117ms
sep 10 08:05:07 vesslan usr-merge.sh[656]: [/lib64/modules/6.10.6-300.current/modules.alias]: moving special file to /usr/lib64/modules/6.10.6-300.current/modules.alias
sep 10 08:05:07 vesslan usr-merge.sh[656]: [/lib64/modules/6.10.6-300.current/modules.alias]: creating compatibility symlink to /usr/lib64/modules/6.10.6-300.current/modules.alias
sep 10 08:05:07 vesslan usr-merge.sh[656]: [/lib64/modules/6.10.6-300.current/modules.alias.bin]: moving special file to /usr/lib64/modules/6.10.6-300.current/modules.alias.bin
sep 10 08:05:07 vesslan usr-merge.sh[656]: [/lib64/modules/6.10.6-300.current/modules.alias.bin]: creating compatibility symlink to /usr/lib64/modules/6.10.6-300.current/modules.alias.bin
sep 10 08:05:07 vesslan usr-merge.sh[656]: [/lib64/modules/6.10.6-300.current/modules.softdep]: creating compatibility symlink to /usr/lib64/modules/6.10.6-300.current/modules.softdep
sep 10 08:05:07 vesslan usr-merge.sh[744]: /usr/bin/sha256sum: /var/solus/usr-merge/orphaned-files/root-lib64-modules-6.10.6-300.current-modules.symbols.20d30db178728be7bfe956de655e9980a1e061c4df9a19d6f5a862030c5>
sep 10 08:05:07 vesslan usr-merge.sh[743]: /usr/lib64/usysconf/usr-merge.sh: line 88: file_checksum[0]: unbound variable
sep 10 08:05:07 vesslan systemd[1]: usr-merge.service: Main process exited, code=exited, status=1/FAILURE
sep 10 08:05:07 vesslan systemd[1]: usr-merge.service: Failed with result 'exit-code'.
sep 10 08:05:07 vesslan systemd[1]: Failed to start usr-merge.service - Perform the usr-merge.
ls -l /
total 12
lrwxrwxrwx 1 root root 7 14 maj 16.39 bin -> usr/bin
drwxr-xr-x 1 root root 8 1 jun 06.33 boot
drwxr-xr-x 21 root root 4340 10 sep 08.05 dev
drwxr-xr-x 1 root root 1548 7 sep 15.57 etc
drwxr-xr-x 1 root root 10 13 maj 19.35 home
lrwxrwxrwx 1 root root 5 14 maj 16.39 lib -> lib64
drwxr-xr-x 1 root root 26 7 sep 15.57 lib32
drwxr-xr-x 1 root root 134 7 sep 15.57 lib64
drwx------ 1 root root 0 8 jan 2024 lost+found
drwxr-xr-x 1 root root 0 13 maj 19.35 media
drwxr-xr-x 1 root root 0 14 feb 2024 mnt
drwxr-xr-x 1 root root 22 15 feb 2024 node_modules_20
dr-xr-xr-x 386 root root 0 10 sep 08.05 proc
drwxr-xr-x 1 root root 170 10 sep 08.07 root
drwxr-xr-x 33 root root 780 10 sep 08.05 run
lrwxrwxrwx 1 root root 8 14 maj 16.39 sbin -> usr/sbin
drwxr-xr-x 1 root root 12 13 jul 08.16 snap
drwxr-xr-x 1 root root 0 8 jan 2024 srv
dr-xr-xr-x 12 root root 0 10 sep 08.07 sys
drwxrwxrwt 26 root root 660 10 sep 08.10 tmp
drwxr-xr-x 1 root root 90 19 jul 2022 usr
drwxr-xr-x 1 root root 116 7 sep 15.56 var
systemd-analyze blame | grep usr-merge
198ms usr-merge.service
ls -l /var/solus/usr-merge/orphaned-files
total 0
Successfully completed usr-merge on my KDE workstation (and symlinks look correct):
ermo@solbox:~
$ sudo systemd-analyze blame | grep usr-merge
819ms usr-merge.service
ermo@solbox:~
$ ls -l /var/solus/usr-merge/orphaned-files
ls: cannot access '/var/solus/usr-merge/orphaned-files': No such file or directory
Well it seemed to failed for me. This is on Budgie stable.
× usr-merge.service - Perform the usr-merge Loaded: loaded (/usr/lib/systemd/system/usr-merge.service; disabled; preset: enabled) Drop-In: /usr/lib64/systemd/system/service.d └─10-timeout-abort.conf Active: failed (Result: exit-code) since Tue 2024-09-10 08:05:07 CEST; 1min 24s ago Process: 656 ExecStart=/usr/lib64/usysconf/usr-merge.sh (code=exited, status=1/FAILURE) Main PID: 656 (code=exited, status=1/FAILURE) CPU: 117ms sep 10 08:05:07 vesslan usr-merge.sh[656]: [/lib64/modules/6.10.6-300.current/modules.alias]: moving special file to /usr/lib64/modules/6.10.6-300.current/modules.alias sep 10 08:05:07 vesslan usr-merge.sh[656]: [/lib64/modules/6.10.6-300.current/modules.alias]: creating compatibility symlink to /usr/lib64/modules/6.10.6-300.current/modules.alias sep 10 08:05:07 vesslan usr-merge.sh[656]: [/lib64/modules/6.10.6-300.current/modules.alias.bin]: moving special file to /usr/lib64/modules/6.10.6-300.current/modules.alias.bin sep 10 08:05:07 vesslan usr-merge.sh[656]: [/lib64/modules/6.10.6-300.current/modules.alias.bin]: creating compatibility symlink to /usr/lib64/modules/6.10.6-300.current/modules.alias.bin sep 10 08:05:07 vesslan usr-merge.sh[656]: [/lib64/modules/6.10.6-300.current/modules.softdep]: creating compatibility symlink to /usr/lib64/modules/6.10.6-300.current/modules.softdep sep 10 08:05:07 vesslan usr-merge.sh[744]: /usr/bin/sha256sum: /var/solus/usr-merge/orphaned-files/root-lib64-modules-6.10.6-300.current-modules.symbols.20d30db178728be7bfe956de655e9980a1e061c4df9a19d6f5a862030c5> sep 10 08:05:07 vesslan usr-merge.sh[743]: /usr/lib64/usysconf/usr-merge.sh: line 88: file_checksum[0]: unbound variable sep 10 08:05:07 vesslan systemd[1]: usr-merge.service: Main process exited, code=exited, status=1/FAILURE sep 10 08:05:07 vesslan systemd[1]: usr-merge.service: Failed with result 'exit-code'. sep 10 08:05:07 vesslan systemd[1]: Failed to start usr-merge.service - Perform the usr-merge.
@androidnisse :
Any chance you could paste the entire line related to the sha256sum command that fails?
It appears to be truncated in the above output...
systemd-analyze blame | grep usr-merge 4ms usr-merge.service
ls -l /var/solus/usr-merge/orphaned-files ls: no se puede acceder a '/var/solus/usr-merge/orphaned-files': No existe el fichero o el directorio
Successfully on Plasma (repo: unstable)
mkl@mkl:~ $ sudo systemd-analyze blame | grep usr-merge 974ms usr-merge.service mkl@mkl:~ $ ls -l /var/solus/usr-merge/orphaned-files ls: cannot access '/var/solus/usr-merge/orphaned-files': No such file or directory
Well it seemed to failed for me. This is on Budgie stable.
× usr-merge.service - Perform the usr-merge Loaded: loaded (/usr/lib/systemd/system/usr-merge.service; disabled; preset: enabled) Drop-In: /usr/lib64/systemd/system/service.d └─10-timeout-abort.conf Active: failed (Result: exit-code) since Tue 2024-09-10 08:05:07 CEST; 1min 24s ago Process: 656 ExecStart=/usr/lib64/usysconf/usr-merge.sh (code=exited, status=1/FAILURE) Main PID: 656 (code=exited, status=1/FAILURE) CPU: 117ms sep 10 08:05:07 vesslan usr-merge.sh[656]: [/lib64/modules/6.10.6-300.current/modules.alias]: moving special file to /usr/lib64/modules/6.10.6-300.current/modules.alias sep 10 08:05:07 vesslan usr-merge.sh[656]: [/lib64/modules/6.10.6-300.current/modules.alias]: creating compatibility symlink to /usr/lib64/modules/6.10.6-300.current/modules.alias sep 10 08:05:07 vesslan usr-merge.sh[656]: [/lib64/modules/6.10.6-300.current/modules.alias.bin]: moving special file to /usr/lib64/modules/6.10.6-300.current/modules.alias.bin sep 10 08:05:07 vesslan usr-merge.sh[656]: [/lib64/modules/6.10.6-300.current/modules.alias.bin]: creating compatibility symlink to /usr/lib64/modules/6.10.6-300.current/modules.alias.bin sep 10 08:05:07 vesslan usr-merge.sh[656]: [/lib64/modules/6.10.6-300.current/modules.softdep]: creating compatibility symlink to /usr/lib64/modules/6.10.6-300.current/modules.softdep sep 10 08:05:07 vesslan usr-merge.sh[744]: /usr/bin/sha256sum: /var/solus/usr-merge/orphaned-files/root-lib64-modules-6.10.6-300.current-modules.symbols.20d30db178728be7bfe956de655e9980a1e061c4df9a19d6f5a862030c5> sep 10 08:05:07 vesslan usr-merge.sh[743]: /usr/lib64/usysconf/usr-merge.sh: line 88: file_checksum[0]: unbound variable sep 10 08:05:07 vesslan systemd[1]: usr-merge.service: Main process exited, code=exited, status=1/FAILURE sep 10 08:05:07 vesslan systemd[1]: usr-merge.service: Failed with result 'exit-code'. sep 10 08:05:07 vesslan systemd[1]: Failed to start usr-merge.service - Perform the usr-merge.@androidnisse :
Any chance you could paste the entire line related to the sha256sum command that fails?
It appears to be truncated in the above output...
Here it is sep 10 08:05:07 vesslan usr-merge.sh[744]: /usr/bin/sha256sum: /var/solus/usr-merge/orphaned-files/root-lib64-modules-6.10.6-300.current-modules.symbols.20d30db178728be7bfe956de655e9980a1e061c4df9a19d6f5a862030c5ef5d5: No such file or directory
~~It kinda seems like it just attached the sha256sum to the filename and then tried to sha256sum that~~'
My bad, seems that is what it's supposed to do, from a quick glance at the script
Shouldn't this be a if [[ -f "$new_file_name" ]]; then
https://github.com/getsolus/packages/blob/167335e80d85849094b0bdf38f0c678e28d48937/packages/u/usysconf-epoch/files/usr-merge.sh#L281
Shouldn't this be a
if [[ -f "$new_file_name" ]]; thenhttps://github.com/getsolus/packages/blob/167335e80d85849094b0bdf38f0c678e28d48937/packages/u/usysconf-epoch/files/usr-merge.sh#L281
@silkeh ^
I'm afraid that this error was carried over from my bash porting gist. :grimacing:
@androidnisse: looks like you actually found two issues with one action, nice! Fixed version should be available on unstable momentarily.
@aquilapl, @soos162: the process completed suspiciously fast on your machines. Can you check if the process succeeded using the commands described in the issue?
@aquilapl: No, I'm mainly wondering if the usr-merge service actually did anything on your machine. What's the output of:
sudo systemctl status usr-merge --no-pagerls -l /
Ok.
$ sudo systemctl status usr-merge --no-pager
[sudo] password for aquila:
● usr-merge.service - Perform the usr-merge
Loaded: loaded (/usr/lib/systemd/system/usr-merge.service; enabled; preset: enabled)
Drop-In: /usr/lib64/systemd/system/service.d
└─10-timeout-abort.conf
Active: active (exited) since Tue 2024-09-10 19:34:40 CEST; 42min ago
Process: 565 ExecStart=/usr/lib64/usysconf/usr-merge.sh (code=exited, status=0/SUCCESS)
Main PID: 565 (code=exited, status=0/SUCCESS)
CPU: 14ms
wrz 10 19:34:40 solus systemd[1]: Starting usr-merge.service - Perform the u…ge...
wrz 10 19:34:40 solus systemd[1]: Finished usr-merge.service - Perform the u…erge.
Hint: Some lines were ellipsized, use -l to show in full.
$ ls -l /
razem 84
drwxrwxrwx 4 root root 4096 09-09 02:57 arch
drwxr-xr-x 2 root root 4096 09-10 10:03 bin
drwxr-xr-x 2 root root 4096 04-29 13:48 boot
drwxr-xr-x 21 root root 4160 09-10 19:34 dev
drwxr-xr-x 56 root root 4096 09-10 17:57 etc
drwxr-xr-x 4 root root 4096 04-29 13:48 home
lrwxrwxrwx 1 root root 5 09-09 03:26 lib -> lib64
drwxr-xr-x 2 root root 4096 09-09 03:42 lib32
drwxr-xr-x 6 root root 4096 09-09 03:42 lib64
drwx------ 2 root root 16384 2024-01-08 lost+found
drwxr-xr-x 2 root root 4096 04-29 13:48 media
drwxr-xr-x 2 root root 4096 09-09 03:19 mnt
drwxr-xr-x 3 root root 4096 09-09 03:58 opt
dr-xr-xr-x 323 root root 0 09-10 19:34 proc
drwxr-xr-x 8 root root 4096 09-09 08:53 root
drwxr-xr-x 34 root root 800 09-10 19:59 run
drwxr-xr-x 2 root root 4096 09-09 03:32 sbin
drwxr-xr-x 2 root root 4096 09-09 04:17 snap
drwxr-xr-x 2 root root 4096 2024-01-08 sof-ipc4-tplg
drwxr-xr-x 2 root root 4096 2024-01-08 srv
dr-xr-xr-x 12 root root 0 09-10 19:34 sys
drwxrwxrwt 24 root root 600 09-10 20:18 tmp
drwxr-xr-x 12 root root 4096 09-09 04:10 usr
drwxr-xr-x 12 root root 4096 09-09 04:17 var
@aquilapl and what's the output of the following commands?
cat /etc/sysconfig/usr-mergefind /var/solus/
$ cat /etc/sysconfig/usr-merge
cat: /etc/sysconfig/usr-merge: Nie ma takiego pliku ani katalogu
$ find /var/solus/
/var/solus/
/var/solus/usr-merge
/var/solus/usr-merge/eopkg-ready
Ah, you need to edit /etc/sysconfig/usr-merge to opt in to the usr-merge. See the description of this issue for details on how to do that. However, I would recommend you wait until more people on unstable have found all the bugs and the fixed script is available in stable. I'll let you know when that's the case!
I don't know if I understood correctly, but I created the file /etc/sysconfig/usr-merge and added USR_MERGE_CHANCE=256
$ sudo systemctl status usr-merge --no-pager
[sudo] password for aquila:
● usr-merge.service - Perform the usr-merge
Loaded: loaded (/usr/lib/systemd/system/usr-merge.service; enabled; preset: enabled)
Drop-In: /usr/lib64/systemd/system/service.d
└─10-timeout-abort.conf
Active: active (exited) since Tue 2024-09-10 21:38:35 CEST; 47s ago
Process: 566 ExecStart=/usr/lib64/usysconf/usr-merge.sh (code=exited, status=0/SUCCESS)
Main PID: 566 (code=exited, status=0/SUCCESS)
Tasks: 2 (limit: 9155)
Memory: 126.1M
CPU: 1min 28.793s
CGroup: /system.slice/usr-merge.service
├─570 /usr/bin/bash /usr/lib64/usysconf/usr-merge.sh
└─573 sleep 530
wrz 10 21:38:35 solus usr-merge.sh[47100]: drwxr-xr-x 30 root root 680 09-10 21:37 run
wrz 10 21:38:35 solus usr-merge.sh[47100]: lrwxrwxrwx 1 root root 8 09-10 21:37 sbin -> usr/sbin
wrz 10 21:38:35 solus usr-merge.sh[47100]: drwxr-xr-x 2 root root 4096 09-09 04:17 snap
wrz 10 21:38:35 solus usr-merge.sh[47100]: drwxr-xr-x 2 root root 4096 2024-01-08 sof-ipc4-tplg
wrz 10 21:38:35 solus usr-merge.sh[47100]: drwxr-xr-x 2 root root 4096 2024-01-08 srv
wrz 10 21:38:35 solus usr-merge.sh[47100]: dr-xr-xr-x 12 root root 0 09-10 21:37 sys
wrz 10 21:38:35 solus usr-merge.sh[47100]: drwxrwxrwt 8 root root 160 09-10 21:37 tmp
wrz 10 21:38:35 solus usr-merge.sh[47100]: drwxr-xr-x 12 root root 4096 09-09 04:10 usr
wrz 10 21:38:35 solus usr-merge.sh[47100]: drwxr-xr-x 12 root root 4096 09-09 04:17 var
wrz 10 21:38:35 solus systemd[1]: Finished usr-merge.service - Perform the usr-merge.
~ $ ls -l /
razem 68
drwxrwxrwx 4 root root 4096 09-09 02:57 arch
lrwxrwxrwx 1 root root 7 09-10 21:37 bin -> usr/bin
drwxr-xr-x 2 root root 4096 04-29 13:48 boot
drwxr-xr-x 21 root root 4160 09-10 21:38 dev
drwxr-xr-x 56 root root 4096 09-10 17:57 etc
drwxr-xr-x 4 root root 4096 04-29 13:48 home
lrwxrwxrwx 1 root root 7 09-10 21:38 lib -> usr/lib
lrwxrwxrwx 1 root root 9 09-10 21:38 lib32 -> usr/lib32
lrwxrwxrwx 1 root root 9 09-10 21:38 lib64 -> usr/lib64
drwx------ 2 root root 16384 2024-01-08 lost+found
drwxr-xr-x 2 root root 4096 04-29 13:48 media
drwxr-xr-x 2 root root 4096 09-09 03:19 mnt
drwxr-xr-x 3 root root 4096 09-09 03:58 opt
dr-xr-xr-x 300 root root 0 09-10 21:37 proc
drwxr-xr-x 8 root root 4096 09-09 08:53 root
drwxr-xr-x 33 root root 780 09-10 21:38 run
lrwxrwxrwx 1 root root 8 09-10 21:37 sbin -> usr/sbin
drwxr-xr-x 2 root root 4096 09-09 04:17 snap
drwxr-xr-x 2 root root 4096 2024-01-08 sof-ipc4-tplg
drwxr-xr-x 2 root root 4096 2024-01-08 srv
dr-xr-xr-x 12 root root 0 09-10 21:38 sys
drwxrwxrwt 21 root root 500 09-10 21:39 tmp
drwxr-xr-x 12 root root 4096 09-09 04:10 usr
drwxr-xr-x 12 root root 4096 09-09 04:17 var
$ find /var/solus/
/var/solus/
/var/solus/usr-merge
/var/solus/usr-merge/eopkg-ready
/var/solus/usr-merge/merge-complete
$ systemd-analyze blame | grep usr-merge
4.660s usr-merge.service
~ $ ls -l /var/solus/usr-merge/orphaned-files
ls: cannot access '/var/solus/usr-merge/orphaned-files': No such file or directory
$ find /var/solus/
/var/solus/
/var/solus/usr-merge
/var/solus/usr-merge/merge-complete
/var/solus/usr-merge/eopkg-ready
Budgie. And apparently passed (?). Edit: I have one of those 'suspiciously fast' times, too.
If I did pass, do I/should I opt out and delete /etc/sysconfig/usr-merge?
@brent111
4.something seconds is not "suspiciously fast"; anything under ~100 ms is "suspiciously fast" in this context, inasmuch as it implies that something made the script abort.
For reference, on fast NVMe 4x4 storage and a decent-ish 5900X CPU, my system took around a full second to complete the /usr/ merge. On a different, older system w/ SATA-600 SSD, it took around 30s because I had some stray kernel versions lying around for some odd reason.
I suspect that most people with SSDs and decent CPUs will see times in the 1-10s range for a successful merge on "normal" installs, but time will tell I suppose.
@brent111
4.something seconds is not "suspiciously fast"; anything under ~100 ms is "suspiciously fast" in this context, inasmuch as it implies that something made the script abort.
For reference, on fast NVMe 4x4 storage and a decent-ish 5900X CPU, my system took around a full second to complete the /usr/ merge. On a different, older system w/ SATA-600 SSD, it took around 30s because I had some stray kernel versions lying around for some odd reason.
I suspect that most people with SSDs and decent CPUs will see times in the 1-10s range for a successful merge on "normal" installs, but time will tell I suppose.
thank you. all makes sense. appreciate the context.
systemctl status usr-merge --lines=0
● usr-merge.service - Perform the usr-merge
Loaded: loaded (/usr/lib/systemd/system/usr-merge.service; disabled; preset: enabled)
Drop-In: /usr/lib64/systemd/system/service.d
└─10-timeout-abort.conf
Active: active (exited) since Thu 2024-09-12 13:13:51 EEST; 1min 31s ago
Process: 750 ExecStart=/usr/lib64/usysconf/usr-merge.sh (code=exited, status=0/SUCCESS)
Main PID: 750 (code=exited, status=0/SUCCESS)
Tasks: 2 (limit: 37472)
Memory: 147.9M
CPU: 38.175s
CGroup: /system.slice/usr-merge.service
├─752 /usr/bin/bash /usr/lib64/usysconf/usr-merge.sh
└─754 sleep 530
systemd-analyze blame | grep usr-merge
37.679s usr-merge.service
find /var/solus/usr-merge
/var/solus/usr-merge
/var/solus/usr-merge/eopkg-ready
/var/solus/usr-merge/merge-complete
ls -l /bin /lib /lib32 /lib64 /sbin
lrwxrwxrwx 1 root root 7 May 14 07:36 /bin -> usr/bin
lrwxrwxrwx 1 root root 7 Sep 12 13:13 /lib -> usr/lib
lrwxrwxrwx 1 root root 9 Sep 12 13:13 /lib32 -> usr/lib32
lrwxrwxrwx 1 root root 9 Sep 12 13:13 /lib64 -> usr/lib64
lrwxrwxrwx 1 root root 8 May 14 07:36 /sbin -> usr/sbin
repo: shanon (aka stable)
The system seems to be operational after the merge. I got lost and confused regarding if I have to switch to unstable now or it's fine to stay on stable ?
Cheers, PY
The system seems to be operational after the merge. I got lost and confused regarding if I have to switch to unstable now or it's fine to stay on stable ?
It's fine to stay on stable, but you should use eopkg.bin for updating if you do.