Re: [announce] skarnet.org Spring 2017 release: s6 init fails with buildroot on MIPS
Hi! On 17-05-11 13:42:31, Van Bemten, Lionel (Nokia - BE/Antwerp) wrote: > Hello all, > > After upgrading to the below release of skarnet packages, my system > is not booting anymore on MIPS. I am using buildroot and the > s6-linux-init-skeleton > provided there by Éric Le Bihan. The master branch of upstream Buildroot currently contains the Fall 2016 skarnet release. I have not yet bumped to Spring 2017: as you may have seen, the patch for build time detection of types needs be refreshed. > The init usually stays blocked there: > > s6-rc: info: processing service fdholder: starting > > with the following processes running: > > 136 root s6-rc -v 3 -u change services-all > 143 root s6-fdholderd -1 -i data/rules > 146 root s6-ipcserverd -1 -- s6-ipcserver-access -v0 -E -l0 -i > data/rules -- s6-sudod -t 2000 -- /usr/libexec/s6-rc-oneshot-run -l > 173 root s6-svlisten1 -u -- /run/s6-rc/scandir/klogd-log s6-svc -u -- > /run/s6-rc/scandir/klogd-log > 183 root s6-ftrigrd > 296 root s6-svlisten1 -U -- /run/s6-rc/scandir/fdholder s6-svc -u -- > /run/s6-rc/scandir/fdholder > 297 root s6-ftrigrd > > and I regularly see the following message, even though not consistently: > > s6-ftrigrd: fatal: unable to flush asyncout: Broken pipe > > When I build the very same system for x86 I do not see any issue, it is very > stable, so I > suspect a cross-compilation issue. Since buildroot patches skalibs in order > to determine > system capabilities through build-time asserts instead of runtime tests, it > is possible that > something goes wrong there. However I have adapted the patches to the new > release, > and so far I cannot identify any error in the detected system settings. I do my cross-compilation tests using QEMU and I remember having this kind of issue sometimes. I always blamed it on a race condition and a slow QEMU emulation, without looking any futher. > If anyone has any idea to help the investigation, it would be highly > appreciated :). > Maybe for example a hint on what could cause s6-ftrigrd to get a broken pipe ? Would you care to share the Buildroot defconfig file you are using? Best regards, -- ELB
Re: Fully worked example of an S6 based system?
On Tue, Mar 01, 2016 at 12:17:24PM +0100, Jan Olszak wrote: > This might be useful: https://github.com/elebihan/buildroot-s6/ Indeed, buildroot-s6 can be a useful example, as it will allow you to build images for QEMU and Raspberry Pi of a Linux system where the s6 stack is used as init system. Note that it is based on Buildroot [1], and thus is a not fully fledged GNU/Linux distribution. > Especially > https://github.com/elebihan/buildroot-s6/tree/master/buildroot/package/s6-linux-init-skeleton/files Yes. This Buildroot package provides the start up scripts as well as some basic services. Additional services (such as running rngd) can be found in the "overlay" subdirectories of custom/board. [1] https://buildroot.org -- ELB
[announce] buildroot-s6 0.4.0
Hi! The version 0.4.0 of buildroot-s6, a set of Makefiles to generate embedded Linux systems using s6 as init system, is available [1]. What's new? - rename ok-* bundles to bundle-* - s6: bump version to 2.2.4.3 - skalibs: bump version to 2.3.9.0 - s6-rc: bump version to 0.0.2.1 - execline: bump version to 2.1.4.5 - buildroot: bump version to 2015.11 buildroot-s6 is a sandbox to play with the s6 stack and see how it could be integrated into the official Buildroot. It is still a work-in-progress. Comments welcomed! [1] https://github.com/elebihan/buildroot-s6/ -- ELB
[announce] buildroot-s6 0.2.0
Hi! The version 0.2.0 of buildroot-s6, a set of Makefiles to generate embedded Linux systems using s6 as init system, is available [1]. What's new? - update of the s6 stack. - possibility to select "s6 init" as init system in Buildroot configuration menu. - addition of s6-linux-init-skeleton. - fix for system shutdown (courtesy of /etc/rc.tini). Formerly, all the files needed to use s6 as an init system were stored in the "custom" subdirectory. In order to allow the user to select "s6 init" as init system, I added a new package named "s6-linux-init-skeleton", which now provides all the files for a basic setup (inspired by the examples from s6-rc). The "custom" directory now only contains the files for the user custom services (e.g. running `rngd` on the Raspberry Pi). See buildroot/package/s6-linux-init-skeleton/files for details. s6-linux-init-skeleton still needs improvements to be properly integrated into Buildroot (e.g. better network/disk management). buildroot-s6 is a sandbox to play with the s6 stack and see how it could be integrated into the official Buildroot. It is still a work-in-progress. About the branching model: the "stable" version will always be available on the "master" branch, the latest developments will take place on "develop" (thank you, Captain Obvious). About the version scheme: stable version string will always contains even numbers (e.g. 0.2.0), development/intermediate/unstable version string will always contains odd numbers (e.g. 0.3.1). I will shortly release 0.2.2, with an update of the s6 stack. Comments welcomed! [1] https://github.com/elebihan/buildroot-s6/ -- ELB
Re: s6 hangs at shutdown
Hi everybody! On Thu, Nov 12, 2015 at 06:37:00PM +0100, Laurent Bercot wrote: > On 12/11/2015 16:45, Alex Suykov wrote: > > s6-svc: fatal: unable to control /run/service/s6-svscan-log: supervisor > > not listening > >(...) > >By this point ps shows pid 1 as > > > > foreground s6-rc -ad change foreground s6-echo Performing reboot. > > s6-reboot > > Indeed: it's a mistake to run "s6-rc -ad change" in /etc/rc.shutdown, > because by that point s6-svscan is not running anymore. s6-rc needs an > operational supervision tree. > > "s6-rc -ad change" should be run before switching to stage 3. > Éric, can you please change this? The latest version of s6-linux-init > produces a set of scripts that work, with an additional /etc/rc.tini > to perform that kind of "stage 2 shutdown". The "develop" branch of the repository contains an updated version of the s6 stack, as well as improvements and fixes for this problem (namely the use of /etc/rc.tini). I will merge it shortly into "master". -- ELB
Re: buildroot-s6: s6 Supervision for Embedded Devices
Hi! On Mon, Oct 05, 2015 at 02:09:41PM +0200, Laurent Bercot wrote: > On 05/10/2015 11:52, Eric Le Bihan wrote: > >- To cross-compile skalibs the documentation of skalibs recommends generating > > the sysdeps offline. This is a problem for Buildroot, as many > > architectures > > are supported and providing sysdeps for them is a no-go. I provide a > > patch for > > skalibs which replaces the run time tests for some type sizes and > > endianness > > with some compile time tests. This removes the need for offline sysdeps. > > I don't understand: if you cross-compile, compile-time tests will always > give the wrong results. How do other systems handle cross-compilation, for > instance wrt endianness? There has to be a database of sysdeps somewhere, > that lists the functionalities of various archs. How does Buildroot handle it? > It's certainly possible to make skalibs tap into that database to extract its > own sysdeps; please tell me if I can help. Buildroot does not have a database of sysdeps. It relies on two things: 1. a description of the supported platforms: name and endianness (see buildroot/arch/Config.in*) 2. the tests provided by the packages themselves (via the autotools or cmake), most of them of the try-compile form. The aforementionned patch is available in the buildroot/package/skalibs [1]. It patches the ./configure of skalibs as follow: 1. replace the src/sysdeps/trysize*.c with generated code to try all the possible sizes of each desired type. When the cross-compiler builds one code successfully then the size of the type has been found. 2. replace the src/sysdeps/tryendianness.c with one for testing little endian and the other for big endian, using the predefined macros from GCC and clang. Hunk 1 does not rely on cross-compiler features, whereas hunk 2 does, so I think I will modify the patch as follow: - keep hunk 1 - remove the tryendianness part and dump the value of Buildroot BR2_ENDIAN variable in the generated sysdeps.h instead. The parts where ./configure tries to link with a library are OK. [1] buildroot/package/skalibs/skalibs-0001-No-runtime-tests-for-type-sizes-nor-endianness.patch -- ELB
buildroot-s6: s6 Supervision for Embedded Devices
Hi all! In order to use s6 and friends on embedded devices, I added support for them in [Buildroot](http://buildroot.org), a set of Makefiles which make building Linux embedded systems easy. As these patches are not available upstream yet, I've created a playground: [buildroot-s6](https://github.com/elebihan/buildroot-s6/). In this playground, the user can build a firmware using s6-rc as init system for the following platforms: - QEMU/x86, dynamically linked against glibc. - Raspberry Pi, statically linked against musl. ATM, I only added the skarnet.org software stack as packages in Buildroot (see "buildroot/package"), the skeleton for using s6-rc as init is available outside (in the "custom" directory of the project). The objective is to add another package for it and allow the user to select s6-rc as init from the configuration menu (among Busybox, SysV and systemd). Additional information: - Buildroot allows the user to build a cross-compilation toolchain using glibc, musl or uclibc-ng. The build of skalibs fails with the later. More details soon. - To cross-compile skalibs the documentation of skalibs recommends generating the sysdeps offline. This is a problem for Buildroot, as many architectures are supported and providing sysdeps for them is a no-go. I provide a patch for skalibs which replaces the run time tests for some type sizes and endianness with some compile time tests. This removes the need for offline sysdeps. This patch may be fine for Buildroot, but I have not verified its portability. - The source files for the s6-rc service database are not stored in the firmware images. The database is built offline. Comments welcomed. Best regards, ELB
