It's good to go. Many thanks
1 Like
thanks to the folks at dietpi ... next build has an (initial)
- debian chroot 'bullseye' service...
- starts an ssh server on port 223
- password is 'dietpi'
for-example
ssh root@10.2.3.1 -p 223
root@10.2.3.1's password:
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
(debchroot)root@rpi-dca6325631:~# grep '^ID' /etc/os-release
ID=debian
(debchroot)root@rpi-dca6325631:~# apt-get upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
libsasl2-2 libsasl2-modules-db libssl1.1 openssl
4 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 2392 kB of archives.
After this operation, 12.3 kB of additional disk space will be used.
Do you want to continue? [Y/n] Y
Get:1 https://deb.debian.org/debian-security bullseye-security/main arm64 libsasl2-modules-db arm64 2.1.27+dfsg-2.1+deb11u1 [69.4 kB]
Get:2 https://deb.debian.org/debian-security bullseye-security/main arm64 libsasl2-2 arm64 2.1.27+dfsg-2.1+deb11u1 [105 kB]
Get:3 https://archive.raspberrypi.org/debian bullseye/main arm64 libssl1.1 arm64 1.1.1k-1+deb11u1+rpt1 [1389 kB]
Get:4 https://archive.raspberrypi.org/debian bullseye/main arm64 openssl arm64 1.1.1k-1+deb11u1+rpt1 [828 kB]
Fetched 2392 kB in 4s (640 kB/s)
debconf: delaying package configuration, since apt-utils is not installed
(Reading database ... 18191 files and directories currently installed.)
Preparing to unpack .../libssl1.1_1.1.1k-1+deb11u1+rpt1_arm64.deb ...
Unpacking libssl1.1:arm64 (1.1.1k-1+deb11u1+rpt1) over (1.1.1k-1+deb11u1) ...
Setting up libssl1.1:arm64 (1.1.1k-1+deb11u1+rpt1) ...
(Reading database ... 18191 files and directories currently installed.)
Preparing to unpack .../libsasl2-modules-db_2.1.27+dfsg-2.1+deb11u1_arm64.deb ...
Unpacking libsasl2-modules-db:arm64 (2.1.27+dfsg-2.1+deb11u1) over (2.1.27+dfsg-2.1) ...
Preparing to unpack .../libsasl2-2_2.1.27+dfsg-2.1+deb11u1_arm64.deb ...
Unpacking libsasl2-2:arm64 (2.1.27+dfsg-2.1+deb11u1) over (2.1.27+dfsg-2.1) ...
Preparing to unpack .../openssl_1.1.1k-1+deb11u1+rpt1_arm64.deb ...
Unpacking openssl (1.1.1k-1+deb11u1+rpt1) over (1.1.1k-1+deb11u1) ...
Setting up libsasl2-modules-db:arm64 (2.1.27+dfsg-2.1+deb11u1) ...
Setting up libsasl2-2:arm64 (2.1.27+dfsg-2.1+deb11u1) ...
Setting up openssl (1.1.1k-1+deb11u1+rpt1) ...
Processing triggers for libc-bin (2.31-13+rpt2+rpi1+deb11u2) ...
if you have a 'z' partition or your own disk changing;
CHROOT_BASEDIR="/z/chroot"
will make it persistent across installs
and if your really using it you'd also want;
ENABLEDSERVICES="bullseye"
fwiw... poked around a little but the 64bit debian/raspbian does not seem to have most things people would want this for...
(pihole, ubiquiticontroller, milkfish or whatever that thing is called, we don't have a gui yet for kodi and stuff or do we 
)
docker is likely the future rather than all these chroots but I like them for messing around...
And I thought I saw some familiar nickname in dietpi forum 
1 Like
i'd heard the distro mentioned several times... but never ran across it 'lots'...
after checking it out over the last two days, I'm really impressed with it's grass roots, minimal, approachable and practical philisophy...
it will definitely be my new 'go-to-full-distro', for anything that openwrt cannot handle... 
(wish they didn't 7zip their images tho' i didn't know the linux 'un7zip' command lol that ones on me I suppose)
1 Like
Do you think you can release a version with UEFI boot? So we can run it on Pimox7 (proxmox on Pi4)ā¦.
probably... but i'd need a cheat sheet and a sample img.gz to take check out how it works first...
thinking
hopefully it retains most of the /boot partition... I did have a quick go at it ages ago (just ubootuefi not the whole openwrt generate) and OTOH the structure was a teency bit different... but same partition/fs afair...
sysupgrade config.txt cmdline.txt stuff could be another (upgrade) deal breaker or complexity... but you could still get factories... if it is...
i'd probably favor a 'post' build 'UEFI Converter' script in this case (short term)... so it can be a general forum thing... and useful-to/used with any build including official ones...
i'm aware of another thread on the forum that does/documents something similar for 'arm fling?'
ok... that jogged memory...
CONFIG_EFI_ARMSTUB_DTB_LOADER=y
CONFIG_EFIVAR_FS=m
...
needs a buildroot... can't be done with imagebuilder / repacking 
(o' thats right that fling thing uses armvirt target inside vmdk... not sure what the story is with Pimox7)
nope: https://www.youtube.com/watch?v=aAGatdvnhcE
rootfs.tar.gz + host kernel? i have one of those you can try...
Hello everyone, newbie here with openwrt and rpi4ā¦
I ran rpi4_eeprom.sh update using root@ssh, and it downloaded the new eeprom and I rebooted the rpi 4.
It failed 3 times to boot, maybe because it failed to flash the new eeprom (the openwrt web interface was reachable but no internet connection and raspberry blinking red ), after 3 power off/on reboot it booted again with old eeprom, internet connection working again.
This is a known issue? I tried to boot without usb hub connected and without Ethernet cable, all without successā¦
Itās ok if I insert another micro sd card with raspbian, update the eeprom and put again the openwrt sd card? It will boot? Or it will check from a known eeprom hash somewhere in the boot?
Thank you
thanks for the report... unfortunately not enough information has been provided to be able to diagnose
- basically you ran the commands to update the eeprom
- it then didn't reboot 3 times
- it then booted fine after 3 power off and on
yeah... i suppose it's possible the file-layout/s was (and still could be) a little odd on /boot or some other complication... led flash patterns and time between reboots will give you clues there...
go for it, there is no exclusivity or eeprom requirements from the OS, other than general compatibility quirks, all the typical recovery and diagnostic methods documented (scroll down to Bootloader Recovery but if normal raspbian works you probably dont need it) by the vendor are available to you
if another use reports a problem with it, I will semi-disable (touch wall)... the 'bullseye' service is actually capable of generating update files to be placed on /boot now also...
1 Like
I donāt see anything special or with eeprom reference when I check the /boot folder.
Where should I look to see if the eeprom update is still pending to apply at each boot?
Edit - what I did was :
1 - eeprom update and reboot command
2 - checked that rpi has rebooted but no internet connection, web interface was working, checked the led light on raspberry and it was blinking red.
3- I removed the power, disconnected the usb hub and Ethernet cable and powered on again, it booted, red led flashed very fast and after that slow again, same behavior as step 2
4- 2 more power off and on and it booted without any problem, with old eeprom.
[root@dca632 / 37Ā°]# rpi4_eeprom.sh update
c1c19fd4ba380a3e349791089701082 [ <=> ] 17.52M 5.42MB/s in 3.2s
::: rpi4_eeprom.sh> download:c1c19fd4ba380a3e349791089701082cb51da39d[ok:0]
BOOTLOADER: [update-available:pieeprom-2022-01-25.bin] stable rpi4-rev1.1
CURRENT: Thu Apr 29 16:11:25 UTC 2021 (1619712685)
LATEST: Tue Jan 25 14:30:41 UTC 2022 (1643121041)
RELEASE: stable (/lib/firmware/raspberrypi/bootloader/stable)
VL805: [dedicated-EEPROM] [up-to-date] CURRENT:000138a1 LATEST:000138a1
*** INSTALLING EEPROM UPDATES ***
hook> ################# merging recommended...
hook> BOOT_UART=1 #present
hook> WAKE_ON_GPIO=0 #present
hook> POWER_OFF_ON_HALT=1 #present
hook> DHCP_TIMEOUT=45000 #present
hook> DHCP_REQ_TIMEOUT=4000 #present
hook> TFTP_FILE_TIMEOUT=30000 #present
hook> ENABLE_SELF_UPDATE=0 #present
hook> DISABLE_HDMI=0 #present
############################ generated-config
[all]
BOOT_UART=1
WAKE_ON_GPIO=0
POWER_OFF_ON_HALT=1
DHCP_TIMEOUT=45000
DHCP_REQ_TIMEOUT=4000
TFTP_FILE_TIMEOUT=30000
ENABLE_SELF_UPDATE=0
DISABLE_HDMI=0
BOOT_ORDER=0xf14
########################################################## EEPROM updates pending
Please reboot to apply the update
##########################################################
To cancel a pending update run "rpi-eeprom-update -r".
1643121041 6efe41bd "Tue Jan 25 14:30:41 UTC 2022"
backupsaved: /restorefiles/firmware/stable-20220227-0845-bootfiles
### [root@dca632 / 37Ā°]# rpi-eeprom-update -r
/boot [scrubbed /boot/pieeprom.upd /boot/pieeprom.sig /boot/recovery.bin]
#^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
you will not see the files listed above on partition 1 ( /boot/ )
if your rpi was vanilla old stock you may also see vl805 file/s there too...
root@dca632 /boot 51Ā°]# ls
COPYING.linux* config.txt* plog/
LICENCE.broadcom* distroconfig.txt* psave/
backup/ fixup4.dat* start4.elf*
bcm2711-rpi-4-b.dtb* fixup4cd.dat* start4cd.elf*
bcm2711-rpi-400.dtb* fixup4x.dat* start4x.elf*
bcm2711-rpi-cm4.dtb* kernel8.img*
cmdline.txt* overlays/
This is the files that I see on boot folder
Edited also last post with more details
1 Like
sound more like some other problem (does not sound eeprom update related)
- lots of green blinks then blinking red = initializing (do not remove power)
- blinking red without lots of green blinks could be eeprom update or just plain sd filesystem issues... (early boot stuff)
run
rpi4_eeprom.sh fetch
rpi-eeprom-update
( paste inside preformatted text tags )
```
your output here
```
[root@dca632 / 51Ā°]# rpi4_eeprom.sh fetch
c1c19fd4ba380a3e3 [ <=> ] 17.52M 9.24MB/s in 1.9s
::: rpi4_eeprom.sh> download:c1c19fd4ba380a3e349791089701082cb51da39d[ok:0]
[root@dca632 / 52Ā°]# rpi-eeprom-update
BOOTLOADER: [up-to-date] stable rpi4-rev1.1
CURRENT: Tue Jan 25 14:30:41 UTC 2022 (1643121041)
LATEST: Tue Jan 25 14:30:41 UTC 2022 (1643121041)
RELEASE: stable (/lib/firmware/raspberrypi/bootloader/stable)
VL805: [dedicated-EEPROM] [up-to-date] CURRENT:000138a1 LATEST:000138a1
[root@dca632 / 52Ā°]# vcgencmd version
Aug 19 2021 12:27:01
Copyright (c) 2012 Broadcom
version ef2c018dccdeb94b0376db62a2ea4c882f9b500d (clean) (release) (start)
1 Like
nope it's updated fine...
- looks like you might have been removing power a little too much...? and/or
- not allowing it to initialize fully? and/or
- some other sdcard / disk issue? ( which are sometimes caused by 'custom' fancy services in the shutdown phase )
- some intermittent network issue interpreted as failure to boot? and/or
- some issue on my end yet to be determined...
Good to know, maybe it was something like vpn connection handshake failingā¦I am using this rpi as WireGuard gateway.
Thank your for the fast support
I have the boot logs I think in the boot folderā¦
1 Like
https://wiki.debian.org/RaspberryPi4#Using_EFI_Firmware_and_the_regular_Debian_Installer
That is a rather neat approach, especially for more general purpose distributions (not using any RPi myself, so no personal exposure to any of this).
1 Like
is it possible to change the theme in your build ?
1 Like
The issues occurred again. Sadly I already did unplug/plug all USB connected to tpi but no luck there
1 Like