Installed Solus from the 4.3 ISO and updated from the CDN today.
I updated from the terminal, and halfway through the update the session ended.
I used eopkg rdb
and ran the update from TTY, and everything worked out.
It's good to be back.
Want A CDN-Powered Repo? Check These Instructions!
Did an update, following the recipe above. 63 packages, roughly same speed as before. No problems with the update, but will boot tomorrow. Only a short time left till shutdown/sundown.
- Edited
ReillyBrogan
If I understand the CDN route correctly, then how does Solus ensure that the packages served by the CDN are exactly the same as those served by the main server? (the one at RIT at the moment).
I'm thinking along the security and integrity perspectives of these updated packages.
To remove all doubt, should users update directly from Solus servers?
snowee almost everything nowadays is served via some kind of CDN. I do not think caching the content on the edge (CDN) is something that could be easily poisoned by malicious party.
Correct me if I'm wrong, but Solus moved everything away from RIT premises and now using the SerpentOS or a copy of it.
snowee then how does Solus ensure that the packages served by the CDN are exactly the same as those served by the main server
The CDN pulls data from our package server directly in the event of cache misses and merely stores them on their edge servers / network closer geographically to the user. We can perform cache invalidation at any point in time. Alongside this, eopkg will validate the shasum from the index. We do not have any security concerns related to the CDN.
snowee To remove all doubt, should users update directly from Solus servers?
Users should use the CDN and once RIT is syncing from us, I'll be pushing a modification to eopkg that will convert existing systems using RIT to the CDN automatically. Intentionally using the non-CDN will mean that not only are you hammering our server more for no reason (when that bandwidth could otherwise be soaked up by the CDN service, to a magnitude of a 97% reduction from the metrics I've seen), but you're doing it at the cost of a worse download experience.
presianbg now using the SerpentOS or a copy of it.
This is not correct. While our infrastructure is no longer hosted by RIT, what we are using is still the previous build infra tech (with various fixes) such as our build management scripts, ferryd, and solbuild. They haven't been replaced with summit and vessel from Serpent OS yet and we're likely quite far out from that as they are coupled closely to moss (Serpent OS package manager).
- Edited
Recovered a Solus Plasma backup I made more than a year ago with Clonezilla, with an AMD RX 570.
Now I have a GeForce 3060 Ti.
Booted up perfectly (with nouveau), changed repo, upgraded:
Rebooted, launched DoFlicky and I am on sail again!
Glad to see you back, @JoshStrobl! (and the rest of the team, ofc)
Changed to CDN, made the update, went through everything perfectly, except:
> sudo eopkg check
...
Checking integrity of sudo Broken
Checking integrity of python3 Broken
...
Doing:
> sudo eopkg install --reinstall sudo python3
That fixed python3, but not sudo. sudo itself seems to work, though.
Thank you, BTW, for bringing everything back to life. I'm happy again.
- Edited
sudo
is not really "broken" https://discuss.getsol.us/d/9190-corrupted-file-usrlibtmpfilesdsudoconf-in-eopkg-check so you can ignore that.
- Edited
The wonderful folks at RIT are now syncing from our repo! Users that haven't switched to the CDN-based one yet will now be getting updates (4hr delay from main repo server) and this week we will be rolling out an update to swap users to CDN (+ lots of other goodies).
Solus is one of the very first distros I ever tried since switching to Linux a year ago. I've been watching the drama surrounding the OS with trepidation the past year and a half. I honestly thought it was done for. Extremely pleased to see Josh and his team step in. I also wish Beatrice the very best.
PS -- Did a fresh install of Budgie today and updated from the new CDN repo. 1.47 GB of data very quickly downloaded and installed. Flawless. Best of luck, Solus Team!
pulled the trigger and dusted off a fine wd caviar...and nuked everything on it.....4.3 iso plus 532 updates...followed the commands above...I wouldn't call this lightning fast by any stretch but about the same speed after you fixed it the last time and what I expected. about 12-14 minutes basically. 532 is a lot of packages. Not one single complaint. Back in the saddle.
I'm going to do things different this time and try to build more stuff myself (if not in repo). New adventure ahead. I am so glad this project is rebirthed,
brent
I couldn't wait either.
I installed it Sunday and have been fiddling around with stuff for a couple of days. It's good enough to have me switch back to it for my daily driver. Same minor issues as before - no fwupd, the Mullvad app won't do split tunneling and is out of date, fstrim doesn't work on LUKS encrypted disks by default (yet it is there pretending LOL). I'll let the team do the big stuff before I start raising issues. I might try to build the Mullvad app. I managed that before it was available. I'm just getting lazy. I used to build all sorts of stuff.
We have just done another sync of updates to our CDN, which RIT will sync in a few hours. This includes an automatic switch for RIT users to the CDN (no user intervention needed), Budgie Desktop updates, WINE, pipewire, a bunch of apps, and a lot more!
the current make me smile ... i remember when eopkg would hang and crash on fetching a -18mib archive and I had to relaunch the cmd.
now it pumps 253mib in less than coffee cup cooking time.
worth the waiting ...
unclemez today I timed it: 61 packages 11:23:41 in the morning to 11:27:03. If it didn't get hung up on the Papirus package and the mimetype sync I think it would've been done in 2:45 minutes. Indeed the speed is phenomenal...I do remember those old hangs...and command reruns...but they do not make me sentimental
The update was successful, great times ahead
- Edited
zmaint Sudo is broken if you changed the contents of sudoers; for example sudo visudo
and added some lines. In that case you have to set the correct hash of the sudoers file in /var/lib/eopkg/package/sudo-1.9.xxxxx/files.xml
.
P.S. To check integrity do a sudo eopkg check sudo
sHAKaJaada I've never changed it on any of my machines. I think I read it's a known issue and it should be fixed on the next update.