mirror of
https://gitlab.com/buildroot.org/buildroot.git
synced 2026-08-09 17:03:35 -09:00
3a2baca4b7
In commitba70f94e62(subversion makes it so we do not need a separate tarball to store empty directories and symlinks for the target_skeleton.) /etc/resolv.conf was made a symlink to ../tmp/resolv.conf. There was no rationale behind this change, but back at the time (2006!), the only location that Buildroot guaranteed to be writable was /tmp, and we needed a writable location to create resolv.conf from a DHCP reply for example, so the change made sense. Commits2f67d9e2fe(preparation for BR2_PACKAGE_BUSYBOX_SKELETON), in 2007, thend9119c0bc5(move default skeleton to fs/ and drop busybox skeleton), in 2010, and finally6c3e3ad419(New top-level directory: system), in 2012, propagated that /etc/resolv.conf without any change in the target of the symlink. However, since commitd380dde1d2(skeleton: make /run a proper directory/filesystem), in 2015, a tmpfs has been mounted on /run, so it is now guaranteed to be writable as well for SYS-V-based systems. That has also been the case for openrc since commita840e485d1(package/skeleton-init-openrc: new package), in 2019. This has also always been the case for systemd as well. resolv.conf is not a temporary file [0]; it is really more of a runtime data; its location in /tmp is just a historical artefact of a long-wrong assertion. Nowadays, distributions either have an actual file as /etc/resolv.conf (when /etc is writable), or it is a symlink to a location below /run. Although resolv.conf is used by the C library resolver, a lot of applications now will directly use it; this is the case for some container management tools, such as podman (and its helpers, like netavark), that expect /etc/resolv.conf to either be a file or a symlink to somewhere in /run, and fail to provide DNS services if that is not the case. So, we move the target of /etc/resolv.conf to ../run/resolv.conf. As a consequence, we can drop the workaround in podman's runtime test. To be noted: there are tow custom fstab files in Buildroot that do not explicitly mount a tmpfs on /run: - one for a systemd runtime test, so /run would also be a tmpfs there anyway, as systemd does mount one; - one for the mender_x86_64_efi_defconfig; that's a not a problem: / is an ext4 that is mounted r/w (and /tmp is not a tmpfs either, so the symlink to /tmp would not not have worked if / was not r/w anyway). This leaves people with their own fstab, to adapt. Cater to them by adding a little blurb in the documentation. Note: the following 43 tests all built and ran successfully: tests.init tests.package.test_apache tests.package.test_docker_compose tests.package.test_dropbear tests.package.test_iputils tests.package.test_podman tests.package.test_skopeo tests.package.test_wget (no other runtime test were attempted) [0] temporary, as in relatively short-lived. Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Signed-off-by: Julien Olivain <ju.o@free.fr>
Buildroot is a simple, efficient and easy-to-use tool to generate embedded Linux systems through cross-compilation. The documentation can be found in docs/manual. You can generate a text document with 'make manual-text' and read output/docs/manual/manual.text. Online documentation can be found at http://buildroot.org/docs.html To build and use the buildroot stuff, do the following: 1) run 'make menuconfig' 2) select the target architecture and the packages you wish to compile 3) run 'make' 4) wait while it compiles 5) find the kernel, bootloader, root filesystem, etc. in output/images You do not need to be root to build or run buildroot. Have fun! Buildroot comes with a basic configuration for a number of boards. Run 'make list-defconfigs' to view the list of provided configurations. Please feed suggestions, bug reports, insults, and bribes back to the buildroot mailing list: buildroot@buildroot.org You can also find us on #buildroot on OFTC IRC. If you would like to contribute patches, please read https://buildroot.org/manual.html#submitting-patches