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 <jnq...@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 <jnq...@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. >> > > > >> > > >> > > >> > > >> >> > > >
