Raspiblitz: Research: Change OS to DietPi to support other SBCs

[unic0der]

For the reason of future-proofing and faster sync, it would be beneficial to introduce support for other, stronger single board computers such as the ROCK64 with stronger CPU, a lot more RAM, as well as USB 3.0 support

[rootzoll]

Yes that would be great and is in the list of ideas. But its a bigger step, because this would mean to exchange the Raspbian base OS to something like DietPi.

The sd crad build script has already some preparations in to detect when building on something else then Raspian - that would need to be extended:
https://github.com/rootzoll/raspiblitz/blob/master/build.sdcard/raspbianStretchDesktop.sh

If someone can get the RaspiBlitz on a Rock64/DietPi running please share experience.

[openoms]

Hi! I have an ODroid HC1 and HC2 originally bought to do the Thunderdroid guide, but never got to it.
I have tried the Raspiblitz script with DietPi unfortunately not successfully so far. I keep running into a strange error during the initial setup after the HDD is set up:

Failed to connect to bus: No such file or directory
1548192239
LND not ready yet ... waiting another 60 seconds.
If this takes too long (more then 10min total) --> CTRL+c and report Problem

see my full output here: https://github.com/openoms/HardwareNode/blob/OdroidHC1Debug/DietPi/initial_setup_output.html
And the whole context here: https://github.com/openoms/HardwareNode/blob/OdroidHC1Debug/DietPi/install.md

[21isenough]

I just got my Odroid HC1 hardware delivered - ready to be loaded with bitcoin software :-D I'll be able to run that script over the weekend as well and report on my errors and outputs.

[justinmoon]

I'll try to test as well. I've got an Odroid lying around ...

[openoms]

making progress here:
using systemctl with sudo allowed to step forward, thanks for helping @21isenough !
Working on some more changes, most additions are already pushed here: https://github.com/openoms/HardwareNode/tree/OdroidHC1Debug

[openoms]

the current working branch is: https://github.com/openoms/HardwareNode/tree/raspiblitz-dev updated with the raspiblitz dev branch code. Everything seems to work so far.

[openoms]

There is this sad and concerning tweet regarding the future of the DietPi project: https://twitter.com/DietPi_/status/1098420068998938625

[openoms]

There is hope, looking forward to the announcement. https://twitter.com/DietPi_/status/1100584695702736896
Will post updates here.

[openoms]

