Re: "mode" option in live config
Just to update you since my previous reply:
- I've filed a bug report for this issue - #992916 ([1]).
- I've produced a patch (MR found at [2]) that should fix the
broken/incomplete implementation of `--initsystem sysvinit`.
If you could please test this that would be great. It took some hours
to put this together in the end, and that's without actually doing any
test builds. Confirmation that it works will be needed before the patch
can be merged into the codebase.
If you need instructions for how to test with the patch, just let me
know.
[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992916
[2]: https://salsa.debian.org/live-team/live-build/-/merge_requests/257
On Tue, 2021-08-24 at 23:17 +0100, Lyndon Brown wrote:
> I see. As I said, I'm very busy with little to no time to spare for
> live-build work / support currently, so I'm afraid there's a limit to
> how much I can help with this. However...
>
> The first thing that I would say is that I'm not certain whether a
> working sysvinit setup is possible on Debian currently. I
> occasionally
> notice the odd discussion about it on the debian-dev mailing list and
> I
> seem to recall that while there's some desire to still support it,
> there's a lack of effort and support might be in a bad shape. So it
> would perhaps be a good idea for you to have a look at those
> discussions first if you've not already, to consider the practicality
> of having a working sysvinit based setup.
>
> With that said, `--mode` has absolutely no impact upon your init
> system
> choice. There is though the `--initsystem` option which is
> specifically
> intended for choosing between systemd or sysvinit, as I'm sure you've
> already noticed and tried. However it's functionality seems currently
> incomplete / broken.
>
> The only thing that `--initsystem` currently achieves is to add
> packages `live-config-sysvinit` and `sysvinit-core` instead of `live-
> config-systemd` to `config/package-lists/live.list.chroot` (if that
> file does not already exist and if `LB_INITRAMFS` is set to `live-
> boot`
> either explicitly via `--initramfs` or by default if `--system` is
> set
> to `live`, as is the default). This of course just specifies some
> additional packages to install to the final live filesystem though.
>
> The inclusion of `sysvinit-core` in that list, and your pinning of
> `systemd-sysv` in your apt config, are both going to fail to achieve
> the desired objective because `systemd-sysv` is actually being
> installed during the initial bootstrapping stage by debootstrap.
>
> Now, getting debootstrap to install `sysvinit-core` instead of
> `systemd-sysv` is very possible as explained at [1]; we're just
> lacking
> an implementation of this procedure. To get `--initsystem sysvinit`
> to
> work, we would have to adapt the `bootstrap_debootstrap` script to
> implement the procedure described in that article. I expect that then
> you'd get a correct sysvinit based setup. We actually already do a
> similar procedure in that script for qemu builds, which should help
> with figuring out how to correctly implement it, but this of course
> requires someone with some spare time to carefully implement and test
> the changes. I can perhaps spare the time to make the changes, but I
> don't have the time to do all of the testing. I'll perhaps try to
> quickly put together the necessary change now and publish the change
> as
> an MR. It'll need someone other than myself to put in the testing
> effort though.
>
> There does not seem to be a bug report about this against the live-
> build package currently. I'll make one.
>
> [1]:
> https://www.notinventedhere.org/articles/linux/debootstrapping-debian-jessie-without-systemd.html
>
>
> On Tue, 2021-08-24 at 17:16 +1000, Michael AU wrote:
> > Hi Lyndon, thanks for your reply.
> >
> > My query about "mode" is because I want to use sysvinit instead of
> > systemd. I can build an MX style system but it always pulls in
> > systemd-sysv even though it is pinned as don't install.
> >
> > I tried using Devuan but it doesn't work in live-build anymore, and
> > while wicd is ok it does leave alot to be desired. That is why I
> > tried
> > "mode" to see if it still works and to my surprise a few of its
> > functions did still work in buster.
> >
> > So looking for advice on how best to stop systemd-sysv from being
> > pulled in at all as while I do not mind systemd I do not want to
> > force
> > it on people.
> >
> > Cheers.
> > Michael.
> >
> > On 24/08/2021, Lyndon Brown <jnqnfe@gmail.com> wrote:
> > > The live-build `--mode` option was for allowing for any
> > > variations
> > > necessary for building images for derivative distros, like Ubuntu
> > > and
> > > "Progress" (which is/was a distro produced by the original live-
> > > build
> > > author Daniel B).
> > >
> > > In part this includes adjusting labels and filenames. Furthermore
> > > it
> > > impacts mirror URLs; It affects the contents written to apt
> > > source
> > > list
> > > files; and it also happens to control whether or not a few extra
> > > packages are included during the installer build stage.
> > >
> > > There used to also be a chunk of code to do with setting up
> > > authentication keys for a "Progress" distro build, however this
> > > was
> > > ripped out some time ago along with other bits of code that
> > > implemented
> > > explicit non-debian distro-specific hacks/variations.
> > >
> > > It's been a quite a while since I had any time to get work done
> > > on
> > > live-build. As far as I recall, and from rough notes in my to-do
> > > list,
> > > `--mode` is in a state of needing to be untangled and removed. We
> > > don't
> > > want a bunch of distro hacks all over the place. However do we
> > > still
> > > want to allow customisation of things like labels/URLs/etc of
> > > course,
> > > for instance to meet the needs of the Kali distro use case. This
> > > adds a
> > > level of complication blocking just ripping out the remaining `--
> > > mode`
> > > artefacts.
> > >
> > > It is thus essentially a legacy artifact, albeit one that you
> > > must
> > > ensure is set correctly to achieve a working build.
> > >
> > > You can search the codebase for `LB_MODE` to find the places
> > > where
> > > the
> > > value of the option impacts things. Similarly you can search the
> > > git
> > > history of the project to see how things have changed over time
> > > with
> > > respect to it, for instance to see where/when the "Progress"
> > > authentication key stuff was ripped out and what it looked like.
> > >
> > >
> > > On Tue, 2021-08-24 at 05:47 +1000, Michael AU wrote:
> > > > Hello everyone.
> > > > I'm assuming no one has any knowledge of this option and where
> > > > the
> > > > files are that run it then, I know it still works because I
> > > > have
> > > > tried
> > > > it but I would like to understand it by seeing how and where
> > > > the
> > > > different options are called and used.
> > > > Cheers.
> > > > Michael.
> > > >
> > > > > In live build and associated packages there is an option in
> > > > > the
> > > > > config
> > > > > file for "mode". It used to have Debian. Progress, and I
> > > > > think
> > > > > Ubuntu.
> > > > > I am trying to find the files that are associated with this
> > > > > option
> > > > > so
> > > > > I can look at how each option differs from the others. Does
> > > > > anyone
> > > > > know which particular files live build "reads" when it comes
> > > > > across
> > > > > the "mode" option?
> > > > > Cheers.
> > > > > Michael.
> > > >
> > >
> > >
> > >
>
>
Reply to: