On 13/02/2021 18:05, Cyril Brulebois wrote:
> Wilco Baan Hofman <wi...@baanhofman.nl> (2021-02-13):
>> I managed to work around it. It seems as when you use 'in-target' in the
>> late script, that the problem starts to occur. chroot /target xxxx does
>> not trigger it.
>>
>> Still, it's a bit strange to have it start to chain to individual
>> commands together as if it is one.
>
> That's interesting. in-target mostly sets up a passthrough mode for
> debconf, which could explain the differences between `in-target` and
> `chroot /target` calls. I'm not sure why this would interfere with
> debconf though.
>
> Any chance you could be more specific about what you were doing via
> in-target? Having some way to reproduce the issue would be a start.
Well, mostly overwriting configuration files to only allow root group su
access and putting in SSH keys + cron job for maintaining those, postfix
config file, adding central syslog to rsyslog.conf, etc... But I'm
guessing those are all irrelevant.
What could be relevant (cobbler syntax):
====
#if $getVar("$init", "sysvinit") != "systemd"
# Remove systemd and dbus
dpkg -P systemd dbus libpam-systemd libnss-systemd
# Add systemd removal hints to APT
printf "Package: systemd-sysv\nPin: release o=Debian\nPin-Priority:
-1\n" > /etc/apt/preferences.d/use-sysvinit
#end if
#
# Stop quiet boot, we want debuggable boot and serial.
#
sed -i 's#^\(GRUB_CMDLINE_LINUX_DEFAULT\)="quiet"$#\1="console=tty0
console=ttyS0,115200n8"#' /etc/default/grub
update-grub
====
I'm guessing either update-grub or dpkg at that point may have some effect.
Kind regards,
-- Wilco
