Garuda Rani - preview releases and testing

I can’t replicate this behavior. Just so we are talking about the same thing: it is the button right here you used, correct?

As of from what I’ve seen I’d say this issue has nothing to do with Rani.
All which this application does concerning handling service management is running plain systemd commands, there is no fancy custom logic involved whatsoever.

https://gitlab.com/garuda-linux/applications/rani/-/blob/main/src/app/systemd-services/systemd-services.component.ts#L122

You can even observe this in the full journalctl logs (I would’ve been very interested in those logs of your incident):

Apr 06 13:28:38 dragons-ryzen pkexec[356038]: nico: Executing command [USER=root] [TTY=unknown] [CWD=/home/nico/Documents/garuda/rani/src-tauri] [COMMAND=/usr/bin/systemctl disable --now power-profiles-daemon.service]
Apr 06 13:28:38 dragons-ryzen systemd[1]: Reload requested from client PID 356038 ('systemctl') (unit user@1000.service)...
Apr 06 13:28:38 dragons-ryzen systemd[1]: Reloading...
Apr 06 13:28:39 dragons-ryzen systemd[1]: Reloading finished in 472 ms.
Apr 06 13:28:39 dragons-ryzen systemd[1]: Stopping Power Profiles daemon...
Apr 06 13:28:39 dragons-ryzen systemd[1]: power-profiles-daemon.service: Deactivated successfully.
Apr 06 13:28:39 dragons-ryzen systemd[1]: Stopped Power Profiles daemon.

Could you possibly give this another try and provide the logs like that?

4 Likes

Using close to the exact words as the previous poster and somewhat overusing “those” “little” “signs” without “real” “reason” makes it hard to take “serious” without providing proper diagnostic “information” or instructions on how to reproduce (especially if the poster has already been suspended in the past), sorry. Maybe its just me though. Anyway, let’s get back to topic.

I’ve taken a look at the thread. Relevant information are:

I can confirm the UI hints about missing modules and headers weren’t fully accurate in some cases, as I’ve just found out. Rectified some of it regarding headers right now.

Hints towards this indeed being an issue with kernel version and nvidia-dkms package version used. There is nothing we can do here. The application simplifies attempting the reinstallation (as it: in runs the appropriate commands for you once applying the actions in the terminal), but it can’t magically fix NVIDIA’s long-known issues of keeping their drivers working for all kernel versions.

Well yes, unless there’s something else going on, this won’t magically work without NVIDIA fixing their stuff. To verify it is indeed the thing I hinted at earlier, we’d need the terminal output of Rani. As Duke pointed out, we can have application logs, and even better in this particular case: logs from the command executions.

As seen above, there is a button for copying the terminal output or uploading it straight to our PrivateBin instance and copying the link to the clipboard.

4 Likes

The way it works is that it it places a .desktop in ~/.config/autostart, and removes it.
I just verified that it indeed works this way. Does your folder contain such a file? I have a certain assumption, haha. org.garudalinux.rani.desktop or similar exists maybe?

4 Likes

Thanks Dr460nf1r3

I will check later im not home because sunny Weather here :smiling_face_with_sunglasses:

1 Like

Is it the same device this is being run on? I’ll later push a version with more trace logs. Weird behaviour!

3 Likes

No, reason it works now. We had a systemd update, maybe that’s why.
Or sometimes the problem is 60 cm in front of the screen or what ever. :joy:

3 Likes

Did you reboot in between? :sweat_smile: (have you tried turning it off and on again?)

4 Likes

Yes its the same Dektop PC yes that was me wondering lol :wink:

Youre are right @dr460nf1r3 ,

ive deleted those file but i was on normal rani because ive installed on new other ssd. I did installed afterwards the git version and it wrote those file again in so i deleted it again and now its working. Thanks for that hint again would not expect that comes back :wink:

After each upt or de +install or changing sys settings → reboot. (perhaps sometime it is not a must.. but i do this) :innocent:

It might be best to not have bottles in rani or the other garuda tools. I can only see it being dropped from the aur and other places in time. OBS might end up like that down the line as well but, they are being a bit better about it for now. Less they start getting more bug reports like bottles was flooded with.

2 Likes

You are thinking about bottles and that fedora fiasko? Isn’t bottles on AUR packaged more often and properly vs what was happening on fedora? :smiley:

Debian and anyone else that pkgs old. even the aur they don’t want bug reports from as they should go to the aur pkger but they wont. And i can’t blame them its to random and a burden on the team.

1 Like

Ahh… rani is always auto starting in new hyprland ISO .
I thought that the following option is for stopping it :

but it is not IG… not stopping from autostart …
is there any option to stop it from auto start ???

hi Ankur,

i had the same issue see this one Garuda Rani - preview releases and testing - #227 by dr460nf1r3 or scroll up check this folder ~/config/autostart

1 Like

There are repeated warnings not to perform updates or remove orphans with the parameter --noconfirm. Why is Rani doing this anyway?

This is not a criticism, I just want to understand why this is the case and if there is a difference between a user or Rani doing it.

Mainly because we don’t have a way of confirming the prompt as of today (meaning sending input back to the spawned process). We could probably implement this in future versions however.

4 Likes

Okay, I almost thought this was the problem.

A little background to my question…

I take care of a few computers for people with little to no IT knowledge. I switched most of them from other distros to Garuda, not least because of the existence of garuda-rani. In my opinion, Rani is a killer application for such users on Linux. Rani allows users with little knowledge and who are afraid of working with the terminal to maintain their system as much as possible themselves.

Up to now, I have preconfigured the most important things (e.g. emptying the pacman cache or updating mirrorlist) or implemented them via bash aliases. With Rani, most of this is unnecessary.

I’m torn about this. We all know how quickly --noconfirm can make a system unusable when removing orphaned packages. If they were to run pacman -Qtdq themselves or via an alias, thery would still call me when pacman sends its query. Then I can intervene before the baby is in the well. So far I have done this every 1-2 months via remote using rustdesk.
Rani was of course a game changer for me and those users.

Nevertheless, Rani is a amazing piece of software, especially for inexperienced Linux users, which is unparalleled among all the distros out there. Many thanks for that.

Keep up your great work. I´m looking forward to.

2 Likes

That’s some nice feedback! :slight_smile:

Definitely will be working on this more intensively in the future again, in case anyone was worried about development slowing down. I’m currently busy with my finals, after finishing those things will return to regular business :technologist:

5 Likes

I don’t know how the other users here see it, but I think it’s a milestone and to my knowledge no other distro has anything close to it. Not yet. Yes, for most of us it may be “useless” because we are used to using the terminal for administrative tasks. But for many switchers (and lazy typists :wink:), it’s a boon.

And hey, it’s open source, free. If development slows down - for whatever reason - that’s that and that’s that. There can be no demands. Unless you pay adequately for the time it takes.

I wish you all the best and every success in your final exams.

4 Likes