Dietpi: Testing on Raspberry Pi 400. Update won't proceed via WiFi even though WiFi has been set up

[retrofriendsdotcom]

Creating a bug report/issue

Kudos to the fact that this is the only current Amiberry distro/image that works on the new rpi400 AFAIK. However, small bug the DietPi-Login can have problems waiting for network connection. It would seem that if you are using WiFi and not ethernet, the time it takes to wait for ethernet DHCP, then wait for WiFi DHCP is not quite long enough, and the DietPi-Login fails. It must be close timing because my first lab attempt yesterday did not have this issue, but my second did. Or perhaps between yesterday and today a new version came out with the bug (I re-downloaded it for the second lab today). The solution was to disable the Ethernet adapter. Upon reboot, the DHCP process was accelerated by skipping DHCP on Ethernet. 13 mins later I had Amiberry.

Thanks for a great product.

Required Information

• DietPi version | cat /boot/dietpi/.version
  6.32.2
• Distro version | echo $G_DISTRO_NAME or cat /etc/debian_version
  Raspbian Lite with Amiberry
• Kernel version | uname -a
  5.4.51-v71+ #1333
• SBC model | echo $G_HW_MODEL_NAME or (EG: RPi3)
  Raspi400
• Power supply used | (EG: 5V 1A RAVpower)
  Raspi400 official
• SDcard used | (EG: SanDisk ultra)
  Patriot 16g

Additional Information (if applicable)

• Software title | (EG: Nextcloud)
• Was the software title installed freshly or updated/migrated?
• Can this issue be replicated on a fresh installation of DietPi?
  
• Bug report ID | echo $G_HW_UUID

Steps to reproduce

1. ...
2. ...

Expected behaviour

• ...

Actual behaviour

• ...

Extra details

• ...

[Joulinar]

Hi,

many thanks for your message. Basically the network check is waiting for 10sec on a valid connection. However you could set it to infinite wait. Means it will wait until a network connection was established, doesn't matter how long it will take.

[MichaIng]

Also note that, as long as you don't use WiFi as Hotspot, having Ethernet and WiFi enabled both does currently not work very well the way dietpi-config configures it. Still an open task that is in the pipeline but I don't find the spare time weekend to finish it 😄.

I think @Joulinar helped on writing a great guide in the forum for setting up Ethernet with WiFi as automated fallback, if I remember right, using ifplugd.

Until then, I suggest to use only either Ethernet or WiFi and disable the other one. And yes, if there is any chance to use a static IP instead of DHCP (most routers allow it, even within the DHCP range, at least when concurrently assigning an IP reservation), then this should be preferred anyway. It does not only speed up network (re)connection but also saves a little background processing and RAM usage for the DHCP client.

And many thanks for your feedback about Amiberry on RPi 400. Great to hear that it works well. I mean it's practically an RPi4 as well but good to have this verified.

[Joulinar]

yep we created a tutorial out of it https://dietpi.com/phpbb/viewtopic.php?f=15&t=7835

[retrofriendsdotcom]

Thanks for the quick response. DietPie is the only distro with Amiberry
that seems to work with the RPi400 out of the box (if using Ethernet). It
should be noted that other distros of Amiberry need modifications for the
RPi400. RetroPie needs tweaks, and I couln't even get Amibian to boot.
FS-UAE works okay if you want to run it from the RPi desktop, but most want
direct-to-emulator booting. I have successfully compiled Amiberry directly
on Raspberry Pi OS lite, but most people can't/aren't gonna go that way.

I will soon be publishing a video tutorial of the RPi400 and
DietPi+Amiberry on my youtube channel. I will link your site in the
description, of course. I alread did a video about the desktop/fs-uae I
mentioned above. My channel:
www.youtube.com/c/retrofriends

On Sun, Dec 6, 2020, 3:03 PM MichaIng [e-mail] wrote:

Also note that, as long as you don't use WiFi as Hotspot, having Ethernet
and WiFi enabled both does currently not work very well the way
dietpi-config configures it. Still an open task that is in the pipeline
but I don't find the spare time weekend to finish it 😄.

I think @Joulinar https://github.com/Joulinar helped on writing a great
guide in the forum for setting up Ethernet with WiFi as automated fallback,
if I remember right, using ifplugd.

Until then, I suggest to use only either Ethernet or WiFi and disable the
other one. And yes, if there is any chance to use a static IP instead of
DHCP (most routers allow it, even within the DHCP range, at least when
concurrently assigning an IP reservation), then this should be preferred
anyway. It does not only speed up network (re)connection but also saves a
little background processing and RAM usage for the DHCP client.

And many thanks for your feedback about Amiberry on RPi 400. Great to hear
that it works well. I mean it's practically an RPi4 as well but good to
have this verified.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/MichaIng/DietPi/issues/3955#issuecomment-739580256,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ASAWLO5DGKXW5GVQWYBEUHTSTQESJANCNFSM4UPUY2ZQ
.

[MichaIng]

That is awesome. Do we have permissions to embed your YouTube video into our (new) documentation page? https://dietpi.com/docs/software/gaming/#amiberry

Btw, if I am not totally mistaken, since RPi 400 has a different revision code identifier that was implemented recently to dev branch but not yet released: https://github.com/MichaIng/DietPi/commit/182f3ae5969829ee1d51f5141184f78e2612cd3b
So on RPi 400 is currently identified as "unknown" RPi model and hence the RPi 1 build (most compatible) of Amiberry is installed. It works due to the included SDL2 builds, but you might get a better experience with v6.34 and the RPi 4 build of Amiberry 😃. But not sure about the details, the differences are performance related an probably the RPi 4(00) is strong enough so that one does not recognise.

[retrofriendsdotcom]

Of course!

I haven't tested Frontier Elite II on it yet (I was assuming it would
work). If that runs good, the current distro should be good for 99% of
applications.

On Mon, Dec 7, 2020, 3:19 AM MichaIng [e-mail] wrote:

That is awesome. Do we have permissions to embed your YouTube video into
our (new) documentation page?
https://dietpi.com/docs/software/gaming/#amiberry

Btw, if I am not totally mistaken, since RPi 400 has a different revision
code identifier that was implemented recently to dev branch but not yet
released: 182f3ae
https://github.com/MichaIng/DietPi/commit/182f3ae5969829ee1d51f5141184f78e2612cd3b
So on RPi 400 is currently identified as "unknown" RPi model and hence the
RPi 1 build (most compatible) of Amiberry is installed. It works due to the
included SDL2 builds, but you might get a better experience with v6.34 and
the RPi 4 build of Amiberry 😃. But not sure about the details, the
differences are performance related an probably the RPi 4(00) is strong
enough so that one does not recognise.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/MichaIng/DietPi/issues/3955#issuecomment-739854061,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ASAWLO4BVVCKKASYVDEA4HLSTS23BANCNFSM4UPUY2ZQ
.

[retrofriendsdotcom]

My video is up on DietPi on the Pi400 (and other Pies). Here is the link:
https://youtu.be/osBU7iVSQ78

On Mon, Dec 7, 2020 at 3:19 AM MichaIng [e-mail] wrote:

That is awesome. Do we have permissions to embed your YouTube video into
our (new) documentation page?
https://dietpi.com/docs/software/gaming/#amiberry

Btw, if I am not totally mistaken, since RPi 400 has a different revision
code identifier that was implemented recently to dev branch but not yet
released: 182f3ae
https://github.com/MichaIng/DietPi/commit/182f3ae5969829ee1d51f5141184f78e2612cd3b
So on RPi 400 is currently identified as "unknown" RPi model and hence the
RPi 1 build (most compatible) of Amiberry is installed. It works due to the
included SDL2 builds, but you might get a better experience with v6.34 and
the RPi 4 build of Amiberry 😃. But not sure about the details, the
differences are performance related an probably the RPi 4(00) is strong
enough so that one does not recognise.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/MichaIng/DietPi/issues/3955#issuecomment-739854061,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ASAWLO4BVVCKKASYVDEA4HLSTS23BANCNFSM4UPUY2ZQ
.

[MichaIng]

Great video. A little wording in the intro title: ~Amibian~ => Amiberry 😉, although Amiberry was inspired by Amibian.

You can btw pre-configure WiFi as well with the dietpi.txt configuration files and the dietpi-wifi.txt, allowing to pre-configure the WiFi slots you found in the menu, which are located at the vfat partition 1, hence can be accessed easily on all OSes.

It's actually true that automatic reboot into Amiberry is not idea without even having the chance to mount a drive with Amiga images/data 🤔. Those could be copied onto the vfat partition of the SD card as well (/boot/kickstarts), but breaks the default location /mnt/dietpi_userdata/amiberry/kickstarts, also the vfat partition, which holds kernel, bootloader and device tree (+overlays) has limited size (256M with ~200M free space), although for Amiga images it should be usually more than enough 😄. Easiest would probably if any amiberry directory in the vfat partitions would be automatically merged into the /mnt/dietpi_userdata/amiberry internal directory on first boot, so that you can place amiberry/kickstarts there right from the OS where you flashed the DietPi image from.

Another possibility that can be done already now is to use dietpi.txt to install a Samba or NFS server on first boot, together with Amiberry: https://dietpi.com/phpbb/viewtopic.php?p=56#p56
It points by default to /mnt/dietpi_userdata, so you can copy/sync Amiga images right away while using the Amiberry GUI on the Pi itself.

Ah and indeed, while I am happy that it works on the RPi 400, on your login prompt you see that it is not yet identified correctly due to the new revision code. It installs the RPi 1/Zero binaries for Amiberry then, while the RPi 4 binaries should work better (although, not sure if recognisable). RPi 400 detection will be part of a release the next days: https://github.com/MichaIng/DietPi/blob/beta/CHANGELOG.txt#L5
After v6.34 have been applied, Amiberry can be reinstalled with RPi 4 binaries via: dietpi-software reinstall 108 (data/configs are preserved)

[retrofriendsdotcom]

Thanks for pointing out the mistake, I set a comment to that affect. Worst
part of youtube if the inability to edit the video.

Regarding the revisions, I assume that the DietPi/Amiberry SD card image on
your site will include the RPi4 image with the RPi400 detection?

On Sun, Dec 13, 2020, 5:09 AM MichaIng [e-mail] wrote:

Great video. A little wording in the intro title: Amibian => Amiberry 😉,
although Amiberry was inspired by Amibian.

You can btw pre-configure WiFi as well with the dietpi.txt configuration
files and the dietpi-wifi.txt, allowing to pre-configure the WiFi slots
you found in the menu, which are located at the vfat partition 1, hence can
be accessed easily on all OSes.

It's actually true that automatic reboot into Amiberry is not idea without
even having the chance to mount a drive with Amiga images/data 🤔. Those
could be copied onto the vfat partition of the SD card as well (
/boot/kickstarts), but breaks the default location
/mnt/dietpi_userdata/amiberry/kickstarts, also the vfat partition, which
holds kernel, bootloader and device tree (+overlays) has limited size (256M
with ~200M free space), although for Amiga images it should be usually more
than enough 😄. Easiest would probably if any amiberry directory in the
vfat partitions would be automatically merged into the
/mnt/dietpi_userdata/amiberry internal directory on first boot, so that
you can place amiberry/kickstarts there right from the OS where you
flashed the DietPi image from.

Another possibility that can be done already now is to use dietpi.txt to
install a Samba or NFS server on first boot, together with Amiberry:
https://dietpi.com/phpbb/viewtopic.php?p=56#p56
It points by default to /mnt/dietpi_userdata, so you can copy/sync Amiga
images right away while using the Amiberry GUI on the Pi itself.

