[Buildroot] Possible conflict with systemd and e2fsprogs?

[Buildroot] Possible conflict with systemd and e2fsprogs?

[Dominik Menke]

Greetings,

I've run into trouble with the following configuration on Buildroot 
2019.02.1-100-g88eff22a9e (current 2019.02.x branch):

     (
       echo BR2_INIT_SYSTEMD=y
       echo BR2_PACKAGE_E2FSPROGS=y
     ) | cat configs/raspberrypi3_defconfig - > configs/myrpi_defconfig
     make myrpi_defconfig

The actual board is a RPi 3B+, and the resulting system fails badly on 
systemd-fsck-root.service (shortly after it found and mounted /dev/root):

     [FAILED] Failed to start File System Check on Root Device.
     See 'systemctl status systemd-fsck-root.service' for details.

Some green OK's appear, but most succeeding services fail to start. It 
looks like mounting the root file system fails completely, and I don't 
get a prompt, which makes checking the status as suggested a bit hard.

(sidenote: I can't see the preceeding log messages, because the scroll 
buffer on /dev/tty1 is too small, setting enable_uart=1 in 
/boot/config.txt [0] doesn't give me a serial console, systemd.log_level 
and similar kernel command line parameters are ignored... the RPi is a 
fun device to play with :-))

I've build the exact system without BR2_PACKAGE_E2FSPROGS, and that 
system does boot without problems.

make menuconfig tells me

     Symbol: BR2_PACKAGE_E2FSPROGS_FSCK [=n]
     Type  : bool
     Prompt: fsck
       Location: (omitted)
       Defined at package/e2fsprogs/Config.in:45
       Depends on: BR2_PACKAGE_E2FSPROGS [=y] &&
                   !BR2_PACKAGE_UTIL_LINUX_FSCK [=y]

which (should) configure e2fsprogs with --disable-fsck [1]. However, 
that only means to not build the wrapper (i.e. /sbin/fsck) [2].

In comparing the two systems built, I've noticed that the one including 
e2fsprogs contains additional binaries /sbin/fsck.ext{2,3,4} which 
symlink to /sbin/e2fsck.

Looking at /usr/lib/systemd/systemd-fsck (which is executed by 
systemd-fsck-root.service), it calls to /sbin/fsck only if 
/sbin/fsck.$type exists [3]. My guess is that it then fails to proceed 
because e2fsprog's fsck behaves differently then fsck (of package util 
linux).

I can't really go without systemd (I'm building appliances deeply 
integrated with it), and I do need to be able to resize/enlarge a data 
partition on a live system; I'm not sure how to proceed from here. I 
mean, I could rm/mv the fsck.* binaries in a post-build hook, but are 
there (cleaner) approaches?

Thanks for your time,
Dominik


[0]: https://www.raspberrypi.org/documentation/configuration/uart.md
[1]: 
https://git.busybox.net/buildroot/tree/package/e2fsprogs/e2fsprogs.mk?h=88eff22a9e#n42
[2]: 
https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/tree/configure?h=v1.44.5#n1554
[3]: https://github.com/systemd/systemd/blob/v240/src/fsck/fsck.c#L343-L349

[Buildroot] Possible conflict with systemd and e2fsprogs?

[Arnout Vandecappelle]

On 25/04/2019 20:15, Dominik Menke wrote:
> Greetings,
> 
> I've run into trouble with the following configuration on Buildroot
> 2019.02.1-100-g88eff22a9e (current 2019.02.x branch):
> 
> ??? (
> ????? echo BR2_INIT_SYSTEMD=y
> ????? echo BR2_PACKAGE_E2FSPROGS=y
> ??? ) | cat configs/raspberrypi3_defconfig - > configs/myrpi_defconfig
> ??? make myrpi_defconfig
[snip]
> Looking at /usr/lib/systemd/systemd-fsck (which is executed by
> systemd-fsck-root.service), it calls to /sbin/fsck only if /sbin/fsck.$type
> exists [3]. My guess is that it then fails to proceed because e2fsprog's fsck
> behaves differently then fsck (of package util linux).

 It would be good to find out what exactly is going wrong.
package/systemd/Config.in does select BR2_PACKAGE_UTIL_LINUX_FSCK precisely for
this reason...
I'm adding Carlos (who added that) in Cc, maybe he has something to say about it.

 If it now needs the fsck from e2fsprogs, then it is getting a little tricky to
do the right thing. We'd have to revert the dependency between e2fsprogs fsck
and util-linux fsck.

 However, I seem to recall that e2fsprogs fsck was considered deprecated.

 Regards,
 Arnout

[Buildroot] Possible conflict with systemd and e2fsprogs?

[Dominik Menke]

On 4/27/19 7:56 PM, Arnout Vandecappelle wrote:
> On 25/04/2019 20:15, Dominik Menke wrote:
>> I've run into trouble with the following configuration on Buildroot
>> 2019.02.1-100-g88eff22a9e (current 2019.02.x branch):
>>
>>  ??? (
>>  ????? echo BR2_INIT_SYSTEMD=y
>>  ????? echo BR2_PACKAGE_E2FSPROGS=y
>>  ??? ) | cat configs/raspberrypi3_defconfig - > configs/myrpi_defconfig
>>  ??? make myrpi_defconfig

As pointed out in another response, BR2_TOOLCHAIN_BUILDROOT_GLIBC=y is 
missing here.


> [snip]
>> Looking at /usr/lib/systemd/systemd-fsck (which is executed by
>> systemd-fsck-root.service), it calls to /sbin/fsck only if /sbin/fsck.$type
>> exists [3]. My guess is that it then fails to proceed because e2fsprog's fsck
>> behaves differently then fsck (of package util linux).
> 
>   It would be good to find out what exactly is going wrong.

Any advise on how I can to get more information? I'm struggeling with 
the UART of the RPi 3B+ to be usable (this may be related to issue 11766 
[0]). Currently, I only have the output on the Monitor connected on the 
HDMI port, only a few pages of scrollback buffer, and no way to interact 
with the system.

[0]: https://bugs.busybox.net/show_bug.cgi?id=11766


> package/systemd/Config.in does select BR2_PACKAGE_UTIL_LINUX_FSCK precisely for
> this reason...
> I'm adding Carlos (who added that) in Cc, maybe he has something to say about it.
> 
>   If it now needs the fsck from e2fsprogs, then it is getting a little tricky to
> do the right thing. We'd have to revert the dependency between e2fsprogs fsck
> and util-linux fsck.

I don't think systemd needs e2fsprog's fsck. *I* need e2fsprogs, but 
only for its resize2fs (nevertheless, it also installs /sbin/fsck.ext4). 
However, systemd finds /sbin/fsck.ext4, and proceeds to execute /sbin/fsck.

My current working theory is that /sbin/fsck then in turn calls out to 
/sbin/fsck.ext4. As far as I can tell, /sbin/fsck originates from 
util-linux, while /sbin/fsck.* come from e2fsprogs.


>   However, I seem to recall that e2fsprogs fsck was considered deprecated.
> 
>   Regards,
>   Arnout

Kind Regards,
Dominik

[Buildroot] Possible conflict with systemd and e2fsprogs?

[Arnout Vandecappelle]

