BunsenLabs Lithium ARM edition...

rbh · 2021-01-22 18:08:54

cog wrote:

I still got the machine in the closet if y’all need anything else. Let me know. I just don’t have bandwidth in the mountains so can’t download a lot.

You are running Litium on Raspberry Pi, without any glitches/problems?

jimjamz · 2021-01-22 18:12:43

rbh wrote:

If you uninstall them, one at a time, and test systemctl? Restart systemd and ask status for one service? or opposite, add bunsen apps one a time and test systemctl...

I appreciate the effort to diagnose the issue, but I feel this would be rather unnecessary.
Firstly, for the amount of time and effort that would take for each package, seriously outweighs the benefit of resolving the actual problem.
We may identify what package is causing systemctl to not respond correctly, but that does not mean it helps us to successfully install BL on the Pi. Others who have succeeded with BL installs on their Raspberry Pi have not reported such systemctl issues, so I feel it is a red herring.
Whatever is causing the systemctl issue, is perhaps due to a flaw in the process I am undertaking, and not the result of an incompatible package.

rbh wrote:

Just for the sake of it, should you not also install all debian packages, not just the BL-packages? The full list is here Bunsenlabs Lithium Package lists

I did a comparison.
Packages exclusive to bunsen-meta-all (*not* in the full package list (64-bit)):

dillo
libexo-1-0
mousepad
mpva
rxvt-unicode
bunsen-configs-lite
bunsen-os-release
bunsen-paper-icon-theme

Packages exclusive to the full package list (64-bit) (excluding `amd64-microcode`):

apt-xapian-index
aptitude
catfish
compton
enchant
filezilla
firefox-esr
fonts-cantarell
fonts-noto
fonts-noto-cjk
fonts-noto-mono
ftp
geany
ghostscript
gnome-themes-standard
gstreamer1.0-libav
gstreamer1.0-plugins-bad
gstreamer1.0-plugins-base
gstreamer1.0-plugins-good
gstreamer1.0-plugins-ugly
gstreamer1.0-pulseaudio
hexchat
i965-va-driver
inotify-tools
intel-microcode
lame
libblockdev-crypto2
libreoffice-calc
libreoffice-gtk2
libreoffice-writer
lxterminal
lzop
papirus-icon-theme
rpl
thunar-media-tags-plugin
tumbler
vlc
vlc-plugin-notify
xfce4-screenshooter
xserver-xorg-video-intel
bunsen-configs
bunsen-papirus-icon-theme

The i386 package list contains only 3 additional packages, which have to be omitted for ARM:

i965-va-driver
intel-microcode
xserver-xorg-video-intel

I can combine the package lists and re-attempt a fresh install with results.

rbh wrote:

Du you have a harddrive attached to your Pi, or a big flashcard, så you can work with (grml-)debootstrap?

I have a USB stick I am using to copy the keys, sources and configuration files to the pi during this whole process.
What other purpose are you suggesting it be used for?

rbh · 2021-01-22 18:40:05

jimjamz wrote:

rbh wrote:
Du you have a harddrive attached to your Pi, or a big flashcard, så you can work with (grml-)debootstrap?
I have a USB stick I am using to copy the keys, sources and configuration files to the pi during this whole process.
What other purpose are you suggesting it be used for?

With debootstrap (grml-debotstrap, is a wraper around debootstrap, ease the manage of debottstrap), you can install debian to a partition, update grub and reboot to the new installation. You can have a working machine while testing the installation of another OS.

Last edited by rbh (2021-01-22 18:40:54)

jimjamz · 2021-01-23 14:59:34

rbh wrote:

jimjamz wrote:
rbh wrote:
Du you have a harddrive attached to your Pi, or a big flashcard, så you can work with (grml-)debootstrap?
I have a USB stick I am using to copy the keys, sources and configuration files to the pi during this whole process.
What other purpose are you suggesting it be used for?
With debootstrap (grml-debotstrap, is a wraper around debootstrap, ease the manage of debottstrap), you can install debian to a partition, update grub and reboot to the new installation. You can have a working machine while testing the installation of another OS.

