Re: "mode" option in live config
Lyndon I really appreciate the effort you put in for this. I probably
will need instructions on how to test with the patch but I will test
it over the next few days and let you know how it goes.
Cheers.
Michael.
On 25/08/2021, Lyndon Brown <jnqnfe@gmail.com> wrote:
> 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: