search

MichaIng / DietPi

Lightweight justice for your single-board computer!
https://dietpi.com/
GNU General Public License v2.0
4.88k stars 497 forks source link

Image | Raspberry Pi 4 #2935

Closed MichaIng closed 5 years ago

MichaIng commented 5 years ago

Device is ordered, initial hardware detection and ID has been added: https://github.com/MichaIng/DietPi/commit/19ab1667e87b760d48414887191ed0b407f13574

Testing image available: https://github.com/MichaIng/DietPi/issues/2935#issuecomment-511226948

Twitter: https://twitter.com/DietPi_/status/1143142028148191232

Third kernel tree added, quite a bunch of data now:

2019-06-24 17:09:41 root@micha:~# G_TREESIZE /lib/modules/
[  OK  ] Root access verified.
174.8 MB /lib/modules/
59.0 MB /lib/modules/4.19.50-v7l+
58.8 MB /lib/modules/4.19.50-v7+
57.0 MB /lib/modules/4.19.50+

Also a new set of kernel/bootloader/start/fixup files has been added, /boot is growing messy:

2019-06-24 17:11:12 root@micha:~# ls -Alh /boot
total 39M
-rwxr-xr-x 1 root root  19K Jun 24 16:06 COPYING.linux
-rwxr-xr-x 1 root root 1.5K Jun 24 16:08 LICENCE.broadcom
-rwxr-xr-x 1 root root  24K Jun 24 16:06 bcm2708-rpi-b-plus.dtb
-rwxr-xr-x 1 root root  23K Jun 24 16:06 bcm2708-rpi-b.dtb
-rwxr-xr-x 1 root root  23K Jun 24 16:06 bcm2708-rpi-cm.dtb
-rwxr-xr-x 1 root root  24K Jun 24 16:06 bcm2708-rpi-zero-w.dtb
-rwxr-xr-x 1 root root  23K Jun 24 16:06 bcm2708-rpi-zero.dtb
-rwxr-xr-x 1 root root  25K Jun 24 16:06 bcm2709-rpi-2-b.dtb
-rwxr-xr-x 1 root root  27K Jun 24 16:06 bcm2710-rpi-3-b-plus.dtb
-rwxr-xr-x 1 root root  26K Jun 24 16:06 bcm2710-rpi-3-b.dtb
-rwxr-xr-x 1 root root  25K Jun 24 16:06 bcm2710-rpi-cm3.dtb
-rwxr-xr-x 1 root root  39K Jun 24 16:06 bcm2711-rpi-4-b.dtb
-rwxr-xr-x 1 root root  52K Jun 24 16:08 bootcode.bin
-rwxr-xr-x 1 root root  103 Mar 26 03:04 cmdline.txt
-rwxr-xr-x 1 root root 2.5K Jun 24 17:08 config.txt
drwxr-xr-x 4 root root 4.5K Mar 23 16:39 dietpi
-rwxr-xr-x 1 root root 9.6K Jun 24 17:08 dietpi.txt
-rwxr-xr-x 1 root root 6.6K Jun 24 16:08 fixup.dat
-rwxr-xr-x 1 root root 6.0K Jun 24 16:08 fixup4.dat
-rwxr-xr-x 1 root root 3.0K Jun 24 16:08 fixup4cd.dat
-rwxr-xr-x 1 root root 9.0K Jun 24 16:08 fixup4db.dat
-rwxr-xr-x 1 root root 9.0K Jun 24 16:08 fixup4x.dat
-rwxr-xr-x 1 root root 2.6K Jun 24 16:08 fixup_cd.dat
-rwxr-xr-x 1 root root 9.6K Jun 24 16:08 fixup_db.dat
-rwxr-xr-x 1 root root 9.6K Jun 24 16:08 fixup_x.dat
-rwxr-xr-x 1 root root 4.8M Jun 24 16:06 kernel.img
-rwxr-xr-x 1 root root 5.1M Jun 24 16:06 kernel7.img
-rwxr-xr-x 1 root root 5.4M Jun 24 16:06 kernel7l.img
drwxr-xr-x 2 root root  15K Jun 24 16:10 overlays
-rwxr-xr-x 1 root root 2.8M Jun 24 16:08 start.elf
-rwxr-xr-x 1 root root 2.7M Jun 24 16:08 start4.elf
-rwxr-xr-x 1 root root 745K Jun 24 16:08 start4cd.elf
-rwxr-xr-x 1 root root 4.5M Jun 24 16:08 start4db.elf
-rwxr-xr-x 1 root root 3.6M Jun 24 16:08 start4x.elf
-rwxr-xr-x 1 root root 670K Jun 24 16:08 start_cd.elf
-rwxr-xr-x 1 root root 4.7M Jun 24 16:08 start_db.elf
-rwxr-xr-x 1 root root 3.7M Jun 24 16:08 start_x.elf

Oh okay, this is even a very close thing on my system:

/dev/mmcblk0p1   43M   41M  2.2M  96% /boot

Checking new Raspbian Lite image: rpi

MichaIng commented 5 years ago

Woooooh, totally overseen: Its BUSTER only!!

Just saw it here: https://www.raspberrypi.org/forums/viewtopic.php?f=66&t=243387 And didn't see on the download page: https://www.raspberrypi.org/downloads/raspbian/

Okay due to needs for RPi 4 it seems that Raspbian is faster this time to release Buster than Debian. This changes much, we can hope that some left Buster issues with Raspbian have been solved then and as well the firmware/RPi repo is now fully maintained.

MattL0 commented 5 years ago

see thi on diet pi buster upgrade :

but i do not see what file i ca delete from the boot ?

MichaIng commented 5 years ago

@MattL0 See in first post the 2nd code box contains all files that are present on clean /boot. These are most probably more then you see in your case since the new files for RPi4 support are already inside. But any files aside from them are most probably junk, so you can move them out of the place, e.g. mv /boot/junk /mnt/dietpi_userdata/junk_bak

MattL0 commented 5 years ago

on a upgrade the boot partition is like 43m , an by looking on your first post i can't remove the large files... so i guess i should reinstall dietpi from a fresh buster image.

edit : can't i remove one of these files ?

-rwxr-xr-x 1 root root 5305768 Jun 24 18:27  kernel7.img
-rwxr-xr-x 1 root root 5608912 Jun 24 18:27  kernel7l.img
-rwxr-xr-x 1 root root 5025568 Jun 24 18:27  kernel.img
-rwxr-xr-x 1 root root    1494 Jun 24 18:28  LICENCE.broadcom
-rwxr-xr-x 1 root root   18974 Mar 13  2018  LICENSE.oracle
drwxr-xr-x 2 root root   14848 Jun 24 18:28  overlays
-rwxr-xr-x 1 root root  762400 Jun 24 18:28  start4cd.elf
-rwxr-xr-x 1 root root 4715912 Jun 24 18:28  start4db.elf
-rwxr-xr-x 1 root root 2758660 Jun 24 18:28  start4.elf
-rwxr-xr-x 1 root root 3672072 Jun 24 18:28  start4x.elf
-rwxr-xr-x 1 root root  685508 Jun 24 18:28  start_cd.elf
-rwxr-xr-x 1 root root 4854056 Jun 24 18:28  start_db.elf
-rwxr-xr-x 1 root root 2878148 Jun 24 18:28  start.elf
-rwxr-xr-x 1 root root 3791528 Jun 24 18:28  start_x.elf
MichaIng commented 5 years ago

@MattL0

can't i remove one of these files ?

LICENSE.oracle can be removed, but yeah indeed non of the large files can be removed, respectively some could, but those are recreated on every firmware update.

So you did already upgrade. Any errors? df should also tell you if 100% is used or not.

As can be seen above, the new firmware fits closely onto the partition. Neither DietPi, not the firmware files, nor the partition should have any different sizes on all RPis, the "dietpi" dir only varies between some kbits. So it should definitely fit.

so i guess i should reinstall dietpi from a fresh buster image.

Our RPi images are not yet based on the new Raspbian Lite Buster with new partition size. This was just released the last days. We will ship new images soon, at lastest after the RPi 4 arrived to run some tests. So reflashing will not solve the close to full /boot partition.

MattL0 commented 5 years ago

ha ok thanks a lot . I'll wait :P

here is the output of df ( i removed some .dtb files not related to my pi model... but as you aid I don't know if there will come back ) :

/dev/mmcblk0p1 42131 41064 1067 98% /boot

No error on two rpi3b+ and rpi3b

MichaIng commented 5 years ago

@MattL0 Hmm interesting that it is even closer in your case. Could you paste ls -Alh /boot to compare?

Which sound card do you use (if any external one)? There are some where custom dtoverlays are/were required that are added to /boot/overlays.

MattL0 commented 5 years ago

yes 

total 39M
-rwxr-xr-x 1 root root  27K Jun 24 19:39  bcm2710-rpi-3-b-plus.dtb
-rwxr-xr-x 1 root root  25K Jun 24 19:39  bcm2710-rpi-cm3.dtb
-rwxr-xr-x 1 root root  52K Jun 24 19:41  bootcode.bin
-rwxr-xr-x 1 root root  142 Mar  3 15:09  cmdline.txt
-rwxr-xr-x 1 root root 3.1K Jun 24 19:53  config.txt
-rwxr-xr-x 1 root root  19K Jun 24 19:40  COPYING.linux
drwxr-xr-x 4 root root 3.0K Mar 30 03:24  dietpi
-rwxr-xr-x 1 root root  12K Jun 24 19:53  dietpi.txt
-rwxr-xr-x 1 root root 3.0K Jun 24 19:41  fixup4cd.dat
-rwxr-xr-x 1 root root 6.0K Jun 24 19:41  fixup4.dat
-rwxr-xr-x 1 root root 9.0K Jun 24 19:41  fixup4db.dat
-rwxr-xr-x 1 root root 9.0K Jun 24 19:41  fixup4x.dat
-rwxr-xr-x 1 root root 2.6K Jun 24 19:41  fixup_cd.dat
-rwxr-xr-x 1 root root 6.6K Jun 24 19:41  fixup.dat
-rwxr-xr-x 1 root root 9.6K Jun 24 19:41  fixup_db.dat
-rwxr-xr-x 1 root root 9.6K Jun 24 19:41  fixup_x.dat
-rwxr-xr-x 1 root root 5.1M Jun 24 19:40  kernel7.img
-rwxr-xr-x 1 root root 5.4M Jun 24 19:40  kernel7l.img
-rwxr-xr-x 1 root root 4.8M Jun 24 19:40  kernel.img
drwxr-xr-x 2 root root  15K Jun 24 19:40  overlays
-rwxr-xr-x 1 root root 745K Jun 24 19:40  start4cd.elf
-rwxr-xr-x 1 root root 4.5M Jun 24 19:41  start4db.elf
-rwxr-xr-x 1 root root 2.7M Jun 24 19:40  start4.elf
-rwxr-xr-x 1 root root 3.6M Jun 24 19:41  start4x.elf
-rwxr-xr-x 1 root root 670K Jun 24 19:41  start_cd.elf
-rwxr-xr-x 1 root root 4.7M Jun 24 19:41  start_db.elf
-rwxr-xr-x 1 root root 2.8M Jun 24 19:40  start.elf
-rwxr-xr-x 1 root root 3.7M Jun 24 19:41  start_x.elf
drwxr-xr-x 2 root root  512 Mar 20  2018 'System Volume Information'
MattL0 commented 5 years ago

I have no ext sound card, I use theses 3 PI as a squeezelite player + shairport. Maybe this is the difference? Capture

MichaIng commented 5 years ago

@MattL0 Okay nope in this case no additional overlays were installed.

Another one that I see: rm -R '/boot/System Volume Information' Also nearly no size, but since Mac has their own files again, Windows might additionally place thumbs.db and desktop.ini and if you ever somehow plug the SDcard to a camera again some dirs/files could be created, this might some up to hit 100%.

MattL0 commented 5 years ago

I just saw that i got this when i load : dietpi-software Capture

MichaIng commented 5 years ago

@MattL0 Could you open a new issue about this? We are already going to far off-topic 😉.

Fourdee commented 5 years ago

@MichaIng

All that work you did on Buster will pay off here, nice one :+1:

I'd also recommend we switch to Buster for RPi image by default. As Raspbian official has removed Stretch links: https://www.raspberrypi.org/downloads/raspbian/

When my device arrives (after 5th July) I will chip in with some testing + implementations where needed.

REF: https://twitter.com/li0nic/status/1143554086991794182

MichaIng commented 5 years ago

@Fourdee

I'd also recommend we switch to Buster for RPi image by default.

Jep, to keep it easy we even have to. Looks like RPi 4 simply works (or is at least officially only supported) on Buster. Otherwise we would need to provide two separate images (RPi4 and non-RPi4) and as of the above issue with close-to-full /boot, extend the boot partition manually. Totally not keen to do so.

There has been just another firmware update just some hours after the first. I think I will wait for another day or two, to assure things are settled, and then redo our RPi image based on the new Raspbian Lite Buster (+ move Stretch image to legacy). So RPi4 support is already there and the issue with small boot partition solved. Will also create this based on beta code, do allow me test new dietpi-firstboot on a non-VM system.

Fourdee commented 5 years ago

@MichaIng

Initial RPi buster image done: https://dietpi.com/downloads/images/DietPi_RPi-ARMv6-Buster.7z

Quick testing my end with general server use + WiFi is fine. Things that need testing are:

The following packages have unmet dependencies: kodi : Depends: libnfs8 but it is not installable or libnfs4 but it is not installable or libnfs1 but it is not installable kodi-bin : Depends: libass5 (>= 0.13.0) but it is not installable Depends: libcdio13 (>= 0.83) but it is not installable Depends: libcurl3 (>= 7.18.0) but it is not installable Depends: libiso9660-8 (>= 0.83) but it is not installable Depends: libmariadbclient18 (>= 10.1.37-0+deb9u1) but it is not installable Depends: libnfs8 (>= 1.9.7) but it is not installable E: Unable to correct problems, you have held broken packages.

- :u5408: FB scrape invalid:

root@DietPi:~# vcgencmd get_config framebuffer_width framebuffer_width=0



Notes to self:
- Update dietpi.com info for RPi 4
MichaIng commented 5 years ago

@Fourdee Btw Kodi APT package can be added by /etc/apt/sources.list.d/raspi.list, adding the stretch branch besides buster branch. We do this by default when changing APT mirror on RPi btw.

But the question is if this Kodi 18 package still works on the new Buster image and RPi4. It is known that there are still some issues with this that is worked on. EDIT: Ah sorry, nope the package from Stretch is simply not compatible with Buster since there only libnfs12 is available: https://packages.debian.org/buster/libnfs12 So we need to wait for RPi Foundation to add a Buster compatible Kodi to the raspberrypi.org Buster repo then.

vcgencmd get_config framebuffer_width

Hmm in my case this only shows 0 when disabling GPU/enabling headless mode 🤔 via hdmi_ignore_composite=1.

There is a new setting enable_tvout, but according to docs this is only effective on RPi4 since by default composite is disabled there. However at least worth to test with:

enable_tvout=1
hdmi_ignore_composite=0

I just removed the Stretch firmware repo from RPi Buster and added raspi-copies-and-fills package which is now compatible with Buster udev/systemd.

MichaIng commented 5 years ago

@lordkane Should be user=root, password=dietpi, if Fourdee did not somehow changed this? Let me do a quick check on the image.

RefineryX commented 5 years ago

Is it just me... but I get this error everything I try and flash the image. Tried re-downloading and starting again.

Screenshot 2019-06-27 at 17 57 01
lordkane commented 5 years ago

@lordkane Should be user=root, password=dietpi, if Fourdee did not somehow changed this? Let me do a quick check on the image.

sorry i am so stupid i have a second dietpi image run.... with pihole and connect not to the new pi

MichaIng commented 5 years ago

@lordkane Okay, glad you recognised it 🙂.

@SimplyGardner Strange, extracts and mounts well here without issues and seems to have worked for @lordkane as well. You could check the hashes from the hash.txt file that is contained. Perhaps the download corrupted.

RefineryX commented 5 years ago

@MichaIng I have following in the file. Although, I deleted the previous download, re-downloaded again and same thing happens. Strange.

FILE:   DietPi_v6.24_RPi-ARMv6-Buster.img
DATE:   Thu 27 Jun 15:10:42 BST 2019
MD5:    a402f96e4f8169e783f4fbdb9d6f43ee
SHA1:   c70b181d41d0b01a7efb33ea7516cec6a4041448
SHA256: 1d1ff3d7e36e9b85f1cb41fb63743d1f8716c20f02a0762a37d2d5e3588f0b49
MichaIng commented 5 years ago

@SimplyGardner Okay when redownloaded, then a corrupt download is very unlikely. Did you try to flash with Ether? If you are on a Windows machine, please try it with Rufus

RefineryX commented 5 years ago

@MichaIng Etcher, yes. On macOS. Just tried reinstalling Etcher - no luck. Only thing I can think of is I've just upgraded to the beta of macOS (Catalina).

MichaIng commented 5 years ago

@SimplyGardner The OS should not be related, however beta, one can not be 100% sure. If you have another machine to try it on, it is at least work a test.

RefineryX commented 5 years ago

@MichaIng Just tried on another Mac that is not running the beta and seemed to have worked! Thank you.... now on to the setup :)