I have managed to make the pi user autologin and the default GPIO LCD display work with DietPi on the RPi without issues, but I have a strange one with this HDMI screen. (https://www.aliexpress.com/item/3-5-inch-LCD-HDMI-USB-Touch-Screen-Real-HD-1920x1080-LCD-Display-Py-for-Raspberri/32818537950.html)
I wonder if anyone experienced similar. The text outputs and dialog boxes appear fine, but the status screen only takes half of the screen as pictured. The resolution is set to the display's native 480x320.



Any tips how to fix this?

[fluidvoice]

I have managed to make the pi user autologin and the default GPIO LCD display work with DietPi on the RPi without issues, but I have a strange one with this HDMI screen. (https://www.aliexpress.com/item/3-5-inch-LCD-HDMI-USB-Touch-Screen-Real-HD-1920x1080-LCD-Display-Py-for-Raspberri/32818537950.html)
I wonder if anyone experienced similar. The text outputs and dialog boxes appear fine, but the status screen only takes half of the screen as pictured. The resolution is set to the display's native 480x320.
Any tips how to fix this?

[edit] see the doc and scroll down to "hdmi_cvt" --> https://www.raspberrypi.org/documentation/configuration/config-txt/video.md

https://www.raspberrypi.org/forums/viewtopic.php?t=175616#p1120534

Here is what need to be set in /boot/config.txt to use this display (this is only a part of the file):

. Force use HDMI

hdmi_force_hotplug=1

. force a specific HDMI mode

hdmi_group=2
hdmi_mode=87

. custom display resolution (480x320 looks good , and 720x480 is not too bad too,3rd res is: 810x540 )

. /----------------- Width: 480px ( or 720px /or 810px)

. | /------------- Height: 320px ( or 480px /or 540px)

. | | /--------- Refresh: 60Hz

. | | | /------- Aspect ratio: 6=15:9 (1=4:3, 2=14:9, 3=16:9, 4=5:4, 5=16:10)

. | | | | /----- Margins: 0=disabled (1=enabled)

. | | | | | /--- Interlace: 0=progressive (1=interlaced)

. | | | | | | /- Reduced blanking: 0=normal (1=reduced)

. | | | | | | |

hdmi_cvt 480 320 60 6 0 0 0

. uncomment to force a HDMI mode rather than DVI. This can make audio work in

. DMT (computer monitor) modes

hdmi_drive=2

[fluidvoice]

Let us know how that screen it works.

[openoms]

Thanks, but I think it suggests the same settings I have used given by the vendor:
http://www.lcdwiki.com/3.5inch_HDMI_Display-B
https://github.com/goodtft/LCD-show/blob/master/boot/config-35-480X320.txt
Will test more on an RPi on Raspbian and on the Odroid XU4 with DietPi.
Everything displays well except the status screen, I suspect it could be a font issue.
Anyway there are some folks, who were testing HDMI screens, I will try to ask more specifically if the problem persists.

[fluidvoice]

The /boot/cmdline.txt has this included in the line fbcon=map:10 fbcon=font:ProFont6x11
Maybe that's it. I don't know where that is being set though. It's not in the build_sdcard.sh script.

[rootzoll]

The dialogboxes can mange different screen/ascii resolutions. The status screen is fixed to the standard ascii width/height of the LCD. I think its a setting of the resolution.

BTW: It would be great if we can get the standard GPIO LCD display working on dietpi - that would open up the possibility to make a complete move at one point from raspbian to dietpi with an update even for all people running the raspberry with the GPIO LCD. Is there any changes to get that working?

[fluidvoice]

possibility to make a complete move at one point from raspbian to dietpi
Why? Is there some advantage, like perhaps lower memory usage, faster, or something?
Support for more SBC boards?

[rootzoll]

Dietpi is a more universal platform that supports a broader range of SBC - including the raspberryPi. Raspbian is very limited just to their own hardware. So being based on dietpi, would give people more choice in choosing their hardware in the future. Also it claims to be lightweight - but thats something to be seen in comparison in the end.

[openoms]

@rootzoll the default GPIO LCD is working together with the automatic install in DietPi on the RPi. I am just waiting with the PR until the 1.1 changes are merged into the dev branch.
Playing along with this HDMI screen for the sake of my Odroid XU4.

[openoms]

The /boot/cmdline.txt has this included in the line fbcon=map:10 fbcon=font:ProFont6x11
Maybe that's it. I don't know where that is being set though. It's not in the build_sdcard.sh script.

The cmdline.txt is being copied in at the end of the build_sdcard.sh by the https://github.com/goodtft/LCD-show/blob/master/LCD35-show or the MPI3508-show in the HDMI screen's case.
DietPi is running the https://github.com/MichaIng/DietPi/blob/master/dietpi/dietpi-autostart at every start overwriting some files with ones from the /DietPi folder depending on the settings.
I will try to put this cmdline.txt in both locations.

I think its a setting of the resolution

It is unlikely as it is set to the display's native 480x320, same as the default GPIO LCD. Also I have tried numerous other (higher and/or different aspect ratio) resolutions and the status screen showed either the same or worse.

[fluidvoice]

Dietpi is a more universal platform that supports a broader range of SBC - including the raspberryPi. Raspbian is very limited just to their own hardware. So being based on dietpi, would give people more choice in choosing their hardware in the future. Also it claims to be lightweight - but thats something to be seen in comparison in the end.

from the Readme... "DietPi is an extremely lightweight Debian-based OS. With images starting at 400MB, that's 3x lighter than 'Raspbian Lite'. It is highly optimized for minimal CPU and RAM resource usage, ensuring your SBC always runs at its maximum potential."
Nice marketing ;-) I wonder what the real difference is in resource usage? Most importantly the RAM usage.

[openoms]

Nice marketing ;-) I wonder what the real difference is in resource usage? Most importantly the RAM usage.

