I don’t have an issue with etcher using it on Windows. I do mainly use popsicle on EndeavourOS.
I’m not saying it is because of the live ISO. Just have to cross all bridges just in case and eliminate the possibility. 
Popcicle… Never heard before. Will take a look the next days…
I tested Method 2. I just downloaded the ddimg-rpi-20230128 image and sha512sum file.
Checked the sha512sum of the image. All ok.
I burned the image to a uSD card on my x86_64 computer using gnome-disk-utility.
Used gnome-disk-utility to unmount the uSD.
The uSD at this point is fully installed and ready to connect to the RPi 4b and boot.
Connected the uSD card to the RPi, and It booted up and it works as expected.
If you got a OpenBox screen like the first image in Post 39. Then the installer is likely working. This is starting to look like a hardware problem.
Are you using a USB wired mouse, a bluetooth mouse, or cordless mouse with a dongle?
Bring up a terminal window, and see if you can type from the keyboard into the terminal.
Are the USB Mouse and USB keyboard plugged into the USB Ports towards the edge (USB 2), and not the ones in the middle (USB 3)
I am just guessing here. Give us some more information on the mouse / keyboard hardware.
Pudge
The keyboard is indeed a wireless one. From logitech, with buildin TouchPad. And USB dongle. But that device is working as expected.
I am assuming the problem is when you get the OpenBox window, and you use the mouse to click on a button, nothing happens. Is there a separate mouse, or is the TouchPad being used in lieu of a physical mouse?
Pudge
A separate Mouse… Sure, can try it later. But right click is working, and leftclick on the icon in the top left corner to run the install make a rotating icon visible for some seconds. That’s curious…
That happens to me as well. Openbox context menu should work: with that, exit openbox. Then, openbox will be automatically restarted, and now everything should work.
1 Like
Btw.
What is the difference between rootfs-rpi… and ddimg-rpi… To be honest, i’ve used the rootfs one… Now downloading the dd Image…
1 Like
Yes. That did the trick. Exit Openbox, and after it comes back the installer comes up…
Thanks…
1 Like
Caution, you may experience a severe case of TL;DR while reading this post.
ROOTFS-RPI
rootfs consists of a kernel with appropriate kernel modules, a bootloader of some sort, firmware, and basic drivers. In other words, just enough to boot up the OS.
For Raspberry Pi 4b the Archlinux ARM team has provided a rootfs at
http://os.archlinuxarm.org/os/
Scroll down to
ArchLinuxARM-rpi-aarch64-latest.tar.gz
This is the base rootfs for the RPi 4b aarch64 OS. Archlinux Arm provides this as a straight up tar file compressed by bz (bz = bzip)
One of the things the install script does early on is obtain the rootfs
printf "\n\nDownload the Archlinux rootfs for RPi 4b\n\n"
wget http://os.archlinuxarm.org/os/ArchLinuxARM-rpi-aarch64-latest.tar.gz
printf "\n\n${CYAN}Untarring the image...may take a few minutes.${NC}\n"
bsdtar -xpf ArchLinuxARM-rpi-aarch64-latest.tar.gz -C MP2
printf "\n\n${CYAN}syncing files...may take a few minutes.${NC}\n"
sync
The print statements pretty much describes what is going on. wget downloads the roofs from Archlinux ARM. bsdtar untars the downloaded rootfs to a mount point MP2.
Sync syncs the files. The following describes the entire procedure to download the RPi 4b rootfs
https://archlinuxarm.org/platforms/armv8/broadcom/raspberry-pi-4
Click on the “Installation” Tab and there are Archlinux’s instructions to download the rootfs
Now we have a base install with just the minimum to boot the OS, and a few extra goodies. Now we run the script that installs all the packages necessary for a basic x11 or Wayland graphics, and all the base packages necessary up to choosing a DE or WM.
At this point the uSD is installed in the RPi 4 and boots into OpenBox with a modified Calamares for the remainder of the install.
ddimg-rpi
With ddimg-rpi, the EnOS ARM devs do all of the above and then compress it into a Joliet ISO6690 iso image and release the .iso on github. The user then downloads this .iso image and uses dd or other imaging apps to copy the .iso on to a uSD card or USB 3 SSD. Once burned, connect the storage device to a RPi 4b and boot into OpenBox with the modified
Calamares for selecting a DE / WM and other personal configuration.
So both end up at the same mid point of installation. The big difference is:
Method 1
This utilizes the x86_64 liveISO in an attempt to kind of integrate ARM into the main EnOS liveISO using the. Then start the script that downloads the rootfs then installs on the uSD or USB SSD. This was done with the assumption that most users wanting EnOS on ARM would already have the EnOS liveISO on a thumb drive. But then we started getting RPi 4 users that were used to using RPi imager to download and then burn the ISO. They did not want the extra step of downloading and burning the EnOS x86_64 liveISO in order to download and burn the completed rootfs. Hence the appearance of
Method 2
In order to appease the Raspberry Pi OS (and other Debian offerings) users, @sradjoker wrote a script to do all of Method 1, then create an ISO that could be downloaded, and burned with most imagers to a uSD or USB SSD. I agree, if a user doesn’t have the EnOS liveISO laying around, why do extra downloading and burning just to get the EnOS liveISO to do more downloading and burning.
Method 3
Is just a throw back to the stage before we started using the X86_64 Calamares for downloading and creating a rootfs and building from there. We had a few requests for this from users wanting to start with a base rootfs and then do their own thing of finishing their building an OS. So this is mainly for tinkering around with.
Pudge
Thanks for reporting this. I am not sure how to troubleshoot this as I cannot recreate the problem, but I will look into it.
@RudiOnTheAir
Are you good to go now with @lorebett 's work around ?
How are things working for you with an installed DE / WM ?
Pudge
Hi
Thank you for the detailed description.
I’ll take a closer look at the Raspi in the next few days. He should primarily run amateur radio programs. I have to see which ones are available for Arch at all. A search with pacman or yay -Ss obviously doesn’t filter out those that aren’t suitable for Arm. Then I have to look again. Thank you again…
Here is the URL for Archlinux ARM packages.
https://archlinuxarm.org/packages
Most things in the AUR will install on a aarch64 OS. Sometimes you may have to edit the PKGBUILD file to include the aarch64 architecture. Such as
fldigi
pkgdesc="Digital Modem Program for Amateur Radio"
arch=('i686' 'x86_64' 'aarch64')
In the architecture line
arch=('i686' 'x86_64' 'aarch64')
aarch64 is already listed for fidigi. So one would only need to “Download snapshot” then as user run
makepkg -cfi PKGBUILD
and that should be it. Options
-c, --clean up leftover work files and directories after a successful build.
-f, --force
-i, --install
If a PKGBUILD does not have aarch64 listed in the
arch=(‘x86_64’)
just edit the PKGBUILD and add the aarch64 architecture and give it a try. Most times, not always, but most times it will compile and install the package.
For the arch=(xxxx) line
arch=(“x86_64” “aarch64”) arch=(‘x86_64’ ‘aarch64’) are both acceptable, just mimic what is alread there.
If you have any questions or problems with using makepkg there is plenty of help here.
Pudge
Uuups. Sorry.
No need to be Sorry. I was just as guilty as you were, probably more so.
Most OT is not consequential on it’s own, so OT is not a big deal here. I just think rustdesk deserved it’s own topic.
Pudge