Know that release is an experimental release... is it easy to upgrade to the official dietpi release once release or will this require another re-flash of the SD card?

MichaIng commented 5 years ago

@SimplyGardner As long as we do no essential changes to the image, and I don't think we need to, you can stay with this image. Once v6.25 is released it will reapply the DietPi update to include all changes done until release, including some changes to Raspberry Pi firmware repo and one additional package (raspi-copies-and-fills) to be installed, that I already applied to dev code.

Just for general interest: Could you paste the output of: dmesg | grep 'crng init done'

RefineryX commented 5 years ago

@MichaIng Gotcha, so just sudo apt-get update && sudo apt-get upgrade and that should put me on the latest stable version when released?

Is it normal the pi4 runs hot? Like 55 degrees when idle (with a heat sick too). Cant remember my 3b+ being that hot.

Sure, output for dmesg | grep 'crng init done' is...

[   45.751574] random: crng init done
MichaIng commented 5 years ago

@SimplyGardner

sudo apt-get update && sudo apt-get upgrade

sudo dietpi-update, which includes the APT upgrade as well. You will also get a notification max 1 day after v6.25 has been released.

Is it normal the pi4 runs hot? Like 55 degrees when idle (with a heat sick too). Cant remember my 3b+ being that hot.

Should not be 🤔. I have no values but read that at least RPi4 takes longer to run that hot that it throttles down clocks automatically compared to RPi3. Ah 3 dietpi-survey uploads with RPi4: https://dietpi.com/survey/#benchmark