It is lighter in the sense that it is stripped down of any unnecessary dependency with the option to install a extras through the dietpi-software.

It is an open source - community managed project, I don't think it needs marketing at all.

[fluidvoice]

@rootzoll @openoms I must say I really like this idea. I'm interested in building on top of a RaspiBlitz type of platform (SBC+bitcoin+LN) and having the option of using a board with more CPU power and more importantly more RAM if I need it... and who knows if/when Raspberry Pi 4 will come out and what spec's it will have. I just hope that the DietPi project will continue.

[fluidvoice]

It is an open source - community managed project, I don't think it needs marketing at all.
I was joking. I just meant they are touting the supposed benefits. If it's true, it's great.

[openoms]

I was joking. I just meant they are touting the supposed benefits. If it's true, it's great.

To be fair they got some bashing lately from the guy managing armbian for the same reason: https://twitter.com/armbian/status/1108645865621737472?s=19
Despite that I think that the project has a big advantage in the support (and testing) of multiple platforms. Making the RaspiBlitz less hardware dependent helps the whole network of Bitcoin and Lightning.
In the unlikely event of the DietPi community halting we would need to fall back to specific builds for different hardwares.

[fluidvoice]

How does Armbian compare to DietPi? I'm assuming you think DietPi is better for some reasons?

[openoms]

@fluidvoice DietPi has this automated setup feature, so one only needs to burn the image and copy or modify two files to have a one button image setup. Please skim through my writeup here (it can and will be improved further) : https://github.com/openoms/raspiblitz/blob/DietPi/dietpi/RaspberryPi.md (to test need to use my repo for now until it is merged in rootzoll's dev branch) .

Here you can see how an image is converted to a DietPi image: https://github.com/MichaIng/DietPi/issues/1285#issue-280771944

So you can even make a DietPi image from an Armbian build.
The two main reasons to use this distro is the automation and the compatibility with multiple SBCs.

[openoms]

