Re: "mode" option in live config
Oh yes, sorry I should have mentioned - there's nothing I could do to
stop the systemd packages from being downloaded, I could only prevent
them from being installed, so you'll just have to ignore those
'retrieving' and 'validating' lines.
Most of the changes I've made in the fix is actually to do with working
around a bug in debootstrap to do with package selection. If the
debootstrap devs ever fix the bug, then this will solve the problem of
the unwanted downloads. There's nothing I can do about that side of it
otherwise, I can only add the sysvinit packages to the list and block
the actual installation of systemd.
You can double check that it's not actually installed by running `dpkg
--list | grep systemd` within the live system - the systemd packages
should not be listed in the output (except `libsystemd0` which is
required by `apt` and so I cannot block being installed).
I'm pretty certain that the fix is fine, I just haven't had the time to
actually make some test builds myself to confirm that I've not made
some silly typo that breaks live-build. If running live-build seems to
work fine for you, and you can confirm that the image ends up with the
correct init system installed depending upon the `--initsystem` option
choice, then we can confirm that this is successful. :)
On Tue, 2021-08-31 at 12:04 +1000, Michael AU wrote:
> 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.
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > >
> > >
> >
Reply to: