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