Package List Visibility Issue

tedy02 commented 1 month ago

Confirmations

[X] I searched for similar bug reports in https://github.com/Botspot/pi-apps/issues and found none were relevant.
[X] I tried updating Pi-Apps and the issue is still not fixed. How to update Pi-Apps?
[X] IMPORTANT: I promise to respond to comments on this issue and write a good bug report https://www.softwaretestinghelp.com/how-to-write-good-bug-report/

What happened?

Upon launching, the application list is completely empty.

Description

Troubleshooting Steps Taken: 1) Uninstalled and Reinstalled: The issue persists after re-installation. 2) Deleted pi-apps Folder: Deleting pi-apps in the home directory did not resolve the problem. 3) Multi-Install Option: Applications are visible only when using the multi-install option. 4) Changed Theme: Modifying the theme did not affect the issue.

Additional Observations:

The issue started after the system worked correctly a few times.
The underlying cause is unknown.

Impact:

Severely hinders usability as applications cannot be accessed through the standard launch mechanism.

What are your system specs (run the following command in your terminal)?

OS: Debian GNU/Linux 12 (bookworm)
OS architecture: 64-bit
Last updated Pi-Apps on: 09/08/24
date: option requires an argument -- 'd'
BusyBox v1.35.0 (Debian 1:1.35.0-4+b3) multi-call binary.
Latest Pi-Apps version: 
Kernel: aarch64 6.6.47-v8+
Device model: Raspberry Pi 4 Model B Rev 1.5
SOC identifier: bcm2711
Cpu name: Cortex-A72
Ram size: 7.81 GB
Raspberry Pi OS image version: 2024-07-04
Language: en_US.UTF-8

(Recommended) Error log? Terminal output? Debug messages?

Downloading Pi-Apps...
Creating menu button...
Creating Settings menu button...
Creating autostarted updater...
Preloading app list...
Installation complete. Pi-Apps can be launched from the start menu or by running the command 'pi-apps'.

github-actions[bot] commented 1 month ago

Hello there 👋 Thanks for submitting your first issue to the Pi-Apps project! We'll try to get back to you as soon as possible. In the meantime, we encourage you join our Discord server, where you can ask any questions you might have.

Please respond as soon as possible if a Pi-Apps maintainer requests more information from you. Stale issues will be closed after a lengthy period of time with no response.

Botspot commented 1 month ago

The output on get_device_info is highly unusual.

OS: Debian GNU/Linux 12 (bookworm)
OS architecture: 64-bit
Last updated Pi-Apps on: 09/08/24
date: option requires an argument -- 'd'
BusyBox v1.35.0 (Debian 1:1.35.0-4+b3) multi-call binary.
Latest Pi-Apps version: 
Kernel: aarch64 6.6.47-v8+
Device model: Raspberry Pi 4 Model B Rev 1.5
SOC identifier: bcm2711
Cpu name: Cortex-A72
Ram size: 7.81 GB
Raspberry Pi OS image version: 2024-07-04
Language: en_US.UTF-8

I've noticed a few things strange with it:

The date for latest online version is blank.
This would explain the error from the date command.
What is the BusyBox output doing there? I'm not sure what that means.

What exactly should another person do to make an operating system similar to yours? Is it a clean install of Pi OS? Is it more like Armbian? What changes have you made?

Also, would you be comfortable with setting up a remote desktop software so I could interact with your system directly and get to the bottom of this issue? Some people consider that risky and are unwilling to do so.

Botspot commented 1 month ago

@tedy02, you are not the first to report this issue, but you will be one of many who has reported it and then never replied back to us. That is, of course, unless of course you do reply back. :)

I want to understand what is happening here so it can be fixed once and for all. Please respond.

tedy02 commented 1 month ago

I have a bunch of stuff installed on the operating system but it's only been a month and a half or so. I would love to get this fixed just tell me what I can do to help

tedy02 commented 1 month ago

I just noticed the label has been changed on this issue to "User Error." I want to emphasize that I haven't made any changes to the Raspberry Pi OS. I'm not even familiar with the term "Armbian," so I definitely didn't modify anything related to that. Could you please provide more specific information about what I am doing that would cause this user error? We can discuss remote access.

