That's fine Lyndon.
On 31/08/2021, Lyndon Brown <
jnqnfe@gmail.com> wrote:
> 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.
>> > > > > > > > >
>> > > > > > > >
>> > > > > > > >
>> > > > > > > >
>> > > > > >
>> > > > > >
>> > > > >
>> > > > >
>> > > > >
>> > >
>> > >
>> >
>
>
>