On 27/04/2019 23:20, Dominik Menke wrote:
> On 4/27/19 7:56 PM, Arnout Vandecappelle wrote:
>> On 25/04/2019 20:15, Dominik Menke wrote:
>>> I've run into trouble with the following configuration on Buildroot
>>> 2019.02.1-100-g88eff22a9e (current 2019.02.x branch):
>>>
>>> ???? (
>>> ?????? echo BR2_INIT_SYSTEMD=y
>>> ?????? echo BR2_PACKAGE_E2FSPROGS=y
>>> ???? ) | cat configs/raspberrypi3_defconfig - > configs/myrpi_defconfig
>>> ???? make myrpi_defconfig
> 
> As pointed out in another response, BR2_TOOLCHAIN_BUILDROOT_GLIBC=y is missing
> here.
> 
> 
>> [snip]
>>> Looking at /usr/lib/systemd/systemd-fsck (which is executed by
>>> systemd-fsck-root.service), it calls to /sbin/fsck only if /sbin/fsck.$type
>>> exists [3]. My guess is that it then fails to proceed because e2fsprog's fsck
>>> behaves differently then fsck (of package util linux).
>>
>> ? It would be good to find out what exactly is going wrong.
> 
> Any advise on how I can to get more information? I'm struggeling with the UART
> of the RPi 3B+ to be usable (this may be related to issue 11766 [0]). Currently,
> I only have the output on the Monitor connected on the HDMI port, only a few
> pages of scrollback buffer, and no way to interact with the system.
> 
> [0]: https://bugs.busybox.net/show_bug.cgi?id=11766

 I've tried to reproduce in qemu, but it works fine there. This is the defconfig
I used:

BR2_arm=y
BR2_cortex_a9=y
BR2_ARM_ENABLE_VFP=y
BR2_CCACHE=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_CUSTOM=y
BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD=y
BR2_TOOLCHAIN_EXTERNAL_URL="http://autobuild.buildroot.org/toolchains/tarballs/br-arm-cortex-a9-glibc-2019.02-rc1.tar.bz2"
BR2_TOOLCHAIN_EXTERNAL_GCC_8=y
BR2_TOOLCHAIN_EXTERNAL_HEADERS_4_20=y
BR2_TOOLCHAIN_EXTERNAL_CUSTOM_GLIBC=y
BR2_TOOLCHAIN_EXTERNAL_CXX=y
BR2_INIT_SYSTEMD=y
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_DEFCONFIG="vexpress"
BR2_LINUX_KERNEL_DTS_SUPPORT=y
BR2_LINUX_KERNEL_INTREE_DTS_NAME="vexpress-v2p-ca9"
BR2_PACKAGE_E2FSPROGS=y
BR2_TARGET_ROOTFS_EXT2=y
BR2_TARGET_ROOTFS_EXT2_4=y


and this is the qemu command to launch:

qemu-system-arm -M vexpress-a9 \
  -drive "file=output/images/rootfs.ext2,if=sd,format=raw" \
  -append "root=/dev/mmcblk0 rootfstype=ext4 rootwait ro console=ttyAMA0" \
  -net nic,model=lan9118 -net user -dtb output/images/vexpress-v2p-ca9.dtb \
  -serial stdio -kernel output/images/zImage


Gives this output:

...
         Starting File System Check on Root Device...
...
[  OK  ] Started File System Check on Root Device.
         Starting Remount Root and Kernel File Systems...
EXT4-fs (mmcblk0): Filesystem with huge files cannot be mounted RDWR without
CONFIG_LBDAF
systemd[1]: systemd-remount-fs.service: Main process exited, code=exited,
status=1/FAILURE
systemd[1]: systemd-remount-fs.service: Failed with result 'exit-code'.
systemd[1]: Failed to start Remount Root and Kernel File Systems.
[FAILED] Failed to start Remount Root and Kernel File Systems.
See 'systemctl status systemd-remount-fs.service' for details.
...
Welcome to Buildroot
buildroot login:

 The remount error is because the filesystem isn't created with ^huge_file
(which we probably should do, as mentioned before somewhere on the list). But it
should not affect fsck AFAIU...