Botspot commented 1 month ago

I just noticed the label has been changed on this issue to "User Error." I want to emphasize that I haven't made any changes to the Raspberry Pi OS. I'm not even familiar with the term "Armbian," so I definitely didn't modify anything related to that. Could you please provide more specific information about what I am doing that would cause this user error?

Sorry about that. @theofficialgman added that label, as he tries to keep everything categorized and tends to assume niche issues are the user's fault. Whether that will be proven true or false in this case, time will tell. But I do understand your confusion for why an issue that we don't understand is already being labelled as your fault. I apologize on gman's behalf.

We can discuss remote access.

I will assume that your system is using the Wayland display manager. If you changed this, please let me know and ignore the instructions below. Please use these commands to set up rustdesk:

wget https://github.com/rustdesk/rustdesk/releases/download/1.3.0/rustdesk-1.3.0-aarch64.deb -O /tmp/rustdesk.deb
sudo apt install -y /tmp/rustdesk.deb xdg-desktop-portal-wlr

Then edit /usr/lib/systemd/user/xdg-desktop-portal-wlr.service as root and add this line before the ExecStart= line:

Environment=XDG_CURRENT_DESKTOP=Wayfire

Now run RustDesk and comment here the ID number. Then I will try to connect and you will need to approve the connection request. From there we can hopefully solve this issue.

theofficialgman commented 1 month ago

I just noticed the label has been changed on this issue to "User Error." I want to emphasize that I haven't made any changes to the Raspberry Pi OS. I'm not even familiar with the term "Armbian," so I definitely didn't modify anything related to that. Could you please provide more specific information about what I am doing that would cause this user error?

Sorry about that. @theofficialgman added that label, as he tries to keep everything categorized and tends to assume niche issues are the user's fault. Whether that will be proven true or false in this case, time will tell. But I do understand your confusion for why an issue that we don't understand is already being labelled as your fault. I apologize on gman's behalf.

Sorry I generally mark problems that users observe with pi-apps as a "bug" only when its something that can be fixed due to an issue in pi-apps itself (ie: it is an actual coding problem). Issues that can only be resolved with an upstream application or package are marked as "upstream bug". Issues that only occur on unsupported systems (eg: chromeOS crostini) are marked as "unsupported system". "User error" is for nearly everything else that could occur due to some issue that only occurs on the user system (ie: a problem that only happens due to a non-standard/non-functional configuration change the user made, a problem with the users hardware, and that sort of thing).

The tldr being: Sorry if I offended you. Don't take it personally, it is just for my (our) tracking purposes, it isn't meant to be a reflection on you. If after further investigation it turns out to "fit" better into one of the other categories it will be edited as such.

theofficialgman commented 1 month ago

Then edit /usr/lib/systemd/user/xdg-desktop-portal-wlr.service as root and add this line before the ExecStart= line:
Environment=XDG_CURRENT_DESKTOP=Wayfire

Minor note, piOS uses labwc on new installs (since a few months now I think) by default. So the environment variable may need to be modified. It is also worth noting that the portal source doesn't have labwc in its portal config https://github.com/emersion/xdg-desktop-portal-wlr/blob/d9ada849aeca6137915de2df69beaef4e272cc1d/wlr.portal#L4 , hopefully piOS devs added it in their package but idk.

theofficialgman commented 1 month ago

The date for latest online version is blank.

that comes from https://github.com/Botspot/pi-apps/blob/92c7775d2cb78c1ee06eab8d33fa3d174372af87/api#L3169 So if the users internet is disconnected/non-functional or the time is wrong (ie: causing certificate errros) date may not be passed any valid input.

What is the BusyBox output doing there? I'm not sure what that means.

That output is indeed strange... the expected output in the above scenario is

date: option requires an argument -- 'd'
Try 'date --help' for more information.

which comes from coreutils's date the presence of busybox's date indicates to me that this command was run from the initramfs or the busybox shell environment

Botspot commented 1 month ago

