search

halmartin / meraki-builder

Scripts and tools to assemble firmware images for various Meraki MS switches and MX routers
GNU General Public License v3.0
77 stars 17 forks source link

simplify docker build #22

Closed hall closed 1 year ago

hall commented 2 years ago

A few updates to make it easier to build in docker. Note that I didn't actually try flashing the final image but I was able to modify and create new packages for the ms220 board.

In fact, the post-image.sh script fails because it's not able to find u-boot-dtb.bin (which appears to have been removed in https://github.com/halmartin/meraki-builder/commit/463fd2ce018bf8ab10f57165e7b590c4289e51cb#diff-7dac38a075e1795513fadcfc6d2f8a3df72d15190e9124f261695f9919c79805L3724).

>>>   Executing post-image script board/meraki/ms220/post-image.sh
/src/buildroot/output/images/u-boot-dtb.bin or /src/buildroot/output/images/uboot-env.bin not found
/src/buildroot/output/build/linux-custom/vmlinuz.bin does not exist
Replacing kernel with zero image, you must netboot!
squashfs.region: "8388608"
Generating JFFS2...
jffs2.region: "5242880"
Image generation failed

I'm not incredibly familiar with buildroot so let me know if any of these changes don't make sense.

halmartin commented 2 years ago

I appreciate your efforts here, but there are some major changes in this PR which I am not willing to accept

For the luton26 based devices, since these are supported by Microchip using a much newer kernel, we probably want to go forward with that instead of this entire repo (since they also won't use click); see #4.

RedBoot can be built from halmartin/MS42-GPL-sources-3-18-122 but it doesn't match what's on flash on any of my switches, and I have no idea how to use the compiled binary as a bootloader because Meraki didn't include any instructions. So, you won't get a flashable image from buildroot anyway without downloading a binary copy of the bootloader as discussed in the installation instructions GDoc.

I have never managed to boot 3.18.123 from halmartin/switch-11-22-ms220 when compiled by buildroot. I cross-compiled it manually (ages ago) and I just added the binary to my buildroot output tree once squashfs is built.

An all-around easier way to manage all this is to use buildroot to generate rootfs.squashfs and then use the instructions in #21 to replace the image on your switch from Linux. To that end, the output of post-image.sh doesn't really matter.

So, yeah. For the time being, I am providing updated builds periodically which you can find in the installation instructions GDoc. There are also some other devices which are in various states of development which I plan to add to this repository when they're in a somewhat usable state. So making the repository only build for the MS220 is not something I want.

Maybe the more long-term solution is to create per-device repositories so that CICD/building is easier.

hall commented 2 years ago

Thanks for the detailed response!

I don't intend to remove support for the MX80; perhaps my README.md edit is misleading. I think I assumed that the old "MX80 router" header was meant for both the MX80 and MS220 as there was a directory for each under ./docker. As far as the Dockerfile and Makefile changes go, I didn't really change much (other than moving the dependencies into the image or mounting them at runtime and combining both MX80 and MS220 into one set of files instead of two).

Good point about the 3.18.123 kernel; I wasn't aware and only changed that line so that it would build for me at all. I can remove that line (and probably add a setup that clones your source repo into the container).

I'll have to go over the gdoc again and review some of those other issues but I think I'm mostly following where things are and a bit about where they might should go. I'll probably give #21 a shot when I'm feeling more comfortable with the build process and filesystem layout.

Perhaps my changes (and the existing docker setup in general) are more suited for developing sw to run on the device instead of building the fw for the device? This was the setup I used to hack on the pd690xx package so it at least works for cross compiling! There are also several rootfs images that were created so the docker process is probably useful at some point to generate the squashfs when software updates become available.

That said, feel free to share your thoughts on what you'd like a build/release process to look like. I'm happy to contribute there. Maybe just a GitHub Action that publlshes a Release with the rootfs.squashfs file?

halmartin commented 2 years ago

@hall Some kind of CICD would be nice, although given how long buildroot takes to build, I'm not sure if there are inexpensive options to accomplish this. Another reason I'm a little against CICD is that there should be an integration test on actual hardware before any image is published as "working" because a syntax error in an initscript can completely break booting.

I anticipate that automating testing on actual hardware will be... complicated.