>> package/systemd/Config.in does select BR2_PACKAGE_UTIL_LINUX_FSCK precisely for
>> this reason...
>> I'm adding Carlos (who added that) in Cc, maybe he has something to say about it.
>>
>> ? If it now needs the fsck from e2fsprogs, then it is getting a little tricky to
>> do the right thing. We'd have to revert the dependency between e2fsprogs fsck
>> and util-linux fsck.
> 
> I don't think systemd needs e2fsprog's fsck. *I* need e2fsprogs, but only for
> its resize2fs (nevertheless, it also installs /sbin/fsck.ext4). However, systemd
> finds /sbin/fsck.ext4, and proceeds to execute /sbin/fsck.
> 
> My current working theory is that /sbin/fsck then in turn calls out to
> /sbin/fsck.ext4. As far as I can tell, /sbin/fsck originates from util-linux,
> while /sbin/fsck.* come from e2fsprogs.

 Yes indeed. And all that is exactly how it's supposed to work. So I don't
really understand why it doesn't work for you.


 Regards,
 Arnout

[Buildroot] Possible conflict with systemd and e2fsprogs?

[Dominik Menke]

On 4/27/19 11:47 PM, Arnout Vandecappelle wrote:
>   I've tried to reproduce in qemu, but it works fine there. This is the defconfig
> I used:
> 
> [...]
> BR2_TOOLCHAIN_EXTERNAL_HEADERS_4_20=y
> [...]

In 2019.02.x, I can only find max. 4.19, do I need master?


> and this is the qemu command to launch:
> 
> qemu-system-arm -M vexpress-a9 \
>    -drive "file=output/images/rootfs.ext2,if=sd,format=raw" \
>    -append "root=/dev/mmcblk0 rootfstype=ext4 rootwait ro console=ttyAMA0" \
>    -net nic,model=lan9118 -net user -dtb output/images/vexpress-v2p-ca9.dtb \
>    -serial stdio -kernel output/images/zImage

     EXT4-fs (mmcblk0): mounted filesystem with ordered data mode. Opts: 
(null)
     VFS: Mounted root (ext4 filesystem) readonly on device 179:0.
     devtmpfs: mounted
     Freeing unused kernel memory: 1024K
     Run /sbin/init as init process
     FATAL: kernel too old
     Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00

(obvious error is obvious :-))


>>> package/systemd/Config.in does select BR2_PACKAGE_UTIL_LINUX_FSCK precisely for
>>> this reason...
>>> I'm adding Carlos (who added that) in Cc, maybe he has something to say about it.
>>>
>>>  ? If it now needs the fsck from e2fsprogs, then it is getting a little tricky to
>>> do the right thing. We'd have to revert the dependency between e2fsprogs fsck
>>> and util-linux fsck.
>>
>> I don't think systemd needs e2fsprog's fsck. *I* need e2fsprogs, but only for
>> its resize2fs (nevertheless, it also installs /sbin/fsck.ext4). However, systemd
>> finds /sbin/fsck.ext4, and proceeds to execute /sbin/fsck.
>>
>> My current working theory is that /sbin/fsck then in turn calls out to
>> /sbin/fsck.ext4. As far as I can tell, /sbin/fsck originates from util-linux,
>> while /sbin/fsck.* come from e2fsprogs.
> 
>   Yes indeed. And all that is exactly how it's supposed to work. So I don't
> really understand why it doesn't work for you.

I will investigate further.

Kind Regards,
Dominik

[Buildroot] Possible conflict with systemd and e2fsprogs?

[Dominik Menke]

On 4/29/19 11:01 AM, Dominik Menke wrote:
> On 4/27/19 11:47 PM, Arnout Vandecappelle wrote:
>>    [...] So I don't
>> really understand why it doesn't work for you.
>
> I will investigate further.

I now belive the fsck package mashup to be a red herring. I've switched 
to buildroot master (89e70a7077 = systemd 241, e2fsprogs 1.44.5, 
util-linux 2.33, kernel 4.19).

By adding systemd.journald.forward_to_console=1 to /boot/cmdline.txt, 
and sifting through the output I found this beauty:


>          Starting File System Check on Root Device...
> [    4.547439] systemd-fsck[94]: /dev/mmcblk0p2: Superblock last write time (Mon Apr 29 17:37:11 2019,
> [    4.551637] systemd-fsck[94]: 	now = Thu Feb 14 11:11:59 2019) is in the future.
> [    4.552072] systemd-fsck[94]: FIXED.
> [    5.101772] systemd-fsck[94]: /dev/mmcblk0p2: ***** REBOOT SYSTEM *****
> [    5.102214] systemd-fsck[94]: /dev/mmcblk0p2: 4658/65536 files (0.7% non-contiguous), 145524/262144 blocks
> [    5.150450] systemd-fsck[94]: fsck failed with exit status 3.
> [    5.180549] systemd-fsck[94]: Running request reboot.target/start/replace
> [FAILED] Failed to start File System Check on Root Device.
> See 'systemctl status systemd-fsck-root.service' for details.
> [    5.210607] systemd-fsck[94]: Failed to start unit: Unit final.target not found.
> [    5.279763] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
>          Starting Remount Root and Kernel File Systems...
> [    5.294799] systemd[1]: systemd-fsck-root.service: Main process exited, code=exited, status=1/FAILURE
> [  OK  ] Started Remount Root and Kernel File Systems.
> [    5.361063] systemd[1]: systemd-fsck-root.service: Failed with result 'exit-code'.
> [  OK  ] Reached target Local File Systems (Pre).
> [    5.430870] systemd[1]: Failed to start File System Check on Root Device.
> [  OK  ] Reached target Local File Systems.
> [    5.501359] systemd[1]: Starting Remount Root and Kernel File Systems...
>          Starting Rebuild Journal Catalog...
> [    5.560605] systemd[1]: Started Remount Root and Kernel File Systems.
>          Starting Flush Journal to Persistent Storage...
> [    5.620725] systemd[1]: Reached target Local File Systems (Pre).
>          Starting Rebuild Hardware Database...
> [    5.681179] systemd[1]: Reached target Local File Systems.
> [FAILED] Failed to start Rebuild Journal Catalog.
> See 'systemctl status systemd-journal-catalog-update.service' for details.
> [    5.741141] systemd[1]: Condition check resulted in Commit a transient machine-id on disk being skipped.
> [FAILED] Failed to start Flush Journal to Persistent Storage.
> [FAILED] Failed to start Rebuild Hardware Database.
> [FAILED] Failed to start udev Kernel Device Manager.
> [FAILED] Failed to start Create Volatile Files and Directories.
> [FAILED] Failed to start Update is Completed.

Correct me if I'm wrong, but this looks like correcting the (correct) 
last write time to the (wrong) current time, fsck tries to trigger a 
system reboot.

Is this fixable without a real-time clock? ntp becomes available far too 
late in the boot process.

Kind Regards,
Dominik

[Buildroot] Possible conflict with systemd and e2fsprogs?

[Arnout Vandecappelle]

On 29/04/2019 18:18, Dominik Menke wrote:
> [??? 4.547439] systemd-fsck[94]: /dev/mmcblk0p2: Superblock last write time (Mon
> Apr 29 17:37:11 2019,
> [??? 4.551637] systemd-fsck[94]:???? now = Thu Feb 14 11:11:59 2019) is in the
> future.

 My systemd-fu is not great, but it looks weird that now = somewhere in 2019 if
you have no RTC. I believe fsck has code to ignore the time-in-future check if
now ~ 1970.

 Regards,
 Arnout

[Buildroot] Possible conflict with systemd and e2fsprogs?

[Dominik Menke]

On 4/29/19 10:37 PM, Arnout Vandecappelle wrote:
> On 29/04/2019 18:18, Dominik Menke wrote:
>> [??? 4.547439] systemd-fsck[94]: /dev/mmcblk0p2: Superblock last write time (Mon
>> Apr 29 17:37:11 2019,
>> [??? 4.551637] systemd-fsck[94]:???? now = Thu Feb 14 11:11:59 2019) is in the
>> future.
> 
>   My systemd-fu is not great, but it looks weird that now = somewhere in 2019 if
> you have no RTC. I believe fsck has code to ignore the time-in-future check if
> now ~ 1970.