[ 45.751574] random: crng init done

Ayayay okay nothing changed. Very long... If you face issues with service restart taking long or boot itself takes long until login is possible: G_AGI haveged If you are interested about this, see the related issue I linked above.

ghost commented 5 years ago

Strange ram benchmark by the way, avarage (write) on the rpi 3/3+ is 366 mb/s and the pi4 is 343, despite it being lpddr4 ram...

MichaIng commented 5 years ago

@ricardoandren Yeah I was also wondering. Perhaps it is indeed related to raspi-copies-and-fills missing on Buster images currently, but can be installed now (it was not compatible with Buster systemd/udev before): G_AGI raspi-copies-and-fills

But I have no idea if these functions are used natively when accessing RAM, or just when some binary explicitly implements and calls them.

You might want to run dietpi-benchmark once without (current state) and once with the above package installed to compare. Also possibly we need to increase the written file size to increase accuracy. Since services are stopped it is safe to use e.g. 80% of free RAM, currently we only use 25% 🤔.

Targeted RAM benchmark btw:

FP_BENCHFILE=/tmp /DietPi/dietpi/func/dietpi-benchmark 1
ghost commented 5 years ago

@MichaIng Will definitely try tomorrow when I get my pi. As it was just a thing I noticed.

RefineryX commented 5 years ago

@MichaIng When installing something from dietpi-software (Avahi-Daemon) and then when I try to uninstall, it does not uninstall. Looks like it is stuck and I can not get rid of the software from this screen.

Screenshot 2019-06-27 at 23 36 08

Update:

MichaIng commented 5 years ago

@SimplyGardner Good find, many thanks! Bug due to some v6.25 change about how we handle whiptail menu return values. Just fixed it with: https://github.com/MichaIng/DietPi/commit/8d382e6b2aee84306902ba6cd1e5f64b50a48996

RefineryX commented 5 years ago

@Michalng Thanks! So did the software uninstall and is just showing still on the menu section. Or, did the bug prevent it from uninstalling? Would this go in the next update or is it live now?

I use avahi-daemon along with Netatalk. But looks like Netatalk is not available in the software menu so have to install manually. On previous versions of dietpi, I had to edit a file to include the HDD mount location (sudo nano /etc/netatalk/AppleVolumes.default) but looks like this file does not exist? It works perfectly when I installed this on Thank you e previous version of dietpi on my 3b+. Wondering if something is preventing it from installing correctly?

ghost commented 5 years ago

Chromium with widevine: Check. sudo reboot makes the board shutdown instead on occasion. Had to reinstall, default mode by the way is headless?

Edit: After reinstallation stuck at:

Starting Flush Journal to Persistent storage... [OK] Started Flush Journal to Persistent storage. [OK] Started udev Kernel Device Manager

Only settings changed are display resolution, occured after reboot from installing dietpi-ramlog.

MichaIng commented 5 years ago

@SimplyGardner

Or, did the bug prevent it from uninstalling? Would this go in the next update or is it live now?

Jep it prevented it from uninstall. Fix is not yet online, will be released with Beta v6.25.1. Note that this RPi4 image is with dev code.

I can't say something with Netatalk, but you can generally install any software on DietPi when following Debian install instruction. DietPi is not preventing anything. In many cases default config files are not created by deb packages or custom builds, so perhaps /etc/netatalk/AppleVolumes.default simply cam be created, if it does not exist.

@ricardoandren Which kind of display do you use? HDMI or composite? Are you able to log in SSH or is the boot process indeed hanging? In case try to be patient for 2 minutes or such, perhaps it's related to: https://github.com/MichaIng/DietPi/issues/2806

ghost commented 5 years ago

HDMI. I will show you a screenshot, it just sits idle after that, no green light blinking, but I can ssh into it.

IMG_0232

EDIT: Changed resolution in ssh and suddenly everything is fine?

EDIT2: Reboot still seems to just put the board in sleep.

EDIT3: Restarted via unplug and now I have no screen and SSH. EDIT4: I think I found it? you need to plug it into the HDMI 0 not HDMI 1, its very picky.

RefineryX commented 5 years ago

@MichaIng There is definitely something on buster stopping the files from being added to /etc/netatalk

Just tried on stretch (fresh install) and these are the files I should see:

Screenshot 2019-06-28 at 14 19 05

On buster, there are missing files

Screenshot 2019-06-28 at 14 20 55

Could you maybe try and see what you get? sudo apt-get install netatalk

MichaIng commented 5 years ago

@SimplyGardner Indeed in the Buster version of netatalk these files are not present by design: https://packages.debian.org/buster/amd64/netatalk/filelist Check out some man pages or official docs about how it is handled with v3.X, as sad porribly these just need to be created now manually.

Ref: https://manpages.debian.org/testing/netatalk/netatalk.8.en.html

MichaIng commented 5 years ago

