Re: "mode" option in live config

[Michael AU <keltoiboy@gmail.com>]

Just to add to the previous message all I want to stop is systemd-sysv
from downloading and installing then being removed . It isn't
efficient and doesn't provide users with much choice.

Thanks again for your efforts.
Cheers.
Michael.

On 31/08/2021, Michael AU <keltoiboy@gmail.com> wrote:
> Hi Lyndon
>
> It appears as though the patch isn't working. Please note below the
> relevant section from the build log.
> "I: Retrieving libsystemd0 247.3-6
> I: Validating libsystemd0 247.3-6
> I: Retrieving libudev1 247.3-6
> I: Validating libudev1 247.3-6
> I: Retrieving systemd 247.3-6
> I: Validating systemd 247.3-6
> I: Retrieving systemd-sysv 247.3-6
> I: Validating systemd-sysv 247.3-6
> I: Retrieving systemd-timesyncd 247.3-6
> I: Validating systemd-timesyncd 247.3-6
> I: Retrieving udev 247.3-6
> I: Validating udev 247.3-6
> I: Retrieving initscripts 2.96-7
> I: Validating initscripts 2.96-7
> I: Retrieving sysv-rc 2.96-7
> I: Validating sysv-rc 2.96-7
> I: Retrieving sysvinit-core 2.96-7
> I: Validating sysvinit-core 2.96-7
> I: Retrieving sysvinit-utils 2.96-7
> I: Validating sysvinit-utils 2.96-7"
>
> Let me know if there is anything else you need me to do.
> Cheers.
> Michael.
>
> On 29/08/2021, Lyndon Brown <jnqnfe@gmail.com> wrote:
>> Sorry for the delay. There are several ways to accomplish installing a
>> copy of the modified code for testing.
>>
>> The simplest would be if I could wrap it up into a new `.deb` package
>> for you to simply install, but I'm not familiar enough with debian
>> packaging to get that done, sorry.
>>
>> So alternatively you essentially just need to (1) grab a copy of the
>> modified live-build program files and then (2) install them (replace
>> the copies already installed by `apt`). (No "compiling" of the code is
>> necessary due to the language it is written in).
>>
>> You can accomplish step 1 (getting a new copy of the live-build program
>> files with my fix included), from the "branch" I've made for this work
>> here: https://salsa.debian.org/jnqnfe/live-build/-/tree/sysvinit
>> Towards the top right there's a button with which you can download a
>> copy in a zip file. Just download it as a zip file and extract its
>> contents to a folder somewhere.
>>
>> You should find that the extracted folder is called "live-build-
>> sysvinit". You'll need to rename it simply to "live-build" for the next
>> step since my install script expects it to have that name.
>>
>> To accomplish step 2 (installing it), I've attached a copy of the shell
>> script that I use myself during development. Place a copy of this
>> alongside the "live-build" folder from above, such that you have the
>> following structure:
>>
>>  - inst_lb.sh
>>  - live-build/
>>     - <directory contents, like the "functions" folder>
>>
>> Then, presuming you know the absolute basics of using a terminal, open
>> a terminal, `cd` to the folder containing the install script and "live-
>> build" directory, then run the following command:
>>
>> sudo ./inst_lb.sh
>>
>> This will run my script (which needs "sudo" permissions) which will
>> proceed to replace any already installed copy of live-build with the
>> modified copy.
>>
>> You can then simply test as normal making a systemd build vs a sysvinit
>> build, to check that my fix works.
>>
>> Afterwards you can either just leave this new modified copy in place
>> for now (it'll get replaced when `apt` next installs an updated
>> official package), or you can ask `apt` to reinstall the current
>> official package via `apt reinstall live-build`.
>>
>>
>> On Wed, 2021-08-25 at 14:56 +1000, Michael AU wrote:
>>> 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.
>>> > > > > >
>>> > > > >
>>> > > > >
>>> > > > >
>>> > >
>>> > >
>>> >
>>> >
>>> >
>>
>>
>