Hi @guysoft, total noob here, just bought a Pi 4 today and as i jump head first into everything was shocked to see that the Octo print software didnt support it.
But i downloaded your file and after a few hours of cursing and marching up and down I finally got it working!!
Just FYI I have it running on no heat sink or fan and currently sat at 41C with printer running.
Thanks to you and whoever else has helped with this 
@guysoft
just wondering if there is an ETA on when the final/stable release based off Raspbian Buster will be made available ? maybe soon , since the stable octoprint 1.3.12 has now been released?
Not really. Soon.
If you test and report that everything works for you it would speed it up.
RaspberryPi foundation did another release at the beginning of the month of a new image. So it looks like their more stable fixes are now in place.
I don't expect though massive changes compared to the last nightly, its likely just picking one, making it an RC and see everyone is happy, then release.
@Burt This might be a good time to remind that I am developing OctoPi 100% out of my free time. No one pays me to do it and this week I had a pretty crazy month on my actual startup. If you would like to support please consider making a donation to CustomPiOs which is what OctoPi is built on.
There is reason we didn't release yet as follows. I hope this reduces your shock:
We had a nightly build out in a matter of hours the morning was RaspberryPi 4 announced. Some people had the device shipped the same day. Unlike the Rpi Foundation that release stuff with no Release candidates we strive to keep stuff stable and only mark builds as released after we are sure they are solid and tested.
Rpi Foundation are much more sporadic in that sense. It caused all their first firmware releases to have some kind of bug which we rather not ship right away.
I installed the image on a Pi 4 and it is working from a web browser. Is there a guide to install a desktop on the pi, without affecting the octopi image?
I found the guide to install octoprint after installing raspbian OS using NOOBS, but I ran into too many errors I didn't know how to fix.
I'd like to have raspbian so I can use Mathematica 12
Well you got two options:
sudo apt-get update --allow-releaseinfo-change
and then
sudo /home/pi/scripts/install-desktop
Installed and working better on the Pi4 1GB comapred to the Pi 3 B+ . only one problem encounted so far, which was easily fixed.
what i did was,
backup from current installation using the build it backup and restore of octoprint
Flash with the 2019-06-24_2019-06-20-octopi-buster-lite-0.17.0 image.
did an "apt update", "apt upgrade" and configure all the other usual os stuff, ip/network/hostname/password/1-wire(for ds18b20) and octopi.txt for a logitech C930e usb camera .
on the web gui, did the wizzard, and updated to latest octoprint 1.3.12
did a restore using the built in backup and restore in octoprint.
tried to do did a test print, but got the following error by octolapse, "The ffmpeg /usr/bin/avconv does not exist."
to fix, went to
settings > webcam & Timelapse > Path to FFMPEG
change from
/usr/bin/avconv
to
/usr/bin/ffmpeg
not sure if this is because of the restore from backup that this issue occurred.
printed fine after that
Don't think it is a waste of time, if you are not going to run the gui(KDE/GNOME), which is the default,
there is still 300mb of free space , and it stays that way even during printing etc.
root@octopi:/home/pi# free -h
total used free shared buff/cache available
Mem: 872Mi 161Mi 300Mi 5.0Mi 411Mi 643Mi
printing from octiprint from a pi3 b+ i was getting quite a bit of blobs and zits on my print.
monitoring the cpu using htop, the octoprint process was regularly hitting 100% . i assume that this was causing the print to pause for a sec or so, which was casing the blobs/zits. load average was getting more than 1 during a print (which is sort of ok as this has 4 cores), but not ok of a single process is using lots on only one core.
printing from the pi4, same gcode, NO MORE Blobs and Zits!!! cpu very rarely goes to 90% for the octoprint process with the highest cpu usage. highest load average was 0.88 , and only for a short while. this was with 2 web gui open on 2 different machine, and streaming the video stream from vlc.
all printed with octolapse on, and model 1 + model 2 printed in a set all at once, close to each other.
to be sure that it is the change to pi4 and not because of the change to buster , probably should try to run the buster image on the pi3 b+ and test.
also, there are quite a few plugins installed, so this may be why it is using a bit more cpu during a print, but overall, i am happy on the outcome, and would definitely recommend the pi4 over the pi3 (since they are the same price).
what i did for cooling for the pi4, is i put the pi4 behind my CR-10S Pro, where the fan exhaust is. so the fan of the CR-10S Pro is blowing air on the pi 4. I did not even put a heatsink on it.
enclosure temp 30.2°C
gantry temp 39.4°C
max pi 4 cpu temp during printing 50.0°C
i should also mention that both pi3 b+ and pi4 are using Ethernet and not wifi.
however, if you are using wifi on buster, to connect to WPA2 enterprise with peap-mschapv2 authentication, you need to do this for it to work.
Ok, I had a pull request ready for that and you are the first to confirm that it indeed fixes the problem.
So I just merged this:
Thanks for reporting. These reports translate to actual code getting in to OctoPi. This should be fixed in the next nightly.
I'll note that I haven't logged that many hours actually printing with the OctoPi nightly image plus the 4B (4GB). Almost everything I'm doing is just trying to get Kivy to talk to a Window provider at this point.
There's probably some tweaking that would need to happen for the /boot/config.txt file. There are some new variables like gpu_mem_1024 which is separate from gpu_mem in addition to sections at the bottom for Pi4B-only and all. There's a lot of debate about the KMS setting (full versus fake) for the GL driver.
If I'm not mistaken gpu_mem_XXXX and gpu_mem are basically the same.
It's just for your convenience if you want to run the same image or config with different pi versions.
You just set the vram based on your version and the bootloader will set it accordingly.
So gpu_mem works always and it's the easiest one for a unique pi os.
If I missed something please correct me 
For example, mine's something like this at the bottom. It's safe to put this microSD into either 3B or 4B (4GB) for my situation. In theory, this would work with a 4B (1GB) as well.
[pi4]
# Enable DRM VC4 V3D driver on top of the dispmanx display stack
dtoverlay=vc4-fkms-v3d
gpu_mem=944
max_framebuffers=2
[all]
#dtoverlay=vc4-fkms-v3d
dtoverlay=pi3-disable-bt
enable_uart=1
gpu_mem_1024=384
start_x=1
Shouldn't the pi 4 part be underneath the all part?
Doesn't the all part overwrite everything that was above?
(I mean if they got the same parameters)
Honestly, I thought the ordering came from the Raspbian image itself. I'm guessing that they just read the whole thing in at once maybe.
is the camera available now?
Well yeah it was never gone 
i put wrong orientation for my CSI cable, so i put it to correct way and then working now. thanks man..
you're welcome
happy printing
Hey!
Is it possible to upload an updated version of the image with current firmware and kernel? The updating process. Would be great becaue the updating process on the old image takes forever.
Thx
Is the Octopi 0.17 nightly image considered stable enough, or would it be better advised to jerryrig it manually with Raspbian or something?
There is no problem so far.
But if you update to latest firmware it takes very long.
Would be great to have an updated image version based on Release date: 2019-09-30.