Testing the /usr merge #3691
Comments
|
Testing on a VM on unstable that was last updated 25-April was not successful
The process was not successful Disabled local repo. |
|
@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
|
|
Just tested usr-merge script on my machine. It works flawlessly |
|
Desktop Budgie Stable |
|
Well it seemed to failed for me. This is on Budgie stable. ls -l / systemd-analyze blame | grep usr-merge ls -l /var/solus/usr-merge/orphaned-files |
|
Successfully completed usr-merge on my KDE workstation (and symlinks look correct): |
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 ls -l /var/solus/usr-merge/orphaned-files |
|
Successfully on Plasma (repo: unstable) mkl@mkl:~ |
Here it is |
|
My bad, seems that is what it's supposed to do, from a quick glance at the script |
|
Shouldn't this be a |
@silkeh ^ I'm afraid that this error was carried over from my bash porting gist. 😬 |
|
@androidnisse: looks like you actually found two issues with one action, nice! Fixed version should be available on unstable momentarily. |
|
So add -f to line 281? And reboot? |
|
@aquilapl: No, I'm mainly wondering if the usr-merge service actually did anything on your machine. What's the output of:
|
|
Ok. |
|
@aquilapl and what's the output of the following commands?
|
|
|
Ah, you need to edit |
|
I don't know if I understood correctly, but I created the file |
|
@aquilapl that looks good! |
Budgie. And apparently passed (?). Edit: I have one of those 'suspiciously fast' times, too. |
|
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 systemd-analyze blame | grep usr-merge find /var/solus/usr-merge ls -l /bin /lib /lib32 /lib64 /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 Cheers, |
It's fine to stay on stable, but you should use |
|
The latest version of eopkg and the usr-merge script were included in the sync. This means that it should be safe to usr-merge on stable and use whatever method of updating you want. |
should we get rid of the file we created |
|
I would say it worked for me now.
|
|
@brent111 you can safely delete the file. @androidnisse thanks, that looks a lot better! Still some files that probably shouldn't have been orphaned. I've created a PR with updated patterns (#3828). You can remove |
|
I think it worked ok. |
|
I had some issues with the usr-merge. I turned on my PC, walked to the kitchen and back, and just saw the display turning off. I waited a while because it seemed to be working on something, but when it didn't react after a while I shut it off (and I didn't think about the usr-merge scenario). When I turned it on again I saw the start of the usr-merge script output for a split second before the display shut off again. I let it work for a while and finally the display turned on again and I was at my login screen. This is with an NVIDIA GPU and the proprietary drivers ( Output of the suggested commands (note that does will refer to the second boot though, since I switched it off after a while the first time): |
|
My system did the usr-merge upon reboot this morning. It was successful. I didn't see the screen shut off like Staudey did, this system also has an nVidia GPU |
|
Works on my machine EDIT: Actually, after scrolling through the comments here, ermo might call this "suspiciously fast". Anything I need to be concerned about? Lmk if I can provide any helpful info. |
Strange. This is not what is supposed to happen. Good to see it completed successfully in the end though.
This would be my guess.
Yeah, that's suspiciously fast. The output looks like the merge was completed successfully though. Maybe it happened in an earlier boot? |
I set up |
If you are on the unstable repository, it had a 100% chance this week before being lowered to 10% for sync. |
|
Ah, that would be it then. Sorry for making a fuss! |
Some people actually had their systems almost (or fully!) /usr-merged back in May (so prior to the current process). Looking at the time stamps in your fs listing, this appears to be the case for you? The current process is designed to bring over both everyone who ended up on a semi-completed /usr-merge system as well as those who held back updating while we mitigated the worst of the disaster back in May. Taken in concert with Harvey's comments, the end result is that, if you updated on unstable last week, you would have had your (by the looks of it) partly usr-merged system fully merged via the usr-merge script we are rolling out. And since it was partly merged, the script didn't have to do a lot of work to complete the merge, hence the "suspiciously short" run time. =) |
|
Worked fine on my MATE laptop. Only thing I'm wondering is whether the missing |
|
Added |
|
A report from a MATE VM that hadn't been updated in a while (yes, this time it's actually a VM) |
|
Looks like my laptop on stable went through this a week ago. Haven't noticed any problems. |
|
And now my workstation. Seems it was partially updated in May. |
|
Closing this issue now the usr-merge has been completed and the first merged ISOs have been released. Thanks for the testing and provided feedback! |
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:
For users on stable only the python3 version of eopkg (All package managers support the usr-merge.eopkg.bin) will work. Regulareopkgor Software Centre might break your system.Opt-in by editing
/etc/sysconfig/usr-mergewith the following value: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):Please report the following:
systemctl status usr-merge --lines=0systemd-analyze blame | grep usr-mergefind /var/solus/usr-mergels -l /bin /lib /lib32 /lib64 /sbinThe text was updated successfully, but these errors were encountered: