My ARM endeavour

This is going to be a post of the more lengthy type, but I felt like sharing my experience and thoughts on this topic and maybe initiate some kind of discussion.

Day 1
So, my plan is to set up my own home cloud (Nextcloud) on a Raspberry Pi 4b powered by EOS-ARM :enos_flag: Reading my way through the how to get started-page, the first thing I noticed was that there is a mistake in the part about SD cards. According to wikipedia the U3-class is better than the U1-class. I think this should be corrected. Question in between: is there a github repo for the website? If yes, just point me towards it and I might just create a pull request when I find the time :slight_smile:

But so far, no big deal. Moving on to automated base install. Tells me to use a Live-USB installer in order to flash the SD card, good thing that I always have an EOS live stick at hand. Booted into the live environment, followed the instructions - everything working just fine. It was way later, when I had my Raspi already running, that I recognized that I should have booted the live environment in legacy mode (if I got it right… in the instructions it says msdos/MBR mode). Anyway, I am quite sure that I booted in UEFI mode, but it worked nevertheless, so this passage seems not at all to be neccesary and might be removed. But maybe someone of the experts comment on this? Am I right that the instructions were written by @Pudge?

So, last page, the EndeavourOS install Booted up the Pi, updated mirrorlist etc. When it came to the install script, I found 2 different ones in the repo I just had cloned (v2.0 and v2.1, the latter of which I executed), maybe this could also be changed in the instructions (perhaps best using *s or sth so that you would not have to change this with each update to the script). No problems from here on, I ended up with a clean headless server install.

Though, I noticed some things that to me are a bit confusing in the aftermath of the installation. First I noticed some missing packages that I would definitely expect on any kind of installation (for example, man-pages and man-db were not preinstalled, but I would not consider this too important because installing them if needed is just a one-liner). Also, no yay. And also no endeavouros-mirrolist, nor a correcponding entry in /etc/pacman.conf. I think, if not preinstalling yay in order to keep the base installation as small as possible, at least the endeavour-repo should be added by the installer by default, because this (besides the installer) basically is it what distinguishes EOS from pure Arch, right? I’m curios about comments on this.

That’s it for the first day. I’ll update this thread and share my experience in the coming days when I made some progress with this.
:beers:

3 Likes

Any and all feedback is appreciated, but the instructions/manuals are only in pdf form on Github. I am not much of an author, so someone editing them would probably be a good thing. The originals are in LibreOffice .odt format. I will gladly make them available to anyone wanting to edit them.

It’s not really necessary to use the Live ISO, any Linux based computer will do. The reason it was suggested to use the EndeavourOS Live ISO is for requests for help and/or troubleshooting problems. That way, it is a known environment for anyone offering help. It also lessens the chance of inexperienced user borking their daily driver, but basically it is for consistency.

That is totally my bad. As is known, we are all volunteers at EndeavourOS. I did make some corrections to the script, hence the V2.1. Before I could finish things up, something came up and I was off on another tangent. The reason V2.0 was still there was I wasn’t totally finished testing V2.1. The item yet to be tested was the section where for the headless server one can have the script partition, format, and and edit /etc/fstab to mount the DATA storage device. Basically fixing a bug where a user could enter an invalid device name and it would be accepted only to fail later. That bug should be fixed, but not thoughly tested. If you had the script prepare the DATA storage device, how did it go and thanks for helping with the testing.

All of the above are installed in the Desktop Environment. However, the original design concept for a server was to install a headless server. So just thinking headless server, man-pages and man-db would be a waste of space as there would be no keyboard and monitor to display them. Also along the headless lines, most packages in the EndeavourOS Arm repo are dependent on a graphical interface to utilize them. The exceptions being downgrade, pahis, inxi and yay. Downgrade, pahi, and inxi could be used for troubleshooting problems, but a headless device only uses a base Linux install, and there just aren’t any problems with a base install. I went back and forth as to including yay. In the end, I didn’t because all of the packages I had instructions for installing, none were from the AUR.

I am happy to entertain feature requests for the headless server.

Thank you for the feedback.

Pudge

3 Likes

Don’t hesitate, I would not mind going through them and do some editing.


Totally get that point! When I wrote

I was more refering to the part where it says that I should not boot the live environment in UEFI mode, or otherwise it would’t work, because it did actually work for me (by that I mean the flashing of the SD card). If I’m still not getting your point, please enlighten me :pensive:


That is indeed known and greatly appreciated and respected! it was not at all my intention to criticize you or anyone else for anything, just in case it came across that way.

Unfortunately I must apologize, I thought about that a second because I indeed have an SSD connected to the Raspberry, but I then decided to omit the automatic setup and perform the nessecary operations manually at a later point. If I had known, I probably would have tested this.


Point!

May I suggest that maybe we could have the endeavour repos added by the installer but without having any of its packages installed by default? That would just add a few 100 bytes of additional weight to the installation(is this actually correct?), but for those who in the future want to do a headless install but want to have easy access to AUR packages, it would save the hassle of either having to build yay manually or having to add the eos repos by hand first. I know that using yay at all and not doing all the package building by hand is a little bit against the Arch philosophy, but I think you decided to package and distribute yay with EOS for a reason :wink:

Thanks for your comprehensive answer!

1 Like

I have already removed that from both the desktop-instructions and the server-instructions. Thanks for pointing that out. It’s been so long since I wrote that into the instructions, I’m not sure why I put that in there. But you are correct it will work either way. Also, I edited the Version numbers in the instructions.

There are three ways to install the base image on the uSD card.
1 Follow the instructions on the Archlinuxarm web site.
2 Follow the instructions in the installation instructions.
3 run a script available at github to install a 64 bit Archlinux base.

Just curious, but I assume you used number 2 when you did your install?

I don’t see a problem with that. Let me run that past the other core members and I will get back to you.

You are very welcome.

Pudge

I have changed the server portion of the script to install the endeavouros-mirrorlist and endeavouros-keyring. The server script also installs downgrade, pahis, inxi, and yay by default. All four of these do not require graphics and can be run via ssh in a client terminal window. Thanks for the feature request.

Pudge

3 Likes