My HDMI diplay issue is solved with running:
sudo setfont /usr/share/consolefonts/Uni3-TerminusBold24x12.psf.gz
(comment here: https://github.com/rootzoll/raspiblitz/issues/341#issuecomment-476664969)
sudo dpkg-reconfigure console-setup works and keeps the settings.
sudo nano /etc/default/console-setup is the place to edit from the commandline.
Thanks to this article: https://www.raspberrypi-spy.co.uk/2014/04/how-to-change-the-command-line-font-size/

[fluidvoice]

@fluidvoice DietPi has this automated setup feature, so one only needs to burn the image and copy or modify two files to have a one button image setup. Please skim through my writeup here (it can and will be improved further) : https://github.com/openoms/raspiblitz/blob/DietPi/dietpi/RaspberryPi.md (to test need to use my repo for now until it is merged in rootzoll's dev branch) .

Here you can see how an image is converted to a DietPi image: MichaIng/DietPi#1285 (comment)

So you can even make a DietPi image from an Armbian build.
The two main reasons to use this distro is the automation and the compatibility with multiple SBCs.

@openoms So I tried this on my Pi 3B+, burned your image to a USB drive and it starts booting up fine and gets pretty far along then gets stuck waiting for the network connection. It just prints out a statement forever on the HDMI screen. I tried editing the dietpi.txt file and setting both wifi and ethernet, using either DHCP or static IP nothing works. I never gets past this. Any ideas?

[openoms]

@fluidvoice Sorry I was not explaining it fully about changing to my repo.

Start with a fresh SDcard.

Use this dietpi.txt: https://github.com/openoms/raspiblitz/raw/DietPi-dev/dietpi/boot/dietpi.txt

And in the Automation_Custom_Script.sh change the

wget https://raw.githubusercontent.com/openoms/raspiblitz/raspiblitz-dev/build.sdcard/raspbianStretchDesktop.sh && sudo bash raspbianStretchDesktop.sh DietPi-dev openoms
to
wget https://raw.githubusercontent.com/openoms/raspiblitz/DietPi-dev/build_sdcard.sh && sudo bash build_sdcard.sh DietPi-dev openoms

this will build exactly what will be there when my PR is merged in (https://github.com/rootzoll/raspiblitz/pull/463).

[fluidvoice]

@fluidvoice Sorry I was not explaining it fully about changing to my repo.

Start with a fresh SDcard.

Use this dietpi.txt: https://github.com/openoms/raspiblitz/raw/DietPi-dev/dietpi/boot/dietpi.txt

And in the Automation_Custom_Script.sh change the

wget https://raw.githubusercontent.com/openoms/raspiblitz/raspiblitz-dev/build.sdcard/raspbianStretchDesktop.sh && sudo bash raspbianStretchDesktop.sh DietPi-dev openoms
to
wget https://raw.githubusercontent.com/openoms/raspiblitz/DietPi-dev/build_sdcard.sh && sudo bash build_sdcard.sh DietPi-dev openoms

this will build exactly what will be there when my PR is merged in (#463).

That's what I did. Burned fresh image w/Etcher to USB drive (I seriously doubt SD card will be any different). Then copied that dietpi.txt file.
Note: I need to use WiFi as my router is too far away from my HDMI monitor and I need to see what's going on during bootup. Why does WiFi not work?
changing that "wget" line won't change anything obviously unless network is up/working.
edit: well I burned the SD card and it seems ethernet is working - at least I can see the node's IP address on the LAN. Now I'm wondering why using a USD drive would make any difference. Need to investigate further.

[openoms]

@fluidvoice This is great, I was not testing using wifi or booting from USB on DietPi yet, so it is all new info.

But first of all I hope the default method works with the SD and ethernet. I got an RPi with the same functionality as with Raspbian. Also an Odroid XU4 with the HDMI screen attached and working and an Odroid HC1 . All built from the same repo.

[fluidvoice]

@openoms so I figured out how to get the WiFi working and everything built and booted up OK.
The only problem is my Raspiblitz LCD screen image is upside down.
Note: I could not get any of the config files to get WiFi working so I had to change the wait setting from "2" (wait forever) to "1" (wait for 10 seconds), then once booted ran dietpi-config to enable WiFi then rebooted. Would be nice to figure out how to do this from config files without needing to run dietpi-config.
By the way, I did this with a USB flash drive instead of SD card. It works with just one simple change to the /boot/cmdline.txt file (set to use PARTUUID) as per my post here: https://github.com/rootzoll/raspiblitz/issues/430#issuecomment-473857217
I use the Crytocloak LightningShell case which does not have access to the SD card slot so it would be a PITA to use that (have to take apart the case).

edit: though a bit more changes needed to make Raspiblitz work from a USB drive. Eg. My boot drive is now /dev/sda and the blockchain DB and LND wallet are now on /dev/sdb1 and the scripts are not finding it (expecting it to be on sda1 or sda2). My new config is this:
admin@DietPi:~ $ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 1 28.7G 0 disk
├─sda1 8:1 1 43.9M 0 part /boot
└─sda2 8:2 1 28.6G 0 part /
sdb 8:16 0 931.5G 0 disk
├─sdb1 8:17 0 341.2G 0 part
├─sdb2 8:18 0 1000M 0 part
├─sdb3 8:19 0 588.4G 0 part
└─sdb4 8:20 0 999M 0 part

[openoms]

The only problem is my Raspiblitz LCD screen image is upside down.

This should solve it:
https://github.com/rootzoll/raspiblitz/blob/master/FAQ.md#can-i-flip-the-screen
Except you need to edit at /DietPi/config.txt, which overwrites the /boot/config.txt ong g restart. I will change the default setting on install, thanks for pointing it out.

Regarding the USB boot setup we need to extend the logic of 30addHDD.sh to look for the biggest partition on sdb as well. That would make it compatible with both the SD and USB booted systems. @fluidvoice would you be ok to test and make a PR for that? I can look into it in a couple of days also.

[fluidvoice]

The only problem is my Raspiblitz LCD screen image is upside down.

This should solve it:
https://github.com/rootzoll/raspiblitz/blob/master/FAQ.md#can-i-flip-the-screen
Except you need to edit at /DietPi/config.txt, which overwrites the /boot/config.txt ong g restart. I will change the default setting on install, thanks for pointing it out.

Regarding the USB boot setup we need to extend the logic of 30addHDD.sh to look for the biggest partition on sdb as well. That would make it compatible with both the SD and USB booted systems. @fluidvoice would you be ok to test and make a PR for that? I can look into it in a couple of days also.

Thanks for the reply/fix.
Yeah will look into it. Services are starting.

[fluidvoice]

The only problem is my Raspiblitz LCD screen image is upside down.

This should solve it:
https://github.com/rootzoll/raspiblitz/blob/master/FAQ.md#can-i-flip-the-screen
Except you need to edit at /DietPi/config.txt, which overwrites the /boot/config.txt ong g restart. I will change the default setting on install, thanks for pointing it out.

Fixed. The problem was /DietPi/config.txt was missing the rotate clause:
dtoverlay=tft35a
was changed to...
dtoverlay=tft35a:rotate=270
now the LCD displays correctly

[fluidvoice]

Regarding enabling WiFi on first boot.
there is this:

https://dietpi.com/phpbb/viewtopic.php?t=4402#p13840

you are right that the WiFi settings within dietpi.txt are only applied on first run setup.
They are then added to /etc/network/interfaces, thus this is also the file you need to edit after first boot.

What I found on my Raspi (after enabling WiFi via running dietpi-config) that the /etc/wpa_supplicant/wpa_supplicant.conf file contained my login info so maybe setting this will do it (need to test):

Edit /etc/wpa_supplicant/wpa_supplicant.conf (change country to the country you are in GB, US, etc.)

country=US
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
network={
    ssid="Your SSID"
    psk="YourWPAPassword"
    key_mgmt=WPA-PSK
}

Also might need to add the line
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
To either the /etc/network/interfaces line in the wlan0 section (look for the entry for your wlan0)

[openoms]

The wpa_supplicant.conf is the way to set wifi up on Raspbian.

For DietPi see: https://dietpi.com/phpbb/viewtopic.php?f=8&t=9#p9

Optional (Wifi):
Pre-configure Wifi Details for DietPi

Goto my computer, select the SD card and open it.
Locate the file called dietpi.txt and open it with wordpad.
Set AUTO_SETUP_NET_WIFI_ENABLED=1
DietPi_v6.15 and lower images:
    Enter your ssid AUTO_SETUP_NET_WIFI_SSID=MySSID and AUTO_SETUP_NET_WIFI_KEY=MyWifiKey (both are case sensitive).
DietPi_v6.16 and higher images:
    Open dietpi-wifi.txt and open it with wordpad
    Change aWIFI_SSID[0]="MySSID" and aWIFI_KEY[0]="MyWifiKey"
Save chanages to edited files
Plug the Wifi adapter into your device, before turning it on.

[fluidvoice]

The wpa_supplicant.conf is the way to set wifi up on Raspbian.

For DietPi see: https://dietpi.com/phpbb/viewtopic.php?f=8&t=9#p9

Optional (Wifi):
Pre-configure Wifi Details for DietPi

Goto my computer, select the SD card and open it.
Locate the file called dietpi.txt and open it with wordpad.
Set AUTO_SETUP_NET_WIFI_ENABLED=1
DietPi_v6.15 and lower images:
    Enter your ssid AUTO_SETUP_NET_WIFI_SSID=MySSID and AUTO_SETUP_NET_WIFI_KEY=MyWifiKey (both are case sensitive).
DietPi_v6.16 and higher images:
    Open dietpi-wifi.txt and open it with wordpad
    Change aWIFI_SSID[0]="MySSID" and aWIFI_KEY[0]="MyWifiKey"
Save chanages to edited files
Plug the Wifi adapter into your device, before turning it on.

@openoms Possibly the dietpi-wifi.txt file will need this entry changed as well (default is WPA-PSK):

Available options: NONE (no key/open) | WPA-PSK | WEP | WPA-EAP (then use settings below)

aWIFI_KEYMGR[0]='WPA-PSK'

[fluidvoice]

Yes this worked. The install via WiFi automatically progressed with these changes. After first boot the dietpi-wifi.txt file was auto-removed so that config file only works on first boot.

Btw @openoms , the second time I tested this I used a big 64GB Samsung USB flash drive. There are a couple places where the bootup pauses for a god-aweful long time... it pauses a bit when auto-resizing the partition to max size (nice!) and then later for even longer when it's doing something unknown - no status is displayed. It looked like it was frozen and not doing anything but eventually it continued. Is there any way to show this output on the LCD screen during the initial install/upgrade process instead of just a white screen?

[openoms]

Yes this worked. The install via WiFi automatically progressed with these changes. After first boot the dietpi-wifi.txt file was auto-removed so that config file only works on first boot.

Great! Please see the intended behaviour of the dietpi.txt: https://github.com/MichaIng/DietPi/blob/master/dietpi.txt

IMPORTANT:
Modifications to /boot/dietpi.txt will not be preserved on reboot.
Please ensure you edit from the DietPi-RAMdisk location: /DietPi/dietpi.txt```

Btw @openoms , the second time I tested this I used a big 64GB Samsung USB flash drive. There are a couple places where the bootup pauses for a god-aweful long time... it pauses a bit when auto-resizing the partition to max size (nice!) and then later for even longer when it's doing something unknown - no status is displayed. It looked like it was frozen and not doing anything but eventually it continued. Is there any way to show this output on the LCD screen during the initial install/upgrade process instead of just a white screen?

Thanks for pointing out. Unfortunately I see no way to make the LCD show the output of the automated building process, because it needs a reboot before it works. To see what is happening you can do as described in the readme: https://github.com/rootzoll/raspiblitz/blob/dev/dietpi/RaspberryPi.md

To follow the logs during the automated building process login with root and press CTRL+C.
tail -n1000 -f /tmp/DietPi-Update/dietpi-update.log - follow the dietpi-update process
tail -n1000 -f /var/tmp/dietpi/logs/dietpi-automation_custom_script.log follow the output of the build_sdcard.sh

[fluidvoice]

no way to make the LCD show the (bootup) output

@openoms Not so sure. Though perhaps it's not simple. This post shows a lot of config details that looks like not rolled into the DietPi release yet...
https://github.com/MichaIng/DietPi/issues/2590#issuecomment-467189302

Btw, if that HDMI LCD you linked to above https://github.com/rootzoll/raspiblitz/issues/244#issuecomment-475311433 is used, then event the bootup process is displayed, correct?

[openoms]

Btw, if that HDMI LCD you linked to above #244 (comment) is used, then event the bootup process is displayed, correct?

yes, it is displayed, but you cannot read it until installing the driver and reboot. See the linked issue above.

[openoms]

@rootzoll I think this issue is best to be closed as it derailed towards a DietPi discussion anyway.
From my side the Rock64 is iced until at least their next (v3) version is out.
https://twitter.com/openoms/status/1111544436054478848

[rootzoll]

@openoms I renamed the issue to a DietPi discussion in general. There is no other issue covering this, so I keep it open - also because its an ongoing development.

[openoms]

As it looks I will look into trialling Armbian. They have ready made images for multiple boards as well and looks to be a cleaner base to build on.
@rootzoll see the comment here: https://github.com/rootzoll/raspiblitz/issues/474#issuecomment-479006912 Is there anything else you consider when choosing a platform for the RaspiBlitz? WWhat you think of the Armbian vs using the manufacturer provided images (Raspbian or even the DietPi ones)

[rootzoll]

@openoms as long as the OS is also running on raspberrys and support what we need to run the RaspiBlitz I am open and curious what you all think is giving us the most flexibility.

[fluidvoice]

As it looks I will look into trialling Armbian. They have ready made images for multiple boards as well and looks to be a cleaner base to build on.
@rootzoll see the comment here: #474 (comment) Is there anything else you consider when choosing a platform for the RaspiBlitz? WWhat you think of the Armbian vs using the manufacturer provided images (Raspbian or even the DietPi ones)

I agree. I think we should test/try building on top of Armbian. I think building on top of Debian base will prob be too much work - adding distro/release maintenance work we don't want to focus on. And we can leverage Armbian community for help and knowledge about what works/doesn't wrt other boards, etc.
I will try to run @openoms DietPi build script on top of Armbian and see if it works on the Pi3B+ and what script changes are needed.

[openoms]

I will try to run @openoms DietPi build script on top of Armbian and see if it works on the Pi3B+ and what script changes are needed.

Don`t try the DietPi instructions on Armbian, that is not how it works.
The buidl_sdcard.sh chooses to use the Raspbian or DietPi instructions according to the hostname.
Also there is no premade Armbian build for the RPi, because of the closed source part of the Pi.

I think for the Pi we should stick to the Raspbian as that is the best managed distro and for other SBC-s we should use the most often and recently updated manufacturer build.

See my answer here: https://github.com/rootzoll/raspiblitz/issues/474#issuecomment-479387848

My conclusion is:

• so far we got a proof of concept of the RaspiBlitz system working reliably on other SBC-s and can be compatible with updates.
• it is far from being possible to provide a platform which can run easily on different boards without serious security trade-offs
• if we are testing other SBC-s a best base distro should be picked individually for every board according to what is updated the most frequently and reliably.
• this is the limitation of Linux on Arm, but we will continue to work with that given the price and form factor is unmatched in Intel based systems.

A minimal Debian or Ubuntu base is usually available like this one: https://wiki.odroid.com/odroid-xu4/os_images/linux/ubuntu_4.14/ubuntu_4.14 . (Armbian is built on the same kernel, bu t I don`t really see the advantage of not using the build provided and updated by the board manufacturer)

If you want to test building on other repo-s than it is probably the best to try to change the hostname to Raspbian before running the build_sdcard.sh because in most cases the directory architecture will be the same as in Raspbian.
Also make the user pi, if it would not exist already.

Will link my experimental repo once have more on this.

[fluidvoice]

I think for the Pi we should stick to the Raspbian as that is the best managed distro and for other SBC-s we should use the most often and recently updated manufacturer build.

Yeah I forgot about the closed source part of Raspbian. Thinking on it a bit I started thinking about all the little tweaks in Raspbian which are hardware specific that I'm sure don't exist in other distros. Things like startup overlays for enabling things on the GPIO pins and other headers. Extended functionality such as intelligent on/off switch shutdown, etc.

[gijswijs]

Not sure if this is the right thread, but the is there a possibility of using the raspiblits sh scripts on a intel based (mini) pc with Ubuntu?

[fluidvoice]

Not sure if this is the right thread, but the is there a possibility of using the raspiblits sh scripts on a intel based (mini) pc with Ubuntu?

I'm planning on testing/working-on this but have not started yet.
@openoms created a distro branch here on Github to track progress, testing, etc. of this:
https://github.com/openoms/raspiblitz/tree/X86_64
You're quite welcome to participate. Which mini-pc do you have or wanting to try?

[openoms]

@gijswijs excellent idea, please join in with the testing. I've just received my Intel Atom based mini PC (AtomicPi) and ready for testing in a couple of days. There is a branch and issue started for the x86 support: https://github.com/openoms/raspiblitz/issues/46
So far only with Bitcoin and LND working. Will need to insert the logic to correct every platform sensitive part and update to the new 1.2 version.
Aiming to support VirtualBox as well to aid testing or just to be able to try the RaspiBlitz on a PC before buying any specific hardware.

Starting with a most basic Ubuntu image is the best choice I think. Many SBC-s come with Ubuntu as the default image, so it will be well tested.

[gijswijs]

@openoms I'd love to help with testing. I'll receive my Partaker B13 i7 within 7 days, if all goes well.

[openoms]

Tried my Rock64 again with a new kernel version updated in Armbian.
Errors persist: https://github.com/openoms/raspiblitz/issues/23#issuecomment-497653174

[openoms]

I have pivoted to Armbian because of better support and more security focus.
Closing this, but panning to continue building to other SBC-s and distros.

Check the updates here: https://github.com/rootzoll/raspiblitz/tree/master/alternative.platforms
and the issue here: https://github.com/rootzoll/raspiblitz/issues/1164