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.
> > > > > >
> > > > >
> > > > >
> > > > >
> > >
> > >
> >
> >
> >
Attachment:
inst_lb.sh
Description: application/shellscript