Tried to compile a buildroot environment to revive an old p1mmx machine. 1) when choosing MariaDB to provide MySQL, perl DBD::mysql and rsyslog have trouble finding mysql.h, have to add -I/path/to/output/target/.../mysql.h to them individually 2) syslinux hits umpteen double definitions when linking. Finally need to override the linker to always add --alow-multiple-definition always, otherwise it won't compile. (Not sure it works, though). (Uboot is not an option on a PC, lilo is absent from buildroot even though it would perfectly fit the need. Grub is not recommended when booting from SD cards, it tends to erase stuff when attempting to write and not waiting for the whole page to be rewritten) 3) for some reason, buildroot needs to download a rust binary, but refuses to skip the hash if the hash is not in the hash file. Removing rust*hash fixes this. ...and still going If it matters, the host is a VM running Ubuntu 20.04 LTS x64 . Buildroot is the last version available on git (git clone ....) I guess not many people are into reviving P1MMX machines with the latest kernel and libraries
Sorry to hear of your issues. You will need to provide more details for us to help though, E.G. what is your Buildroot configuration and what are the exact error messages? We indeed don't have a lilo package, but feel free to submit one if you are willing to maintain it. Given how old it is, I could imagine that newer toolchain versions could cause breakage.
Created attachment 8776 [details] .config used This is the config file requested, compressed with xz (Bugzilla won't attach it otherwise).
This is the .config I used (see attached file). Try to use it yourself on a Ubuntu 20.04 x64 VM as a host, to get a closer look at the issues I found. 2.2) Also forgot about this one: when compiling syslinux, it cannot find the strlen function to link in file ..../buildroot/output/build/syslinux-6.03/libinstaller/syslxmod.c Since it's the only thing used from <string.h>, it's easier to just comment out /* #include <string.h> */ and enter a quick and dirty replacement for it: #ifndef strlen int strlen(char *s){ int l=0; while (*s) { ++l;++s;} return l; } #endif it seems to like it 4) someone else also noticed that buildroot doesn't build a gcc binary for the targets, even though it does build other development tools. Please note that it IS needed for anyone who needs to program on the target in C, C++, perl, python, lua, fortran 2018+, etc. . One can try musl, but it's not the same as GNU gcc. 5) I understand the connection with busybox, but I'd still like an option to not use it on systems that can afford the drive space. If this option already exists, please document it. 6) syslinux finally worked, but with very little documentation. Here's how I did it: a) install the mbr binary in the first 440 bytes of the hdd image. b) partition the image, make a linux partition of the exact same size as rootfs.ext2 then a small FAT16 partition. Make the FAT16 partition bootable. c) find the 32 bit syslinux binary in the buildroot folder, install the 32 bit libraries on the host Ubuntu 20.04, run the 32-bit syslinux to install in the FAT16 partition d) manually add bzImage to the FAT16 partition, then create a syslinux.cfg file there (documentation on the Syslinux web site) *Guessing* that if one has an older system that needs an upgrade and IF the upgrade goes on a different disk, one could use the old LILO with the new kernel and the new disk or partition, without syslinux. Haven't tried this yet. The LILO documentation is on TLDP (watch out for the case when installing on a hdd that is not in the same position as when it will boot; it is documented and useful). At any rate, syslinux is needed to boot on a naked VM (for testing the image) without any older boot loader.
7) stopping the "transmission" service fails. This is fully documented in here: https://forum.transmissionbt.com/viewtopic.php?t=11561 I tried that solution and it works fine (file /etc/init.d/S92transmission) : # diff -u S92transmission~ S92transmission --- S92transmission~ +++ S92transmission @@ -93,7 +93,7 @@ # 1 if daemon was already stopped # 2 if daemon could not be stopped # other if a failure occurred - start-stop-daemon --stop --quiet --retry=TERM/10/KILL/5 --pidfile $PIDFILE --name $NAME + start-stop-daemon --stop --quiet --retry=TERM/10/KILL/5 --pidfile $PIDFILE --exec $DAEMON RETVAL="$?" [ "$RETVAL" = 2 ] && return 2 (I mean it starts, stops without error and if I check the process afterwards it is indeed starter or stopped as requested.) It may be an upstream bug, but a simple patch in buildroot won't hurt it either (if they fix it upstream, the patch will just skip, no biggie).
You are reporting a bunch of more-or-less unrelated issues and suggested improvements, making it kind of hard to keep track of. Care to send your suggestions as patches to the mailing list instead? http://lists.busybox.net/mailman/listinfo/buildroot Also for the bugreports, please be specific, E.G. you mentioned issues with mariadb and syslinux. What is your exact defconfig and what is the exact error message you get?
Regarding Description - Point 3) - rust binary/missing hash: Fixed by https://patchwork.ozlabs.org/project/buildroot/patch/20210306112307.28337-1-ps.report@gmx.net/ The dependency is by package ripgrep --> host-rustc --> host-rust-bin (take a look at 'make graph-depends' buildroot feature)...
Regarding Description - Point 3) - syslinux double definitions Fixed (hopefully) by: https://patchwork.ozlabs.org/project/buildroot/patch/20210307174753.9400-1-ps.report@gmx.net/ Out of interest, any references for the grub statement? Regarding Description - Point 1) - MariaDB No problem building your provided defconfig here, did you do a full rebuild after changing your config (see [1] for details)? In case a full rebuild fails, any special packages installed on your build system? [1] http://nightly.buildroot.org/manual.html#full-rebuild
Regarding Comment 4 Point 6) - syslinux installation Take a look at board/technologic/ts5500/readme.txt for a similar system configuration/setup?
(In reply to Peter Seiderer from comment #7) About the grub issue: For an older project of mine (reviving an old AMD Sempron laptop where the original hdd had unrecoverable bad sectors), I tried Lubuntu 18.04 LTS with an IDE44pin-to-SDCard convertor with a fairly new micro-SD card. All went fine except for the part when booting it with grub would erase the partition table at every boot from the hdd (well, sd-card+adapter). After tons of Googling (can't remember the exact search terms) found that one guy had replaced grub with lilo (which fortunately still comes as a Lubuntu package at least in 18.04) and it worked. So I did the same (full install, add the lilo package, purge grub, remove all grubby remnants, configure and run lilo) and it worked fine. For syslinux - if one wraps the linker in a shell file that adds --allow-multiple-definition, all works fine. And it's even simpler than LILO but it needs a FAT partition (no biggie), tested that one as well. For the revival project at hand (ancient 32-bit 5*86 with an asterisk zap card) I reused the ancient LILO which can load new kernels as well. Still a lot to do (Asterisk+zaptel doesn't compile directly either from buildroot on 586, GCC doesn't come at all with buildroot and GCC's documentation is not very friendly as to what sources one needs to download to do the whole bootstraping stuff) and since it's a pet low-priority project, it will take a long while. If anything pops up in the mean time, I will let you know.
(In reply to Peter Korsgaard from comment #5) For the .config file, see previous attachment. The issues with mariadb is that parl-dbd-mysql and rsyslog have trouble finding mysql.h. Modifying Makefile and re-running make fixes that temporarily, so they can finally compile. Have NOT tested with Oracle's flavor.
(In reply to ingineru_de_sistem from comment #10) oops: s/parl/perl/
(In reply to ingineru_de_sistem from comment #4) Regarding sysv init script for transmission Fixed by: https://patchwork.ozlabs.org/project/buildroot/patch/20210310223743.7879-1-ps.report@gmx.net/
Thank you for your report. The issue tracker for the Buildroot project has been moved to the Gitlab.com issue tracker: https://gitlab.com/buildroot.org/buildroot/-/issues We are taking this opportunity to close old issues in this old tracker. If you believe your issue is still relevant, please open one in the new issue tracker. Thank you!