New ISO vs Updated: improvents missed

I have been using garuda for at least 344 days, as I would have installed before I joined this forum. So glad that I did! I know the inxi install date listed below is wrong.... Just look at my history on this forum, you will see i have had a few hickups and learning curves along the way.

When I download a newer garuda kde iso, there are a lot more changes, than my recently updated system .Using the command garuda-update, usually once every day or two. including different programs (some replaced, others are new) and looks to the desktop environment.

What is the easiest way to keep all of this updated? There are a lot of improvements that I really like!

System:
Kernel: 5.16.11-1-cacule x86_64 bits: 64 compiler: gcc v: 11.2.0
parameters: BOOT_IMAGE=/@/boot/vmlinuz-linux-cacule
root=UUID=00b33177-335b-466d-8a5b-e5bad5669f19 rw [email protected]
quiet splash rd.udev.log_priority=3 vt.global_cursor_default=0
systemd.unified_cgroup_hierarchy=1 loglevel=3
Desktop: KDE Plasma 5.24.2 tk: Qt 5.15.2 info: latte-dock wm: kwin_x11
vt: 2 dm: SDDM Distro: Garuda Linux base: Arch Linux
Machine:
Type: Laptop System: Micro-Star product: GL65 9SE v: REV:1.0
serial: <superuser required> Chassis: type: 10 serial: <superuser required>
Mobo: Micro-Star model: MS-16U5 v: REV:1.0 serial: <superuser required>
UEFI: American Megatrends v: E16U5IMS.102 date: 03/17/2020
Battery:
ID-1: BAT1 charge: 23.5 Wh (60.1%) condition: 39.1/51.6 Wh (75.9%)
volts: 11.1 min: 10.9 model: MSI BIF0_9 type: Li-ion serial: N/A
status: N/A
CPU:
Info: model: Intel Core i7-9750H bits: 64 type: MT MCP arch: Coffee Lake
family: 6 model-id: 0x9E (158) stepping: 0xA (10) microcode: 0xEC
Topology: cpus: 1x cores: 6 tpc: 2 threads: 12 smt: enabled cache:
L1: 384 KiB desc: d-6x32 KiB; i-6x32 KiB L2: 1.5 MiB desc: 6x256 KiB
L3: 12 MiB desc: 1x12 MiB
Speed (MHz): avg: 2396 high: 2600 min/max: 800/4500 scaling:
driver: intel_pstate governor: performance cores: 1: 1873 2: 2600 3: 2600
4: 2600 5: 2585 6: 2598 7: 2084 8: 2600 9: 2600 10: 2600 11: 1421
12: 2600 bogomips: 62469
Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
Vulnerabilities:
Type: itlb_multihit status: KVM: VMX disabled
Type: l1tf
mitigation: PTE Inversion; VMX: conditional cache flushes, SMT vulnerable
Type: mds mitigation: Clear CPU buffers; SMT vulnerable
Type: meltdown mitigation: PTI
Type: spec_store_bypass
mitigation: Speculative Store Bypass disabled via prctl
Type: spectre_v1
mitigation: usercopy/swapgs barriers and __user pointer sanitization
Type: spectre_v2 mitigation: Full generic retpoline, IBPB: conditional,
IBRS_FW, STIBP: conditional, RSB filling
Type: srbds mitigation: Microcode
Type: tsx_async_abort status: Not affected
Graphics:
Device-1: Intel CoffeeLake-H GT2 [UHD Graphics 630] vendor: Micro-Star MSI
driver: i915 v: kernel ports: active: eDP-1 empty: none bus-ID: 00:02.0
chip-ID: 8086:3e9b class-ID: 0300
Device-2: NVIDIA TU106M [GeForce RTX 2060 Mobile] vendor: Micro-Star MSI
driver: nvidia v: 510.54 alternate: nouveau,nvidia_drm pcie: gen: 1
speed: 2.5 GT/s lanes: 16 link-max: gen: 3 speed: 8 GT/s bus-ID: 01:00.0
chip-ID: 10de:1f11 class-ID: 0300
Device-3: Chicony HD Webcam type: USB driver: uvcvideo bus-ID: 1-13:5
chip-ID: 04f2:b695 class-ID: 0e02
Display: x11 server: X.Org v: 1.21.1.3 compositor: kwin_x11 driver: X:
loaded: intel,nvidia unloaded: modesetting,nouveau alternate: fbdev,nv,vesa
gpu: i915 display-ID: :0 screens: 1
Screen-1: 0 s-res: 1920x1080 s-dpi: 96 s-size: 508x285mm (20.0x11.2")
s-diag: 582mm (22.9")
Monitor-1: eDP1 mapped: eDP-1 model: AU Optronics built: 2019
res: 1920x1080 hz: 120 dpi: 143 gamma: 1.2 size: 340x190mm (13.4x7.5")
diag: 394mm (15.5") ratio: 16:9 modes: 1920x1080
OpenGL: renderer: Mesa Intel UHD Graphics 630 (CFL GT2)
v: 4.6 Mesa 21.3.7 direct render: Yes
Audio:
Device-1: Intel Cannon Lake PCH cAVS vendor: Micro-Star MSI
driver: snd_hda_intel v: kernel
alternate: snd_soc_skl,snd_sof_pci_intel_cnl bus-ID: 00:1f.3
chip-ID: 8086:a348 class-ID: 0403
Sound Server-1: ALSA v: k5.16.11-1-cacule running: yes
Sound Server-2: PulseAudio v: 15.0 running: no
Sound Server-3: PipeWire v: 0.3.47 running: yes
Network:
Device-1: Intel Cannon Lake PCH CNVi WiFi driver: iwlwifi v: kernel
bus-ID: 00:14.3 chip-ID: 8086:a370 class-ID: 0280
IF: wlo1 state: up mac: <filter>
Device-2: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet
vendor: Micro-Star MSI driver: r8169 v: kernel pcie: gen: 1 speed: 2.5 GT/s
lanes: 1 port: 3000 bus-ID: 03:00.0 chip-ID: 10ec:8168 class-ID: 0200
IF: enp3s0 state: down mac: <filter>
IF-ID-1: virbr0 state: down mac: <filter>
Bluetooth:
Device-1: Intel Bluetooth 9460/9560 Jefferson Peak (JfP) type: USB
driver: btusb v: 0.8 bus-ID: 1-14:6 chip-ID: 8087:0aaa class-ID: e001
Report: bt-adapter ID: hci0 rfk-id: 1 state: down
bt-service: enabled,running rfk-block: hardware: no software: no
address: <filter>
Drives:
Local Storage: total: 1.38 TiB used: 547.4 GiB (38.9%)
SMART Message: Unable to run smartctl. Root privileges required.
ID-1: /dev/nvme0n1 maj-min: 259:0 vendor: Western Digital
model: PC SN520 SDAPNUW-512G-1032 size: 476.94 GiB block-size:
physical: 512 B logical: 512 B speed: 15.8 Gb/s lanes: 2 type: SSD
serial: <filter> rev: 20140000 temp: 49.9 C scheme: GPT
ID-2: /dev/sda maj-min: 8:0 vendor: Western Digital
model: WD10JPVX-60JC3T0 size: 931.51 GiB block-size: physical: 4096 B
logical: 512 B speed: 6.0 Gb/s type: HDD rpm: 5400 serial: <filter>
rev: 1A01 scheme: GPT
Partition:
ID-1: / raw-size: 146.48 GiB size: 146.48 GiB (100.00%)
used: 53.18 GiB (36.3%) fs: btrfs dev: /dev/nvme0n1p2 maj-min: 259:2
ID-2: /boot/efi raw-size: 256 MiB size: 252 MiB (98.46%)
used: 557 KiB (0.2%) fs: vfat dev: /dev/nvme0n1p1 maj-min: 259:1
ID-3: /home raw-size: 146.48 GiB size: 146.48 GiB (100.00%)
used: 53.18 GiB (36.3%) fs: btrfs dev: /dev/nvme0n1p2 maj-min: 259:2
ID-4: /var/log raw-size: 146.48 GiB size: 146.48 GiB (100.00%)
used: 53.18 GiB (36.3%) fs: btrfs dev: /dev/nvme0n1p2 maj-min: 259:2
ID-5: /var/tmp raw-size: 146.48 GiB size: 146.48 GiB (100.00%)
used: 53.18 GiB (36.3%) fs: btrfs dev: /dev/nvme0n1p2 maj-min: 259:2
Swap:
Kernel: swappiness: 133 (default 60) cache-pressure: 100 (default)
ID-1: swap-1 type: zram size: 15.47 GiB used: 0 KiB (0.0%) priority: 100
dev: /dev/zram0
Sensors:
System Temperatures: cpu: 46.0 C pch: 58.0 C mobo: N/A
Fan Speeds (RPM): N/A
Info:
Processes: 348 Uptime: 11m wakeups: 1 Memory: 15.47 GiB
used: 2.81 GiB (18.2%) Init: systemd v: 250 tool: systemctl Compilers:
gcc: 11.2.0 clang: 13.0.1 Packages: pacman: 1813 lib: 550 Shell: fish
v: 3.3.1 running-in: konsole inxi: 3.3.13
Garuda (2.5.5-1):
System install date:     2022-01-25
Last full system update: 2022-03-10
Is partially upgraded:   No
Relevant software:       NetworkManager
Windows dual boot:       No/Undetected
Snapshots:               Snapper
Failed units:
2 Likes

garuda-update only fetches newer versions of packages you already have.

It does not include new packages that the newer Garuda ISO comes with, since Garuda is an ever evolving rolling release, major changes happen like the Timeshift to Snapper migration. Under such migration, old installation of Garuda are not forced to migrate, and users are given the option to make the jump manually.

I myself has not migrated to Snapper and running a Frankenstein Garuda install on ext4 partition.

4 Likes

A recent example of this I couldn't help but notice is I have this beautiful updated Swaylock screen SGS made on a fresh install I put on a new laptop. :heart_eyes:

There are several factors that contribute to this "feature drift". One is that after the initial installation, .config/ and other directories below the /home folder are not typically modified during updates. The home folder contains the user's personal files after all, so this is probably for the best--but as you noticed this also means that updated config customization does not "trickle down" from new ISOs in any appreciable way (unless you restore from the updated skeleton).

Package selection changes in the ISO would similarly be way too intrusive to try to push into existing installs. It's fine for a maintainer to say, "Pamac sucks lately, let's take it out of the ISO and use Octopi," or whatever--but if you start barging in on someone's standing installation and ripping out software that they might be using to put in something else that you think is better, people are bound to become unhappy with some of those choices. Once the user is has their installation up and running, it's probably best they make those kinds of decisions for themselves.

You can read through the changelog that the Garuda team posts on the Gitlab page if you are interested in what is changing from ISO to ISO. It comes up easily in a web search, or find it here. You can make package changes on your own if you spot something that appeal to you, and updated config files sometimes get conspicuously posted so you can grab those as well.

Really the only way to ensure you are enjoying all the niceties of the freshest ISOs is to develop a backup routine for files and configs that will allow you to periodically reinstall without too much disruption, and then once or a few times a year go ahead and refresh.

13 Likes

I am not speaking from a position of great knowledge(!) - but doesn't Arcolinux have a 'system' in place for 'keeping rolling' with the changes/updates? I know it includes skel-based updating, as well as other tweaks...

Apart from that, it should be possible to create a pkglist file based on the diff between previous and current installs - along with pacnew-style variants of config files so that the user could meld them if desired...

Personally, I could do any part of this procedure if motivated enough - but is it worth someone putting dev time into realizing it as a procedure? Don't know - just something to think about.... :grin:

5 Likes

Are you saying that there is some configuration drift between the rolling-updates and the new ISO's?

I don't think it is a question of "how", I think it is more a question of "should". Garuda does push some changes to existing installs but not all. The danger with pushing all of them is:

I pretty much agree with statement 100%.

4 Likes

So do I (agree with statement) - but what I was thinking of is an optional script being available to those who might want it. Pushing changes of configuration would be indefensible! Just speculating on how hard it would be to tie a script to a button somewhere for 'optional changes'.

The only change (from recent ISOs) that I would consider for my setup would be from Timeshift to Snapper - but I've never needed either so that has seemingly become permanently embedded on a 'future todo' list...

Of course my thinking might be unduly influenced by enjoyment of creating such things myself! :grin:

3 Likes

My experience has been that updates have not over-written local configurations. Why would this be different? Any update should be written so that it handles local configurations without any data loss.

What am I missing here?

IF all the new features were included in an update scenario, THEN overwrites would happen - not good. Unfortunately, this means at the moment that the new features need to be discovered and implemented on an individual basis - and require some research and knowledge that isn't universal across the user base.

I just thought it might be nice if easier access to the changes was available, and possibly selectable....

2 Likes

Wouldn't you think the simplest solution is just to install fresh from a fresh ISO?

2 Likes

It wouldn't be bad for me, as I keep ALL my data on a separate drive, but even then tracking and introducing all the config changes could be a pain. It's not like I use a 'mainline' version of things either - does Garuda still have an XFCE build - haven't looked in a while. There are a bunch of mods for 4K screen use too, both GTK and QT to worry about - so it woujld be nice to see another way to do it (selectable options would be nice too). Can you say LAZY? I thought you could! :grin:

Doesn't that defeat the purpose of a rolling-upgrade?

I try to keep all changes to my home directory, but some changes do make it to /etc. I could easily expand my .dot file mgmt process to include those files, but at this point, I don't know what the differences are.

My ideal OS is not one where I need to install the whole OS from scratch just to get a new feature or some improvements in the desktop environment. I like using garuda (arch) because when I do update, everything gets updated (ie: graphics drivers, kernels, libreoffice, etc...) in one command and a reboot. If things don't work I can rollback, and all is good until I can find a fix.

This, Is something that is interesting.

  • Some sort of a check that would see what is currently installed against whatever the flavor of the month.
  • Some sort of an explanation of why/what the program is used for.
  • Ask if you would like to install/uninstall whatever is needed.
1 Like

You can't have it all, regrettably.

Short answer:
This cannot be done in such a distro.

Little longer but not long enough answer:
Garuda is a distro based on another distro (Archlinux) with a strongly opinionated list of additions and configuration and some custom utilities.
Since Garuda is primarily a hobby project, the team alters their opinionated view of the added value and sometimes, the changes are not easily converted on older systems.

If the team supposedly decided to create such a mechanism, it would raise the professional level of the whole Gauda Orgnization, that would make it such High that would make them think of selling their work and effort to accomplish this task. This might eventually make Garuda a service for sale, and not many would want that, either Garuda Team members, or user base.

That's just my personal opinion.


Note:
I have changed the topic's category, since it's just a discussion and not a request for help/support.

6 Likes

Good category change. I guess I was a bit blue-sky there - I know the team isn't big enough (or paid enough!) to try that... it is just that I haven't seen the changes between any 2 ISOs be enough to be out-of-reach - but I'm not in on them soon enough to try to set up a change mechanism for the interested user. Perhaps someday a changefile could be created, along with a tool to apply them (bash with yad selection of which to apply?) but I don't know how tough that would be in practice, so I'll shut up now :grin: Dreams are good, but unrealistic ones remain....unrealistic.

1 Like

Thanks for sharing your insight.

1 Like

If you consider the purpose of using a rolling-release distribution to be never having to reinstall your OS again, then yes. That would defeat the purpose.

Bear in mind, many point release distributions support in-place upgrades from one release to the next. So you can just as well install Linux Mint on your computer and never reinstall again--no need to choose a rolling-release.

I think most people who use a rolling-release distribution do not perceive the primary benefit to be not having to reinstall on a point-release, but rather the continuous availability of the newest software, upgrades, and improvements.

I think this is the rub right here. Once people get their installation up, they tend to customize it to suit their use case and preferences. Software gets added and removed, config files get changed...as you have pointed out, it can be difficult for the user themselves to keep track of. Never mind the distro trying to modify the OS without disturbing all of the special customization the user spent all that time getting just right.

Once a distro starts barging in and changing stuff to be the latest and greatest with no regard for how the user specifically wants it...well then it's just macOS, isn't it? :joy:

Yes, and perhaps someone from Garuda will stop by your house and see if you would like a foot rub or a glass of lemonade as well. :rofl:

I'm kidding of course--that does sound like a really cool idea. But it also seems like something that might be very difficult to properly execute, and would likely require a lot of development time to maintain. And then, every time the program expresses a bug or crashes somebody's rig, everyone will get their pitchforks out and come after the Garuda team!

5 Likes

While I do understand what you are saying, isn't that the reason for .dotfiles? So, that they are kept in the user's home directory and out of the way of upgrades?

Might have completely misunderstood the topic, but doesn't the following command get and install packages from the latest ISO to your current system without the need of a reinstall or anything? I'd post where this came from but I don't remember the source unfortunately.

curl https://iso.builds.garudalinux.org/iso/garuda/dr460nized/xxxxxx/garuda-dr460nized-linux-zen-xxxxxx.pkgs.txt | grep -Eo '^[^ ]+' | paru -Syu --needed -

I've run the above before without any real issues and all I do after is uninstall zen and firedragon and I'm all back to where I was with some extra updated packages.

5 Likes

Thanks for sharing this. I'll give it a try. What could go wrong? If anything does, Garuda is awesome enough that I can so easily roll-back the changes. What a beautiful thing !!!