@ricardoandren Ah yeah forgot about the two HDMI ports.

See here HDMI mode options: https://www.raspberrypi.org/documentation/configuration/config-txt/video.md

Ref2: https://www.raspberrypi.org/documentation/configuration/config-txt/conditional.md

Not sure now if/why port 1 is disabled by default or if there is a general switch to enable/disable one port. In your case it seems like the port for HDMI signal is switched during boot for some reason.

DietPi side we need to add an option to dietpi-config on RPi4 to switch the used HDMI port or enable both. All HDMI related entries then need to be switched between <setting>:1 <=> <setting>:0 (while 0 is default), or doubled, depending on selection. Or we devide the whole Display menu into two sub menus to apply settings individually for each port. hdmi_hotplug_ignore:0=1 should allow to disable HDMI port 0 here, hdmi_force_hotplug:1=1 should force output to port 1.

There is a bunch of new settings as well, many only available for RPi4, e.g. enable/disable 4k output.

Obviously auto-detection of HDMI port does not work reliable. Also a question if/how to use shared screen (one TTY on both screens) or if one TTY for each screen can be mapped. The documentation stil lacks some details here.

So for now, as DietPi v6.25 is already in Beta, we leave things as they are. HDMI port 0 should respond then according to chosen settings in dietpi.txt/dietpi-config. Switching/configuring port 1 is then something that we can add with v6.26, as this requires some more work and research and hopefully some extended documentation.

Some config ideas/details can be hopefully derived from: https://github.com/RPi-Distro/raspi-config

RefineryX commented 5 years ago

Indeed in the Buster version of netatalk these files are not present by design: https://packages.debian.org/buster/amd64/netatalk/filelist Check out some man pages or official docs about how it is handled with v3.X, as sad porribly these just need to be created now manually. Ref: https://manpages.debian.org/testing/netatalk/netatalk.8.en.html

@MichaIng Hmm, assuming Netatalk is dead? Strange how that is not included... these are core files for it work.

MichaIng commented 5 years ago

@SimplyGardner Absolutely not dead, it's a whole new major version on Buster. Just the way to configure it obviously changed. Just compared a bid and it seems that on the Buster version you use afp.conf to configure mount points: https://manpages.debian.org/testing/netatalk/afp.conf.5.en.html This was not available on Stretch.

Here the official Wiki: http://netatalk.sourceforge.net/wiki/index.php/Install_Netatalk_3.1.12_on_Debian_9_Stretch#Setting_Up

meeki007 commented 5 years ago

@MichaIng DietPi side we need to add an option to dietpi-config on RPi4 to switch the used HDMI port or enable both.

I am making strides on bringing in hdmi auto detection to dietpi Pi 4 is ordered an on the way. I will play with bringing these up mid july.

Current detection work has got me this. all the ones called DMT or CEA were scraped from the detected monitor connected and put in an array.

yepyep

MichaIng commented 5 years ago

Planned for implementation: https://github.com/MichaIng/DietPi/issues/2939

MichaIng commented 5 years ago

Additional topic for RPi4:

teksindev commented 5 years ago

Problem i have : after a while, the pi can't be reached by SSH but i see the PI it in the network. My mounted smb USB drive can't be reached anymore too. I tried to restart the pi, but impossible to access it.

The only solution is to reflash the sd card.

I have installed : emby, transmission and medusa

ghost commented 5 years ago

Thats the same problem I had except I didnt install emby transmission and medusa.

MichaIng commented 5 years ago

@teksindev @ricardoandren This is both related to Raspberry Pi 4 with the testing image? You have access to local console via keyboard and monitor?

So initial boot and first run setup works well, reboots afterwards also work well and after a sudden (no upgrades/installs/changes done to the system) network access (besides ping) fails? 🤔

MattL0 commented 5 years ago

Just wondering. Can I download the buster image now? I mean, is the boot partition changed to get more space?

MichaIng commented 5 years ago

@MattL0 Jep the fresh Buster image of course has the larger boot partition already, only when upgrading the RPi firmware packages on an older image, one might run into issues.