Live-build - searching for (a) solution(s)

[Hans-J. Ullrich]

Dear list, 

I am using live-build for building kali-linux images. The standard build 
procedure is working well with live-build. But for my purposes I have some 
special needs, which the documentation of live-build does not explain.

I hope, someone experienced can help me.

This is, what I want to do:

1. I want to download and unpack the packages, then create the chroot.
When the changeroot has been created, the script shall stop.

2. When the chroot is existent, I want to make changes in the chroot (edit 
some files, add some files like wordlists etc.). 
I know, I can go into the chroot with the command "chroot /path/to/chroot", 
then work in it, just as in a normal linux system

3. After I have finished my changes, I want to leave the chroot and now create 
the ISO-image of it.

It would be nice, if someone could give me the correct commands. 

Last but not least, there is just a general question, the manual also could 
not answer me. 

Question 1: Must I create for every architecture a seperated live-build 
structure (one for i386, one for amd64, one for arm and so on) or can I build 
in in one environment (just add the --architecture command to the build 
command)?

Question 2: Must I build a livefile for a special architecture in a special 
environment? (Say: Can I build an amd64- or arm-livefile on a 32-bit i386 
system?)

Please send any answers to my privat adress (huns.ullr...@loop.de), as I am 
not subsribed to the list.

Thank you very much for any help.

Best regards

Hans-J. Ullrich

  

problems building custom live image

[Don Raikes]

Hello,

 

I am using live-build to build a custom kali linux 2.0 image, however when I 
try to modify the basic build environment to add some customizations, the 
resulting iso is unbootable.

 

What I want to do:

I want to enable brltty on the running live kali image. 

 

What I have done:

I have created a package list named accessibility.list.binary and added the 
necessary brltty packages to the file.

I have added an etc/rc.local file to config/includes.binary 

In this file I have added the line:

/sbin/brltty

 

Is there something obvious that I am missing in order to get Braille support 
working on the live system?

Re: boot error with backport jessie

[Diederik de Haas]

On Tuesday 17 November 2015 20:33:19 David Ansart wrote:
> It did not worked. live-build 4.0.3-1 is it inconsistent with overlay. 
> Must i do another thing ?

Does it work without backports enabled?
I build an image (with live-build 5.0~a11-1) from a config I had laying around 
with jessie, but without backports and that seems to work.

signature.asc
Description: This is a digitally signed message part.

Re: Live-build - searching for (a) solution(s)

[Yves Combe]

Le 18/11/2015 19:47, Hans-J. Ullrich a écrit :

Dear list,

I am using live-build for building kali-linux images. The standard build
procedure is working well with live-build. But for my purposes I have some
special needs, which the documentation of live-build does not explain.

I hope, someone experienced can help me.

This is, what I want to do:

1. I want to download and unpack the packages, then create the chroot.
When the changeroot has been created, the script shall stop.

2. When the chroot is existent, I want to make changes in the chroot (edit
some files, add some files like wordlists etc.).
I know, I can go into the chroot with the command "chroot /path/to/chroot",
then work in it, just as in a normal linux system

3. After I have finished my changes, I want to leave the chroot and now create
the ISO-image of it.

It would be nice, if someone could give me the correct commands.

For me, you don't need to stop the build to do that.

You can put and replace files in chroot, puting them in 
config/includes.chroot

You can add scripts in config/hooks, they are runned before ISO creation.

See the manual, section 9.1.1 and 9.2.1

--
yves

live-wrapper - RFE - Arch boot automatic detection

[adrian15]

1) I make the assumption that live-wrapper currently supports to build 
an x86 system with both a 586 kernel and amd64 kernel in the same iso.


2)  I would like live-wrapper to have support for arch automatic 
detection at boot. That means that the bootloader chooses the right 
kernel depending on the available architecture.


I already did this work for live-build and the commits can be found here:

https://github.com/adrian15/live-build/commit/5852a69976da36abd7bcbbce95807a7a2451a7a6

https://github.com/adrian15/live-build/commit/36f781c4dc55e9a0d14cc74df5ff36f9eac2e33f

3) I don't mind implementing the bits to improve the grub cfg file and 
live cfg file but taking a look at:


https://anonscm.debian.org/cgit/debian-live/live-wrapper.git/tree/lbng/vm.py?id=4c908cd1682f5d15912810a33c71c35a54fc7115

where the detect_kernel function is defined and:

https://anonscm.debian.org/cgit/debian-live/live-wrapper.git/tree/lbng/grub.py?id=4c908cd1682f5d15912810a33c71c35a54fc7115

which it's one of the places where it is used... well...

I need not only what you currently save on version but also the arch... 
not sure how irl wants to implement it, with two variables,... Should I 
parse myself the detect_kernels output and play from there? Should the 
output be two variables ? A dict variable ?



Given these files found:

vmlinuz-3.16.0-4-amd64
vmlinuz-3.16.0-4-586
vmlinuz-3.14.0-1-amd64
vmlinuz-3.14.0-1-586

I need to be able to loop over 3.16.0-4 so that I found that it has two 
architectures. Then if one of them is amd64 I guess I can suppose the 
other one would be 586.


Once that happens I can add my auto entry which if it was a function 
would need to know the kernel filenames and the kernel associated arch.


Additional note: Pae can also be supported by autodetection if pae 
kernels are still available in Debian. I think pae it's supported on 
syslinux but not on grub2.


4) Hopefully this RFE can improve the current live-wrapper design.


adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el software 
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/

Re: live-wrapper - RFE - Arch boot automatic detection

[Ben Armstrong]

These opinions are my own and do not represent an official statement by
Debian or any of its subprojects.

On 18/11/15 08:52 PM, Michael . wrote:
> With regards to a couple of points you have made in this, and your
> previous, post nothing about Live Build is clear anymore. Actually
> that is incorrect, the only thing that is clear is Daniel has given up
> with it as a Debian project and as the lead developer it seems Live
> Build as a Debian project is discontinued (remember we were told it
> was deprecated).

Upstream gave up on the project. This is not unique in the software in
Debian. Upstreams give up all the time, for various reasons. And there
doesn't need to be confusion about it. The abandoned software remains in
Debian, and if someone doesn't step up to take it over, it eventually
goes to Debian QA. If someone does take it over, as often happens with
software that is useful for which there is no alternative, then
hopefully it continues to live on in Debian indefinitely under new
leadership.

It's too early yet to know what's happening with it in the longer term.
I think that in a large part depends on the user/developer community's
response to it (i.e. which software they favour with their attention),
and not at all with what Debian does or does not endorse. If development
on live-wrapper is swift, and it gains a following and rapidly becomes
feature complete, it may quickly overtake live-build and come to be
preferred by the community. If it is slow, live-build may dominate for a
while longer. But I cannot possibly predict at this stage which way it
will go.

At the risk of sounding like a broken record ... people are still acting
as though live-build will be imminently removed from Debian or will
suddenly lose support, neither of which are true. There's no reason at
this time to remove it. It is in decent shape, and a significant pool of
developers and users remain who know enough about it that it will for
the time being continue to be supported.

> Your Previous post on the issue of Live build mentioned something
> about people taking Live Build on, has this happened? Are you,
> personally, keeping Live Build going?

I'm not taking a technical leadership role. However, I'm continuing in a
support role for as long as it looks like that is in Debian's best
interest. I have a fair bit of experience with it and try to assist
whenever I can.

> The splitting of the resource pool had happened well before anyone in
> Live Build (thats what the available evidence suggests) or its user
> community new anything about it. Debian CD split the pool of resources
> by making their own project (which they are entitled to do) and not
> assisting Live Build (which they are also entitled to do).

From what I could see, Debian CD made every effort to assist Debian Live
before striking off on their own. They reported problems and provided
patches (some of which, like the UEFI one, were rejected, and no
alternative solution provided for a very, very long time). So I don't
think it's fair to say they "split the resource pool". That could only
be true if they actively pulled the existing Debian Live developers off
the project. That's not what happened. They are now *adding to* what
we've built with live-wrapper, as I understand it using live-boot and
live-config at the core, bringing to the table their own resources, to
try to help Debian (you know, the *whole* project, not two autonomous
projects Debian Live and Debian CD with opposing goals and interests)
have sane, non-fragile official live CD builds. I think that's an
excellent goal, and therefore am in support of their efforts. It's a
more inclusive process than you have portrayed it, which is why I'm
counseling unity here and not divisiveness.

> The discussions in coming months are a rather mute point now aren't
> they? What has happened has happened, what has been said has been
> said, and the users of Live Build are caught in the middle and are
> going to have to either wait for someone to fill them in or move to
> using Live Wrapper (which isn't really usable at the moment). My point
> here is this process of discussions over the coming months really
> needs to be quicker.

So your answer to moving those discussions quicker is to push the
live-wrapper developers away where they won't bother you?

> It is unfair to people who depend on these tools to let this drag on.
> I'm simply not willing to start releasing iso images for a stable
> system for the South Pacific when the tool I've been building it on
> and getting people to test it with is in a state of limbo and the tool
> that is supposed to replace it isn't usable.

To let what drag on? live-build does what it does the same way that it
did last month. It has excellent documentation (if I do say so myself,
having contributed in a large degree to it), and Debian has a process of
NMUs that allows it to continue receiving patches as needed. People are
continuing to help with problems here on the mailing 

Re: live-wrapper - RFE - Arch boot automatic detection

[Michael .]

I apologise for any confusion caused by my previous reply.

With regards to a couple of points you have made in this, and your
previous, post nothing about Live Build is clear anymore. Actually that is
incorrect, the only thing that is clear is Daniel has given up with it as a
Debian project and as the lead developer it seems Live Build as a Debian
project is discontinued (remember we were told it was deprecated). Your
Previous post on the issue of Live build mentioned something about people
taking Live Build on, has this happened? Are you, personally, keeping Live
Build going?

The splitting of the resource pool had happened well before anyone in Live
Build (thats what the available evidence suggests) or its user community
new anything about it. Debian CD split the pool of resources by making
their own project (which they are entitled to do) and not assisting Live
Build (which they are also entitled to do).

The discussions in coming months are a rather mute point now aren't they?
What has happened has happened, what has been said has been said, and the
users of Live Build are caught in the middle and are going to have to
either wait for someone to fill them in or move to using Live Wrapper
(which isn't really usable at the moment). My point here is this process of
discussions over the coming months really needs to be quicker. It is unfair
to people who depend on these tools to let this drag on. I'm simply not
willing to start releasing iso images for a stable system for the South
Pacific when the tool I've been building it on and getting people to test
it with is in a state of limbo and the tool that is supposed to replace it
isn't usable.

If Live Build lives on then great, if it doesn't then so be it. One day
someone in the Debian project will provide some clear statements as to what
is going on and then downstream projects like mine and many others can get
on with their work without wondering if we can keep using the tool we have
taken time to learn how to use or if we have to switch to another "live"
tool and then learn new things.

Until we actually hear something definitive my project is officially on
hold. The 2 "disjoint groups", as you called them, need to have these
discussions and get to work sooner rather than later so the effects of this
mess don't linger on. Please keep us informed.

On 19 November 2015 at 10:33, Ben Armstrong 
wrote:

> On 18/11/15 07:15 PM, Michael . wrote:
> > Correct me if I am wrong but I'm not sure this is the right list for
> > this. Live Wrapper and Live build are 2 separate projects run by, or
> > at least they were until Live Build has been discontinued, 2 differnt
> > groups.
>
> First of all, to clarify, "Live Build has been discontinued" is not yet
> reality. It is slated to be replace as the software to build official
> Debian Live CDs, but that doesn't mean that the software suddenly ceases
> to exist. It will continue to be supported here the best we can, as I've
> written about here before.
>
> In my opinion, this is also the right list to support live-wrapper. It
> is written here:
>
> https://lists.debian.org/debian-live/
>
>
>   Discussion and maintenance of the Debian Live systems
>
> Development of the Debian Live systems (i.e. live cds).
>
>
> The list is run by the Debian project for the purpose of supporting the
> development and maintenance of "the Debian Live systems". That is not
> clearly defined, but by the use of the definite article "the", some
> specific software is implied. Since live-build is the specific software
> that the current Debian Live CDs is built with, and live-wrapper is the
> specific software that the Debian CD team intends to use to replace it,
> it is a reasonable interpretation of "the Debian Live systems" as being
> systems that are built with either software, the old and the new.
>
> > If you want to message the Live Wrapper group I suggest you contact
> > Debian CD and ask them what list is appropriate for your ideas and
> > patches.
>
> I don't see any justification for splitting our pool of expertise across
> two disjoint groups. In coming months we will likely need to have many
> conversations involving both the old and the new, and the resulting
> cross-posting between groups would just be confusing, and hamper
> development going forward.
>
> Ben
>
>
>

Re: live-wrapper - RFE - Arch boot automatic detection

[Michael .]

>These opinions are my own and do not represent an official statement by
>Debian or any of its subprojects.

That clarifies everything for me. You have been, in effect, posting your
opinion but with an appearance of authority. I can respect that as you are
trying to maintain peaceful relations, which is in everyones best interest.

>Upstream gave up on the project. This is not unique in the software in
>Debian. Upstreams give up all the time, for various reasons. And there
>doesn't need to be confusion about it. The abandoned software remains in
>Debian, and if someone doesn't step up to take it over, it eventually
>goes to Debian QA. If someone does take it over, as often happens with
>software that is useful for which there is no alternative, then
>hopefully it continues to live on in Debian indefinitely under new
>leadership.

I'm well aware that abandoned software remains part of Debian for a time
but that is, for me personally at least, besides the point here. Live Build
is in Jessie, Testing, Sid, and even Experimental. Live Wrapper isn't in
anything so it is not usable. If no one picks up the active development of
Live Build how long will it remain in testing? That's a rhetorical question.


>At the risk of sounding like a broken record ... people are still acting
>as though live-build will be imminently removed from Debian or will
>suddenly lose support, neither of which are true. There's no reason at
>this time to remove it. It is in decent shape, and a significant pool of
>developers and users remain who know enough about it that it will for
>the time being continue to be supported.

It is highly unlikely Debian will move alpha software into Stretch when it
becomes stable. Jessie is 6 moths old so Testing freeze is possibly 12
months away with Stretech's release approximately 6 months after that. I
can only hope Live Wrapper is mature by then.

>I'm not taking a technical leadership role. However, I'm continuing in a
>support role for as long as it looks like that is in Debian's best
>interest. I have a fair bit of experience with it and try to assist
>whenever I can.

I, personally, appreciate that.

>From what I could see, Debian CD made every effort to assist Debian Live
>before striking off on their own. They reported problems and provided
>patches (some of which, like the UEFI one, were rejected, and no
>alternative solution provided for a very, very long time).

So they did provide patches, ok I was unaware of that even though I asked
the Debian CD team if they had done that and did not get any response.

>So I don't
>think it's fair to say they "split the resource pool". That could only
>be true if they actively pulled the existing Debian Live developers off
>the project. That's not what happened. They are now *adding to* what
>we've built with live-wrapper, as I understand it using live-boot and
>live-config at the core, bringing to the table their own resources, to
>try to help Debian (you know, the *whole* project, not two autonomous
>projects Debian Live and Debian CD with opposing goals and interests)
>have sane, non-fragile official live CD builds.

May I ask then what was not sane, what was fragile, and what was
unofficial, with regards to Live Build?

>I think that's an
>excellent goal, and therefore am in support of their efforts. It's a
>more inclusive process than you have portrayed it, which is why I'm
>counseling unity here and not divisiveness.

I am in support of a better product, if it can be done. I am not in support
of the way this appeared to have occurred. I am in support of unity which
is why I asked a couple of times did the Debian CD team try to work with
(providing patches etc) the Live Build team which you have answered now.

>So your answer to moving those discussions quicker is to push the
>live-wrapper developers away where they won't bother you?

Push them away so they wont bother me? I've tried to get answers to simple
questions, you know answers like "yes we did provide patches and they were
ignored-rejected-whatever". If this has, as you appear to be saying and the
other team actually did say, "coming for a long time" the logistics of this
should have been worked out already. Having these discussions after the
fact indicates a whole heap of poor planning.

>To let what drag on? live-build does what it does the same way that it
>did last month. It has excellent documentation (if I do say so myself,
>having contributed in a large degree to it), and Debian has a process of
>NMUs that allows it to continue receiving patches as needed. People are
>continuing to help with problems here on the mailing list, and people
>are continuing to help on irc. What, exactly, is the problem with this
>situation? You can continue to build images and projects based on
>live-build until whenever *you* decide it isn't working well for you and
>you want to switch to something else.

And we are back to will Live Build 5 get out of alpha so it can continue? I
know you can't answer 

Re: live-wrapper - RFE - Arch boot automatic detection

[Michael .]

Correct me if I am wrong but I'm not sure this is the right list for this.
Live Wrapper and Live build are 2 separate projects run by, or at least
they were until Live Build has been discontinued, 2 differnt groups.

If you want to message the Live Wrapper group I suggest you contact Debian
CD and ask them what list is appropriate for your ideas and patches.

On 19 November 2015 at 09:51, adrian15  wrote:

> 1) I make the assumption that live-wrapper currently supports to build an
> x86 system with both a 586 kernel and amd64 kernel in the same iso.
>
> 2)  I would like live-wrapper to have support for arch automatic detection
> at boot. That means that the bootloader chooses the right kernel depending
> on the available architecture.
>
> I already did this work for live-build and the commits can be found here:
>
>
> https://github.com/adrian15/live-build/commit/5852a69976da36abd7bcbbce95807a7a2451a7a6
>
>
> https://github.com/adrian15/live-build/commit/36f781c4dc55e9a0d14cc74df5ff36f9eac2e33f
>
> 3) I don't mind implementing the bits to improve the grub cfg file and
> live cfg file but taking a look at:
>
>
> https://anonscm.debian.org/cgit/debian-live/live-wrapper.git/tree/lbng/vm.py?id=4c908cd1682f5d15912810a33c71c35a54fc7115
>
> where the detect_kernel function is defined and:
>
>
> https://anonscm.debian.org/cgit/debian-live/live-wrapper.git/tree/lbng/grub.py?id=4c908cd1682f5d15912810a33c71c35a54fc7115
>
> which it's one of the places where it is used... well...
>
> I need not only what you currently save on version but also the arch...
> not sure how irl wants to implement it, with two variables,... Should I
> parse myself the detect_kernels output and play from there? Should the
> output be two variables ? A dict variable ?
>
>
> Given these files found:
>
> vmlinuz-3.16.0-4-amd64
> vmlinuz-3.16.0-4-586
> vmlinuz-3.14.0-1-amd64
> vmlinuz-3.14.0-1-586
>
> I need to be able to loop over 3.16.0-4 so that I found that it has two
> architectures. Then if one of them is amd64 I guess I can suppose the other
> one would be 586.
>
> Once that happens I can add my auto entry which if it was a function would
> need to know the kernel filenames and the kernel associated arch.
>
> Additional note: Pae can also be supported by autodetection if pae kernels
> are still available in Debian. I think pae it's supported on syslinux but
> not on grub2.
>
> 4) Hopefully this RFE can improve the current live-wrapper design.
>
>
> adrian15
> --
> Support free software. Donate to Super Grub Disk. Apoya el software libre.
> Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
>
>

Re: live-wrapper - RFE - Arch boot automatic detection

[Ben Armstrong]

On 18/11/15 07:15 PM, Michael . wrote:
> Correct me if I am wrong but I'm not sure this is the right list for
> this. Live Wrapper and Live build are 2 separate projects run by, or
> at least they were until Live Build has been discontinued, 2 differnt
> groups.

First of all, to clarify, "Live Build has been discontinued" is not yet
reality. It is slated to be replace as the software to build official
Debian Live CDs, but that doesn't mean that the software suddenly ceases
to exist. It will continue to be supported here the best we can, as I've
written about here before.

In my opinion, this is also the right list to support live-wrapper. It
is written here:

https://lists.debian.org/debian-live/


  Discussion and maintenance of the Debian Live systems

Development of the Debian Live systems (i.e. live cds).


The list is run by the Debian project for the purpose of supporting the
development and maintenance of "the Debian Live systems". That is not
clearly defined, but by the use of the definite article "the", some
specific software is implied. Since live-build is the specific software
that the current Debian Live CDs is built with, and live-wrapper is the
specific software that the Debian CD team intends to use to replace it,
it is a reasonable interpretation of "the Debian Live systems" as being
systems that are built with either software, the old and the new.

> If you want to message the Live Wrapper group I suggest you contact
> Debian CD and ask them what list is appropriate for your ideas and
> patches.

I don't see any justification for splitting our pool of expertise across
two disjoint groups. In coming months we will likely need to have many
conversations involving both the old and the new, and the resulting
cross-posting between groups would just be confusing, and hamper
development going forward.

Ben

live-wrapper - RFE - Set your own distribution name

[adrian15]

1) Current live-wrapper implementation hardcodes 'Debian GNU/Linux Live' 
string in the bootloader entries as you can see here:


https://anonscm.debian.org/cgit/debian-live/live-wrapper.git/tree/lbng/grub.py?id=4c908cd1682f5d15912810a33c71c35a54fc7115

I would like to be able to set a 'distribution name' variable so that a 
common string could be replaced on:


* Bootloader entries
* Login screen (I will need this in the future for adapting tails-greeter)
* Possibly in another places

2) Hopefully this RFE can improve the current live-wrapper design.


adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el software 
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/