Ah and indeed, while I am happy that it works on the RPi 400, on your
login prompt you see that it is not yet identified correctly due to the new
revision code. It installs the RPi 1/Zero binaries for Amiberry then, while
the RPi 4 binaries should work better (although, not sure if recognisable).
RPi 400 detection will be part of a release the next days:
https://github.com/MichaIng/DietPi/blob/beta/CHANGELOG.txt#L5
After v6.34 have been applied, Amiberry can be reinstalled with RPi 4
binaries via: dietpi-software reinstall 108 (data/configs are preserved)

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/MichaIng/DietPi/issues/3955#issuecomment-744005410,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ASAWLO7F4TTOOITBVPZVVBLSUS4H5ANCNFSM4UPUY2ZQ
.

[retrofriendsdotcom]

Dosregard the quetion, just saw that is what you meant when you said "part
of a release..."

On Sun, Dec 13, 2020, 8:55 AM Jonathan Vine [e-mail] wrote:

Thanks for pointing out the mistake, I set a comment to that affect. Worst
part of youtube if the inability to edit the video.

Regarding the revisions, I assume that the DietPi/Amiberry SD card image
on your site will include the RPi4 image with the RPi400 detection?

On Sun, Dec 13, 2020, 5:09 AM MichaIng [e-mail] wrote:

Great video. A little wording in the intro title: Amibian => Amiberry 😉,
although Amiberry was inspired by Amibian.

You can btw pre-configure WiFi as well with the dietpi.txt configuration
files and the dietpi-wifi.txt, allowing to pre-configure the WiFi slots
you found in the menu, which are located at the vfat partition 1, hence can
be accessed easily on all OSes.

It's actually true that automatic reboot into Amiberry is not idea
without even having the chance to mount a drive with Amiga images/data 🤔.
Those could be copied onto the vfat partition of the SD card as well (
/boot/kickstarts), but breaks the default location
/mnt/dietpi_userdata/amiberry/kickstarts, also the vfat partition, which
holds kernel, bootloader and device tree (+overlays) has limited size (256M
with ~200M free space), although for Amiga images it should be usually more
than enough 😄. Easiest would probably if any amiberry directory in the
vfat partitions would be automatically merged into the
/mnt/dietpi_userdata/amiberry internal directory on first boot, so that
you can place amiberry/kickstarts there right from the OS where you
flashed the DietPi image from.

Another possibility that can be done already now is to use dietpi.txt to
install a Samba or NFS server on first boot, together with Amiberry:
https://dietpi.com/phpbb/viewtopic.php?p=56#p56
It points by default to /mnt/dietpi_userdata, so you can copy/sync Amiga
images right away while using the Amiberry GUI on the Pi itself.

Ah and indeed, while I am happy that it works on the RPi 400, on your
login prompt you see that it is not yet identified correctly due to the new
revision code. It installs the RPi 1/Zero binaries for Amiberry then, while
the RPi 4 binaries should work better (although, not sure if recognisable).
RPi 400 detection will be part of a release the next days:
https://github.com/MichaIng/DietPi/blob/beta/CHANGELOG.txt#L5
After v6.34 have been applied, Amiberry can be reinstalled with RPi 4
binaries via: dietpi-software reinstall 108 (data/configs are preserved)

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/MichaIng/DietPi/issues/3955#issuecomment-744005410,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ASAWLO7F4TTOOITBVPZVVBLSUS4H5ANCNFSM4UPUY2ZQ
.

[MichaIng]

The self-update on first boot (if network is available) applies that automatically, and since the DietPi+Amiberry image does not already contain Amiberry, but is configured to freshly and automatically install it on first boot, after the self-update, it will then pull the correct Amiberry binary as well 🙂. So only who installed Amiberry prior to DietPi v6.34 release on RPi 400, would need to reinstall Amiberry one time manually to switch to RPi 4 binaries.

Hmm, actually we could trigger an Amiberry reinstall during dietpi-update on RPi 400. But I try to avoid reinstalls as long as the old particular software setup is not incompatible with the DietPi update, or, in case of Amiberry if we compiled new binaries with an important upstream update. But that did just happen with our last release there hasn't been an upstream update since then 🙂. Since I don't believe that there is any significant difference between the binaries, it should be okay.