v6.0 | Recreate all images

[Fourdee]

v6.0 image notes:

• All images will be Debian Stretch (excluding Odroid's)
• All NanoPi official FriendlyARM based images, are running 4.x kernels
• All ARMbian based devices https://github.com/Fourdee/DietPi/issues/1537#issue-298337026

---

High priority devices:

• RPi Stretch
• Odroid C2 Jessie
• Odroid XU3/4/HC1 Jessie
• VMware Stretch
• Odroid C1 Jessie | Thanks @k-plan 👍
• VirtualBox Stretch | Thanks @MichaIng 👍
• ASUS TB Stretch
• Rock64 Stretch
• PineA64 Stretch
• Sparky SBC Stretch
• RPi Jessie (required for AmiBerry, and as a fallback for any Stretch related issues for our users)

Low priority devices:

• Native PC BIOS | now uses PREP https://github.com/Fourdee/DietPi/issues/1385#issuecomment-361006965
• Native PC EFI | https://github.com/Fourdee/DietPi/issues/1171#issuecomment-336522021

all ARMbian based devices. https://github.com/Fourdee/DietPi/issues/1537#issue-298337026
NanoPi:
[-] NanoPi Neo | ARMbian
[-] NanoPi Neo Air | ARMbian (https://github.com/Fourdee/DietPi/issues/1385#issuecomment-361003168)

• NanoPi Neo2 | Official FriendlyARM image
• NanoPi M1 | Official FriendlyARM image
• NanoPi M1+ | Official FriendlyARM image
• NanoPi M2 | Official FriendlyARM image
• NanoPi M3 | Official FriendlyARM image

Banana Pi: https://github.com/Fourdee/DietPi/issues/1537#issue-298337026
[-] BPi Pro | ARMbian
[-] BPi M2+| ARMbian

Orange Pi: https://github.com/Fourdee/DietPi/issues/1537#issue-298337026
[-] OPi PC | ARMbian
[-] OPi PC 2 | ARMbian
[-] OPi Prime | ARMbian
[-] OPi Win 🈴 https://github.com/Fourdee/DietPi/issues/1385#issuecomment-358002327 | ARMbian
[-] OPi One | ARMbian
[-] OPi Lite | ARMbian
[-] OPi Plus https://github.com/Fourdee/DietPi/issues/1385#issuecomment-358002327 | ARMbian
[-] OPi Zero | ARMbian
[-] OPi Zero 2+ ARMv7 | ARMbian
[-] OPi Zero 2+ ARMv8 | ARMbian

Other low priority:

• BBB | 4 installs (most likley me and @k-plan lol), now uses PREP
• Roseapple Pi | Lack hardware device to implement. now uses PREP

Specials:

• RPi ARMv7 Allo GUI (NB: will contain latest kernel via rpi-update to ensure allo overlay entries are upto date, held packages apt-mark hold raspberrypi-bootloader raspberrypi-kernel libraspberrypi-bin) | Will handle manually, further testing, after v6.0 release: https://github.com/Fourdee/DietPi/issues/1385#issuecomment-360993993
• Sparky SBC Allo GUI | Will handle manually, further testing, after v6.0 release: https://github.com/Fourdee/DietPi/issues/1385#issuecomment-360993993
• RPi AmiBerry https://github.com/Fourdee/DietPi/issues/1410#issuecomment-360883774 https://github.com/Fourdee/DietPi/issues/1410

[Fourdee]

Reference:

• https://github.com/Fourdee/DietPi/issues/1285
• https://github.com/Fourdee/DietPi/issues/1268
• https://github.com/Fourdee/DietPi/issues/1355

[Fourdee]

Must be done for each image, during PREP:

• 🈯️ Done via v6.0 patch: Manually check /etc/bash.bashrc and clean (eg: LANG= options if added)
• Manually delete outdated /lib/modules

[k-plan]

@Fourdee

Sorry, but I am really unsure, if it make sense, to help you building images from my site.

PREP is to new and there are surely several bits and bobs you will find out while building images. So fixes are a lot easier for you and mainly faster altogether.

[Fourdee]

ASUS TB: http://dlcdnet.asus.com/pub/ASUS/mb/Linux/Tinker_Board_2GB/20171115-tinker-board-linaro-stretch-alip-v2.0.4.zip?_ga=2.111431302.324915190.1515670093-379854191.1515670093

Issue:

• 🈴 ramdisk fail. /boot mounted after ramdisk service?!?!?!?
  -- 🈯️ RequiresMountsFor=/boot works, however, we must check for /boot mount, per device.
  -- 🈯️ disable /etc/fstab x-systemd.automount for /boot

root@DietPi:~# cat /var/tmp/dietpi/logs/dietpi-ramdisk.log
Thu 11 Jan 14:47:54 UTC 2018 | DietPi-Ramdisk: Starting
Thu 11 Jan 14:47:54 UTC 2018 | DietPi-Ramdisk: Completed
Thu 11 Jan 14:48:45 GMT 2018 | DietPi-Ramdisk: Stopping
Thu 11 Jan 14:48:45 GMT 2018 | DietPi-Ramdisk: Completed
/bin/bash: /boot/dietpi/dietpi-ramdisk: No such file or directory
root@DietPi:~# ls -lha /boot
total 7.3M
drwxr-xr-x  7 root root 1.0K Jan  1  1970 .
drwxr-xr-x 22 root root 4.0K Jan 11 14:47 ..
-rwxr-xr-x  1 root root 2.1K Jan 11 14:48 config.txt
drwxr-xr-x  5 root root 3.0K Jan 11 14:47 dietpi
-rwxr-xr-x  1 root root  10K Jan 10 13:18 dietpi.txt
drwxr-xr-x  2 root root  512 Nov 15 07:05 extlinux
drwxr-xr-x  2 root root  512 Jan 11 14:18 hdmi
-rwxr-xr-x  1 root root  304 Nov 15 07:05 hw_intf.conf
drwxr-xr-x  2 root root 1.0K Nov 15 07:05 overlays
-rwxr-xr-x  1 root root 6.0K Jan 11 14:47 README.md
-rwxr-xr-x  1 root root  64K Nov 15 07:05 rk3288-miniarm.dtb
drwxr-xr-x  2 root root  512 Jan 11 14:04 System Volume Information
-rwxr-xr-x  1 root root 7.2M Nov 15 07:05 zImage

Cant for life of me find out which package is for kernel/modules. Must be a non-std package, as, PREP uninstalls zImage. There is no package, /boot contents fine on 2nd run.

root@tinkerboard:~# dpkg-query -S /boot/rk3288-miniarm.dtb
dpkg-query: no path found matching pattern /boot/rk3288-miniarm.dtb
root@tinkerboard:~# dpkg-query -S /boot/zImage
dpkg-query: no path found matching pattern /boot/zImage

root@DietPi:~# poweroff
-bash: poweroff: command not found

[FAILED] DietPi-PREP_SYSTEM_FOR_DIETPI: G_AGA
[ INFO ] exit_code = 100
[ INFO ] VERSION:v. | HW_MODEL:100 | HW_ARCH:2 | DISTRO:4
[ INFO ] Log file contents:
Removing libwww-perl (6.15-1) ...
Removing libhttp-negotiate-perl (6.00-2) ...
Removing libfile-listing-perl (6.04-1) ...
Removing libwww-robotrules-perl (6.01-1) ...
Removing libnet-http-perl (6.12-1) ...
Removing libhtml-tree-perl (5.03-2) ...
Removing libhtml-parser-perl (3.72-3) ...
Removing libhtml-tagset-perl (3.20-3) ...
Removing libhttp-cookies-perl (6.01-1) ...
Removing libio-socket-ssl-perl (2.044-1) ...
Removing libnet-ssleay-perl (1.80-1) ...
Removing netbase (5.4) ...
Removing perl-openssl-defaults:armhf (3) ...
Removing python3 (3.5.3-1) ...
Removing dh-python (2.20170125) ...
Removing libhttp-message-perl (6.11-1) ...
Removing libencode-locale-perl (1.05-1) ...
Removing liburi-perl (1.71-1) ...
Removing libhttp-date-perl (6.02-1) ...
Removing libio-html-perl (1.001-1) ...
Removing liblwp-mediatypes-perl (6.02-1) ...
Removing libpython3-stdlib:armhf (3.5.3-1) ...
Removing python3.5 (3.5.3-1) ...
Removing libpython3.5-stdlib:armhf (3.5.3-1) ...
Removing libmpdec2:armhf (2.4.2-1) ...
Removing python3-minimal (3.5.3-1) ...
Removing python3.5-minimal (3.5.3-1) ...
Removing libpython3.5-minimal:armhf (3.5.3-1) ...
Removing libtimedate-perl (2.3000-2) ...
Removing mime-support (3.60) ...
Removing perl (5.24.1-3+deb9u2) ...
Removing libperl5.24:armhf (5.24.1-3+deb9u2) ...
Removing libgdbm3:armhf (1.8.3-14) ...
Removing perl-modules-5.24 (5.24.1-3+deb9u2) ...
dpkg: libip4tc0:armhf: dependency problems, but removing anyway as you requested:
 systemd depends on libip4tc0 (>= 1.6.0+snapshot20161117).

Removing libip4tc0:armhf (1.6.0+snapshot20161117-6) ...
dpkg: libseccomp2:armhf: dependency problems, but removing anyway as you requested:
 systemd depends on libseccomp2 (>= 2.3.1); however:
  Package libseccomp2:armhf is to be removed.

Removing libseccomp2:armhf (2.3.1-2.1) ...
dpkg: libcryptsetup4:armhf: dependency problems, but removing anyway as you requested:
 systemd depends on libcryptsetup4 (>= 2:1.4.3).

Removing libcryptsetup4:armhf (2:1.7.3-4) ...
Errors were encountered while processing:
 systemd

---

Rock64:

[FAILED] DietPi-PREP_SYSTEM_FOR_DIETPI: grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=arch_grub --recheck
[ INFO ] exit_code = 127
[ INFO ] VERSION:v6.-1 | HW_MODEL:43 | HW_ARCH:3 | DISTRO:4
[ INFO ] Log file contents:
./dietpi-globals: line 546: grub-install: command not found

---

Pine:

• 🈴 dietpi-led_control 1 not terminating during boot on 1st run, processing animation stuck?
  fine run manually:
  fine after subsequent boots

root@DietPi:~# /DietPi/dietpi/func/dietpi-led_control 1
[  OK  ] Root access verified.
ls: cannot access '/sys/class/leds': No such file or directory
[FAILED] Unable to find any supported LEDS on this device.

[MichaIng]

@Fourdee
If you find time, could you check if the packages init and/or systemd-sysv were & are installed on ASUS TB and if yes, if they come from Debian repo or are somehow overwritten by some Asus repo? I wonder, as init is an essential package, which should be on every image reinstalled, cannot be autoremoved and depends on (either the old sysvinit or) systemd.

If somehow init is not preinstalled, then we should set systemd-sysv as our dependency, as it is direct dependant of systemd and provides the replacement links for it's core commands, such as reboot, shutdown, halt, init: https://packages.debian.org/en/stretch/systemd-sysv

€: Ah you just found that also 😆. So init seems to be not preinstalled on ASUS TB base image?

[Fourdee]

@MichaIng
Just finished PREP:

root@DietPi:~# dpkg --get-selections | grep ^init
init-system-helpers                             install
initramfs-tools                                 install
initramfs-tools-core                            install
initscripts                                     install

###
root@DietPi:~# dpkg --get-selections | grep ^sys
systemd                                         install
systemd-sysv                                    install
sysv-rc                                         install
sysvinit-utils                                  install

---

Pre-Prep:

root@tinkerboard:~# dpkg --get-selections | grep ^init
init-system-helpers                             install
initramfs-tools                                 install
initramfs-tools-core                            install
initscripts                                     install
root@tinkerboard:~# dpkg --get-selections | grep ^sys
system-tools-backends                           install
systemd                                         install
systemd-sysv                                    install
sysv-rc                                         install
sysvinit-utils                                  install

[MichaIng]

@k-plan
Okay, no init there: https://packages.debian.org/en/stretch/init
Jep, then we should just always install systemd-sysv, which also ensures base systemd. We could then actually also purge init, which is just a meta package to ensure one of systemd or sysvinit is installed.

[k-plan]

I don't want to disturb your image creation process.
But I want to better mention this here.
I have a quick look into your fresh build images. Nice work. 👍
Think, we have to do some housekeeping after this (delete some unwanted/useless/violate files).

Suggestion:

• build all new images now until it is finshed
• then we can delete all unwanted/useless/violate files altogether at once (mount and delete/edit)
• drawback: must create a new hash file 😢 , so I would suggest not to create a hash.txt before last finalize (woebegone experience)

But this is only fine tuning. We can as well leave it as it is.

[MichaIng]

@Fourdee
Edit: Just have a look into the PR 😉.

@k-plan
As we currently use version string 6.-1, we could do final cleanup by 6.0 update

[MichaIng]

Accidentally merged commit into existing PR branch: https://github.com/Fourdee/DietPi/pull/1386

• After investigation, (main) reason for stuck process animation was, that /var/run seemed to be cleared ~2 times during boot. Thus no pid information remained => nobody can kill the animation.
• Added file check into animation script, now breaks if file does not exists anymore, never faced the issue anymore so far.
• Proactive: Sadly it seems to be impossible that user dietpi removes a file from user root no matter what permissions he has on the file or the parent directory: Both 777 does not work, also not on own created directory within /. So for now I don't see any possibility where a non-root user can ever stop the animation (besides sudo, that of course works!), if started by root. Thus we still need to ensure, that every animation is handled well and in the end the same script always does some error handling in case, to clean animation.

[MichaIng]

@Fourdee
While creating VirtualBox image, I recognized following warning during APT installations when doing via dropbear (actually already face this since I can think):

dropbear: WARNING: Invalid authorized_keys file, remote unlocking of cryptroot via SSH won't work!

Made some research and found, that dropbear-initramfs causes the error, which is only necessary to unlock full encrypted drives and expects the key file for this: https://packages.debian.org/stretch/dropbear-initramfs

Instead of installing dropbear (dummy package including dropbear-initramfs), for images we just need dropbear-run: https://packages.debian.org/de/stretch/dropbear-run
They made the separation some time ago, as users faced problem with the fix initramfs integration.
Everyone who uses encrypted drives will anyway configure the system + SSH client to use key authentication and stuff and then in case need to install the additional package.

=> https://github.com/Fourdee/DietPi/pull/1392

[Fourdee]

NanoPi Neo (default kernel):

We'll need to use mainline kernel to create Stretch images.

[Fourdee]

Considering:
If we can automate the detection of current kernel packages in PREP, I'll create only the popular OPi/BPi/NanoPi images, the less used ones can be user created with PREP.

ref: https://github.com/Fourdee/DietPi/issues/1281#issuecomment-350585096

[Fourdee]

🈯️ Fourdee@9660e1d ARMbian PREP images failing to boot:
-- /boot/dtb missing

Retry time exceeded; starting again
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
BOOTP broadcast 4
BOOTP broadcast 5
DHCP client bound to address 192.168.0.30 (4270 ms)
Using ethernet@1c30000 device
TFTP from server 0.0.0.0; our IP address is 192.168.0.30; sending through gateway 192.168.0.1
Filename 'boot.scr.uimg'.
Load address: 0x42000000
Loading: T T T T T T T T T
Retry count exceeded; starting again
=>

[Fourdee]

NanoPi NEO2:
-- Could be due to my FX6300 (possible HW issue)...

qemu: uncaught target signal 11 (Segmentation fault) - core dumped
                                                                  /root/armbian/build/lib/debootstrap-ng.sh: line 204: 78878 Segmentation fault      LC_ALL=C LANG=C chroot $SDCARD /bin/bash -c "DEBIAN_FRONTEND=noninteractive apt-get -y -q $apt_extra $apt_extra_progress --no-install-recommends install $PACKAGE_LIST"
                                                                            [ error ] ERROR in function create_rootfs_cache [ debootstrap-ng.sh:208 ]
                                                                     [ error ] Installation of Armbian packages failed
                                       [ o.k. ] Process terminated
                                                                   [ error ] ERROR in function unmount_on_exit [ image-helpers.sh:59 ]
                                                      [ error ] debootstrap-ng was interrupted
               [ o.k. ] Process terminated
                                           root@vmcross16:~/armbian/build#

[Fourdee]

@MichaIng

Do you think that would be possible? I am not too deep in in early boot scripts, in case including fs changes.

We cant place the extra partition after the rootFS partition, would prevent expansion of rootFS.

We could try shifting the rootFS partition to P2, then create a 64MB FAT16/32 P1 at start after 4MiB for ARMbian. We'd need to check all the kernel command line options in /boot, ensuring UUID is used etc.

• Move all boot files to P1
• Then edit /etc/fstab with /boot mount

Lengthy/tedious process if applied to all ARMbian images, and, that is assuming its successful.

[Fourdee]

@k-plan

Try more then once and ended up with Paragon ExtFS for Windows and NTFS/ExtFS for Mac.

If these options work (i've downloaded Paragon to test)? We could provide this information in 1st run guide for ARMbian images.

[MichaIng]

@Fourdee
And if we, based on HW_MODEL/2nd partition size/content(dietpi.txt), just remove the tiny 2nd partition before first run resizing rootfs? A tiny free space would not hurt. I am afraid of generally changing all the partitions for other devices, if I understand your idea right, as this was/is always a bid fragile.

[Fourdee]

@MichaIng

just remove the tiny 2nd partition before first run resizing rootfs?

Could work 👍

• prior to rootFS resize
• mount p1/p2
• move dietpi.txt to /boot
• unmount p1/p2
• del p2
• rootfs resize

---

But honestly, I can't comprehend why MS, with all their billions of $ and many thousands of staff, simply can't support EXT4 in their OS. Drives me up the wall lol.

[Fourdee]

@zador-blood-stained @ThomasKaiser @igorpecovnik

Question:

Are the following options, fully supported in ARMbian build tools?

• BOOTFS_TYPE
• BOOTSIZE

https://github.com/armbian/build/blob/e546ac684d0fe0c0f47ab032aa867062e37da4e6/lib/configuration.sh#L224-L225

Reason for query:

• No mention of BOOTSIZE in the online doc
• Its been mentioned in the past as a depreciated feature: (armbian/build@e3c0988#diff-0a30c16b7ceda04b74ad5a1dc0a9e2a3R57) (lib/configuration.sh | BOOTSIZE= has no effect armbian/build#660 (comment))

[zador-blood-stained]

Are the following options, fully supported in ARMbian build tools?
BOOTFS_TYPE
BOOTSIZE

No, and by that answer I mean that it may work (or rather should work) in most cases, but

• FAT /boot partition is not tested in general so it may be broken on some platforms
• FAT /boot partition support was not added to some newer platforms so it may not be supported on all boards
• there are known issues with the nand-sata-install script on multi-partition images

so it is a semi-supported build script option that may not work since currently we favor single-partition images (except for experimental OMV builds).

Its been mentioned in the past as a depreciated feature

FAT boot partition support in general and using BOOTSIZE to switch to a FAT partition is deprecated, but except for mentioned bugs and limitations building 2-partition images is supported.

[MichaIng]

@Fourdee @zador-blood-stained
FAT partition support should be no problem, as DietPi by default adds dosfstools package. So we should be able to create the tiny FAT partition after full distro/package upgrade was done during preparation script, and then it should be able to mount during first run. All kernel/boot files can/should stay on 1st root partition to not mess something up there.

[zador-blood-stained]

FAT partition support should be no problem, as DietPi by default adds dosfstools package.

True unless you are talking about the first partition on the system device mounted to /boot.

This was discussed already, but there are several problems:

• dpkg breaks when updating files on FAT filesystem so without special workarounds the system will break on the kernel upgrade

• you can't make symlinks on FAT so again the system will break after the kernel upgrade without workarounds for ln -s call in the kernel upgrade logic

• u-boot boot script loading sequence and the boot script itself should be able to work for loading files from FAT as older u-boot has different commands - fatload and ext2load/ext4load

[Fourdee]

Notes:
Native PC BIOS, 1st attempt failed. invalid filesystem after image ready (faulty SSD 😢 ).

• Odroid EMMC + USB reader = debian
• lexar 16GB install
• Read lexar

[k-plan]

@Fourdee

If these options work (i've downloaded Paragon to test)? We could provide this information in 1st run guide for ARMbian images.

Quick check on Windows 7 running native on hardware.

💯 fail

• Paragon can mount, read and write ext4 partitions on SD card, but to unmount you need administrator rights! 👎

• AND Paragon extfsservice.exe block access for image writing software, eg for Rufus, to format and write SD cards, if Paragon is installed. No chance to stop this services without administrator rights and windows taskmanager! 👎

Forget it - uninstalled - finish

[Fourdee]

@k-plan

@MichaIng method (extra 1MB fat partition) is the solution here, however, if i'am being honest, time limited at the moment. It may be after v6.0 is released that we can achieve it (all images need to be re-configured and script changes etc)

notes:

if [ partitionlabel = 'dietpi_extra' ]; then

del part


fi

expand

[Fourdee]

Sparky Allo install, hangs system. Hardware issue?:

• squeezelite 100% cpu usage, SIGKILL no effect.

Setting up x11-common (1:7.7+19) ...
update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults

[ 1076.024195] read phy reg-5
[ 1200.875145] INFO: task kworker/1:2:102 blocked for more than 120 seconds.
[ 1200.875155] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1200.875162] kworker/1:2     D c07bfe48     0   102      2 0x00000000
[ 1200.875187] Workqueue: events_power_efficient close_delayed_work
[ 1200.875213] [<c07bfe48>] (__schedule+0x390/0x7cc) from [<c07c065c>] (schedule_preempt_disabled+0x14/0x20)
[ 1200.884908] [<c07c065c>] (schedule_preempt_disabled+0x14/0x20) from [<c07bef44>] (__mutex_lock_slowpath+0x174/0x368)
[ 1200.895631] [<c07bef44>] (__mutex_lock_slowpath+0x174/0x368) from [<c07bf144>] (mutex_lock+0xc/0x24)
[ 1200.904913] [<c07bf144>] (mutex_lock+0xc/0x24) from [<c056ebdc>] (close_delayed_work+0x20/0xc8)
[ 1200.913756] [<c056ebdc>] (close_delayed_work+0x20/0xc8) from [<c00470dc>] (process_one_work+0x134/0x414)
[ 1200.923380] [<c00470dc>] (process_one_work+0x134/0x414) from [<c00477b8>] (worker_thread+0x138/0x37c)
[ 1200.932730] [<c00477b8>] (worker_thread+0x138/0x37c) from [<c004d394>] (kthread+0xa4/0xb0)
[ 1200.941113] [<c004d394>] (kthread+0xa4/0xb0) from [<c000f3d8>] (ret_from_fork+0x14/0x3c)
[ 1210.845796] read phy reg-4
[ 1210.846145] read phy reg-0
[ 1210.846487] read phy reg-5

---

Need to update DB user in GUI code.

(2/2) QueryException
SQLSTATE[HY000] [1698] Access denied for user 'root'@'localhost' (SQL: select * from `users` where `email` = [email protected] limit 1)

[Fourdee]

AmiBerry image test did not install, automation issue? Fixed with Fourdee@36b5934

Fails to install due to connection test name or service not known, fine after running it again. Most likely DHCP/DNS not ready in time, may need to increase default wait time for net boot, or, allow G_CHECK_URL to re-run 2/3 times with 1/2 second delay?

[Fourdee]

AlloGUI images notes:
Need to test Allo GUI indepth before release of updated v6.0 image (soundcard selection etc). v159 image will still function in the mean time, so no rush.

---

Sparky only, RPi fine, same web interface code and .bashrc.

CPU Temperature :Bash: G_OBTAIN_CPU_TEMP: Command Not Found 'C

[Fourdee]

NanoPi Neo Air WiFi (and possibily all ARMbian devices with onboard WiFi)

[  118.030568] brcmfmac: brcmf_fw_map_chip_to_name: using brcm/brcmfmac43430a0-sdio.bin for chip 0x00a9a6(43430) rev 0x000000
[  118.033560] brcmfmac mmc2:0001:1: Direct firmware load for brcm/brcmfmac43430a0-sdio.bin failed with error -2
[  118.033580] brcmfmac mmc2:0001:1: Falling back to user helper

root@DietPi:~# ls -lha /lib/firmware/brcm/brcmfmac43430a0-sdio.bin
ls: cannot access '/lib/firmware/brcm/brcmfmac43430a0-sdio.bin': No such file or directory

Contained in armbian-firmware

		#	Check for existing firmware
		#	- ARMbian
		# AUTO_DETECT_FIRMWARE_PKG=$(dpkg --get-selections | grep '^armbian-firmware' | awk '{print $1}')
		# if [ -n "$AUTO_DETECT_FIRMWARE_PKG" ]; then

			# G_AGI $AUTO_DETECT_FIRMWARE_PKG

		# fi
			# Unpacking armbian-firmware (5.35) ...
			# dpkg: error processing archive /var/cache/apt/archives/armbian-firmware_5.35_all      .deb (--unpack):
			# trying to overwrite '/lib/firmware/rt2870.bin', which is also in package firmwa      re-misc-nonfree 20161130-3
			# dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)

---

Options:

• Disable firmware-* for all ARMbian devices (most likely will break all support for USB based WiFi chipsets), allowing install of armbian-firmware?
• Manually extract (all or only required files from) armbian-firmware (eg: via deb) to images that are WiFi only devices?
• Drop support for WiFi only ARMbian devices?

For now (to ensure v6.0 release), i've copied the required brcm firmware to image. But i'll need to revisit this for devices with onboard WiFi (before v6.0 release if possible).

---

Verify:

• 🈯️ OPi Zero2 +, needs bcrm firmware. Manual copy of bcrm firmware as per NanoPi Neo Air for now. Done.
• 🈯️ OPi lite | Fine, not required.

[Fourdee]

Ok Native PC BIOS:
Tried several attempts at this. Unsuccessful in terms of available USB drives failing to boot (even with Debian simply installed and boot enabled in MBR etc). PC/USB issue/incompatibility, unsure, needs further investigation.
PREP script is fine.

I'll need to revisit this, however, for now, i'll do a guide that references installing Debian, then forward user to running PREP.

[k-plan]

@Fourdee

only remark:

method (extra 1MB fat partition) is the solution here, however, if i'am being honest, time limited at the moment. It may be after v6.0 is released that we can achieve it (all images need to be re-configured and script changes etc)

YES! 👍

On last image DietPi_OPiZeroH2-ARMv7-Stretch there no way to configure first config in dietpi.txt
So I can't connect with Wi-Fi.

https://github.com/Fourdee/DietPi/issues/1427