Then edit /usr/lib/systemd/user/xdg-desktop-portal-wlr.service as root and add this line before the ExecStart= line:
Environment=XDG_CURRENT_DESKTOP=Wayfire
Minor note, piOS uses labwc on new installs (since a few months now I think) by default. So the environment variable may need to be modified. It is also worth noting that the portal source doesn't have labwc in its portal config https://github.com/emersion/xdg-desktop-portal-wlr/blob/d9ada849aeca6137915de2df69beaef4e272cc1d/wlr.portal#L4 , hopefully piOS devs added it in their package but idk.

Yes I tested that on labwc and with the setting set to Wayfire, RustDesk still works.

tedy02 commented 1 month ago

installing the stuff and setting up now. i wasn't offended just caught me off guard is all. Linux is still rather new for me and I'm just figuring it out as I go so if there was something I was doing I legitimately wanted to know what it was. I'll get the ID numbers soon. Will this make it so anyone reading this can access my system?

Botspot commented 1 month ago

Alright. I have made some changes to pi-apps that should warn you of what is going wrong. I think I also left your system with ~/bin renamed to ~/bin2, or maybe it was ~/usr/bin renamed to ~/usr/bin2. I don't recall. You should probably just delete these directories. Pi-Apps ought to run normally for you now. Just allow it to update and you should be good to go.

Closing this issue because the cause of the issue is now known, and it should be fixed on your system specifically.

Botspot commented 1 month ago

Commits made as a result of this discussion: https://github.com/Botspot/pi-apps/commit/5a53d38e151e520440a1e97b70b898130a3b2d77 and https://github.com/Botspot/pi-apps/commit/3de0ae7d98253407248cc0d51f0e4135272b89a4

theofficialgman commented 1 month ago

@Botspot if I am reading this correctly the problem was that the user had BusyBox binaries stored in ~/bin/ (which have a higher priority in the PATH than /usr/bin/ binaries) and this binaries don't behave like the distro equivalent of the binaries?

Do you have a backup of that folder? It would be interesting to try and figure out what binaries were there (and ultimately the source of why the user had them installed).

Botspot commented 1 month ago

@Botspot if I am reading this correctly the problem was that the user had BusyBox binaries stored in ~/bin/ (which have a higher priority in the PATH than /usr/bin/ binaries) and this binaries don't behave like the distro equivalent of the binaries?

Completely correct.

Do you have a backup of that folder? It would be interesting to try and figure out what binaries were there (and ultimately the source of why the user had them installed).

While I don't have a backup of the folder, I did take this screenshot. 20240913_17h59m31s_grim Later on I found that on this user's system, the same list of files were present in both ~/bin and ~/usr/bin. If you are curious enough, I suppose you could ask tedy02 to send you a zip file of the folder if he still has it, or provide a link to where he acquired it.

tedy02 commented 1 month ago

Yeah I haven't done anything to the raspberry since the troubleshooting except for removing the remote access software. if anybody wants anything from me just let me know...

tedy02 commented 1 month ago

Also, for the record, it apparently was user error. 😁

tedy02 commented 1 month ago

Do you have a backup of that folder? It would be interesting to try and figure out what binaries were there (and ultimately the source of why the user had them installed).

Here is a zip file of the mysterious bin folder found in my Home directory: https://app.box.com/s/jkxgjdvfka2bzioes8ci9bqwt3b9hifa

If anyone can tell me what I did to create it in the first place that would be cool (so I don't do it again). :)

theofficialgman commented 1 month ago

If anyone can tell me what I did to create it in the first place that would be cool (so I don't do it again). :)

Can't tell you that, only you can tell us that by retracing what steps you have done on this operating system.

What I can say is these are indeed busybox binaries. Busybox is a single binary that contains many programs. What you sent over shows all the programs separately probably because of how you packaged it. In reality all they need to be is a symlink to the main busybox binary. The name of the executable (or symlink) determines which program gets run.

The strings of the busybox binary from the zip you sent match up with https://packages.debian.org/bookworm/busybox-udeb BusyBox v1.35.0 (Debian 1:1.35.0-4+b3) but the binaries themselves are not identical and neither is the directory structure (no deb or udeb would install in /home). So what is most likely is whoever built these or whatever script you ran used the debian busybox-udeb packaging as a base but recompiled and set the output directory in your home directory.

Botspot / pi-apps