The "now" date coincides with the commit date of 
https://github.com/systemd/systemd/commit/e62a7fea757f259eb330da5b6d3ab4ede46400a2. 
 From what I can gather, systemd-timesyncd claims to be responsible for 
setting the initial boot time. systemd-timesyncd.service(8) reads:

> /var/lib/systemd/timesync/clock
>     
> The modification time of this file indicates the timestamp of the
> last successful synchronization (or at least the systemd build date,
> in case synchronization was not possible).

However, after disabling systemd-timesyncd (in menuconfig) and a clean 
build, the date persists...

I'm now considering to permanently add fsck.mode=skip to the kernel 
command line. That'll restore the default behaviour for BR2 systems with 
systemd enabled and ext4 partitions (util-linux' fsck does not provide 
support for those).

My short term goal is to get to an A/B booting scheme anyway. I can then 
trigger fsck manually on the running system for the *other* root fs, 
instead of the *current* root fs.

I'm aware this is a "works for me" solution.

Again, thanks for your time and input!
Dominik

[Buildroot] Possible conflict with systemd and e2fsprogs?

[Yann E. MORIN]

On 2019-04-25 20:15 +0200, Dominik Menke spake thusly:
> Greetings,
> 
> I've run into trouble with the following configuration on Buildroot
> 2019.02.1-100-g88eff22a9e (current 2019.02.x branch):
> 
>     (
>       echo BR2_INIT_SYSTEMD=y
>       echo BR2_PACKAGE_E2FSPROGS=y
>     ) | cat configs/raspberrypi3_defconfig - > configs/myrpi_defconfig
>     make myrpi_defconfig

How can that even work, when systemd depends on glibc?

And indeed, here, systemd is not selected when I do the above
commands...

Regards,
Yann E. MORIN.

> The actual board is a RPi 3B+, and the resulting system fails badly on
> systemd-fsck-root.service (shortly after it found and mounted /dev/root):
> 
>     [FAILED] Failed to start File System Check on Root Device.
>     See 'systemctl status systemd-fsck-root.service' for details.
> 
> Some green OK's appear, but most succeeding services fail to start. It looks
> like mounting the root file system fails completely, and I don't get a
> prompt, which makes checking the status as suggested a bit hard.
> 
> (sidenote: I can't see the preceeding log messages, because the scroll
> buffer on /dev/tty1 is too small, setting enable_uart=1 in /boot/config.txt
> [0] doesn't give me a serial console, systemd.log_level and similar kernel
> command line parameters are ignored... the RPi is a fun device to play with
> :-))
> 
> I've build the exact system without BR2_PACKAGE_E2FSPROGS, and that system
> does boot without problems.
> 
> make menuconfig tells me
> 
>     Symbol: BR2_PACKAGE_E2FSPROGS_FSCK [=n]
>     Type  : bool
>     Prompt: fsck
>       Location: (omitted)
>       Defined at package/e2fsprogs/Config.in:45
>       Depends on: BR2_PACKAGE_E2FSPROGS [=y] &&
>                   !BR2_PACKAGE_UTIL_LINUX_FSCK [=y]
> 
> which (should) configure e2fsprogs with --disable-fsck [1]. However, that
> only means to not build the wrapper (i.e. /sbin/fsck) [2].
> 
> In comparing the two systems built, I've noticed that the one including
> e2fsprogs contains additional binaries /sbin/fsck.ext{2,3,4} which symlink
> to /sbin/e2fsck.
> 
> Looking at /usr/lib/systemd/systemd-fsck (which is executed by
> systemd-fsck-root.service), it calls to /sbin/fsck only if /sbin/fsck.$type
> exists [3]. My guess is that it then fails to proceed because e2fsprog's
> fsck behaves differently then fsck (of package util linux).
> 
> I can't really go without systemd (I'm building appliances deeply integrated
> with it), and I do need to be able to resize/enlarge a data partition on a
> live system; I'm not sure how to proceed from here. I mean, I could rm/mv
> the fsck.* binaries in a post-build hook, but are there (cleaner)
> approaches?
> 
> Thanks for your time,
> Dominik
> 
> 
> [0]: https://www.raspberrypi.org/documentation/configuration/uart.md
> [1]: https://git.busybox.net/buildroot/tree/package/e2fsprogs/e2fsprogs.mk?h=88eff22a9e#n42
> [2]: https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/tree/configure?h=v1.44.5#n1554
> [3]: https://github.com/systemd/systemd/blob/v240/src/fsck/fsck.c#L343-L349
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] Possible conflict with systemd and e2fsprogs?

[Dominik Menke]

On 4/27/19 8:08 PM, Yann E. MORIN wrote:
> On 2019-04-25 20:15 +0200, Dominik Menke spake thusly:
>> I've run into trouble with the following configuration on Buildroot
>> 2019.02.1-100-g88eff22a9e (current 2019.02.x branch):
>>
>>      (
>>        echo BR2_INIT_SYSTEMD=y
>>        echo BR2_PACKAGE_E2FSPROGS=y
>>      ) | cat configs/raspberrypi3_defconfig - > configs/myrpi_defconfig
>>      make myrpi_defconfig
> 
> How can that even work, when systemd depends on glibc?
> 
> And indeed, here, systemd is not selected when I do the above
> commands...

I may have forgotten to include BR2_TOOLCHAIN_BUILDROOT_GLIBC=y, yes. I 
must have assumed selecting BR2_INIT_SYSTEMD would also change the libc 
selection automatically, so I didn't verify that this is actually the 
case (because, as you say, systemd depends on it).

Please find my complete defconfig here:

BR2_arm=y
BR2_cortex_a53=y
BR2_ARM_FPU_NEON_VFPV4=y
BR2_TOOLCHAIN_BUILDROOT_GLIBC=y
BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_14=y
BR2_BINUTILS_VERSION_2_31_X=y
BR2_GCC_VERSION_8_X=y
BR2_TOOLCHAIN_BUILDROOT_CXX=y
BR2_INIT_SYSTEMD=y
BR2_TARGET_LOCALTIME="Europe/Berlin"
BR2_ROOTFS_POST_BUILD_SCRIPT="board/raspberrypi3/post-build.sh"
BR2_ROOTFS_POST_IMAGE_SCRIPT="board/raspberrypi3/post-image.sh"
BR2_ROOTFS_POST_SCRIPT_ARGS="--gpu_mem_1024=256"
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_TARBALL=y
BR2_LINUX_KERNEL_CUSTOM_TARBALL_LOCATION="$(call 
github,raspberrypi,linux,83b36f98e1a48d143f0b466fcf9f8c4e382c9a1c)/linux-83b36f98e1a48d143f0b466fcf9f8c4e382c9a1c.tar.gz"
BR2_LINUX_KERNEL_DEFCONFIG="bcm2709"
BR2_LINUX_KERNEL_DTS_SUPPORT=y
BR2_LINUX_KERNEL_INTREE_DTS_NAME="bcm2710-rpi-3-b bcm2710-rpi-3-b-plus 
bcm2710-rpi-cm3"
BR2_PACKAGE_E2FSPROGS=y
BR2_PACKAGE_OPENSSH=y
BR2_TARGET_ROOTFS_EXT2=y
BR2_TARGET_ROOTFS_EXT2_4=y
BR2_TARGET_ROOTFS_EXT2_SIZE="150M"
# BR2_TARGET_ROOTFS_TAR is not set
BR2_PACKAGE_HOST_DOSFSTOOLS=y
BR2_PACKAGE_HOST_GENIMAGE=y
BR2_PACKAGE_HOST_MTOOLS=y


Kind Regards,
Dominik