I'm not sure why I would need to do this. What would I be doing this for?
I'm also not familiar with debootstrap (grml-debotstrap), and considerin that others who have installed BL on a Raspberry Pi have not had to go through this process, I don't see how it is mandatory.

jimjamz · 2021-01-23 15:19:52

rbh wrote:

Just for the sake of it, should you not also install all debian packages, not just the BL-packages? The full list is here Bunsenlabs Lithium Package lists

Once again, I started from the beginning with a fresh image of Raspi OS dd'ed to the SD card.
All the subsequent steps were the same, except I replaced the custom bunsen-meta-all package list with the full package list (64-bit), but omitting the following 4 packages from the list due to architecture incompatibility:

amd64-microcode
i965-va-driver
intel-microcode
xserver-xorg-video-intel

The install required a download of more than 3GB of packages. After the 'apt install' and a reboot, I still received the same NetworkManager failures (not sure whether this is linked to the issues I'm having), however, I noticed this time that when I checked the version of Linux:

lsb_release -a

The response was 'Raspbian' and not 'BunsenLabs'.

At this stage, I always check what packages need to be upgraded:

apt list --upgradable

Regardless of the package list I used during the install, the list of upgradable packages is always the same:

Listing...
bsdmainutils/stable 11.1.2+b1 armhf [upgradable from: 11.1.2]
dc/stable 1.07.1-2+b1 armhf [upgradable from: 1.07.1-2]
gcc-7-base/stable 7.4.0-6 armhf [upgradable from: 7.3.0-19]
gdb/stable 8.2.1-2+b3 armhf [upgradable from: 8.2.1-2]
libfile-fcntllock-perl/stable 0.22-3+b5 armhf [upgradable from: 0.22-3+b4]
liblocale-gettext-perl/stable 1.07-3+b4 armhf [upgradable from: 1.07-3+b3]
libnfnetlink0/stable 1.0.1-3+b1 armhf [upgradable from: 1.0.1-3]
libperl5.28/stable 5.28.1-6+deb10u1 armhf [upgradable from: 5.28.1-6]
linux-libc-dev/stable 4.19.160-2 armhf [upgradable from: 4.18.20-2+rpi1]
lua5.1/stable 5.1.5-8.1+b2 armhf [upgradable from: 5.1.5-8.1+b1]
mawk/stable 1.3.3-17+b3 armhf [upgradable from: 1.3.3-17]
ncdu/stable 1.13-1+b1 armhf [upgradable from: 1.13-1]
perl-base/stable 5.28.1-6+deb10u1 armhf [upgradable from: 5.28.1-6]
perl-modules-5.28/stable 5.28.1-6+deb10u1 all [upgradable from: 5.28.1-6]
perl/stable 5.28.1-6+deb10u1 armhf [upgradable from: 5.28.1-6]
rng-tools/stable 2-unofficial-mt.14-1+b2 armhf [upgradable from: 2-unofficial-mt.14-1]

An `apt upgrade` always seems to break on `rng-tools`, perhaps as a result of a pollution of the packages that may have been installed from the mix of different sources (raspbian, debian, bunsenlabs).

rbh · 2021-01-23 15:20:58

jimjamz wrote:

I don't see how it is mandatory.

The Linux way is far from single mandatory way when it comes to installing.

Debootstrap, is one way, to install Debian base installation, to use rescue or for foundation to mane an desktop or whatewer you want.

Quite handy tool. Instead of using lightest install cd, with debootstrap, you strap just what you want. Chroot in, contiune to install components and configure. When ready, just update grubb or copy to other disk and reboot to the new installation.

Feel free to investigate or do not.

jimjamz · 2021-03-08 21:23:28

I jwanted to wrap up the rest of my notes here as, at the very least, a reminder for myself for doing future Raspberry Pi installs.

So, the whole issues I were having previously in this thread, were ultimately related to the generation of Pi I was using.
A Pi 1 Model B is not compatible with all the armhf packages that are being installed. This is because the CPU is not actually armhf, but armel. It is labelled as armhf because TPF have made a few tweaks for it to be recognised so. But, it cannot support a full blown Debian distribution and therefore, a BL configuration either.

As soon as I ran my same install procedure and scripts on my RPi 4, BunsenLabs was up and running.

The one annoying issue I have is, after installing my BunsenLabs packages, the nm-applet is reporting "device not ready", just as reported by the OP in this topic.

I could manually setup the wireless network by using `raspi-config`. Through an NCurses menu, I just had to enter the SSID and the passphrase.
But even when the Wi-Fi is correctly setup and working, the nm-applet still reports 'device not ready'.

Other than that, everything is working well.

akator · 2022-02-23 14:58:34

Sorry for resurrecting this thread, but I haven't found anything better to answer my questions. I have read through this thread multiple times but I'm still unclear on how to get this working. Could someone point me to explicit working instructions on how to get Lithium running on a RPi 4?

Thanks!

grubernd · 2022-02-24 08:41:38

akator wrote:

Could someone point me to explicit working instructions on how to get Lithium running on a RPi 4?

Sorry, no explicit content from me. (pun intended)

But having used a (mostly) working Lithium on RPi4 as our TV-system in the living room for a year here are some notes:

- use a SDD via USB3 for the system
- start with the Raspios Lite image
- work through the BL Li Netinstall
- tweak from there

One thing is for sure: you totally want to run the system from a USB3 SSD.

We had BL Li running from the SD-card. Nothing lasts longer than a quick sunday afternoon prototype.

Anyway, the SD-card is great when just watching movies or doing basic file stuff in Thunar or working from the terminal. But once you open a regular GUI app that is a bit more demanding on the disk it is a pain. Browsing the web is the worst, even with adblockers and scripts in lockdown. It works, but your yester-year mobile phone would be a way more pleasant experience.

PS: That RPi4 has been delegated to some headless project.
We are now watching TV from a RPi3 running libreElec KODI.
All other Linux desk/laptops in the house remain as bunsenlabs.

akator · 2022-02-24 12:10:40

grubernd wrote:

But having used a (mostly) working Lithium on RPi4 as our TV-system in the living room for a year here are some notes:
- use a SDD via USB3 for the system
- start with the Raspios Lite image
- work through the BL Li Netinstall
- tweak from there
One thing is for sure: you totally want to run the system from a USB3 SSD.
We had BL Li running from the SD-card. Nothing lasts longer than a quick sunday afternoon prototype.
Anyway, the SD-card is great when just watching movies or doing basic file stuff in Thunar or working from the terminal. But once you open a regular GUI app that is a bit more demanding on the disk it is a pain. Browsing the web is the worst, even with adblockers and scripts in lockdown. It works, but your yester-year mobile phone would be a way more pleasant experience.
PS: That RPi4 has been delegated to some headless project.
We are now watching TV from a RPi3 running libreElec KODI.
All other Linux desk/laptops in the house remain as bunsenlabs.

Thanks! That's pretty much what I had assembled in notes based on this thread.

Good to know about the storage requirements, too. For simple stuff like PiHole I haven't run into any problems using micro SD but with anything more storage demanding (Lakka, Home Assistant, MotionEye) I've used USB storage because it's far more reliable.

I've got 32-bit Lithium on a netbook that I mostly use as a control panel for automation, remote access, music server, etc. Lithium has been perfect for that netbook. I was surprised at how much faster Lithium was on that machine than other distros I've used over the years.

I've got a few spare 120GB SSDs around and I'll use one to skip the whole SD experience.

jimjamz · 2022-04-10 13:12:10

@hhh

I want to update the package lists that are required for installing beryllium on top of a Raspberry Pi Bullseye OS (armhf and arm64 architectures - these are not covered in John's guide).
Do you have a beryllium package list like you posted for the Lithium release here?
Thanks!

EDIT:

Is this the meta-all package list for beryllium? But, for which architecture?
How can I differentiate which packages are for amd64, i386?

I suspect I need to take this list and remove the packages that are specific to non-ARM architecture, as I did before?

Last edited by jimjamz (2022-04-10 13:21:51)

Bearded_Blunder · 2022-04-10 13:56:53

But, for which architecture?
How can I differentiate which packages are for amd64, i386?

That list is correct for i386 & amd64 there's just the one meta for both achitectures. Control has it as "Architecture: all" which is slightly naughty, given it's basically i386 & amd64 & depends lists X86 specific stuff.

Simply skipping the packages not available on arm once the arm repo for Beryllium is available & fully populated will I think get you pretty much there.

apt-cache show bunsen-meta-all | grep ^Depends

will get you the list for whichever release without going digging if you have an installed i386/amd64 BL system (or VM) of the release in question to issue it on.

I have no arm hardware, so caveat emptor on anything I say.

jimjamz · 2022-04-11 21:55:44

Thanks for clearing that up. I sort of expected the list to be a combo for both i386 and amd64.
The reason why I asked is because there was a differentiated Lithium list for both architectures.

I had an attempt myself in January 2021 to distinguish the separation of packages but I don't know how much of this is still valid.

I managed to get a working BunsenLabs on a Raspberry Pi 4 (armhf Raspbian Lite as a base) and I only had to omit 4 packages from the meta-all list for this to be successful.

This time I intend to try Beryllium on Raspbian's arm64 distro and see how it goes.

Bearded_Blunder · 2022-04-11 22:17:31

The "32 Bit" variations are about lighter applications & less space used (and actually fitting it in a cd size image, along with the live session)..
The trick to do that would be to look at bunsen-meta-lite rather than bunsen-meta-all.

It's not about anything more technical than space & resource usage.

Though the packages in meta-lite might be more suited to a lower powered cpu..

Last edited by Bearded_Blunder (2022-04-11 22:19:58)

johnraff · 2022-04-12 02:28:49

^The "lite" package list might have some room for improvement. Dropping the 700MB CD limit still leaves some possible package substitutions for less powerful machines.

Most (all?) of the bunsen-* packages themselves are either config files or shell scripts, pretty much architecture-agnostic in themselves, but their dependencies might have other things to say.

#41 2021-01-22 18:08:54

Re: BunsenLabs Lithium ARM edition...

#42 2021-01-22 18:12:43

Re: BunsenLabs Lithium ARM edition...

#43 2021-01-22 18:40:05

Re: BunsenLabs Lithium ARM edition...

#44 2021-01-23 14:59:34

Re: BunsenLabs Lithium ARM edition...

#45 2021-01-23 15:19:52

Re: BunsenLabs Lithium ARM edition...

#46 2021-01-23 15:20:58

Re: BunsenLabs Lithium ARM edition...

#47 2021-03-08 21:23:28

Re: BunsenLabs Lithium ARM edition...

#48 2022-02-23 14:58:34

Re: BunsenLabs Lithium ARM edition...

#49 2022-02-24 08:41:38

Re: BunsenLabs Lithium ARM edition...

#50 2022-02-24 12:10:40

Re: BunsenLabs Lithium ARM edition...

#51 2022-04-10 13:12:10

Re: BunsenLabs Lithium ARM edition...

#52 2022-04-10 13:56:53

Re: BunsenLabs Lithium ARM edition...

#53 2022-04-11 21:55:44

Re: BunsenLabs Lithium ARM edition...

#54 2022-04-11 22:17:31

Re: BunsenLabs Lithium ARM edition...

#55 2022-04-12 02:28:49

Re: BunsenLabs Lithium ARM edition...

Board footer