from:"adrian15"

El 09/03/19 a las 15:03, Thomas Schmitt escribió:
> Hi,
> 
> adrian15 wrote:
>> Well, guess what happened... my obvious patch:
>>  if ! search --set=root --file /live/vmlinuz ; then
>search --set=root --file /live/vmlinuz1
>> does not boot in my computer because it's still finding /live/vmlinuz in
>> the internal hard disk.

So, I have been taking a look at Debian official Live build images
(which are built with lwr) and they happen to search for:

search --set=root --file /.disk/info

So there are two scenarios where this might arise as a problem:

1) Two live USB images being plugged in at the same time.
And somehow the UEFI firmware is so good that it shows both of them to grub.

I think we shouldn't care too much about this scenario because it's too
unlikely.

2) One live USB image plugged in. And some computer manufacter having
installed a possibly lwr based live build on an internal hard disk
partition.

I think this is highly unlikely because when you build an image designed
to be used in a hard disk you do not use mkisofs. Why? Because you want
the partition to be writable. Isn't it?
So if mkisofs is not used then there won't be a /.disk/info file.

So there is not a problem.

What I'm saying with all of this is that I'm going to propose a fix that
involves not using any earmark (which involves too much work) but just
searching for /.disk/info instead.

Hopefully Thomas you are not too bad at me. You seemed to be very
excited with all of this earmark implementation ;) .

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

Bug#924053: live-build: UEFI shows grub> on HP250 G6 2SX60EA

El 09/03/19 a las 16:35, Thomas Schmitt escribió:
> Hi,
> 
> adrian15 wrote:
>> replace:
>> search --set=root --file /live/vmlinuz
>> with:
>> search --set=root --label \"${LB_ISO_VOLUME}\"
> 
> This looks ok for me, as far as GRUB2's work is concerned.
Yeah, it had TYPO but, yeah, as I said it worked for me.
> 
> But when the GNU/Linux comes up, it may again be necessary for software
> in the initrd to locate the ISO filesystem.
> Unarchiving dim memories from last year:
>   https://lists.debian.org/debian-live/2018/04/msg5.html
> 
> If the initrd indeed looks for marker files, then one should coordinate
> both find-the-ISO efforts.
> If it has other methods, then one should consider whether they are good
> and whether it is possible to join them in GRUB2 .cfg.

No, that's not the case. findiso works fine when the iso filename is not
repeated in many devices.

That's not going to happen too often.

The bug you were pointing out, although I have not tested myself I think
it's present nowadays in official Debian Live builds (based on lwr).

The loopback.cfg tries to load grub/grub.cfg while it should load
boot/grub/grub.cfg instead.

I'll try to reproduce it later and report it in a new bug if it's needed.

> 
> -
> 
> If you stay with the idea of an earmark file, then the GRUB2 efi.img
> and the initrd need to know the name for their version of a live ISO
> (or installation ISO).
> Any two debian-live ISOs which shall be distinguishable would have to bear
> different earmark files.

No, findiso works with the iso filename.
Then when the iso has been loopmounted in grub shell the loopback.cfg
pass the iso path and iso filename to the kernel.
Initrd then looks for this specific path and iso filename in all of your
devices.

And that's it.

I mean,... if you have one hard disk with /boot/boot-isos/debian.iso
and you also have another hard disk with the same exact
/boot/boot-isos/debian.iso then you cannot be sure about which one has
been boot.

The first hard disk iso might be run from Super Grub2 Disk but then the
initrd might load the squashfs from second hard disk.

Well, I don't care too much for this scenario because we are dealing
specifically with having the same iso path and iso filename, which it
would be very rare.

> 
> This imposes some work on tools which want to remaster Debian ISOs and
> derive own distingushable versions. The benefit is that those remastered
> ISOs can coexist with the originals not only in the firmware's list of
> boot devices but also later in the initrd's list of possible storage
> devices for mounting the ISO.
> Tools which just want to add some packages may maintain the original
> earmark and bet on not meeting the original ISO at boot time on the same
> machine.
> 
> 
> How stupid is the idea to let GRUB2 tell initrd the earmark name in
> a kernel parameter ? I.e. in
>   linux  /live/vmlinuz-4.9.0-6-amd64 boot=live earmark="${earmark}" 
> components "${loopback}"
> where "${earmark}" would be set in the GRUB configuration of efi.img ?
> 
> Needs possibly coordination with "${loopback}" which already cares for
> ISO image files.
> 
> If debian-live switches to GRUB2 for BIOS, then "${earmark}" would
> have to be known to the .cfg empire in the ISO. But for now it would
> suffice to let efi.img tell it to all others.

Well, I don't care too much about syslinux/isolinux because grub is what
we use in Secure Boot (and the fact that Secure Boot has a minimal grub
environment it's what triggers all of these problems).

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

Bug#924053: live-build: UEFI shows grub> on HP250 G6 2SX60EA

I just wanted to write down that the label approach works for me.

This would be the patch/commit for this approach:

https://github.com/rescatux/live-build/commit/cf11816e64256d8028c4b2f10de2996de09328f2

replace:

search --set=root --file /live/vmlinuz

with:

search --set=root --label "${LB_ISO_VOLUME}"

.

As I said I'll work on the /live/id/12345678.ABC approach later.

adrian15

El 09/03/19 a las 15:18, adrian15 escribió:
> I am currently building and testing a label search approach.
> It works manually on both UEFI USB boot and TianaCore UEFI CDROM boot.
> 
> The patch is here:
> https://github.com/rescatux/live-build/commit/2716635f6314bba1d94f0693a33bbb55eba323e5
> 
> and, well it's quite simple:
> replace:
> 
> search --set=root --file /live/vmlinuz
> 
> with:
> 
> search --set=root --label \"${LB_ISO_VOLUME}\"
> .
> 
> 
> I might discard this label approach and take yours because of tools to
> remaster distros.
> 
> If I hard code 'DebianLive87' or whatever Debian label is then anyone
> who wants modify minimally the iso then needs to reconstruct the efi.img
> file so that it searchs for their label.
> 
> Because, obviously when you remaster an ISO you want to put your volume
> name and not "Debian", "Ubuntu" or whatever.
> 
> 
> Your filename base approach just enforces the remaster tool to find an
> unknown 8.3 file and make sure to copy it. Or maybe every single file at
> device root ?
> 
> It's way simpler than mine.
> 
> 
> So Thomas... any more thoughts that you can bring me in... to make
> remaster tools work easier?
> 
> Maybe I'm missing something obvious.
> 
> Thank you.
> 
> 
> adrian15
> 

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

Bug#924053: live-build: UEFI shows grub> on HP250 G6 2SX60EA

El 09/03/19 a las 15:03, Thomas Schmitt escribió:
> Hi,
> 
> adrian15 wrote:
>> Well, guess what happened... my obvious patch:
>>  if ! search --set=root --file /live/vmlinuz ; then
>search --set=root --file /live/vmlinuz1
>> does not boot in my computer because it's still finding /live/vmlinuz in
>> the internal hard disk.
>  
> That's the second bad spinoff from using as ISO earmark a file which
> already has a different job.
> (First in my counting is that a change in kernel naming inadvertedly
>  could spoil the recognition of the ISO.)
> 
> 
>> 3) I'll try to code this dedicated unique identification file path that
>> you are proposing and see if it works better.
> 
> I am pondering whether the name should be long and human readable
> like "d-live_9.4.0_xf_amd64" or short and bootloader agnostic like
> "0F63AE66.87F" (*).
> The former needs Rock Ridge support to be recognizable (GRUB2 has it,
> afaic), the latter would show up the same in all naming systems of
> the ISO. Be it plain ISO 9660 level 1, Rock Ridge, or Joliet.
> 
> (*) The short name was derived by:
> 
>   x=$(echo -n 'd-live 9.4.0 xf amd64' | md5sum | tr 'a-z' 'A-Z' | dd bs=1 
> count=11)
>   name=$(echo "$x" | dd bs=1 count=8)"."$(echo "$x" | dd bs=1 skip=8 count=3)
> 
> (I am sure it can be done more elegantly.)
> 
> 
> Have a nice day :)
> 
> Thomas

I have been scratching my head on where to put this file.

/live/0F63AE66.87F makes things more difficult to remaster tools because
there is not an easy way to determine which file is the identifier one.

However we could use a new directory for sort of identifying the distro
thanks to its filename.

So you would have:

/live/id/0F63AE66.87F
.

This is something that I think could work and I'm happy with.

I only need to choose which variables to generate the seed from and I'm
done.

Taking a look at: scripts/build/config :

LB_ARCHITECTURES
LB_DISTRIBUTION
LB_PARENT_DISTRIBUTION
LB_LINUX_FLAVOURS
LB_LINUX_PACKAGES
LB_ISO_APPLICATION
LB_ISO_PREPARER
LB_ISO_PUBLISHER
LB_ISO_VOLUME

This seems quite arbitrary but it should be enough I think.


I think next day I'm able to develop on this matter I will checkout a
new branch for this.


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

Bug#924053: live-build: UEFI shows grub> on HP250 G6 2SX60EA

El 09/03/19 a las 15:03, Thomas Schmitt escribió:
> Hi,
> 
> adrian15 wrote:
>> Well, guess what happened... my obvious patch:
>>  if ! search --set=root --file /live/vmlinuz ; then
>search --set=root --file /live/vmlinuz1
>> does not boot in my computer because it's still finding /live/vmlinuz in
>> the internal hard disk.
>  
> That's the second bad spinoff from using as ISO earmark a file which
> already has a different job.
> (First in my counting is that a change in kernel naming inadvertedly
>  could spoil the recognition of the ISO.)
> 
> 
>> 3) I'll try to code this dedicated unique identification file path that
>> you are proposing and see if it works better.
> 
> I am pondering whether the name should be long and human readable
> like "d-live_9.4.0_xf_amd64" or short and bootloader agnostic like
> "0F63AE66.87F" (*).
> The former needs Rock Ridge support to be recognizable (GRUB2 has it,
> afaic), the latter would show up the same in all naming systems of
> the ISO. Be it plain ISO 9660 level 1, Rock Ridge, or Joliet.
> 
> (*) The short name was derived by:
> 
>   x=$(echo -n 'd-live 9.4.0 xf amd64' | md5sum | tr 'a-z' 'A-Z' | dd bs=1 
> count=11)
>   name=$(echo "$x" | dd bs=1 count=8)"."$(echo "$x" | dd bs=1 skip=8 count=3)
> 
> (I am sure it can be done more elegantly.)
> 
> 
> Have a nice day :)
> 
> Thomas

I am currently building and testing a label search approach.
It works manually on both UEFI USB boot and TianaCore UEFI CDROM boot.

The patch is here:
https://github.com/rescatux/live-build/commit/2716635f6314bba1d94f0693a33bbb55eba323e5

and, well it's quite simple:
replace:

search --set=root --file /live/vmlinuz

with:

search --set=root --label \"${LB_ISO_VOLUME}\"
.

I might discard this label approach and take yours because of tools to
remaster distros.

If I hard code 'DebianLive87' or whatever Debian label is then anyone
who wants modify minimally the iso then needs to reconstruct the efi.img
file so that it searchs for their label.

Because, obviously when you remaster an ISO you want to put your volume
name and not "Debian", "Ubuntu" or whatever.

Your filename base approach just enforces the remaster tool to find an
unknown 8.3 file and make sure to copy it. Or maybe every single file at
device root ?

It's way simpler than mine.

So Thomas... any more thoughts that you can bring me in... to make
remaster tools work easier?

Maybe I'm missing something obvious.

Thank you.

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

Bug#924053: live-build: UEFI shows grub> on HP250 G6 2SX60EA




El 09/03/19 a las 13:46, Thomas Schmitt escribió:
>> 4) And, well, I might try an obvious patch that searches with regex both
>> /live/vmlinuz and /live/vmlinuz1 and give us more feedback about it.
> 
> Or a dedicated unique identification file path ?
> 
> An empty file in an alreay existing directory would cost 0 or 2048 bytes
> in the ISO.
> Even in a conservative 8.3 name it would be possible to expose 56 bit
> with a birthday paradox threshold of 256 million. A plain hex encoding
> could expose 44 bit of random id (~ 4 million children in the class).
> 
> If reproducibility is of concern, then the filename could be derived
> from some version-dependent strings like the ISO's volume id. All
> mangled through md5sum and tr 'a-f' 'A-F', the first eleven result
> characters would yield a quasi-unique DOS style file name.
> 
> 
> Have a nice day :)
> 
> Thomas

1)
Well, guess what happened... my obvious patch:
https://github.com/rescatux/live-build/commit/52bb32989078b9a724c13e73a0ac87673d728199

which basically replaces:

search --set=root --file /live/vmlinuz

by:

if ! search --set=root --file /live/vmlinuz ; then
search --set=root --file /live/vmlinuz1
fi

does not boot in my computer because it's still finding /live/vmlinuz in
the internal hard disk.

Of course I could reverse the logic:

if ! search --set=root --file /live/vmlinuz1 ; then
search --set=root --file /live/vmlinuz
fi

but who assures me that in the future there is an scenario where:

* Debian Live CD uses /live/vmlinuz
and
* HP internal disk Live CD uses /live/vmlinuz1

and it breaks again?

2) I think there is something different from Secure Boot enable boot to
non-Secure Boot that triggers this fallback to minimal grub.cfg scenario.

Else I would have found these problem when in one my tests I skipped the
overwriting of .efi files with the signed ones.

3) I'll try to code this dedicated unique identification file path that
you are proposing and see if it works better.

Then I want to compare grub hard disks / devices being detected with
Secure Boot enabled and Secure Boot disabled.

So that we can conclude if this fallback to minimal grub.cfg is
inevitable and attached to Secure Boot or if it's a Secure Boot bug itself.



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

Bug#924053: live-build: UEFI shows grub> on HP250 G6 2SX60EA

inary/${_INITRAMFS}/vmlinuz
ln $(ls -r1 --sort=version 
binary/${_INITRAMFS}/initrd.img-* | head
-n 1) binary/${_INITRAMFS}/initrd.img

sed -e "s|@FLAVOUR@|${LB_LINUX_FLAVOURS}|g" \
-e "s|@LINUX@|/${_INITRAMFS}/vmlinuz|g" \
-e "s|@INITRD@|/${_INITRAMFS}/initrd.img|g" \
"${_TARGET}/live.cfg.in" >> "${_TARGET}/live.cfg"

rm -f "${_TARGET}/live.cfg.in"
;;

This means that when there are two kernel flavours we are using:
vmlinuz1 and vmlinuz2 on the disk.
But when there is only one kernel flavour we use vmlinuz.

2.3) So... as you can see from (2.1) the boot process is expecting
/live/vmlinuz and in (2.2) we are not giving it /live/vmlinuz but
/live/vmlinuz1 and /live/vmlinuz2.

So, in the specific case of brand new HP250G6:

search --set=root --file /live/vmlinuz : Does not find the file in our
live cd and loops other system storage devices. /live/vmlinuz is being
found in the second internal partition and
grub's root variable is set to "hd1,msdos2".


set prefix=($root)/boot/grub

grub's prefix variable is set to "(hd1,msdos2)/boot/grub"

configfile ($root)/boot/grub/grub.cfg

This is trying to load:
"(hd1,msdos2)/boot/grub/grub.cfg"
and per (1.1) you know that this file does not exist in this internal
hard disk partition.

So grub.cfg ends and the user is presented:

grub> .

3) I'll try to do more tests. Maybe renaming /live/vmlinuz in the
internal hard disk partition to mimic non HP250G6 systems but I already
know what's going to happen. I'll get the grub> prompt too because it
will have no useful grub.cfg to configfile into.

4) And, well, I might try an obvious patch that searches with regex both
/live/vmlinuz and /live/vmlinuz1 and give us more feedback about it.



El 08/03/19 a las 23:21, adrian15 escribió:
> Package: live-build
> Version: 1:20180224
> Severity: important
> 
> Current live-build head ( f242323fa246840ba9581586ad78a8301629d84c We
> should add buster for release ) brings on my HP250 G6 2SX60EA laptop
> UEFI boot an:
> 
> grub>
> output.
> 
> My specific build is done in a Buster chroot and the target distro is
> Buster i386 with 686 and amd64 kernels.
> 
> I also happen to use this commit:
> https://github.com/rescatux/live-build/commit/6217dea5bc84212098d0efee18953151b41b3497
> so that amd64 kernel works for i386. I don't think you need this commit
> to be able to reproduce my problem (if you had an HP250 G6 2SX60EA or
> equivalent).
> 
> 
> I have done a manual bisect and it seems the problem comes from:
> 035518ff69a97fa5d3fa432e13c9593a9f459a4e UEFI: add support for Secure
> Boot on amd64 and arm64.
> 
> I'll try to tinker a bit reverting the commit that breaks things for me
> and applying it part by part. Anyways any feedback that can speed up my
> testing is welcomed.
> 
> Thank you very much!
> 
> adrian15
> 
> 
> Here there is the bisect just in case you need me to test more commits:
> 
> ( grub> ) f242323fa246840ba9581586ad78a8301629d84c We should add buster
> for release
> ( N/A ) 2fa258cca25d834f7896b7adc64892dc583010bf use deb.debian.org as
> default
> ( N/A ) 069d0d7b5a67f71b60cdaea01e498bb2559cc3c7 Update changelog for
> 1:20180925 release
> ( N/A ) cc1341ab4ad2302c46469c15039fac948cdec094 lintian: override error
> on dependency on e2fsprogs
> ( N/A ) 66839c4346c63e8c48d7eba6b3d1ca99f1dd691f Bump Standards-Version
> to 4.2.1.
> ( N/A ) b2a760de575c1439e996cb895deb575c611ddf15 Add
> Rules-Requires-Root: no.
> ( N/A ) 4db6471248223ffec7ea1a028b929cd819abd490 Build-Depend on
> debhelper >= 10~ to facilitate backports.
> ( N/A ) f108fdfa71c9d66a5ef9dfe7f1f48c170c7f228e UEFI: remove the
> EFI/debian/grub.cfg, not necessary anymore
> ( grub> ) c22f1f5b71745922ae28df0ebf4b7d1a49d89f55 Use
> gcd{x64.aa64}.efi.signed for amd64/arm64 arch.
> ( grub> ) 8403487d4e3bda65cdd2ea6081399f7977325adb copy keys to
> /etc/apt/trusted.gpg.d with appropriate extension for them to not be
> ignored.
> (  ) 52908422880f8d5cfa18c577d4138d5449af37f6 Handle includes.chroot
> files installed over symlinked directories
> (  ) 332c170c3b8dc2449b348191562c784db68ed331 Update changelog for
> 1:20180618 release
> (  ) be7bc0a9ffcc0b59ae66a63a863fb586d7ac1fca Bump Standards-Version to
> 4.1.4, no changes.
> ( Skipped ) 316b1281581b188e3353fe59bb40bcb81cbd953f UEFI: parse vendor
> from Grub package metadata
> (  ) e5492b1c702858eb26e2b93c65810773ad0bfa85 Avoid apt-key add and just
> drop the key in /etc/apt/trusted.gpg.d
> (  ) 186765e3fd905a2ecd08cd22dd9afdcc581b1d0a lb clean: remove ONIE image
> (  ) b3e

Bug#924053: live-build: UEFI shows grub> on HP250 G6 2SX60EA

2019-03-08 Thread adrian15

1) I found some code that when commented solves the problem for me.

These are:

https://salsa.debian.org/live-team/live-build/blob/f242323fa246840ba9581586ad78a8301629d84c/scripts/build/binary_grub-efi#L181-188

or

if you prefer a "fixing" commit:
https://github.com/rescatux/live-build/commit/7a17008337b31ab968224b70dbdbde39c6d5a108
.

These lines are:


if [ -r
${_CHROOT_DIR}/usr/lib/grub/\$platform-signed/gcd\$efi_name.efi.signed -a \
-r 
${_CHROOT_DIR}/usr/lib/shim/shim\$efi_name.efi.signed -a \
"${LB_UEFI_SECURE_BOOT}" != "disable" ]; then
cp
${_CHROOT_DIR}/usr/lib/grub/\$platform-signed/gcd\$efi_name.efi.signed \
${_CHROOT_DIR}/grub-efi-temp/EFI/boot/grub\$efi_name.efi
cp ${_CHROOT_DIR}/usr/lib/shim/shim\$efi_name.efi.signed \
${_CHROOT_DIR}/grub-efi-temp/EFI/boot/boot\$efi_name.efi
fi


2) So let's add more information about this issue:

Build logs shows that Secure Boot is enabled.
And that it's true because I find the .signed files in the live-build's
chroot for my build.

That would explain why that code gets triggered.

This laptop has both UEFI and BIOS/CSM boot modes.
I make sure to boot with UEFI.
I guess this laptop works with x64 and not ia32. I can try to boot an
ia32-UEFI-only version of Super Grub2 Disk if you want to.

This laptop does NOT have any UEFI Secure Boot enabled in its UEFI firmware.


3) I expect the live-build generated image to be able to fallback to a
working grub menu even if Secure Boot is not enabled here.

Anyways I don't think the problem is not related to UEFI firmware not
supporting Secure Boot but to something else related on how those signed
images try to find their own config (grub cfgs) files on a given path.

4) A deeper look tells me that the non-SB efi images are built before at:

https://salsa.debian.org/live-team/live-build/blob/f242323fa246840ba9581586ad78a8301629d84c/scripts/build/binary_grub-efi#L159-162

So let's focus on:
"\${LIVE_BUILD_PATH}/efi-image" "${_CHROOT_DIR}/\$outdir" "\$platform"
"\$efi_name" "\$netboot_prefix"

This is using efi-image which I stole back in the day from
src:live-installer .

https://salsa.debian.org/live-team/live-build/blob/f242323fa246840ba9581586ad78a8301629d84c/scripts/build/efi-image


Can anyone more experienced than me take a look at the 'signed packages'
'source package' and check how the EFI are actually built?

I guess they use a different script than efi-image or an update one that
changes some paths.



As always, any feedback is welcome.

adrian15

El 08/03/19 a las 23:21, adrian15 escribió:
> Package: live-build
> Version: 1:20180224
> Severity: important
> 
> Current live-build head ( f242323fa246840ba9581586ad78a8301629d84c We
> should add buster for release ) brings on my HP250 G6 2SX60EA laptop
> UEFI boot an:
> 
> grub>
> output.
> 
> My specific build is done in a Buster chroot and the target distro is
> Buster i386 with 686 and amd64 kernels.
> 
> I also happen to use this commit:
> https://github.com/rescatux/live-build/commit/6217dea5bc84212098d0efee18953151b41b3497
> so that amd64 kernel works for i386. I don't think you need this commit
> to be able to reproduce my problem (if you had an HP250 G6 2SX60EA or
> equivalent).
> 
> 
> I have done a manual bisect and it seems the problem comes from:
> 035518ff69a97fa5d3fa432e13c9593a9f459a4e UEFI: add support for Secure
> Boot on amd64 and arm64.
> 
> I'll try to tinker a bit reverting the commit that breaks things for me
> and applying it part by part. Anyways any feedback that can speed up my
> testing is welcomed.
> 
> Thank you very much!
> 
> adrian15
> 
> 
> Here there is the bisect just in case you need me to test more commits:
> 
> ( grub> ) f242323fa246840ba9581586ad78a8301629d84c We should add buster
> for release
> ( N/A ) 2fa258cca25d834f7896b7adc64892dc583010bf use deb.debian.org as
> default
> ( N/A ) 069d0d7b5a67f71b60cdaea01e498bb2559cc3c7 Update changelog for
> 1:20180925 release
> ( N/A ) cc1341ab4ad2302c46469c15039fac948cdec094 lintian: override error
> on dependency on e2fsprogs
> ( N/A ) 66839c4346c63e8c48d7eba6b3d1ca99f1dd691f Bump Standards-Version
> to 4.2.1.
> ( N/A ) b2a760de575c1439e996cb895deb575c611ddf15 Add
> Rules-Requires-Root: no.
> ( N/A ) 4db6471248223ffec7ea1a028b929cd819abd490 Build-Depend on
> debhelper >= 10~ to facilitate backports.
> ( N/A ) f108fdfa71c9d66a5ef9dfe7f1f48c170c7f228e UEFI: remove the
> EFI/debian/grub.cfg, not necessary anymore
> ( grub> ) c22f1f5b71745922ae28df0ebf4b7d1a49d89f55 Use
> gcd{x64.aa64}.efi.signed for amd64/arm64 arch.
> ( grub> ) 8403487d4e3bda65cdd2ea6081399f7977325adb copy keys to
&g

Bug#924053: live-build: UEFI shows grub> on HP250 G6 2SX60EA

2019-03-08 Thread adrian15

( I CC Luca Bocassi which commited the bug that makes showing grub> on
HP 250 G6 2SX60EA instead of the grub menu. )

I forgot to mention about the grub environment in both cases. So that it
can help, maybe to understand, why it's failing.

1) grub environment on failing build

I suspect I get in a blink of an eye the message:
/boot not found
but I'm not 100% sure.

As I said I'm getting a grub> prompt.
Which has some variables defines, among these variables there are these
ones:

cmdpath=(hd0,msdos2)/EFI/BOOT # USB
prefix=(hd1,msdos2)/boot/grub # Laptop internal hard disk
root=hd1,msdos2 # Laptop internal hard disk

How do I manage to show the menu manually?

set root=hd0,msdos2
chainloader (hd0,msdos2)/efi/boot/grubx64.efi
boot

2) grub environment on grub showing menu at boot
This is Debian Live testing amd64 gnome nonfree
and I know it's not live-build based but lwr based.

Anyways I put the variables here:

cmdpath=(hd0,msdos2)/EFI/BOOT # USB
prefix=(hd0)/boot/grub # USB
root=hd0 # USB

3) grub environment on grub showing menu at boot
This is on ac3ed23638cbc4b10059f9678283d08b4a082136 commit (UEFI: add
minimal grub.cfg to fat32 partition)


cmdpath=(hd0,msdos2)/EFI/BOOT # This might be an additional EFI
partition because it only has 'efi' and 'boot' directories.
prefix=(hd0)/boot/grub # USB ( boot/ , efi/, efi.img, isolinux/, live/ y
md5sum.txt )
root=hd0 # USB ( boot/ , efi/, efi.img, isolinux/, live/ y md5sum.txt )


adrian15

El 08/03/19 a las 23:21, adrian15 escribió:
> Package: live-build
> Version: 1:20180224
> Severity: important
> 
> Current live-build head ( f242323fa246840ba9581586ad78a8301629d84c We
> should add buster for release ) brings on my HP250 G6 2SX60EA laptop
> UEFI boot an:
> 
> grub>
> output.
> 
> My specific build is done in a Buster chroot and the target distro is
> Buster i386 with 686 and amd64 kernels.
> 
> I also happen to use this commit:
> https://github.com/rescatux/live-build/commit/6217dea5bc84212098d0efee18953151b41b3497
> so that amd64 kernel works for i386. I don't think you need this commit
> to be able to reproduce my problem (if you had an HP250 G6 2SX60EA or
> equivalent).
> 
> 
> I have done a manual bisect and it seems the problem comes from:
> 035518ff69a97fa5d3fa432e13c9593a9f459a4e UEFI: add support for Secure
> Boot on amd64 and arm64.
> 
> I'll try to tinker a bit reverting the commit that breaks things for me
> and applying it part by part. Anyways any feedback that can speed up my
> testing is welcomed.
> 
> Thank you very much!
> 
> adrian15
> 
> 
> Here there is the bisect just in case you need me to test more commits:
> 
> ( grub> ) f242323fa246840ba9581586ad78a8301629d84c We should add buster
> for release
> ( N/A ) 2fa258cca25d834f7896b7adc64892dc583010bf use deb.debian.org as
> default
> ( N/A ) 069d0d7b5a67f71b60cdaea01e498bb2559cc3c7 Update changelog for
> 1:20180925 release
> ( N/A ) cc1341ab4ad2302c46469c15039fac948cdec094 lintian: override error
> on dependency on e2fsprogs
> ( N/A ) 66839c4346c63e8c48d7eba6b3d1ca99f1dd691f Bump Standards-Version
> to 4.2.1.
> ( N/A ) b2a760de575c1439e996cb895deb575c611ddf15 Add
> Rules-Requires-Root: no.
> ( N/A ) 4db6471248223ffec7ea1a028b929cd819abd490 Build-Depend on
> debhelper >= 10~ to facilitate backports.
> ( N/A ) f108fdfa71c9d66a5ef9dfe7f1f48c170c7f228e UEFI: remove the
> EFI/debian/grub.cfg, not necessary anymore
> ( grub> ) c22f1f5b71745922ae28df0ebf4b7d1a49d89f55 Use
> gcd{x64.aa64}.efi.signed for amd64/arm64 arch.
> ( grub> ) 8403487d4e3bda65cdd2ea6081399f7977325adb copy keys to
> /etc/apt/trusted.gpg.d with appropriate extension for them to not be
> ignored.
> (  ) 52908422880f8d5cfa18c577d4138d5449af37f6 Handle includes.chroot
> files installed over symlinked directories
> (  ) 332c170c3b8dc2449b348191562c784db68ed331 Update changelog for
> 1:20180618 release
> (  ) be7bc0a9ffcc0b59ae66a63a863fb586d7ac1fca Bump Standards-Version to
> 4.1.4, no changes.
> ( Skipped ) 316b1281581b188e3353fe59bb40bcb81cbd953f UEFI: parse vendor
> from Grub package metadata
> (  ) e5492b1c702858eb26e2b93c65810773ad0bfa85 Avoid apt-key add and just
> drop the key in /etc/apt/trusted.gpg.d
> (  ) 186765e3fd905a2ecd08cd22dd9afdcc581b1d0a lb clean: remove ONIE image
> (  ) b3ec8d59787a2c59c5cc68f9fd60ff004049d828 Update changelog for
> 1:20180411 release
> (  ) b062ede56c5aef3b1909efbf87f71d6617bc1936 Fix debian/NEWS date to
> match an actual release
> (  ) 277f0cec71b8a9a1b109225a69551ef5c7ba05e2 Reconfigure bootstrapped
> packages after preseeding.
> (  ) da0119396559308b29c78a7cc983013cf07797f0 Don't recommend gzip, it's
> essential
> (  ) 08dd0b90dbe87411fb0657c940926c85730ac3e7 Print an error and exit if
> a host package (dependency) is missing.
> (  ) 05

Bug#884553: live-build: Foreign architecture package support for linux kernel flavours in Stretch

2019-03-03 Thread adrian15

El 20/11/18 a las 14:19, Raphael Hertzog escribió:

Sorry for the delay in answering but I have been busy.

> Hi,
> 
> On Sun, 18 Nov 2018, adrian15 wrote:
>> After testing this change the Grub menu which should have two kernel
>> entries has only one. It might be other of my patches are pending of
>> applying or somewhat I messed up with this patch.
> 
> It's up to you to figure this. I won't do it for you. And I won't merge
> the patch until you have something working entirely.

I understand.
I think I was talking aloud because I wish I had no difference from my
live-build fork to the upstream one (The Debian one) but there are still
differences nowadays.

I will try the patch as an standalone patch without merging it with my
other patches. That way I can prove the modifications are right.

Anyways let's continue answering the email.

> 
>> I know modifying the live-manual package is pending. I prefer waiting
>> for your feedback on my new implementation before commiting work on
>> live-manual.
> 
> The attached patch looks acceptable. The only small comments are below:

Ok.

> 
>> Once you have done this thanks to this commit
>> now you can set linux flavours ( --linux-flavours ) as:
>>
>> "i386 amd64:amd64"
>>
>> in a i386 system and it will install the amd64 kernel alongside the i386 
>> system.
> 
> This should really be part of the documentation (manual page) because
> right now the explanation is not clear on what it brings:
> 
>>  .IP "\-k|\fB\-\-linux\-flavours\fR \fIFLAVOUR\fR|""\fIFLAVOURS\fR""" 4
>> -sets the kernel flavours to be installed. Note that in case you specify 
>> more than that the first will be configured the default kernel that gets 
>> booted.
>> +sets the kernel flavours to be installed. Note that in case you specify 
>> more than that the first will be configured the default kernel that gets 
>> booted. Optionally you can use an architecture qualifier, e.g. amd64:amd64, 
>> so that it works ok when you add a foreign architecture to your build system.
> 
> That's the part to be expanded.

Ok, I'll try to do something on it.

> 
>> --- a/scripts/build/config
>> +++ b/scripts/build/config
>> @@ -1133,7 +1133,7 @@ LB_KEYRING_PACKAGES="${LB_KEYRING_PACKAGES}"
>>  
>>  # \$LB_LINUX_FLAVOURS: set kernel flavour to use
>>  # (Default: autodetected)
>> -LB_LINUX_FLAVOURS="${LB_LINUX_FLAVOURS}"
>> +LB_LINUX_FLAVOURS_WITH_ARCH="${LB_LINUX_FLAVOURS}"
> 
> I think you need to update all 3 occurences of LB_LINUX_FLAVOURS in this
> hunk... not only the name of the variable being assigned.

The reason why I didn't renamed everything to
LB_LINUX_FLAVOURS_WITH_ARCH was so that any project relying on the old
variable LB_LINUX_FLAVORUS did work without having to update its
configuration.


I don't have too much time so I will use the long name as you suggested
and probably update some related documentation, changelog or something.


> 
> Cheers,
> 

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

Bug#884553: live-build: Foreign architecture package support for linux kernel flavours in Stretch

2018-11-18 Thread adrian15

El 23/02/18 a las 17:43, Raphael Hertzog escribió:
> Hi,
> 
> On Sat, 23 Dec 2017, adrian15 wrote:
>> 3) So I dropped that implementation of the patch and searched for
>> something more elegant. A patch that modified the least possible lines
>> of the live-build code and I finally found out how... with this new
>> package based variable that would only have to be used in one specific
>> place.
>>
>> And that's the patch I submitted here in the first place.
> 
> Ok, fine. But we should use more explicit variable names.
> 
> Please modify scripts/build/config to store the value of
> --linux-flavours in LB_LINUX_FLAVOURS_WITH_ARCH and then
> define LB_LINUX_FLAVOURS in functions/defaults.sh
> based on LB_LINUX_FLAVOURS_WITH_ARCH (as you did but with different
> variable names).
> 
> Also update the lb-config manual page to explain that you
> can use architecture qualifier. And you should submit an update
> to live-manual too (see section 8.2.9 Kernel flavour and version).
> https://debian-live.alioth.debian.org/live-manual/stable/manual/html/live-manual.en.html#435
> 
> Please submit both patches as merge requests:
> https://salsa.debian.org/live-team/live-build/merge_requests
> https://salsa.debian.org/live-team/live-manual/merge_requests
> 
> Cheers,

Sorry for the late reply.

I have reworked this a bit.
I no longer use the somewhat artificial LB_PACKAGE_LINUX_FLAVOURS variable.

This patch is based on the current master tip (
2fa258cca25d834f7896b7adc64892dc583010bf ) .

After testing this change the Grub menu which should have two kernel
entries has only one. It might be other of my patches are pending of
applying or somewhat I messed up with this patch.

I know modifying the live-manual package is pending. I prefer waiting
for your feedback on my new implementation before commiting work on
live-manual.

You can find the same commit on this branch:
https://salsa.debian.org/adrian15sgd-guest/live-build/tree/foreign-architecture-support-salsa2018-quicktest4

.

Thank you for your feedback.


adrian15
-- 
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
>From d8cb285610ff620f62fae4601e99f11e1edd0cb2 Mon Sep 17 00:00:00 2001
From: Adrian Gibanel Lopez 
Date: Fri, 15 Dec 2017 17:22:57 +
Subject: [PATCH] Fixed foreign architecture package support to linux kernel
 flavours

This problem originated in Stretch where amd64 kernel is not part of i386 repo.
So it needs to be fetched from amd64 repo.

So first of all you need to enable amd64 foreign architecture in your i386 system
thanks to:

dpkg --add-architecture amd64
apt-get update
.

Once you have done this thanks to this commit
now you can set linux flavours ( --linux-flavours ) as:

"i386 amd64:amd64"

in a i386 system and it will install the amd64 kernel alongside the i386 system.
---
 functions/defaults.sh| 24 
 manpages/en/lb_config.1  |  2 +-
 scripts/build/chroot_linux-image |  2 +-
 scripts/build/config |  2 +-
 4 files changed, 19 insertions(+), 11 deletions(-)

diff --git a/functions/defaults.sh b/functions/defaults.sh
index c48955104..c1ca10258 100755
--- a/functions/defaults.sh
+++ b/functions/defaults.sh
@@ -407,27 +407,27 @@ Set_defaults ()
 	# Setting linux flavour string
 	case "${LB_ARCHITECTURES}" in
 		arm64)
-			LB_LINUX_FLAVOURS="${LB_LINUX_FLAVOURS:-arm64}"
+			LB_LINUX_FLAVOURS_WITH_ARCH="${LB_LINUX_FLAVOURS_WITH_ARCH:-arm64}"
 			;;
 
 		armel)
 			# armel will have special images: one rootfs image and many additional kernel images.
 			# therefore we default to all available armel flavours
-			LB_LINUX_FLAVOURS="${LB_LINUX_FLAVOURS:-marvell}"
+			LB_LINUX_FLAVOURS_WITH_ARCH="${LB_LINUX_FLAVOURS_WITH_ARCH:-marvell}"
 			;;
 
 		armhf)
 			# armhf will have special images: one rootfs image and many additional kernel images.
 			# therefore we default to all available armhf flavours
-			LB_LINUX_FLAVOURS="${LB_LINUX_FLAVOURS:-armmp armmp-lpae}"
+			LB_LINUX_FLAVOURS_WITH_ARCH="${LB_LINUX_FLAVOURS_WITH_ARCH:-armmp armmp-lpae}"
 			;;
 
 		amd64)
-			LB_LINUX_FLAVOURS="${LB_LINUX_FLAVOURS:-amd64}"
+			LB_LINUX_FLAVOURS_WITH_ARCH="${LB_LINUX_FLAVOURS_WITH_ARCH:-amd64}"
 			;;
 
 		i386)
-LB_LINUX_FLAVOURS="${LB_LINUX_FLAVOURS:-686-pae}"
+LB_LINUX_FLAVOURS_WITH_ARCH="${LB_LINUX_FLAVOURS_WITH_ARCH:-686-pae}"
 			;;
 
 		ia64)
@@ -438,7 +438,7 @@ Set_defaults ()
 	;;
 
 *)
-	LB_LINUX_FLAVOURS="${LB_LINUX_FLAVOURS:-itanium}"
+	LB_LINUX_FLAVOURS_WITH_ARCH="${LB_LINUX_FLAVOURS_WITH_ARCH:-itanium}"
 	;;
 			esac
 			;;
@@ -451,7 +451,7 @@ Set_defaults ()
 	;;
 
 *)
-

Re: Missing the rescue CD image, what can I do?

2018-07-26 Thread adrian15

El 25/07/18 a las 16:27, Steve McIntyre escribió:
> On Wed, Jul 25, 2018 at 01:36:56PM +0100, Jose M Calhariz wrote:
>>
>> Just to check I am on the right path.  You mean to create a task
>> like this:
>>
>> 0 9 SSH-AGENT  Wed Jul 25 13:23:50 CWD=~/debian_work/cd-images/live-tasks.git
>> cal@riker[582]>git diff
>> diff --git a/debian/control b/debian/control
>> index b7728a4..a4a2f08 100644
>> --- a/debian/control
>> +++ b/debian/control
>> @@ -357,3 +357,14 @@ Recommends: live-task-localisation,
>> Description: Live environment support for Mate
>>  This metapackage installs packages and documentation to support the Debian
>>  live Mate environment.
>> +
>> +Package: live-task-rescue
>> +Architecture: all
>> +Depends: ${misc:Depends},
>> +live-task-base,
>> +live-task-recommended,
>> +live-task-extra,
>> +amanda-client
>> +Description: Live environment support for Rescue CD
>> + This metapackage installs packages and documentation to support the Debian
>> + live Rescue CD.
> 
> That's exactly it, yes. And be prepared to maintain the list
> as/when/if other people want changes.
> 

There are some resources which you can probably recycle from my older work:

https://lists.debian.org/debian-live/2015/11/msg00075.html
which links to the more useful:
https://adrian15sgd.wordpress.com/2015/11/13/about-rescue-tools-in-gnulinux-systems-in-2014-draft/
.

Then also check for the rescapp and rescatux dependencies at:

https://github.com/rescatux/rescapp/blob/debian-dev/debian/control

and:

https://github.com/rescatux/rescatux/blob/jessie/rescatux_common_packages

.

Be wise to discard graphical programs because rescapp needs an UI.

I know that rescapp does not fit into a rescue task rescue because it
needs and UI but if you happen to take a look and you find somehow
rescapp interesting you can take a look at:
https://www.supergrubdisk.org/other-stuff/rescatux-package-repository/
.

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

Bug#884585: live-build: Grub autodetect option no longer works with 686 kernel

2017-12-23 Thread adrian15

El 21/12/17 a las 14:32, Raphael Hertzog escribió:
> On Sun, 17 Dec 2017, adrian15 wrote:
>>* What led up to the situation?
> 
> The reportbug templates are not always very appropriate when you
> just want to submit a patch... just go straight to the explanation
> of the patch and why it should be merged.
> 
>> I attach a patch (that can be applied on current git head) that fixes
>> this bug by replacing the old 486 references
>> with the new 686 references in binary_loopback_cfg file.
> 
> Applied. I also renamed the variables for consistency.
> 
> Cheers,
> 
Thank you for applying it.

Just for the record. I did not update those variables so that further
commits / pull requests around that code did work in a clean manner and
would not have to depend on a previous commit / patch of mine.

And, well, I somehow thought it did not matter too much. Actually
renaming them to X86 would be a better move.

But, then, you know there is 686 but... there hasn't been any 786
kernels so I don't think that variable will get renamed any where in the
future... so that's fine after all.

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

Bug#884553: live-build: Foreign architecture package support for linux kernel flavours in Stretch

2017-12-23 Thread adrian15

El 21/12/17 a las 14:11, Raphael Hertzog escribió:
> Hi,
> 
> On Sat, 16 Dec 2017, adrian15 wrote:
>> Now using:
>>
>> --linux-flavours="amd64:amd64 686"
>>
>> in a i386 system does install amd64 kernel from amd64 architecture in a
>> transparent manner.
>>
>> Please tell me if there's something to be polished so that it's accepted
>> upstream.
> 
> Your patch does nothing except dropping the ":amd64" suffix. You could
> just as well not use the suffix and use your system where you manually
> enabled the foreign architecture.
> 
> I would have expected your patch to somehow add the foreign architecture
> to the build chroot and figure it out from there.
> 
> As it stands, I don't see the point of this patch.
> 
> Cheers,

  I wanted to spare you the long explanation but here it goes.

1) live-build already enables the foreign architecture in linux flavour
associated packages

https://anonscm.debian.org/cgit/debian-live/live-build.git/tree/scripts/build/chroot_install-packages?id=acafe6618bfb7a9f7525e723e13ade2956e10b4f#n45

That: packages.foreign-architectures file gets created at:

https://anonscm.debian.org/cgit/debian-live/live-build.git/tree/scripts/build/chroot_package-lists?id=acafe6618bfb7a9f7525e723e13ade2956e10b4f#n80

which it's reading: packages.chroot file.

packages.root file is being feed up with the linux flavour packages in:

https://anonscm.debian.org/cgit/debian-live/live-build.git/tree/scripts/build/chroot_linux-image?id=acafe6618bfb7a9f7525e723e13ade2956e10b4f#n51

2) My first implementation of this patch tried not to invent a new
package variable (which would keep the :amd64 package suffix) but to
invent a new filename variable so that further code regarding installing
different linux kernel filenames did not fail later in the code.

I mean:

DEFAULT_KERNEL="$(basename chroot/boot/vmlinuz-*${DEFAULT_FLAVOUR})"

would have translated to:

DEFAULT_KERNEL="$(basename chroot/boot/vmlinuz-*amd64:amd64)"

and there is no such installed files with those filenames.

You can check it here:
https://github.com/rescatux/live-build/commit/25bbc377a2e9ca67240f7a396f53637426ba4eb6

I discarded myself this implementation because it modifies too many
lines (Occam's razor reference) and seems too much of an artificial fix.

3) So I dropped that implementation of the patch and searched for
something more elegant. A patch that modified the least possible lines
of the live-build code and I finally found out how... with this new
package based variable that would only have to be used in one specific
place.

And that's the patch I submitted here in the first place.

  Do you prefer my discarded implementation? The one I sent initially?
Or is it a better way of approaching this problem?

  Thank you for your feedback.

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

Bug#884591: live-build: grub.cfg failsafe entries rework

2017-12-17 Thread adrian15

Package: live-build
Version: 1:20171207
Severity: normal
Control: tags -1 + patch

Dear Maintainer,


   * What led up to the situation?

I was trying to build a live cd that has both two kernels: 686 and amd64
and at the same time which would be any hybrid disk so that I can boot
in a BIOS-only machine and in an UEFI-only machine.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

I used these options:
--linux-flavours="686 amd64"
--bootloaders="syslinux,grub-efi"
to build my system.

   * What was the outcome of this action?

Failsafe entries were shown next to the autodetect entry for a default
kernel.

   * What outcome did you expect instead?

I expected to see specific autodetect failsafe entries that only are
shown when the autodetect entries are used.

   * Patch attached

I attach a patch that fixes this problem. Now failsafe entries are
consistent in both autodetect entries and not autodetect entries.

You can also find the same patch at:
* Repo: https://github.com/rescatux/live-build.git
* Branch: loopback_cfg_failsafe_rework

-- System Information:
Debian Release: 9.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8),
LANGUAGE= (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages live-build depends on:
ii  debootstrap  1.0.89

Versions of packages live-build recommends:
ii  apt-utils   1.4.8
ii  cpio2.11+dfsg-6
pn  live-boot-doc   
pn  live-config-doc 
pn  live-manual-html | live-manual  
ii  wget1.18-5+deb9u1

live-build suggests no packages.
>From 3be183c837df0cb11f8ea29e688f0e2002381b13 Mon Sep 17 00:00:00 2001
From: Adrian Gibanel Lopez 
Date: Sat, 16 Dec 2017 23:01:33 +
Subject: [PATCH] Failsafe entries rework at binary_loopback_cfg

---
 scripts/build/binary_loopback_cfg | 21 +++--
 1 file changed, 15 insertions(+), 6 deletions(-)

diff --git a/scripts/build/binary_loopback_cfg b/scripts/build/binary_loopback_cfg
index 00f537c48..04a1624bc 100755
--- a/scripts/build/binary_loopback_cfg
+++ b/scripts/build/binary_loopback_cfg
@@ -199,14 +199,23 @@ if [ "${_AMD64_486_NUMBER}" -ge 2 ] ; then
 		"/${INITFS}/${AMD64_INITRD}" \
 		"/${INITFS}/${_486_KERNEL}" \
 		"/${INITFS}/${_486_INITRD}" \
-		"$APPEND_LIVE"
+		"${APPEND_LIVE}"
+
+	if [ "${LB_BOOTAPPEND_LIVE_FAILSAFE}" != "none" ]
+	then
+		Grub_live_autodetect_entry "Live system (autodetect) (fail-safe mode)" \
+			"/${INITFS}/${AMD64_KERNEL}" \
+			"/${INITFS}/${AMD64_INITRD}" \
+			"/${INITFS}/${_486_KERNEL}" \
+			"/${INITFS}/${_486_INITRD}" \
+			"${LB_BOOTAPPEND_LIVE_FAILSAFE}"
+	fi
 else
 	Grub_live_entry "Live system" "/${INITFS}/${DEFAULT_KERNEL}" "/${INITFS}/${DEFAULT_INITRD}" "${APPEND_LIVE}"
-fi
-
-if [ "${LB_BOOTAPPEND_LIVE_FAILSAFE}" != "none" ]
-then
-	Grub_live_entry "Live system (fail-safe mode)" "/${INITFS}/${DEFAULT_KERNEL}" "/${INITFS}/${DEFAULT_INITRD}" "${LB_BOOTAPPEND_LIVE_FAILSAFE}"
+	if [ "${LB_BOOTAPPEND_LIVE_FAILSAFE}" != "none" ]
+	then
+		Grub_live_entry "Live system (fail-safe mode)" "/${INITFS}/${DEFAULT_KERNEL}" "/${INITFS}/${DEFAULT_INITRD}" "${LB_BOOTAPPEND_LIVE_FAILSAFE}"
+	fi
 fi
 
 _COUNT=0

Bug#884588: live-build: Showing all kernels at grub menu when there is more than one kernel is not working

2017-12-17 Thread adrian15

Package: live-build
Version: 1:20171207
Severity: normal
Control: tags -1 + patch

Dear Maintainer,


   * What led up to the situation?

I was trying to build a live cd that has both two kernels: 686 and amd64
and at the same time which would be any hybrid disk so that I can boot
in a BIOS-only machine and in an UEFI-only machine.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

I used these options:
--linux-flavours="686 amd64"
--bootloaders="syslinux,grub-efi"
to build my system.

   * What was the outcome of this action?

After autodetect menu in grub.cfg / grub menu there was not
any specific menu for either amd64 kernel or 686 kernel.
And I remember having these menus back in the day.

   * What outcome did you expect instead?

I expected to have an additional amd64 kernel boot entry
and a 686 kernel boot entry.

   * Patch attached

I attach a patch that fixes this problem. It seems it was just a typo.

You can also find the same patch at:
* Repo: https://github.com/rescatux/live-build.git
* Branch: showing-all-kernels-at-grub-cfg-when-more-than-one-kernel


-- System Information:
Debian Release: 9.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8),
LANGUAGE= (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages live-build depends on:
ii  debootstrap  1.0.89

Versions of packages live-build recommends:
ii  apt-utils   1.4.8
ii  cpio2.11+dfsg-6
pn  live-boot-doc   
pn  live-config-doc 
pn  live-manual-html | live-manual  
ii  wget1.18-5+deb9u1

live-build suggests no packages.
>From ea4199e9cdb6ae57ce6b729e4b66066c56f18916 Mon Sep 17 00:00:00 2001
From: Adrian Gibanel Lopez 
Date: Sat, 16 Dec 2017 22:18:21 +
Subject: [PATCH] Now grub.cfg shows all the kernel options Before this patch
 when you had more than two kernels it only showed the auto option.

---
 scripts/build/binary_loopback_cfg | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/build/binary_loopback_cfg b/scripts/build/binary_loopback_cfg
index 00f537c48..7312adcd0 100755
--- a/scripts/build/binary_loopback_cfg
+++ b/scripts/build/binary_loopback_cfg
@@ -211,7 +211,7 @@ fi
 
 _COUNT=0
 for KERNEL in chroot/boot/vmlinuz-*; do
-	_COUNT=$(( $COUNT + 1 ))
+	_COUNT=$(( $_COUNT + 1 ))
 done
 
 if [ $_COUNT -gt 1 ]; then

Bug#884585: live-build: Grub autodetect option no longer works with 686 kernel

2017-12-17 Thread adrian15

Package: live-build
Version: 1:20171207
Severity: normal
Control: tags -1 + patch

Dear Maintainer,


   * What led up to the situation?

I was trying to build a live cd that has both two kernels: 686 and amd64
and at the same time which would be any hybrid disk so that I can boot
in a BIOS-only machine and in an UEFI-only machine.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

I used these options:
--linux-flavours="686 amd64"
--bootloaders="syslinux,grub-efi"
to build my system.

   * What was the outcome of this action?

No autodetect menu was shown in grub.cfg / grub menu.

   * What outcome did you expect instead?

I expected an autotect menu to appear on grub.cfg / grub menu.

  * Patch attached

I attach a patch (that can be applied on current git head) that fixes
this bug by replacing the old 486 references
with the new 686 references in binary_loopback_cfg file.

You can also find the same patch at:
* Repo: https://github.com/rescatux/live-build.git
* Branch: loopback_cfg_686_kernel_support


-- System Information:
Debian Release: 9.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8),
LANGUAGE= (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages live-build depends on:
ii  debootstrap  1.0.89

Versions of packages live-build recommends:
ii  apt-utils   1.4.8
ii  cpio2.11+dfsg-6
pn  live-boot-doc   
pn  live-config-doc 
pn  live-manual-html | live-manual  
ii  wget1.18-5+deb9u1

live-build suggests no packages.
>From 8e769fbc9c43cc1f52649f16b25e06f897a641c2 Mon Sep 17 00:00:00 2001
From: Adrian Gibanel Lopez 
Date: Fri, 15 Dec 2017 18:27:48 +
Subject: [PATCH] Updated binary_loopback_cfg so that it uses Stretch's 686
 kernel instead of old 486 one.

---
 scripts/build/binary_loopback_cfg | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/build/binary_loopback_cfg b/scripts/build/binary_loopback_cfg
index 00f537c48..93c50f485 100755
--- a/scripts/build/binary_loopback_cfg
+++ b/scripts/build/binary_loopback_cfg
@@ -182,7 +182,7 @@ _AMD64_486_NUMBER="0"
 
 for _FLAVOUR in ${LB_LINUX_FLAVOURS}
 do
-	if [ "${_FLAVOUR}" = "amd64" -o "${_FLAVOUR}" = "486" ] ; then
+	if [ "${_FLAVOUR}" = "amd64" -o "${_FLAVOUR}" = "686" ] ; then
 		_AMD64_486_NUMBER="$((${_AMD64_486_NUMBER} + 1))"
 	fi
 done
@@ -191,7 +191,7 @@ if [ "${_AMD64_486_NUMBER}" -ge 2 ] ; then
 	# Default entries
 	AMD64_KERNEL="$(basename chroot/boot/vmlinuz-*amd64)"
 	AMD64_INITRD="initrd.img-$(echo ${AMD64_KERNEL} | sed -e 's|vmlinuz-||')"
-	_486_KERNEL="$(basename chroot/boot/vmlinuz-*486)"
+	_486_KERNEL="$(basename chroot/boot/vmlinuz-*686)"
 	_486_INITRD="initrd.img-$(echo ${_486_KERNEL} | sed -e 's|vmlinuz-||')"
 
 	Grub_live_autodetect_entry "Live system (autodetect)" \

Bug#884553: live-build: Foreign architecture package support for linux kernel flavours in Stretch

2017-12-16 Thread adrian15

I attach a patch that fixes this bug.

Now using:

--linux-flavours="amd64:amd64 686"

in a i386 system does install amd64 kernel from amd64 architecture in a
transparent manner.

Please tell me if there's something to be polished so that it's accepted
upstream.

This patch:

* It uses the current git head ( d33943ea7a71ba5d874eb20f47bb898da485c77d )

* Can also be found at:
** Repo: https://github.com/rescatux/live-build.git
** Branch: foreign-architecture-support-quicktest3


adrian15
-- 
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
>From 2db746bc858683cee82130caef496376c5bf11f7 Mon Sep 17 00:00:00 2001
From: Adrian Gibanel Lopez <adrian.giba...@btactic.com>
Date: Fri, 15 Dec 2017 17:22:57 +
Subject: [PATCH] Fixed foreign architecture package support to linux kernel
 flavours

This problem originated in Stretch where amd64 kernel is not part of i386 repo.
So it needs to be fetched from amd64 repo.

So first of all you need to enable amd64 foreign architecture in your i386 system
thanks to:

dpkg --add-architecture amd64
apt-get update
.

Once you have done this thanks to this commit
now you can set linux flavours ( --linux-flavours ) as:

"i386 amd64:amd64"

in a i386 system and it will install the amd64 kernel alongside the i386 system.
---
 functions/defaults.sh| 12 
 scripts/build/chroot_linux-image |  2 +-
 scripts/build/config |  4 
 3 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/functions/defaults.sh b/functions/defaults.sh
index 78ca358d1..541cf8a7b 100755
--- a/functions/defaults.sh
+++ b/functions/defaults.sh
@@ -475,6 +475,18 @@ Set_defaults ()
 			;;
 	esac
 
+	if [ -z "${LB_PACKAGE_LINUX_FLAVOURS}" ]
+	then
+		LB_PACKAGE_LINUX_FLAVOURS="${LB_LINUX_FLAVOURS}"
+		LB_LINUX_FLAVOURS=""
+		for FLAVOUR in ${LB_PACKAGE_LINUX_FLAVOURS}
+		do
+			PACKAGE_FILTERED_FLAVOUR="$(echo ${FLAVOUR} | awk -F':' '{print $1}')"
+			LB_LINUX_FLAVOURS="${LB_LINUX_FLAVOURS} ${PACKAGE_FILTERED_FLAVOUR}"
+		done
+	fi
+
+
 	# Set linux packages
 	LB_LINUX_PACKAGES="${LB_LINUX_PACKAGES:-linux-image}"
 
diff --git a/scripts/build/chroot_linux-image b/scripts/build/chroot_linux-image
index a96c4e529..d06ad8261 100755
--- a/scripts/build/chroot_linux-image
+++ b/scripts/build/chroot_linux-image
@@ -48,7 +48,7 @@ Create_lockfile .lock
 #		;;
 #esac
 
-for FLAVOUR in ${LB_LINUX_FLAVOURS}
+for FLAVOUR in ${LB_PACKAGE_LINUX_FLAVOURS}
 do
 	for PACKAGE in ${LB_LINUX_PACKAGES}
 	do
diff --git a/scripts/build/config b/scripts/build/config
index c692a926f..850cbb9b5 100755
--- a/scripts/build/config
+++ b/scripts/build/config
@@ -1116,6 +1116,10 @@ LB_KEYRING_PACKAGES="${LB_KEYRING_PACKAGES}"
 # (Default: autodetected)
 LB_LINUX_FLAVOURS="${LB_LINUX_FLAVOURS}"
 
+# \$LB_PACKAGE_LINUX_FLAVOURS: set kernel flavour package to use
+# (Default: autodetected)
+LB_PACKAGE_LINUX_FLAVOURS="${LB_PACKAGE_LINUX_FLAVOURS}"
+
 # \$LB_LINUX_PACKAGES: set kernel packages to use
 # (Default: autodetected)
 LB_LINUX_PACKAGES="${LB_LINUX_PACKAGES}"

Bug#884553: live-build: Foreign architecture package support for linux kernel flavours in Stretch

2017-12-16 Thread adrian15

Package: live-build
Version: 1:20171207
Severity: normal

Dear Maintainer,

   * Introduction

Jessie had linux-amd64 package in its own i386 section.
Stretch has linux-amd64 package not in i386 section but in amd64 section
only.
When using live-build with Jessie you could use in an i386 Jessie system
this option:
 --linux-flavours="amd64 586"
in order to the amd64 kernel to be installed alongside the 586 kernel in
the same live cd image.

   * What led up to the situation?

Trying to rewrite a live-build configuration from Jessie to Stretch:
 --linux-flavours="amd64 686"

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

I tried this option (using live-build in Stretch):
 --linux-flavours="amd64:amd64 686"

   * What was the outcome of this action?

It failed because linux-image-amd64:amd64-* path for kernel filenames
are not found.

   * What outcome did you expect instead?

I expected the linux-image-amd64:amd64 to be installed and the appropiated
foreign architecture (amd64) to be added in an i386 system.


-- System Information:
Debian Release: 9.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8),
LANGUAGE= (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages live-build depends on:
ii  debootstrap  1.0.89

Versions of packages live-build recommends:
ii  apt-utils   1.4.8
ii  cpio2.11+dfsg-6
pn  live-boot-doc   
pn  live-config-doc 
pn  live-manual-html | live-manual  
ii  wget1.18-5+deb9u1

live-build suggests no packages.

Re: Multiarch live CDs

2017-12-12 Thread adrian15

El 12/11/17 a las 08:38, Borden Rhodes escribió:
> There were days, about a year ago, when I could write in auto/config:
> 
> --architectures 'i386'
> --linux-flavours 'amd64 686-pae'
> 
> And this made me happy because I could generate an image that ran
> natively on both 32 and 64-bit processors (every now and then I run
> into a 32-bit processor I want to run this live CD on). However, now
> when I run lb build, I eventually get the error message:
> 
> Couldn't find any package whose name or description matched 
> "linux-image-amd64"

I ran into your same problem and thanks to the Mert advice I was able to
work it out.

First of all you need to add foreign amd64 architecture to your i386
installation / chroot .

dpkg --add-architecture amd64
apt-get update



And finally what it used to be (in your case):

--linux-flavours 'amd64 686-pae'

now should be replaced by:

--linux-flavours 'amd64:amd64 686-pae'


Enjoy!


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

Re: accessibility like speech and braille in the debian live console and desktop images

2017-05-09 Thread adrian15 adrian15

Well,

  I don't care too much about the approach or if you apply it to
live-wrapper (current Debian Live) or live-build (former Debian Live).
In any case make sure you implement it for both UEFI and BIOS boot. UEFI
uses GRUB2 menues and thus it's slightly different to the current proposed
isolinux/syslinux menues.

  If you need help on developing or testing the UEFI boot options don't
hesitate to ask (after you try on your own ;) ).

2017-05-08 22:11 GMT+02:00 Samuel Thibault :

> Hello,
>
> So, debian-live people, are you fine with this proposal?  I can have a
> look at implementing it, I just want to make sure everybody is fine with
> the approach.
>
> Samuel
>
> Samuel Thibault, on ven. 05 mai 2017 02:01:22 +0200, wrote:
> > I mean having this menu at live boot (shortcuts marked with ^):
> >
> > ^Live
> > Live (^failsafe)
> > ^Install
> > ^Advanced options
> > Live with ^speech synthesis
> >
> > and the Install submenu would just be the standard install menu:
> > ^Back
> > ^Graphical install
> > ^Install
> > ^Advanced options
> > ^Help
> > Install with ^speech synthesis
>
>

-- 
Support free software. Donate to Super Grub Disk. Apoya el software libre.
Dona a Super Grub Disk. http://www.supergrubdisk.org/index.php?pid=10

Re: apt-get install "Failed to fetch" "404 Not Found" IP ...

2017-05-06 Thread adrian15

El 06/05/17 a las 13:31, Albretch Mueller escribió:
>  For more than one good reason (among them an unreliable Internet
> connection at times or simply not wanting to go online)
> 
>  I would like to run apt-get locally (or be able to functionally do
> the same using dpkg or whatever). This is what I have in mind:
> 
>  1) use apt-get in simulate mode to know which files I need to install
> and in what order
> 
>  2) fetch those files and keep them locally
> 
>  3) install them locally whenever I need to
> 
>  Most (all?) people simply go "sudo apt-get" under the assumption that
> the back end repositories will be fine etc.
> 
>  Yes, I am trying to install stuff when I need it without having to
> connect to the Internet
> 
>  How do you do this? What would be the pros and cons of doing things this way?
> 
>  lbrtchx

I didn't have the 'not going at all to the internet' premise but I
didn't want to waste so many bandwith building the isos thanks to
live-build.

Long back I used to apt-mirror the full Debian repos but nowadays it's
too much for my hard disks.

So I use approx for it. It only caches the packages that you actually
download.

I have not tested apt-offline myself so I cannot comment on it.
According to other repliers say it might be more suitable for your needs.


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

Re: propose creation of a debian-rescue blend

2017-03-10 Thread adrian15 adrian15

I just found this new MX Workbench respin iso based on Mepis.

Here's the current list of packages that they use:

https://github.com/AdrianTM/workbench-defaults/blob/master/workbench-tools.list

Just in case it can help you.

adrian15

2016-01-28 17:47 GMT+01:00 Donald Raikes <draike...@gmail.com>:

> --
> Sincerely,
> Donald Raikes
> Hello,
>
> I have been involved in a discussion on the debian-live list for the
> last week or two concerning the old debian-rescue livecd, and based on
> that discussion it seems like converting debian-rescue to a blend is a
> more appropriate direction to go.
>
> I am willing to take the lead on this effort, but I will definitely
> need some help along the way since I haven't ever worked with a blend
> nor do I completely understand what is involved in setting one up.
> I have read the blends manual already, but admittedly I am a little
> confused on the best way to get started.
>
> Any help would be appreciated.
>
> Sincerely,
> Donald Raikes
>
>


-- 
Support free software. Donate to Super Grub Disk. Apoya el software libre.
Dona a Super Grub Disk. http://www.supergrubdisk.org/index.php?pid=10

Re: UEFI Support

2016-09-22 Thread adrian15


El 22/09/16 a las 18:45, Machu Chukov escribió:

As far as I can see from the practical results of my builds, the
modifications of the packages are different:

The live-build package i've built from
anonscm.debian.org/git/debian-live/live-build.git/ produces
uefi-bootable hybrid-isos only when

--bootloader grub-efi


It should produce a UEFI bootable disk if you use:

* --bootloader grub-efi (What you tried)

It should produce a BIOS + UEFI bootable disk if you either use:

* --bootloader syslinux,grub-efi
OR
* --bootloader is not set

.




is set. But I don't want to use grub.

--bootloader syslinux

will produce a iso-hybrid image without UEFI-Suport, that is only
bootable in legacy/CSM mode.


In contrast, the Live-build- Package from Kali
(http://http.kali.org/kali/pool/main/l/live-build/live-build_20151215kali3_all.deb)
produces UEFI-bootable iso-hybrid Images with syslinux.

Is that correct, or have I overlooked something?

My build system is jessie, the target live-system too.



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

Re: UEFI Support

2016-09-14 Thread adrian15




El 13/09/16 a las 14:46, machu chukov escribió:

Hi all,

i am trying to build a debian live-system with UEFI support. Could
please someone verify, if I understood the following correctly:

1. live-build until today does not support uefi-boot for known reasons.
Someone from Debian, I don't know who, would need to release a new 
package with new feature from git.


2. live-build is orphaned, so the patches provided in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731709 until now did
not make it into the live-build package in stretch, so does not help
installing it via backports.

I don't know the Debian specific bits but you are probably right.


3. live-wraper is/wants to get the new live-build/debian-live. But it is
not installable in jessie via backports, because it does'nt work and was
removed some weeks ago from testing, beacuse of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=831637
You might be probably right too. I have heard that irl will invest some 
more time on polishing these problems.


So at the moment there is no way, to build a debian live-system with
uefi-support using only the official repositories.
That's right if by repositories you mean package repositories. There 
might be an slight possibility of daily-build Debian Live images which 
could be in turn based on git... but... I actually don't know how it 
works at all.


The only Workaround is, to build live-build on my own from the Code
provided in https://anonscm.debian.org/cgit/debian-live/live-build.git
in which the patch suggested in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731709 was already
applied.

Is that correct?

Yes, that's correct. That should work.

sudo make install

does it for me. You don't actually need to build the package for using 
the software.But, yes, it should work if you build it and install it.




thanks,

Machu


Waiting for your feedback on the recently UEFI boot support added.

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

Getting Debian Live Packages Source Code not working when pinning and extra repos

2016-09-03 Thread adrian15


  Introduction


  I'm preparing a Rescatux ( http://www.supergrubdisk.org/rescatux/ ) 
stable release. And I'm quite excited because last stable release was 
some years ago.


  As you might know when you release GPL based binaries you are obliged 
to provide its source code. And, as part of growing myself as a FLOSS 
developer I want to get that part right.


  What I tried


  According to the live-build manual if you want to generate your 
Debian Live ISO source code you need to use:


lb config --source true

I personally use:

lb config --source true --source-images tar

so that everything is found in just two tar files.


  Extra repositories and pinning


  Rescatux cannot have its full capabilities without taking some 
additional packages from here and there.


  * Selinux packages are needed from SID because they are not present 
in Jessie. I add a sid repo and pinning for that matter.
  * Boot-repair is used from an Ubuntu PPA. I happen to obtain its 
source code from its repo in an additional step in my source code build 
process. I mention it here because it's quite similar to the Selinux case.
  * Custom tails-greeter packages for nice keyboard selection at login 
screen



  What I get

  I get the source code from all of the packages which are found on the 
default repo (the jessie one).



  What I want

  I want the sid packages source code when those are choosen by pinning 
and the boot-repair ones too.
  I do not expect the packages I install manually (deb packages) to 
have its source code sorted out.


  Live-build code dive preview
-
  The main work is done at: scripts/build/source_debian where not 
additional repos or pinning are taken into account.
  The place where additional repos and pinning is taking into account 
is: scripts/build/chroot_archives but if I'm not mistaken this is only 
used when installing packages.


  So I guess I'll need to figure out how to reuse chroot_archives from 
source_debian if it's possible. Or maybe enhacing source_debian so that 
it reuses some copied parts from chroot_archives.


  A warning

  If you are developing a Debian Live based distribution which relied 
only on "lb config --source true" to comply with GPL requirements that 
happens to have additional repos then you should help me on fixing this 
issue or find a workaround.



Finally, should I fill a bug or am I missing something obvious?
Thank you.


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-build UEFI support: WAS: Re: Debian derivatives census: changes around Debian Live; live-build orphaned

2016-02-25 Thread adrian15


El 25/02/16 a las 10:14, Raphael Hertzog escribió:

Hi Paul,

On Thu, 25 Feb 2016, Paul Wise wrote:

On Thu, 2016-02-25 at 19:46 +1100, Michael . wrote:


Just incase no one already know this there is a version of Live-Build
that supports UEFI.
Kali Linux developer (also Debian Developer) Raphael Hertzog has
patched the current development branch of Live Build to add UEFI
support and it works brilliantly. To use it you must use the Kali
version of Live-Build from their repositories.


Mati, Raphael: would it be possible for you to merge the Kali
live-build UEFI support into the Debian Live team's live-build
repositories?


Our work was submitted in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731709 but
I'm not fully happy with it. And in fact I'm contemplating
replacing it entirely with the GRUB2 based EFI support that
has been contributed in the same bug report more recently.

Cheers,


Hi Paul, Raphael and all.

  I still have to submit an updated patch but what I sent it does work 
already it is just a matter of variable names. Hopefully I don't forget 
what I wanted to change in the first place.


  I am also thinking on also dealing with Grub2 background so that the 
Debian CD does not need to deal with it on its own but I would probably 
implement it in a second step.


  Guess what, I was upset on not having Raphael feedback on the issue 
for more than a month and... well... I have found myself busy on other 
things so I haven't been able to submit an updated patch for almost 
three weeks.


  As Bern Armstrong says we are sometimes more busy with personal lives 
and other projects. :).



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

Re: Various options in Debian Live

2016-02-01 Thread adrian15


El 29/01/16 a las 03:24, Michael . escribió:

FYI I am doing this to see if I can maintain live-build for my own
purposes. My intent is to apply patches that have already been offered,
if I can find them, in order to increase live-build's usability on EFI
machines etc.
 (...)
All relevant replies greatly appreciated.
Cheers.
Michael.



For EFI support please check: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731709 . Hopefully I 
will be able to upload another version of my patch (hopefully a 
definitive one) in seven days.



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

Bug#812358: debian-live: Please add gparted

2016-01-22 Thread adrian15


El 22/01/16 a las 23:47, Don Raikes escribió:

Hi,

I am willing to take the lead on resurrecting debian-live-rescue, but according 
to this webpage:
http://syn.theti.ca/2015/06/23/debian-live-rescue-needs-some-love/comment-page-1/#comment-5665

I should start by trying to build a rescue image from the existing live-image 
sources.

However, when I go to https://github.com/debian-live/live-images.git I cannot 
find a branch that contains the old rescue build configuration.

Is this configuration laying around somewhere I can use as a starting point?


Take a look at:

https://lists.debian.org/debian-live/2014/08/msg00081.html

https://adrian15sgd.wordpress.com/2015/11/13/about-rescue-tools-in-gnulinux-systems-in-2014-draft/ 
(Find the configuration link you want there. ;) )


https://lists.debian.org/debian-live/2015/11/msg00075.html

On one night we discussed in #debian-live irc about this rescue image / 
rescue blend and well. I leave you some bits here:



1) There was some discussion about the original dba plans on submitting 
a tasksel-rescue package versus what it's currently used:


* task-rescue (task-* is official tasks maintained by the d-i team).
* blendname-tasks (Already used in blends for their specific stuff.)

What I mean is that my article begins with me trying to make a 
tasksel-rescue package and it turns out that this package name not even 
exists.


2) Ben Armstrong wanted to reuse some of the packages I used on 
Rescatux. I warned him that Rescatux was graphical oriented and that I 
left out some cli tools from it. Some sysadmins might consider using 
grml instead of Rescatux for cli purposes just for that.



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

live-wrapper - RFE - Arch boot automatic detection

2015-11-18 Thread 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/

live-wrapper - RFE - Set your own distribution name

2015-11-18 Thread 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/

Draft for tasksel-rescue

2015-11-12 Thread adrian15

, but that do not have too
  much in common.
* Editors. Some console editors. Some of them as hexedit are 
specific for

  non standard text editing.
* Hard disk. Tools for dealing with cdrom and hard disks.. Check 
hard disk

  status. Secure delete.
* Browser. Some console Internet browsers.
* Compression. Compression tools similar to well known zip tool.
* Backup. Some handy tools for doing backups.
* File comparison. Tools for comparing files.
* General. Similar to system section. Many tools that you might 
need but

  that do not fit somewhere else.
* Special hardware. Some special hardware packages.
* Network
  o Network – Firewall. Tools for avoiding having ports open.
  o Network – Essential networking. These tools make easier to 
connect

the live cd to the Internet.
  o Network – Bridging. Tools for doing network bridges.
  o Network – Routing. More toos for dealing with networks.
  o Network – Monitoring. Tools for monitoring the network.
  o Network – Testing. Mainly tools for testing the network.
  o Network Analysers. Some of these tools help debugging networks.
  o Network servers. Some useful tools when you want to serve some
network services.
* Log Analysers . These tools help you to analyse log files.
* Filesystem tools. Filesystem tools for doing operations over 
filesystems.
* Microsoft tools. Some filesystem and network tools that only make 
sense

  for Microsoft systems.
* Miscellanea. Whatever does not fit in the rest of groups.
* Flab. Not sure what it means.
 Package groups analysis 
Now I’m going to go through all these groups and argue if they need to be
inside Rescatux or in rescue tasksel.
*  Gnu/Linux Rescue Live CDs *
Now I’m going to go through most of the current GNU/Linux Rescue Live 
CDs. The

idea is having a little description of the cd, what it’s main purpose and
relation to rescue tools. We will try to find its packages groups to add 
them

to taxonomy section above. Finally we will have a link to its packages,
specially the rescue ones.
In order not to forget any GNU/Linux Rescue Live CDs is interesting to 
use some

rescue_cds_listings:


* Debian Live Rescue CD
* Rescatux
* Parted Magic
* System Rescue CD
* Ultimate Boot CD

* Miscellanea *
non-free packages. This is Debian specific.
*  Non GNU/Linux tools *
Memtest
Super Grub2 Disk

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

SELinux support for Debian Live - Feedback welcomed

2015-10-17 Thread adrian15

1)  I just wanted to share with you that I have finally managed to add 
SELinux support for Debian Live.


  The current SELinux packages in Debian are a bit buggy. You even need 
to use packages from Debian sid in order to make it work. That's why I'm 
not going to push this into Debian Live next branch till all the needed 
packages are in Debian Jessie.


2) Is there anyone interested in SELinux being part of Debian Live?
I need your feedback on knowing if you want enforced mode by default or 
if permissive is fine. Anything about default policy type.


3) Needed live-build upgrades can be found at:

* Repo: https://github.com/adrian15/live-build/
* Tag: rescatux-0.40b1

* Commit: 42a8f50690be1153285dc8841ec532ac2281e27d

What it's missing from the implementation is:

* Choosing to enable it or not (It's enabled by default)
* Choose between permissive or enforce mode at boot
* Ensure the kernel command line parametres are the right ones for 
selinux (I do it on the Rescatux (My Debian Live distro) side.)
* Ensure minimal SELinux packages are installed on chroot. Not sure if 
live-build it's the place where to force these package installations by 
the way.


If you are interested on the other side of the implementation in 
Rescatux take a look at:


* Repo: http://sourceforge.net/p/rescatux/git/
* Tag: v0.40b1

* Commits:
** 9f74111d7c5222a739054af1900784481f6496c3
** 7b9c95246d56fc539ad2e0cb899e83b7fe2c7518
** 3237938e62e37c62cd03575e5be0c349e3d923e5
** 4318f18b61901d898ca24734f578a7846b14dc0d

4) Finally check the Rescatux page ( 
http://www.supergrubdisk.org/rescatux/ ) . In less than 48 hours I will 
be releasing 0.40 beta 1 featuring this SELinux support.


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

Advice on adding SELinux to Debian Live

2015-10-17 Thread adrian15

(Sorry if some pieces explained here seems too obvious for Debian Live 
list normal users. I am recycling an former email sent to a non Debian 
Live person.)


1) Introduction

1.1) I develop Rescatux ( http://www.supergrubdisk.org/rescatux/ ) which 
it's a live cd aimed at rescue tasks.

1.2) Rescatux is based on Debian Live ( http://live.debian.net/ ).
1.3) Debian Jessie (current Debian stable version) supports SElinux if 
you install some packages from sid (Debian unstable branch). What I mean 
by "supports SElinux" is that you can use it from a Debian installation.


2) SElinux permissions problems on Fedora / Centos / RHEL systems.

Rescatux has many options for interacting from itself (as a Debian Live 
cd) to installed systems.

E.g. you can change root password easily.

These operation involves modifying /etc/shadow file.

As Rescatux does not currently support SElinux the /etc/shadow loses its 
default SElinux permissions.


As you might know the consequence is that if you did that in a SElinux 
enforced mode Fedora installation the next time you try to login into 
your system as root (and actually as another users too) it will fail. 
Why? Because SElinux refuses whatever library handles login to read the 
/etc/shadow file.


3) As Rescatux is a Debian Live based system I want to add SElinux 
support to Debian Live in order to have SElinux support in Rescatux and 
avoid these problems.


The final target is to have SElinux support and then change selinux 
policy for the chrooted system's one. As mjg59 suggested in fedora-devel 
chat it's just running: semodule -R (inside the chroot I guess) which 
does it.


4) What I have done so far?

4.1) I have added Debian SELinux packages
(
+ libapol4 \
+ libqpol1 \
+ policycoreutils \
+ python-ipy \
+ python-selinux \
+ python-semanage \
+ python-sepolgen \
+ python-sepolicy \
+ python-setools \
+ selinux-utils \
+ selinux-basics \
+ auditd \
)

to both binary and chroot part of Debian Live (binary is what goes into 
the final iso itself and chroot is what's inside the squashfs).


4.2) When I boot from Rescatux I add to kernel boot command line these 
parametres: selinux=1 enforcing=0 .


4.3) I have also modified Debian Live to inforce SELinux. (Not fully 
succesfully but I have done it.)


(Here there is where I got inspiration from Fedora's livecd-tools 
(https://github.com/rhinstaller/livecd-tools) 
(https://github.com/rhinstaller/livecd-tools/blob/master/imgcreate/creator.py).


4.3.1) Make sure the directory which it's going to be converted into 
SElinux has SELinux permissions thanks to:


+   setfiles -F -r chroot 
/etc/selinux/default/contexts/files/file_contexts chroot

+   chcon -u system_u chroot/proc
+   chcon -u system_u chroot/sys

4.3.2) Make sure the mksquashfs puts the SElinux permissions into the 
big squashfs file (I have checked and it's true that they are there).


+   MKSQUASHFS_OPTIONS="${MKSQUASHFS_OPTIONS} -xattrs"

5) So, well, the problem is that after all these changes Rescatux 
refuses to boot in SElinux mode thus I cannot load any policy manually 
and thus the SElinux permissions problems persists.


6) What am I missing?

Is there anything about how livecd-tools prepare the live cd that I am 
missing?
Something that has to be inside the initrd that does not come by default 
in the Debian or Debian Live's initrds ?


Thank you very much for any insight you might have.

7) Annex A. Rescatux updates:

Jessie branch: http://sourceforge.net/p/rescatux/git/ci/jessie/tree/
Commit: 9f74111d7c5222a739054af1900784481f6496c3

8) Annex B. Debian Live update:

tmp-selinux branch: https://github.com/adrian15/live-build/tree/tmp-selinux
Commit: 42a8f50690be1153285dc8841ec532ac2281e27d


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

Re: Multi Bootloaders support patch (not working)

2015-08-26 Thread adrian15


I attach the new patch that seems to work ok with the default value.
I have not tried two bootloaders at the same time yet.
I will do these tests when I implement loopback.cfg binary based on this 
commit.


I copy and paste from the git commit because I'm concerned on how to 
deal with IFS variable (not saving and reusing the old value (well, 
that's not exactly what I'm actually doing) was the reason why things 
did not work as expected).


Finally I have not commited this to a custom tmp-something branch based 
debian-next yet. I will wait till I have something more robust unless 
you think it's better for me to commit it instead of sending patches here.


---

Note: OLDIFS use makes IFS to be reset to  instead to it being unset.
Either we need to detect if old IFS was unset to unset it
or we need a proper way of setting it as a local variable.
Even more IFS it's not currently used in
Check_package (which it's called from: binary_hdd).
we should have a clean way of resetting/unsetting IFS when calling 
Check_package.


The other approach it's to explicitly define IFS with its default 
value in the
places inside live-build code where we implicitly suppose that it's 
going to have

its default value.




El 21/08/15 a las 20:08, adrian15 escribió:
This is a patch for adding Multi bootloaders support to Debian Live. 
(Based on current git master).


This is the first step I need to be able to add loopback.cfg support 
to Debian Live.


It's currently not working. Any help on debugging it it's needed.

Thank you !

adrian15


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

commit 036355074e84e4088d307d7c4cd7474ac0010b04
Author: Adrian Gibanel Lopez adrian.giba...@btactic.com
Date:   Fri Aug 21 23:54:46 2015 +0200

Multi bootloader support

Note: OLDIFS use makes IFS to be reset to  instead to it being unset.
Either we need to detect if old IFS was unset to unset it
or we need a proper way of setting it as a local variable.
Even more IFS it's not currently used in
Check_package (which it's called from: binary_hdd).
we should have a clean way of resetting/unsetting IFS when calling Check_package.

The other approach it's to explicitly define IFS with its default value in the
places inside live-build code where we implicitly suppose that it's going to have
its default value.

diff --git a/functions/defaults.sh b/functions/defaults.sh
index eba52ae..a0cb968 100755
--- a/functions/defaults.sh
+++ b/functions/defaults.sh
@@ -536,11 +536,11 @@ Set_defaults ()
 	esac
 
 	# Setting bootloader
-	if [ -z ${LB_BOOTLOADER} ]
+	if [ -z ${LB_BOOTLOADERS} ]
 	then
 		case ${LB_ARCHITECTURES} in
 			amd64|i386)
-LB_BOOTLOADER=syslinux
+LB_BOOTLOADERS=syslinux
 ;;
 		esac
 	fi
@@ -853,7 +853,10 @@ Check_defaults ()
 		fi
 	fi
 
-	if [ ${LB_BOOTLOADER} = syslinux ]
+
+	LB_PRIMARY_BOOTLOADER=$(echo ${LB_BOOTLOADERS} | awk -F, '{ print $1 }')
+
+	if [ ${LB_PRIMARY_BOOTLOADER} = syslinux ]
 	then
 		# syslinux + fat or ntfs, or extlinux + ext[234] or btrfs
 		case ${LB_BINARY_FILESYSTEM} in
@@ -867,7 +870,7 @@ Check_defaults ()
 
 	case ${LIVE_IMAGE_TYPE} in
 		hdd*)
-			case ${LB_BOOTLOADER} in
+			case ${LB_PRIMARY_BOOTLOADER} in
 grub)
 	Echo_error You have selected a combination of bootloader and image type that is currently not supported by live-build. Please use either another bootloader or a different image type.
 	exit 1
diff --git a/scripts/build/binary_grub-legacy b/scripts/build/binary_grub-legacy
index 8a2093b..59daab0 100755
--- a/scripts/build/binary_grub-legacy
+++ b/scripts/build/binary_grub-legacy
@@ -24,9 +24,19 @@ Arguments ${@}
 Read_conffiles config/all config/common config/bootstrap config/chroot config/binary config/source
 Set_defaults
 
-if [ ${LB_BOOTLOADER} != grub-legacy ]
-then
-	exit 0
+FOUND_MYSELF=
+IFS=, ; for BOOTLOADER in ${LB_BOOTLOADERS} ; do
+
+   case ${BOOTLOADER} in
+   grub-legacy )
+   FOUND_MYSELF=True
+   break ;;
+   esac
+
+done
+
+if [ -z ${FOUND_MYSELF} ] ; then
+exit 0
 fi
 
 Echo_message Begin installing grub-legacy...
diff --git a/scripts/build/binary_grub-pc b/scripts/build/binary_grub-pc
index de2683c..d8085fb 100755
--- a/scripts/build/binary_grub-pc
+++ b/scripts/build/binary_grub-pc
@@ -24,9 +24,21 @@ Arguments ${@}
 Read_conffiles config/all config/common config/bootstrap config/chroot config/binary config/source
 Set_defaults
 
-if [ ${LB_BOOTLOADER} != grub-pc ]
-then
-	exit 0
+FOUND_MYSELF=
+OLDIFS=$IFS
+IFS=, ; for BOOTLOADER in ${LB_BOOTLOADERS} ; do
+
+   case ${BOOTLOADER} in
+   grub-pc )
+   FOUND_MYSELF=True
+   break ;;
+   esac
+
+done
+IFS=$OLDIFS
+
+if [ -z ${FOUND_MYSELF} ] ; then
+exit 0
 fi
 
 Echo_message Begin installing

Multi Bootloaders support patch (not working)

2015-08-21 Thread adrian15

This is a patch for adding Multi bootloaders support to Debian Live. 
(Based on current git master).


This is the first step I need to be able to add loopback.cfg support to 
Debian Live.


It's currently not working. Any help on debugging it it's needed.

Thank you !

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

commit c0263ca760f1af55a4b74c386baba14ea84eea7c
Author: Daniel Baumann m...@daniel-baumann.ch
Date:   Fri Aug 14 14:05:39 2015 +0200

Wrap and sort debian control file.

diff --git a/debian/control b/debian/control
index 05d6c59..f2996af 100644
--- a/debian/control
+++ b/debian/control
@@ -2,8 +2,10 @@ Source: live-build
 Section: misc
 Priority: optional
 Maintainer: Live Systems Maintainers debian-live@lists.debian.org
-Uploaders: Daniel Baumann m...@daniel-baumann.ch
-Build-Depends: debhelper (= 9)
+Uploaders:
+ Daniel Baumann m...@daniel-baumann.ch,
+Build-Depends:
+ debhelper (= 9),
 Standards-Version: 3.9.6
 Homepage: http://live-systems.org/devel/live-build/
 Vcs-Browser: http://live-systems.org/gitweb/?p=live-build.git
@@ -12,18 +14,18 @@ Vcs-Git: git://live-systems.org/git/live-build.git
 Package: live-build
 Architecture: all
 Depends:
- ${misc:Depends},
  debootstrap,
+ ${misc:Depends},
 Recommends:
  apt-utils,
  cpio,
- wget,
  live-boot-doc,
  live-config-doc,
  live-manual-html | live-manual,
+ wget,
 Suggests:
- gpgv,
  debian-keyring,
+ gpgv,
 Description: Live System Build Components
  The Live Systems project maintains the components to build Debian based Live
  systems and the official Debian Live images themselves.

Bug#757883: support for loopback.cfg file

2015-08-14 Thread adrian15


Right. Grub does not need to be inside the iso.

Your example is right is the filename is loopback.cfg and not 
looback.cfg which I think it's a typo.


El 14/08/15 a las 08:41, Daniel Baumann escribió:

Hi,

just to be sure: loopback.cfg support means that the iso doesn't
necessarily has to have grub on the iso itself, right?

so, just as an example, having a non-bootable iso image *with* just one
additional file (looback.cfg) at the right location makes it bootable
from the outside. correct?

Regards,
Daniel



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

Bug#775322: Bootloader code issues and improvements

2015-01-18 Thread adrian15

 if 
you need further help.



I think what you are describing is what's currently done with
bootloaders directory, at least, for the isolinux family. You can check:
http://live.debian.net/manual/stable/html/live-manual.en.html#563
to see what I mean. It's not perfect (it does not have heritage) but
it usually works.

Yes, I'm aware of that, but the lack of heritage as you put it forces
derivatives (and even Debian's live-images package) to duplicate files
that are not being changed from the defaults, making the burden of
maintaining those copies greater (needing to watch out for and merge
changes across a greater number of files), for instance, so I want to
investigate improving things here. In fact I'm not totally thrilled by
the duplication of files across the syslinux family of bootloader
directories.


I suppose that the syslinux family duplication is just in case you want 
to have a different image (cdrom image, usb image, rj45 image) depending 
on the media you boot from.


If grub2 was the default and syslinux was removed (not to happen in the 
next five years :) ) you could script it like ... If this file exists 
read it else ignore it. Syslinux is more limited in that regard.


Actually I'm not so concerned as you for duplication because I just 
write the four directory with a script. What I really would like to have 
special is an special directory that once its use it overwrites (or its 
used instead of the other ones).


I mean, if bootloaders/syslinuxforced/ is found use those files instead 
of the bootloaders/{syslinux,extlinux,...} files. That would be a nice 
adding for those of us that are not concerned about having different 
boot configurations depending on the boot media.



I wanted myself to improve it so that grub2 does the same thing as I
have explained before. As far as I know bootloaders/grub2/ folder is
not checked by binary_grub2.

Actually that functionality is already there for grub/grub2, it's just a
different directory, because the grub/grub2 files are for whatever
reason considered template files rather than bootloader files, so
it's config/templates/grub2 not config/bootloaders/grub2, unlike with
syslinux.

Note (in live-build v4.x/5.x at least) the 'Check_templates grub2'
function execution in the binary_grub2 script, and the Check_templates
function in functions/templates.sh, this looks for a local config
template directory and sets the location in the TEMPLATE variable, which
is used later in binary_grub2.

I don't really see the point in grub/grub2 stuff being treated
differently in this way though...
I did not know about this templates directory. Thank you very much. I 
guess the difference is that the grub2 package has some template files 
by default while the syslinux has not these templates by default so the 
bootloaders directory needed to be used. But, well, I'm just wild guessing.



adrian15

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



--
To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54bbee2a.2050...@gmail.com

Bug#775322: Bootloader code issues and improvements

2015-01-17 Thread adrian15


El 17/01/15 a las 02:21, jnqnfe escribió:


On 15/01/2015 14:52, adrian15 wrote:

I just write down here that I will have to review your mentioned: #1,
#2, #3, #4, #5, #6, #7, #8 and #9 in my (#757883) (support for
loopback.cfg file) so that it matches your improvements and fixes.

No problem, I will upload the first batch of work soon, just running a
test and need to find out why I'm getting an error trying to load
memtest86 first. I will also take your looback support into
consideration and try to help review it and mold it into a state ready
to merge.


Thank you very much!


Do you mean the normal entry and the single entry per one kernel? Or
do you actually mean repeated kernels?

Syslinux generates only a single pair (normal + failsafe) when there is
only one kernel, and if multiple kernels, one such pair each. With
grub/grub2, it's outputting this pair of entries as a standard/default
pair, then also one per kernel, so for one of the kernels you're getting
double entries, i.e. if you've only got only one kernel, you get two
normal entries and two failsafe entries that are identical except in
their labels, which is unecessary. I intend to bring grub2 inline with
syslinux.


I did not find that problem in my tests. But that can be explained by 
saying that my initial tests were done with live-build-4.0.



I had also thought on this problem. I think there should a way of just
reusing the current syslinux SVG file so that it generates a suitable
image that can be used by grub2 as a background image.

I disagree, why add such complexity to live-build when you can just
provide a ready made image file as we do now. Besides, this problem
wasn't about creation of the image, it was about grub2 not displaying
it. I have created a small set of commits which improve the grub2 config
file, solving several graphics configuration issues, including a getting
the splash background displayed.


As I was about to improve grub2 support on Live Build (changed my mind 
because Debian's Grub2 package does not match the minimum for Super 
Grub2 Disk) I'll explain a bit about what I had in mind.


Hopefully you can share some of these ideas and, who knows, implement 
some of them.


1) SVG and bootloaders directory
1.1) If you check the current default Debian Live, at least in Debian 
Wheezy, you will see that its boot background image for 
syslinux/isolinux family is based on a: svg.in file which gets converted 
into a svg. Finally the svg file is converted into something that svg 
can understand.


I'm just saying to clone and reuse this code but to produce an image 
that grub2 can understand and use in one of its themes.


1.2) Rework the theme to match the default syslinux one.

Rework the current grub2 theme (if there is one) to match the current 
syslinux one. Why? I would like to see the same boot menu by default 
either by using syslinux as a bootloaer or by using grub2.


You will understand why a bit later.

2) Syslinux and loopback

If you check my bug about loopback cfg support you will see that I'm 
using as much as I can the default grub2 code. Let's suppose you build a 
Debian Live which has loopack cfg support. If you boot it normally 
isolinux will show the default syslinux theme and it will be pretty. If 
you boot it from Super Grub2 Disk thanks to its option to load loopback 
cfg you will find another no-so-pretty menu.


If the loopback cfg support code in Live Build takes that into 
consideration it will take the syslinux svg.in, convert it into svg, 
then into a grub2-theme-suitable-image. Then you can have a great menu 
even if booting from Super Grub2 Disk or other loopback cfg system.


3) Syslinux and grub hybrid iso

My grub2 improvements suggestions are given by me wanting Super Grub2 
Disk to be included by default on Debian Live builds. The thing is that 
I do not want it to be emulated as a RAM image but I want it to be native.


That would also add the benefit of supporting EFI by default very easily.

So, first of all I need a grub2 based Debian Live which its grub2 
package matches minimum requirements for Super Grub2 Disk (not in Jessie 
currently). Then I just need to make the Super Grub2 Disk scripts (they 
are just cfg files) get into that disk.


So what does happen when you have a grub2 Debian Live iso? How do the 
multi distro usb tools handle them? Well, most of these tools cannot 
handle them. However these tools are very good at handling isolinux 
based isos.


So... a nice new option for Debian Live which I think I would only use 
myself for Rescatux would be the following one:


Build a grub2 based Debian Live while at the same time you add to it the 
files that isolinux build would have added. Just to be clear in the end 
the ISO would be booted by grub2 but not by isolinux.


This new kind of syslinux and grub hybrid iso will have the advantage of 
having a native grub2 (thus a native Super Grub2 Disk would be easy) and 
at the same time the Multi USB tools will detect

Bug#775322: Bootloader code issues and improvements

2015-01-15 Thread adrian15


El 14/01/15 a las 04:54, jnqnfe escribió:

Package: live-build
Version: 5.0~a2-1

Reviewing the bootloader menu creation code, I have drawn up the
following list of fixes and improvements needed. Some of these I have
already reported and supplied patches for separately, but I'm listing
them here again to provide a comprehensive set of issues.

Where applicable, I'll specify the bug number of the separate bug report
either specifically for the issue, or where a patch has been previously
supplied already as part of addressing something else. I intend to wrap
this bug report up with one or more sets of commits to address them all.

Thank you for your recent hard work.


Broken boot capability issues:
---
#1) grub2 broken, with missing file error on boot due to files being
placed in the wrong directory (#775316).

Kernel parameter issues:
---
#2) [install entries] user supplied kernel params added in wrong
position in grub/grub2 (#775143).
#3) [install entries] 'quiet' (d-i?) param excluded from rescue entries
instead of expert entries in grub2 (#775143).
#4) [install entries] the '--' delimiter prior to the (d-i?) quiet
kernel parameter is not output for grub/grub2 (#775143).
#5) [install entries] the '--' delimiter needs to be replaced now with
'---' (#775128).
#6) [live entries] user supplied kernel params added in wrong position
in grub/grub2 (less important than for installer entries) (#775143).
#7) [live entries] normal user supplied params being added to fail-safe
entry instead of fail-safe user params in grub/grub2.
#8) [live entries] unnecessary replacement of fail-safe-installer user
params placeholder in syslinux
#9) depreciated video/graphics kernel parameters are being used.

Menu entry set issues:
---
#10) [install entries] speech synthesis option missing, affecting
accessibility
I just write down here that I will have to review your mentioned: #1, 
#2, #3, #4, #5, #6, #7, #8 and #9 in my (#757883) (support for 
loopback.cfg file) so that it matches your improvements and fixes.


Unless somehow your #18 is fixed so that the kernel is always renamed. 
That would probably mean that I could just do as the grml implementation 
[1] which would be as simple as always generating grub2 file and 
symlinking /boot/grub/loopback.cfg to /boot/grub/grub.cfg .



#12) [live entries] too many entries added in grub/grub2 (redundant
entries with kernel version specified)
Do you mean the normal entry and the single entry per one kernel? Or do 
you actually mean repeated kernels?

#13) memtest entry included in syslinux menus even if no memtest included
#14) install entries included in syslinux menus even if no installer
included
What I had found out myself is that there were installer entries in 
grub2 but not in syslinux but that was when I checked it in Wheezy's 
Debian Live so that might explain it. In GIT it should be as you explain 
then.




Other issues:
---
#16) grub2 splash not being displayed
I had also thought on this problem. I think there should a way of just 
reusing the current syslinux SVG file so that it generates a suitable 
image that can be used by grub2 as a background image.

#17) grub splash displayed, but horribly (can this be fixed?)
If it's grub1 I don't think it's worth maintaining it. But, I don't know 
what's the Debian's grub vs grub2 policy in Jessie actually.

#18) grub/grub2 do not rename kernel files unlike syslinux. syslinux
does this for a technical reason, but it might be desirable to do across
the board anyway. This needs further consideration.
Please check (#757883) (support for loopback.cfg file) where you can see 
how I re-use syslinux code to avoid syslinux being stubborn on renaming 
the kernel filenames. Don't get me wrong, I also prefer the kernel files 
to be renamed always so that the code is consistent accross all the 
bootloaders.



#19) consider switching grub/grub2 code to work more like syslinux, with
pre-constructed pieces of the menus in files, from which the full menu
can be constructed by including chunks from those files, and replacing
placeholders.
Well, yes, we could do that with grub2 variables. My dream is defining 
these variables or settings once (in a xml file? in a ini file?) and 
then being translated into a syslinux file or to a grub2 file.



Also to be considered, particularly in respect to #18 and #19 are bug
#757697 (support arch autodetection) and the best way to allow
derivatives (e.g. Kali) to replace menu components such as labels and
splash.
Yes, I also think that somehow a DerivativeName setting is missing so 
that we can easily replace Debian to e.g. Kali from a config file 
without too much effort.



As of this moment I have written patches for 11 of these issues, some of
which have already been posted separately. More to follow soon.


Thank you again for your hard work.

adrian15

[1]: 
http

Bug#757697: RFE: Autodetection of architecture at boot time to load appropiate kernel

2015-01-15 Thread adrian15


El 22/12/14 a las 01:19, Michal Suchanek escribió:

Hello,

On 10 August 2014 at 18:31, Adrian Gibanel Lopez adrian15...@gmail.com wrote:

Source: live-config
Severity: wishlist

Dear Maintainer,

   If one has configured its Debian Live to have more than one architecture
kernel this is what I am expecting would be the default behaviour is:
(...)
Upstream documentation: http://www.syslinux.org/wiki/index.php/Ifcpu64.c32

Thank you!



While at this is it also possible to detect i486 vs i686-pae?


You could do it with the current ifcpu64.c32 comboot module. This poses 
another problem, what to do when you have three or more than three 
different kernels?


I prefer not to implement i486 vs i686-pae.
I think it's better the patch to be accepted as-is and later to be 
improved if someone finds out a reasonable way of improving it for 
enabling i486 vs i686-pae.



Thanks

Michal


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



--
To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54b7cad1.9050...@gmail.com

Bug#757697: RFE: Autodetection of architecture at boot time to load appropiate kernel

2014-12-21 Thread adrian15


El 15/08/14 a las 13:04, Daniel Baumann escribió:

On 08/15/2014 07:12 AM, adrian15 wrote:

I attach a patch for Isolinux / Syslinux implementation for cpu detection.


nice, thanks.

from a quick look, sounds good. will check, test, and apply next week.


As suggested (by another bug) I attach both patches / commits updated so 
that they are based on debian-next branch.


Related branch can be found at: 
https://github.com/adrian15/live-build/commits/rescatux_0.32_debian-next_arch_detection_rebased


adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el software 
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
commit 5852a69976da36abd7bcbbce95807a7a2451a7a6
Author: Adrian Gibanel Lopez adrian.giba...@btactic.com
Date:   Sun Dec 7 17:46:07 2014 +0100

Syslinux build now supports: Arch detection
It adds a default boot option that automatically chooses either amd64 or x86 kernel depending on the detected cpu flags.

diff --git a/scripts/build/binary_syslinux b/scripts/build/binary_syslinux
index abd900a..d59bd05 100755
--- a/scripts/build/binary_syslinux
+++ b/scripts/build/binary_syslinux
@@ -233,6 +233,12 @@ case ${LB_BUILD_WITH_CHROOT} in
 		;;
 esac
 
+# Copy necessary syslinux modules
+for module in ifcpu64.c32
+do
+	cp chroot/usr/lib/syslinux/modules/bios/${module} ${_TARGET}/
+done
+
 # Configuring files
 if [ -e ${_TARGET}/live.cfg.in ]
 then
@@ -255,6 +261,22 @@ then
 			;;
 
 		*)
+			_AMD64_486_NUMBER=0
+
+			for _FLAVOUR in ${LB_LINUX_FLAVOURS}
+			do
+if [ ${_FLAVOUR} = amd64 -o ${_FLAVOUR} = 486 ] ; then
+	_AMD64_486_NUMBER=$((${_AMD64_486_NUMBER} + 1))
+fi
+			done
+
+			if [ ${_AMD64_486_NUMBER} -ge 2 ] ; then
+_AMD64_LABEL=$(cat ${_TARGET}/live.cfg.in | grep ^label | grep -v failsafe | sed 's/label //g' | sed -e s|@FLAVOUR@|amd64|g)
+_486_LABEL=$(cat ${_TARGET}/live.cfg.in | grep ^label | grep -v failsafe | sed 's/label //g' | sed -e s|@FLAVOUR@|486|g)
+_AUTO_LABEL=$(cat ${_TARGET}/live.cfg.in | grep ^label | grep -v failsafe | sed 's/label //g' | sed -e s|@FLAVOUR@|autodetect|g)
+_AUTO_MENU_LABEL=$(cat ${_TARGET}/live.cfg.in | grep menu label | grep -v failsafe | sed 's/.*menu label //g' | sed -e s|@FLAVOUR@|auto|g)
+			fi
+
 			_NUMBER=0
 
 			for _FLAVOUR in ${LB_LINUX_FLAVOURS}
@@ -269,7 +291,22 @@ then
 	echo   ${_TARGET}/live.cfg
 	grep -v 'menu default' ${_TARGET}/live.cfg.in  ${_TARGET}/live.cfg
 else
-	cat ${_TARGET}/live.cfg.in  ${_TARGET}/live.cfg
+	if [ ${_AMD64_486_NUMBER} -ge 2 ] ; then
+		cat  EOF  ${_TARGET}/live.cfg
+label ${_AUTO_LABEL}
+	menu label ${_AUTO_MENU_LABEL}
+	com32 ifcpu64.c32
+	append ${_AMD64_LABEL} -- ${_486_LABEL} -- ${_486_LABEL}
+
+EOF
+	fi
+
+
+	if [ ${_AMD64_486_NUMBER} -ge 2 ] ; then
+		grep -v 'menu default' ${_TARGET}/live.cfg.in  ${_TARGET}/live.cfg
+	else
+		cat ${_TARGET}/live.cfg.in  ${_TARGET}/live.cfg
+	fi
 fi
 
 sed -i -e s|@FLAVOUR@|${_FLAVOUR}|g \
commit 36f781c4dc55e9a0d14cc74df5ff36f9eac2e33f
Author: Adrian Gibanel Lopez adrian.giba...@btactic.com
Date:   Sun Dec 7 17:50:16 2014 +0100

Grub2 build now supports: Arch detection
It adds a default boot option that automatically chooses either amd64 or x86 kernel depending on the detected cpu flags.

diff --git a/scripts/build/binary_grub2 b/scripts/build/binary_grub2
index bf5f8ce..a23c2f9 100755
--- a/scripts/build/binary_grub2
+++ b/scripts/build/binary_grub2
@@ -60,6 +60,16 @@ Restore_cache cache/packages.binary
 Install_package
 
 # Local functions
+Grub_live_entry_commands ()
+{
+	KERNEL=${1}
+	INITRD=${2}
+	APPEND=${3}
+
+	LINUX_LIVE=${LINUX_LIVE}\nlinux\t\t/${KERNEL} ${INITFS:+boot=${INITFS} }config LB_BOOTAPPEND_LIVE ${APPEND}
+	LINUX_LIVE=${LINUX_LIVE}\ninitrd\t\t/${INITRD}
+}
+
 Grub_live_entry ()
 {
 	LABEL=${1}
@@ -68,8 +78,25 @@ Grub_live_entry ()
 	APPEND=${4}
 
 	LINUX_LIVE=${LINUX_LIVE}\nmenuentry \Debian GNU/Linux - ${LABEL}\ {
-	LINUX_LIVE=${LINUX_LIVE}\nlinux\t\t/${KERNEL} ${INITFS:+boot=${INITFS} }config LB_BOOTAPPEND_LIVE ${APPEND}
-	LINUX_LIVE=${LINUX_LIVE}\ninitrd\t\t/${INITRD}
+	Grub_live_entry_commands ${KERNEL} ${INITRD} ${APPEND}
+	LINUX_LIVE=${LINUX_LIVE}\n}
+}
+
+Grub_live_autodetect_entry ()
+{
+	LABEL=${1}
+	AMD64_KERNEL=${2}
+	AMD64_INITRD=${3}
+	_486_KERNEL=${4}
+	_486_INITRD=${5}
+	APPEND=${6}
+
+	LINUX_LIVE=${LINUX_LIVE}\nmenuentry \Debian GNU/Linux - ${LABEL}\ {
+	LINUX_LIVE=${LINUX_LIVE}\nif cpuid -l ; then
+	Grub_live_entry_commands ${AMD64_KERNEL} ${AMD64_INITRD} ${APPEND}
+	LINUX_LIVE=${LINUX_LIVE}\nelse
+	Grub_live_entry_commands ${_486_KERNEL} ${_486_INITRD} ${APPEND}
+	LINUX_LIVE=${LINUX_LIVE}\nfi
 	LINUX_LIVE=${LINUX_LIVE}\n}
 }
 
@@ -153,6 +180,29 @@ LB_BOOTAPPEND_LIVE=$(echo ${LB_BOOTAPPEND_LIVE} | sed -e 's|  ||')
 
 # Assembling kernel configuration
 
+_AMD64_486_NUMBER=0
+
+for _FLAVOUR in ${LB_LINUX_FLAVOURS}
+do
+	if [ ${_FLAVOUR} = amd64 -o ${_FLAVOUR} = 486 ] ; then
+		_AMD64_486_NUMBER

Bug#757883: Patch for Loopback cfg support

2014-12-08 Thread adrian15


El 08/12/14 a las 00:09, jnqnfe escribió:

I had a quick look over your patch. You're building it against
live-build 3.x, but since it's a feature improvement not a critical
bug  in core functionality, I believe I'm right in saying that you must
build against live-build 4.x, preferably the debian-next branch, if you
want to get it accepted (http://live.debian.net/project/lifespan/).
I actually do not know which are the differences between live-build 3.x 
and debian-next but I will try to cherry-pick the commit there and try 
it. I'll try to the tests on a new Debian Unstable chroot then.



Some small issues I have with your binary_loopback_cfg script besides
being built against the wrong version:
  - It would be nice to have a brief comment preceding the big if
structure beginning on line 165 to explain why you're branching based on
syslinux, so it's there for future people reading the code, saving them
a hunt through git commit logs or staring at the code trying to make
sense of it.


Yes, ok, I can do that. The explanation is that binary_syslinux 
implementation breaks other bootloader configuration because it renames 
kernel filenames.


So you have to take care of this problem ahead so that it does not 
happen as when I first was doing my tests. Back then even if I was using 
the same code as in binary_grub2 the kernel was not being found (after 
binary_syslinux was run).



  - Unless I've overlooked something, all the script is doing is
generating a grub config file, the template for which it retrieves from
live-build. It's not actually using or copying any grub binaries, unlike
the grub script. If that's correct, and I think it is, the dependency on
the grub-pc package is unnecessary and should be removed. You can strip
out the dependency itself in lines 48-49, along with the supporting code
in lines 51-55 and 298-302.
Yes, you are right. Grub2 is supposed to be loaded from another media, 
not the live cd itself. I will remove them.



  - Don't forget to update the copyright heading in your new script when
you rebase onto 4.x.

I'll also check that.


  - I don't agree with the sequence you've inserted it in within the
binary script, I think that it should come after the bootloaders
(between syslinux and disk in 4.x). My primary reason being, mandatory
or otherwise, and although related to grub, loopback support is an
entirely separate component from the choice between grub, grub2 and
syslinux. The three lines of code executing the grub/grub2/syslinux
scripts (more in LB 3.x I believe) collectively represent the step of
implementing our chose (primary) bootloader in the overall sequence.
This should not be broken up unless absolutely necessary, otherwise
you're muddling things up.
If I have to run binary_loopback_cfg support after binary_syslinux that 
means reworking a new algorithm that somehow infers kernel architecture 
from its renamed filenames and that it works for only one x86 kernel, or 
only one amd64 kernel or both kernels.


If binary_loopback_cfg is run before binary_syslinux I don't have to 
write from an scratch an algorithm I just have to reuse the 
binary_syslinux one making sure that I do not rename the kernel 
filenames. That's what it's currently implemented.


Any thoughts on how to approach the binary_syslinux renaming the kernel 
filenames or is it ok the way I'm doing it?


Thank you.

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



--
To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54858b9b.2010...@gmail.com

Bug#757883: Patch for Loopback cfg support

2014-12-08 Thread adrian15


El 08/12/14 a las 07:28, Daniel Baumann escribió:

On 12/08/14 00:09, jnqnfe wrote:

I believe I'm right in saying that you must
build against live-build 4.x, preferably the debian-next branch


correct, we will not touch live-* 3.x anymore unless there's a security
issue or another bug making the existing, officially built 3.x/wheezy
live images unusable.


I attach the rebased commit for loopback cfg adapted to debian-next as 
requested and with some of your suggestions implemented.


The order in binary file remains the same because, as I explained 
earlier, syslinux renames the kernel filenames.


Just in case you want the detailed commits from debian-old-3.0 to 
debian-next they can be found here:


https://github.com/adrian15/live-build/commit/b907d5ca4cfac5407e4231a202b5b84cfcf8c56c
https://github.com/adrian15/live-build/commit/5c7636f8848b3d1d058bb2ed7fd69e01ad05270d
https://github.com/adrian15/live-build/commit/1dcec1bdc96a9b5eefb3a464b40250738bf3dfec
https://github.com/adrian15/live-build/commit/f08a3bbfeb98faad99643dbf88aead8a98a69b6f
https://github.com/adrian15/live-build/commit/0cd9b26c8697d4eeb5e950546c6e7b9c94b5ac14
https://github.com/adrian15/live-build/commit/77ac5d6acce430b6a1106e0cdb20a177e36a1b48
https://github.com/adrian15/live-build/commit/9afdaf59138392b09fce41bb522d0d0e1ea1ca11

The new patch and the resulting binary_loopback_cfg file can be also 
found here:


https://github.com/adrian15/live-build/commit/9c67d2d05502e03e0c52827a4e0c7d088f361e88

https://github.com/adrian15/live-build/blob/9c67d2d05502e03e0c52827a4e0c7d088f361e88/scripts/build/binary_loopback_cfg

adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el software 
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
commit 9c67d2d05502e03e0c52827a4e0c7d088f361e88
Author: Adrian Gibanel Lopez adrian.giba...@btactic.com
Date:   Sun Dec 7 18:20:09 2014 +0100

This is a patch for adding Loopback cfg support.

Development details


* This patch has been based originally on: binary_grub2 . It has been
improved thanks to some binary_syslinux bits.

* This patch ensures that binary_loopback_cfg needs is run before binary_syslinux is run.
The reason is that it reuses some code from binary_syslinux to avoid
problems when binary_syslinux renames the kernel filenames.

* This patch already supports CPU detection

* I haven't tested all the possible scenarios for the script (with the
latest version). When amd64 and 486 Gnu/Linux flavours is used and the
bootloader is syslinux it works ok.

* I have not implemented a disable switch for not generating it.
Usually you always want loopback.cfg to be there.

* Compared to binary_grub2 script I have removed the installation
entries because I did not see any of them in binary_syslinux.

How to test
---

These are some steps to easily test if Looback cfg support is working ok.

0) We assume you have generated an iso
1) Make sure you have a partition that Grub understands. Plain ext4 or
vfat should do it.
2) Create directory: /boot/boot-isos/
3) Put the iso file into that directory making sure it has an ISO or iso
extension.
4) Setup your computer to boot from cdrom and use: Super Grub2 Disk
2.00s2 (Hybrid version recommended)
5) Choose Boot manually...
6) Choose Bootable ISOs (in /boot- ... )
7) Choose (the detected) GRUB Loopback Config
(hdN,msodsN)/boot/boot-ios/name-of-the.iso
8) You will be presented your loopback.cfg. Choose anyone of the entries
(unless it does not match your cpu architecture of course).
9) You should boot into your Debian Live without problems (thanks to
findiso boot parametre).

If you ever wanted to test from your grub2 installation instead from
Super Grub2 Disk check: http://www.supergrubdisk.org/wiki/Loopback.cfg
for an example.

diff --git a/scripts/build/binary b/scripts/build/binary
index c1f9ec6..97d7ebc 100755
--- a/scripts/build/binary
+++ b/scripts/build/binary
@@ -63,6 +63,7 @@ lb binary_linux-image ${@}
 lb binary_memtest ${@}
 lb binary_grub ${@}
 lb binary_grub2 ${@}
+lb binary_loopback_cfg ${@}
 lb binary_syslinux ${@}
 lb binary_disk ${@}
 lb binary_loadlin ${@}
diff --git a/scripts/build/binary_loopback_cfg b/scripts/build/binary_loopback_cfg
new file mode 100755
index 000..64958c4
--- /dev/null
+++ b/scripts/build/binary_loopback_cfg
@@ -0,0 +1,311 @@
+#!/bin/sh
+
+## live-build(7) - System Build Scripts
+## Copyright (C) 2006-2014 Daniel Baumann m...@daniel-baumann.ch
+##
+## This program comes with ABSOLUTELY NO WARRANTY; for details see COPYING.
+## This is free software, and you are welcome to redistribute it
+## under certain conditions; see COPYING for details.
+
+
+set -e
+
+# Including common functions
+[ -e ${LIVE_BUILD}/scripts/build.sh ]  . ${LIVE_BUILD}/scripts/build.sh

Bug#757697: RFE: Autodetection of architecture at boot time to load appropiate kernel

2014-12-07 Thread adrian15

I have these same patches available for live-build package on my 
live-build git repo here:


Isolinux: 
https://github.com/adrian15/live-build/commit/4419638ab9cdfb1bacd98593e31d7f700b15a2dc
Grub2 : 
https://github.com/adrian15/live-build/commit/a06085381ba346b576064ee84b325de54a81e33d


Just in case it makes it easier to be included into upstream. Probably 
after Jessie release.


El 15/08/14 a las 13:04, Daniel Baumann escribió:

On 08/15/2014 07:12 AM, adrian15 wrote:

I attach a patch for Isolinux / Syslinux implementation for cpu detection.


nice, thanks.

from a quick look, sounds good. will check, test, and apply next week.


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



--
To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5484900f.2080...@gmail.com

Bug#757883: Patch for Loopback cfg support

2014-12-07 Thread adrian15

Just in case it's easier for you to accept my patch you can also find it 
in this git repo commit based on live-build git repo:


https://github.com/adrian15/live-build/commit/c6da5ff61bb46cb66b23fcb66daa83e23fc8a36b

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



--
To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/548490a2.8010...@gmail.com

Bug#757883: Patch for Loopback cfg support

2014-12-07 Thread adrian15


I know that:

git push --force

is kind of forbidden when working in public with other people.

As this is my kind of personal repo I did it.

So the replaced commit (which only fixes file permissions) is found at:

https://github.com/adrian15/live-build/commit/32fc1ddcd01f092933d19d0cc04bf2583aca7e71

El 07/12/14 a las 18:38, adrian15 escribió:

Just in case it's easier for you to accept my patch you can also find it
in this git repo commit based on live-build git repo:

https://github.com/adrian15/live-build/commit/c6da5ff61bb46cb66b23fcb66daa83e23fc8a36b


adrian15


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



--
To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5484c232.3040...@gmail.com

Testing tails-greeter in Wheezy's Debian Live

2014-11-23 Thread adrian15

 or 
whatever is called. Isn't it?



Possible fork
-

  I might begin to work in a fork so that I can use tails-greeter in 
Rescatux, and so that we can have more insights on how to modify 
tails-greeter to make it suitable for Debian Live.


  The first changes will be aimed at no having to workaround files 
manually in order to make it work and probably also some design details, 
and some Tails string being replaced by Rescatux.


  I'll keep you informed of such fork.

More information

The instructions above imply that you have to replace lightdm by gdm3. 
That's not strictly needed if you know how to replace the default 
lightdm greeter.



Thank you for having read till this point. I know it was a long message.

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



--
To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54720053.1000...@gmail.com

Re: Testing tails-greeter in Wheezy's Debian Live

2014-11-23 Thread adrian15


So, I have a fork for tails-greeter at:

https://github.com/adrian15/tails-greeter

branch master: Upstream's master which happens to be: 0.8.5 version.
branch debian-live: Enforces as much as possible not to enable specific 
Tails bits. Kind of a workaround.

branch rescatux_0.32: debian-live + It hides 'Welcome to Tails' message.

If you build your tails-greeter package from it you won't have to do the 
hacks I showed you. You would only have to install the package, stop 
lightdm and then start gdm3 and you are done.


El 23/11/14 a las 16:42, adrian15 escribió:

Introduction

   As you might know I'm interested in the final user being able to
choose a keyboard from a menu. And that should work in Debian Live by
default. ( https://lists.debian.org/debian-live/2014/10/msg00056.html )

   I finally made my mind to use tails-greeter as a base for this
specific requirement (
https://lists.debian.org/debian-live/2014/11/msg00041.html) and this
email explains my findings and doubts about it.

...



Possible fork
-

   I might begin to work in a fork so that I can use tails-greeter in
Rescatux, and so that we can have more insights on how to modify
tails-greeter to make it suitable for Debian Live.

   The first changes will be aimed at no having to workaround files
manually in order to make it work and probably also some design details,
and some Tails string being replaced by Rescatux.

   I'll keep you informed of such fork.

More information

The instructions above imply that you have to replace lightdm by gdm3.
That's not strictly needed if you know how to replace the default
lightdm greeter.


Thank you for having read till this point. I know it was a long message.

adrian15


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



--
To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54724c2e.1040...@gmail.com

Re: Testing tails-greeter in Wheezy's Debian Live

2014-11-23 Thread adrian15


El 23/11/14 a las 18:04, intrigeri escribió:

Hi,

I suggest to send the questions aimed at Tails developers to... Tails
developers = tails-...@boum.org.


Ok, I will do.


adrian15 wrote (23 Nov 2014 15:42:11 GMT) :

1) I did a search in tails repository packages (apt-file) and there was no
live-persist executable. What makes it possible that Tails live cd
has such a file?


It's in our main Git repository:
https://tails.boum.org/contribute/git/


I see now. Any plan on packaging it or does not make sense?


2) Do you have in mind having a variable inside tails-greeter to disable or hide
non-specific Debian Live features like persistence or encription (Yes, I know 
that
Debian Live has persistence but I'm pretty sure it's different from the Debian 
Live
one) ?


What do you mean with different from the Debian Live one exactly?

Well, that a look at my fork here:
https://github.com/adrian15/tails-greeter/commits/rescatux_0.32

The options which are found in 'More options' dialog and their 
associated actions/setups.



That would be useful for not having to fork tails-greeter and have a common
base code.


Sure. I guess we would be happy to take good patches that make our
Greeter more generic :)

Great.



3) Both: [...]


I don't have the answer to these questions on top of my head.

Ok.



4) When I install tails-greeter apart from tails-greeter package itself there 
are
some packages that are download from tails repository. These are:



python-dbus-dev
python-dbus



Taking a look at:
https://git-tails.immerda.ch/greeter/tree/debian/control?id=tails-greeter_0.8.5
I guess this is happening because your repo versions are newer than the wheezy 
ones.



Should I do apt-pinning into these packages so that the I only fetch 
tails-greeter
from your repository?


Yes.
Ok, having done a fork tails-greeter I no longer have this problem about 
your repository then.



5) I suppose no one in Tails is planning on rewriting tails-greeter into QT 
instead
of GTK, isn't it?


Indeed. GTK works fine for us, and we're using GNOME, so it's better
integrated and looks nicer.

Ok, then.



6) (Kind of offtopic) Any reason why your wheezy dist in your repo has no 
packages?


I wasn't aware we had a wheezy suite. If we indeed have one, well,
it's not being used. Our APT repo layout is documented there:
https://tails.boum.org/contribute/APT_repository/

Ok.

Thank you for your input. I'll try to ask remaining questions to the 
Tails development mailing list.


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



--
To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54724e20.7060...@gmail.com

Re: Isolinux and Multi language - How do you want it?

2014-10-25 Thread adrian15


El 20/10/14 14:03, intrigeri escribió:

Hi,

adrian15 wrote (20 Oct 2014 07:03:06 GMT) :

5) Are you already doing this in your Debian Live based project ? How do you do 
it?


We at Tails use a custom GDM greeter:

 https://git-tails.immerda.ch/greeter

I suspect it wouldn't be s hard to extract the Tails-specific
bits, and make the rest reusable.


Thank you intrigeri for your input !

I don't discard modifying and improving your greeter (Language, 
keyboard, and keyboard options should be bigger and in the center of the 
screen) in order to use with Rescatux.


I personally prefer a graphical way of people choosing such settings 
(and probably also the screen resolution).


However this approach has a problem with Debian Live because it won't be 
reusable for non Xorg based Debian Live cds. So people who use command 
line would still need something like, let's say, the grml language selector.


The boot approach seems universal enough to cover both non Xorg systems 
and Xorg systems this is why I proposed it in the first place.


What are other people thoughts on this issue?

Should we care about non Xorg based Debian Live cds?
Or are they target final user able to edit isolinux command line to add 
their own language preferences?


Thank you for additional inputs on this matter.

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



--
To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/544b6c7f.40...@gmail.com

Re: Isolinux and Multi language - How do you want it?

2014-10-25 Thread adrian15


El 25/10/14 14:10, Ronny Standtke escribió:

Hi all


The boot approach seems universal enough to cover both non Xorg
systems and Xorg systems this is why I proposed it in the first place.

What are other people thoughts on this issue?


For the same reasons we (Lernstick distribution, see here
http://www.imedias.ch/lernstick) developed xmlboot, a gfxboot script
that supports what you want and much, much more.
I just uploaded an intro video to youtube. See here:
http://youtu.be/zedRbCFJ_b4

Cheers

Ronny


Hi Ronny,

  Your video has impressed me.

  I personally do not like your approach for Debian Live because it 
seems too away from upstream syslinux.


  First you have to use the gfxboot com32 module which I'm not sure it 
will maintained upstream even if Ubuntu uses it and then your custom 
xmlboot.


  I personally do not like gfxboot (although I must admit that I have 
not used since 10 years ago or so) because you have to manually build a 
binary messsage file. Not all the resolutions are supported. And 
finally once you've got the final result it was not very easy (meaning 
being able to edit text files) to edit it.


  Maybe your xmlboot script provides what gfxboot is lacking for its 
configuration, that is, being able to save it into a SCM or DVCS.


  I repeat that I am impressed and I don't discard it but it sounds as 
being too over complex as per taking a quick look at: 
https://github.com/imedias/xmlboot and its examples. I mean complex as 
how many files and configuration files one should be editing in order to 
take full advantage of it in live-build package.


  Do you have some sort of live-build package patch that enables it so 
that we can take a look at it? Or maybe two different commits in your 
git repository which we can compare manually?


  Thank you.


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



--
To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/544c0b8b.1040...@gmail.com

Re: Isolinux and Multi language - How do you want it?

2014-10-25 Thread adrian15


El 25/10/14 11:53, intrigeri escribió:

Hi,

(please don't Cc me, I read the list.)

adrian15 wrote (25 Oct 2014 09:25:19 GMT) :

I don't discard modifying and improving your greeter (Language, keyboard, and
keyboard options should be bigger and in the center of the screen)


FYI, that's WIP already:

https://tails.boum.org/blueprint/greeter_revamp_UI/
https://mailman.boum.org/pipermail/tails-ux/2014-October/92.html


This is very nice. That's pretty much what I was thinking of for 
Rescatux. I might reuse it when it's complete or maybe just now :).



The boot approach seems universal enough to cover both non Xorg systems and Xorg
systems this is why I proposed it in the first place.


Accessibility support seems important to me, when aiming at being
universal. I doubt one gets that in a boot loader.


As per Daniel suggestion about having a graphical language selector and 
a non graphical one. Does your greeter architecture design will allow to 
have a non graphical frontend, maybe ncurses based ?


Thank you.

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



--
To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/544c2a2a.6070...@gmail.com

Re: Dropping rescue as an official flavour

2014-10-20 Thread adrian15

El 23/08/14 18:23, Daniel Baumann escribió:

On 08/23/2014 06:20 PM, adrian15 wrote:

Ok, I'll try to do my best. I have been impressed because there are way
many more rescue packages on these two lists than what I had thought of
originally.

that would be great, thank you very much.

The article is still in a draft and I have not been able to work much on it.

What I mean is that I'm going to end the article one day or another. Not
as soon as I thought though.

So if you are one of these people that do not want a Rescue disk to be
taken out of Debian Live official flavours (and given that Jessie freeze
will soon happen) you should probably work on:

- Issuing a tasksel bug that includes current packages found at latest
Debian Live Rescue disk. Probably the ones found at:

http://live.debian.net/gitweb/?p=live-images.git;a=tree;f=images/rescue/config/package-lists;hb=HEAD
(debian-forensincs and rescue)

as Daniel originally suggested at:

https://www.mail-archive.com/debian-live@lists.debian.org/msg13525.html

Thank you.

P.S.: I don't care about Debian Live Rescue not being available in
Jessie myself because I prefer to rethink its packages wisely but I
don't want to be blamed on it not being available.

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

--
To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5444b640.1040...@gmail.com

Isolinux and Multi language - How do you want it?

2014-10-20 Thread adrian15

As one step for freezing Rescatux (
http://www.supergrubdisk.org/rescatux/ which it's based on Debian Live )
I need users to be able to select a language, well, most exactly a keyboard.

Currently the best way of doing it seems to be using Isolinux menus
and using kernel boot parametres as described in the manual:

http://live.debian.net/manual/stable/html/live-manual.en.html#512

I want to contribute back this new feature to Debian Live but in a
way that everybody likes it. You can assume that I will get the locales
automatically from /usr/share/X11/xkb/rules/base.lst or similar files.

* Syslinux does not support variables (
http://www.syslinux.org/wiki/index.php/SYSLINUX#Is_There_A_Way_To_Define_Constants_Or_Variables.3F
)
* cmd.c32 ( http://www.syslinux.org/wiki/index.php/Cmd.c32 ) is almost
not useful because it would only deal with one boot parametre (i.e.
being able to choose locale only and not both locale and keyboard layout)
* lua.c32 ( http://www.syslinux.org/wiki/index.php/Lua.c32 ) might be
used for variables but I'm not quite sure.

So there are some questions there.

1) What do you think is it way for letting the user choosing its locale?
2) How many screens would you present to the final user?
3) Have you ever tried to do something with this Lua.c32? Do you think I
would be able to use it for this purpose?
4) Would you mind having like 50+ isolinux cfg files which represent the
different combinations of locale, keyboards and its variants so that I
can use syslinux without using variables? Or is it ok with you?
5) Are you already doing this in your Debian Live based project ? How do
you do it?

Thank you for your feedback!

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

mkfs.btrfs not working ok on Debian Live (chroot?)

2014-10-11 Thread adrian15


What I am using
---

I am using: live-build 3.0.5-1 in Wheezy in order to build a Debian Live 
cd (Rescatux 0.32b1). This cd has: btrfs-tools installed so that I can 
use: mkfs.btrfs .


About the problem I'm seeing

The problem I have found comes when using:

mkfs.btrfs /dev/sdc1 # Adapt to your device

The error says:

error checking /dev/sdc1 mount status

The workaround
--
By using strace I have detected a file / path that was trying to check. 
I just recreate it so that it works.


The file is: /live/medium/live/filesystem.squashfs

My workaround is (I guess it would work the same just by touching it as 
a file and not linking to a directory):


mkdir --parents /live/medium/live
ln -s /lib/live/mount/rootfs/filesystem.squashfs 
/live/medium/live/filesystem.squashfs


Some thoughts
-
According to: https://patchwork.kernel.org/patch/449001/ (which it's a 
patch not found on Wheezy) and 
http://marc.info/?l=linux-btrfsm=129681265301384w=2 it would seem the 
problem about using a chroot.


My question is if it's ok or if I should raise a bug against live-build 
because the ISO should work in a way that it's more similar to an 
installed system than it currently is.


I don't have the missing file in my /proc/mounts . My suspicion is that 
somehow mkfs.btrfs gets that missing file (or path) from the 
/proc/mounts file which it's found outside the chroot. Or maybe talking 
directly to the kernel.




Does it make any sense to anyone of you?

Thank you.

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



--
To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5439a4b5.9030...@gmail.com

Re: Bug#759744: debian-cd: loopback.cfg support for booting ISOs from within GRUB

2014-08-29 Thread adrian15


El 30/08/14 00:04, Michael Prokop escribió:

Hi,

Cc-ing also debian-live ML to make sure they are aware of the issue.

* Michael Prokop [Fri Aug 29, 2014 at 11:28:13PM +0200]:


I'm hereby following up our discussion we - Steve McIntyre, Colin
Watson and me - had at DebConf14.
Quoting from http://www.supergrubdisk.org/wiki/Loopback.cfg:

[...]

Adrian just pointed out to me that in #757883 he was working on this
feature for supporting it in debian-live, that might be useful for
further development and sharing this feature between debian-cd and
debian-live.

regards,
-mika-



This implementation is not easy as it might seem at first glance.

So, you know in Debian Live we have both fromiso and findiso boot 
parametres. You define them in Grub so that they Linux kernel gets them 
as a cmdline and then initrd detects fromiso or findiso and acts 
accordingly.


So fromiso needs the exact location of the iso (including its device) 
and, you might guess the Debian Live is loop mounted and then usual 
stuff ocurrs like trying to mount the squashfs big image and the boot of 
Debian Live continues.


Findiso does not need the exact location of the iso. The reason is that 
it loops all its devices and its partitions till it finds the iso. Then 
once it knows its device it acts as fromiso boot parametre does.


So, I will give three examples so that you get the point:

* fromiso=/dev/sda1/live/mydistro.iso
* 
fromiso=/dev/disk/by-uuid/c02dcbff-3222-4555-b333-c2351b73f88b/live/mydistro.iso


* findiso=/live/mydistro.iso

Basically if you want loopback.cfg to work you need a findiso alike option.

So, what you need in Debian-cd (or other packages) is a findiso alike 
option. This option is not currently available (please read on).


Support for a findiso alike option is already implemented in: #724931 . 
However the actual patch status for adding this functionality seems to 
affect many packages and I think it has been kind of put aside because 
of other higher priorities.


I plan myself on reviewing the patch and discovering why it affects so 
many packages ( 3 or 4 ) while Debian Live only needed live-boot to be 
modified (well, fromiso boot parametre had already implemented when I 
ported grml's findiso code, maybe that explains the reason why I find 
Debian Live much more simple).


So, that's it:
* Either someone implements a findiso alike option from scratch that 
affects as less packages as possible

* Either current patch is stripped down and fully tested

so that somehow less packages are affected than with the current patch.

* or current patch is fully tested

because, you know, it has some additional features like discovering new 
isos that are great. Additional features are, you know, more things to 
test, so it makes the patch less likely to be frozen or even considered 
so I suppose you have to weight it pros and cons.


By the way if Debian Live's findiso implementation is handy you can find 
its associated bug at: #656135.


Feel free to make depend this bug on #724931 if that it makes sense (not 
very experienced on BTS and Debian policies).


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



--
To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5401034f.5070...@gmail.com

Re: Dropping rescue as an official flavour

2014-08-23 Thread adrian15


El 23/08/14 07:57, Daniel Baumann escribió:

On 08/23/2014 02:16 AM, adrian15 wrote:

A rescue task for tasksel means having a metapackage like:
task-lxde-desktop
but being named as: task-rescue ?


yes (or whatever the tasksel maintainers would name it).

Great.



If my assumption is right, do we have the list of rescue packages that
will be there?


if someone would want to work towards such a task-rescue, he would
start with the rescue package list in live-images.


For those of you that you don't know where that list is (like me just 
before reading this email) you can check:


http://live.debian.net/gitweb/?p=live-images.git;a=tree;f=images/rescue/config/package-lists;hb=HEAD

where there are two interesting package lists:

* debian-forensics
* rescue




If that's what needed in order to submit the bug I can write an article
about it in my blog (It's a so big answer that I can reuse it as a blog
post :) ) about this subject.


in that case.. it would be nice if you could first review our rescue
list and clean/order/improve it, and then take that list and work out
with the tasksel maintainers if they are interested in adopting that
list for taskel.


Ok, I'll try to do my best. I have been impressed because there are way 
many more rescue packages on these two lists than what I had thought of 
originally.


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



--
To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53f8bf3e.6050...@gmail.com

Re: Dropping rescue as an official flavour

2014-08-22 Thread adrian15


El 22/08/14 17:35, Daniel Baumann escribió:

Hi,

having looked at our official live-images configurations, i think we
should enforce to not build any official images if there's no task in
tasksel for it.

currently all the desktop and the standard image correspond to one or
more tasksel task(s) except for the rescue flavour.

does anyone volunteer to submit a bug against tasksel to include a
rescue task there?


A rescue task for tasksel means having a metapackage like:
task-lxde-desktop
but being named as: task-rescue ?

If my assumption is right, do we have the list of rescue packages that 
will be there?

Or is it something that we need to define now?

I'm asking it because when developing Rescatux I missed a task-rescue 
package so that I had a set of minimal rescue packages, actually, I 
mean, sort of official Debian set of minimal rescue packages.


If that's what needed in order to submit the bug I can write an article 
about it in my blog (It's a so big answer that I can reuse it as a blog 
post :) ) about this subject.


Then I would copy and paste the important parts of the article here so 
that we can discuss the packages that should be in that task-rescue 
metapackage.


Is there any other mailing list in Debian where other people might be 
interested on the task-rescue package contents so that we ask there too?


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



--
To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53f7dd77.6070...@gmail.com

Re: Common bootloaders configuration thoughts


El 17/08/14 15:06, Daniel Baumann escribió:

On 08/17/2014 03:37 AM, adrian15 wrote:

In one hand I want to be able to rename Debian Live distro into
Something distro by just changing one variable. And at the same time I
want that multi-live usb tools detect the iso as a Debian live so that
they don't have to implement their code for each and everyone of the
Debian derivatives.


lb is moving, albeit slowly, to that eventually, yes.


I am mostly interested in renaming distro name, specially, at the 
bootloader stage.


If I can help on any of these please tell me how would you go on how to 
implement it. I know how would I do it but I don't know every detail 
about live-build and, well,...


if Live-build has to be rewritten into python (Has this even started?) 
so... not sure if my contribution would be worth.


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



--
To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53f0e5d6.70...@gmail.com

Re: Installation entries on bootloaders binary scripts


El 17/08/14 15:07, Daniel Baumann escribió:

On 08/17/2014 02:55 AM, adrian15 wrote:

* Are ok


yes.
Interesting. So, probably, there are people using syslinux by default 
and enabling installation but not seeing those entries at boot time.



* Should not be in grub2


they should.
Ok. So, that means that loopback_cfg should also have these entries and 
mine does not have. But, this only makes sense if my implemented:

findiso boot parametre also affect installation boot entries.

I guess the findiso boot parametre does not affect installation boot 
entries? Can you somehow check it for me?


I know I have implemented findiso myself but, somehow, I don't recall 
very well my code.



* Should also be in syslinux


at some point, yes.
Not interested in implementing the syslinux part for installation boot 
entries although it should not be too much difficult.


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



--
To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53f0e6b0.2030...@gmail.com

Re: binary-grub2 stage file filename doubt


El 17/08/14 15:11, Daniel Baumann escribió:

On 08/17/2014 02:51 AM, adrian15 wrote:

which I suppose should be renamed to be:

   # Checking stage file
   Check_stagefile .build/binary_grub2

   # Creating stage file
   Create_stagefile .build/binary_grub2


no; iirc it used to be that we needed them to be the same in order to
prevent binary_grub and binary_grub2 running at the same time.

since binary_grub* need to be rewritten anyway, this can be 'fixed' at
that point, for which nobody bothered yet since we're using syslinux as
default (and so do most people).


Need to be rewritten because of live-build going into python?
Or is there any other reason?

I mean, I wouldn't mind implement binary_grub2 myself but I would like 
to know what functionalities should be implemented according to 
live-build upstream.


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



--
To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53f0e736.1060...@gmail.com

live-build bootloader manpages doubt


(This applies to Debian Stable's Debian Live)

  So the bug is:

man lb_config

showing:
[--bootloader grub|syslinux|yaboot]
instead of:
[--bootloader grub|syslinux|yaboot|grub2]
.

However if I go online and check most current manpages here:
http://live.debian.net/manpages/unstable/en/txt/
there is no: lb_config entry at all.

I have to go to:

http://live.debian.net/manpages/oldstable/en/txt/lb_config.1.txt

to find something similar.

So... If that lb_config manpage is no longer present in latest Live 
build versions... Why issue the bug?


In that case is there any replacement tool for lb_config so that it has 
another manpage than I can finally check and issue a bug if grub2 is not 
mentioned as an available bootloader?


Thank you.

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



--
To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53f1001e.8040...@gmail.com

Bug#757883: Patch for Loopback cfg support

2014-08-16 Thread adrian15


I attach a patch for adding Loopback cfg support.

Development details


A) This patch has been based originally on: binary_grub2 . It has been 
improved thanks to some binary_syslinux bits.


B) binary_loopback_cfg needs to be run before binary_syslinux is run. 
The reason is that it reuses some code from binary_syslinux to avoid 
problems when binary_syslinux renames the kernel filenames.


C) This patch already supports CPU detection

D) Be sure to include the new binary_loopback_cfg file in package definition

E) I haven't tested all the possible scenarios for the script (with the 
latest version). When amd64 and 486 Gnu/Linux flavours is used and the 
bootloader is syslinux it works ok.


F) I have not implemented a disable switch for not generating it. 
Usually you always want loopback.cfg to be there.


G) Compared to binary_grub2 script I have removed the installation 
entries because I did not see any of them in binary_syslinux.


H) Please advise how to improve it so that it gets accepted upstream.

How to test
---

These are some steps to easily test if Looback cfg support is working ok.

0) We assume you have generated an iso
1) Make sure you have a partition that Grub understands. Plain ext4 or 
vfat should do it.

2) Create directory: /boot/boot-isos/
3) Put the iso file into that directory making sure it has an ISO or iso 
extension.
4) Setup your computer to boot from cdrom and use: Super Grub2 Disk 
2.00s2 (Hybrid version recommended)

5) Choose Boot manually...
6) Choose Bootable ISOs (in /boot- ... )
7) Choose (the detected) GRUB Loopback Config 
(hdN,msodsN)/boot/boot-ios/name-of-the.iso
8) You will be presented your loopback.cfg. Choose anyone of the entries 
(unless it does not match your cpu architecture of course).
9) You should boot into your Debian Live without problems (thanks to 
findiso boot parametre).


If you ever wanted to test from your grub2 installation instead from 
Super Grub2 Disk check: http://www.supergrubdisk.org/wiki/Loopback.cfg 
for an example.



adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el software 
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
diff -urN original/usr/lib/live/build/binary 
fork_loopback_cfg/usr/lib/live/build/binary
--- original/usr/lib/live/build/binary  2014-08-16 03:09:01.512575406 +
+++ fork_loopback_cfg/usr/lib/live/build/binary 2014-08-16 03:09:37.377196377 
+
@@ -64,6 +64,7 @@
 lb binary_memtest ${@}
 lb binary_grub ${@}
 lb binary_grub2 ${@}
+lb binary_loopback_cfg ${@}
 lb binary_syslinux ${@}
 lb binary_yaboot ${@}
 lb binary_silo ${@}
diff -urN original/usr/lib/live/build/binary_loopback_cfg 
fork_loopback_cfg/usr/lib/live/build/binary_loopback_cfg
--- original/usr/lib/live/build/binary_loopback_cfg 1970-01-01 
00:00:00.0 +
+++ fork_loopback_cfg/usr/lib/live/build/binary_loopback_cfg2014-08-16 
23:12:21.746935266 +
@@ -0,0 +1,305 @@
+#!/bin/sh
+
+## live-build(7) - System Build Scripts
+## Copyright (C) 2006-2013 Daniel Baumann dan...@debian.org
+##
+## This program comes with ABSOLUTELY NO WARRANTY; for details see COPYING.
+## This is free software, and you are welcome to redistribute it
+## under certain conditions; see COPYING for details.
+
+
+set -e
+
+# Including common functions
+[ -e ${LIVE_BUILD}/scripts/build.sh ]  . ${LIVE_BUILD}/scripts/build.sh 
|| . /usr/lib/live/build.sh
+
+# Setting static variables
+DESCRIPTION=$(Echo 'installs loopback.cfg into binary')
+HELP=
+USAGE=${PROGRAM} [--force]
+
+Arguments ${@}
+
+# Reading configuration files
+Read_conffiles config/all config/common config/bootstrap config/chroot 
config/binary config/source
+Set_defaults
+
+Echo_message Begin installing loopback.cfg...
+
+# Requiring stage file
+Require_stagefile .build/config .build/bootstrap
+
+# Checking stage file
+Check_stagefile .build/binary_loopback_cfg
+
+# Checking grub2 templates
+Check_templates grub2
+
+# Checking lock file
+Check_lockfile .lock
+
+# Creating lock file
+Create_lockfile .lock
+
+# Check architecture
+Check_architectures amd64 i386
+Check_crossarchitectures
+
+# Checking depends
+#Check_package chroot/usr/bin/grub-mkimage grub-pc
+
+# Restoring cache
+Restore_cache cache/packages.binary
+
+# Installing depends
+Install_package
+
+# Local functions
+Grub_live_entry_commands ()
+{
+   local KERNEL=${1}
+   local INITRD=${2}
+   local APPEND=${3}
+
+   LINUX_LIVE=${LINUX_LIVE}\nlinux\t\t/${KERNEL} ${INITFS:+boot=${INITFS} 
}config LB_BOOTAPPEND_LIVE ${APPEND}
+   LINUX_LIVE=${LINUX_LIVE}\ninitrd\t\t/${INITRD}
+}
+
+Grub_live_entry ()
+{
+   local LABEL=${1}
+   local KERNEL=${2}
+   local INITRD=${3}
+   local APPEND=${4}
+
+   LINUX_LIVE=${LINUX_LIVE}\nmenuentry \Debian GNU/Linux - ${LABEL}\ {
+   Grub_live_entry_commands ${KERNEL} ${INITRD} ${APPEND} 
findiso=\${iso_path}
+   LINUX_LIVE=${LINUX_LIVE}\n}
+}
+
+Grub_live_autodetect_entry

binary-grub2 stage file filename doubt

2014-08-16 Thread adrian15


(This applies to Debian Stable's Debian Live)

I have noticed that:

/usr/lib/live/build/binary_grub2

has these two lines:

  # Checking stage file
  Check_stagefile .build/binary_grub

  # Creating stage file
  Create_stagefile .build/binary_grub

which I suppose should be renamed to be:

  # Checking stage file
  Check_stagefile .build/binary_grub2

  # Creating stage file
  Create_stagefile .build/binary_grub2


As grub2 is not grub2 but grub version 2 I was asking myself if that 
TYPO was made on purpose or if I should file a bug for it.


Thank you.

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



--
To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53effc90.6080...@gmail.com

Progress-linux and customisation

2014-08-16 Thread adrian15


(This applies to Debian Stable's Debian Live)

While editing:

/usr/lib/live/build/binary_syslinux

I have discovered a reference to Progress Linux. That is a Linux 
distribution from Daniel (dba)'s company I think. I suspect that Debian 
Live was an internal Progress Linux project that was given to Debian ?


I comment it because I find references in live-build package in:

binary_checksums
binary_debian-installer
binary_disk
and much more files at:
/usr/lib/live/build directory .

As Daniel is one of the most active Debian Live developers I wanted to 
discuss about it here just before issuing a bug.


So my initial thought bug: Get rid of everything Progress Linux 
related I think could rephrased into something like:


Convert everything Progress Linux related into hooks or variables so 
that one can achieve the same functionality by customisation driven by 
Debian Live standard procedures.


So...

1) Is there any schedule for recycling all of these Progress Linux stuff?
2) Maybe some of these references have been already scheduled for removal?
3) Maybe the policy is to recycle them as people need those specific 
functionalities?
4) Maybe we can remove all of these embedded code because Progress Linux 
no longer uses it but only official Debian Live customisation procedures?
5) Is there (much?) more Progress Linux stuff ? (I have only checked in 
live-build package. /usr/lib/live/build directory).



Thank you.

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



--
To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53f00f22.6090...@gmail.com

Bug#757697: CPU detection patch for grub2 attached

2014-08-15 Thread adrian15

I attach a patch for CPU detection when Debian Live uses grub2 as its 
bootloader.


Please advise how to improve it so that it gets included upstream.

Thank you.

adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el software 
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
diff -urN original/usr/lib/live/build/binary_grub2 
fork_cpu64bit_detection_grub2/usr/lib/live/build/binary_grub2
--- original/usr/lib/live/build/binary_grub22014-08-15 20:05:54.774035184 
+
+++ fork_cpu64bit_detection_grub2/usr/lib/live/build/binary_grub2   
2014-08-15 22:08:29.721746736 +
@@ -60,6 +60,16 @@
 Install_package
 
 # Local functions
+Grub_live_entry_commands ()
+{
+   KERNEL=${1}
+   INITRD=${2}
+   APPEND=${3}
+
+   LINUX_LIVE=${LINUX_LIVE}\nlinux\t\t/${KERNEL} ${INITFS:+boot=${INITFS} 
}config LB_BOOTAPPEND_LIVE ${APPEND}
+   LINUX_LIVE=${LINUX_LIVE}\ninitrd\t\t/${INITRD}
+}
+
 Grub_live_entry ()
 {
LABEL=${1}
@@ -68,8 +78,25 @@
APPEND=${4}
 
LINUX_LIVE=${LINUX_LIVE}\nmenuentry \Debian GNU/Linux - ${LABEL}\ {
-   LINUX_LIVE=${LINUX_LIVE}\nlinux\t\t/${KERNEL} ${INITFS:+boot=${INITFS} 
}config LB_BOOTAPPEND_LIVE ${APPEND}
-   LINUX_LIVE=${LINUX_LIVE}\ninitrd\t\t/${INITRD}
+   Grub_live_entry_commands ${KERNEL} ${INITRD} ${APPEND}
+   LINUX_LIVE=${LINUX_LIVE}\n}
+}
+
+Grub_live_autodetect_entry ()
+{
+   LABEL=${1}
+   AMD64_KERNEL=${2}
+   AMD64_INITRD=${3}
+   _486_KERNEL=${4}
+   _486_INITRD=${5}
+   APPEND=${6}
+
+   LINUX_LIVE=${LINUX_LIVE}\nmenuentry \Debian GNU/Linux - ${LABEL}\ {
+   LINUX_LIVE=${LINUX_LIVE}\nif cpuid -l ; then
+   Grub_live_entry_commands ${AMD64_KERNEL} ${AMD64_INITRD} ${APPEND}
+   LINUX_LIVE=${LINUX_LIVE}\nelse
+   Grub_live_entry_commands ${_486_KERNEL} ${_486_INITRD} ${APPEND}
+   LINUX_LIVE=${LINUX_LIVE}\nfi
LINUX_LIVE=${LINUX_LIVE}\n}
 }
 
@@ -158,6 +185,29 @@
 
 # Assembling kernel configuration
 
+_AMD64_486_NUMBER=0
+
+for _FLAVOUR in ${LB_LINUX_FLAVOURS}
+do
+   if [ ${_FLAVOUR} = amd64 -o ${_FLAVOUR} = 486 ] ; then
+   _AMD64_486_NUMBER=$((${_AMD64_486_NUMBER} + 1))
+   fi
+done
+
+if [ ${_AMD64_486_NUMBER} -ge 2 ] ; then
+   # Default entries
+   AMD64_KERNEL=$(basename chroot/boot/vmlinuz-*amd64)
+   AMD64_INITRD=initrd.img-$(echo ${AMD64_KERNEL} | sed -e 
's|vmlinuz-||')
+   _486_KERNEL=$(basename chroot/boot/vmlinuz-*486)
+   _486_INITRD=initrd.img-$(echo ${_486_KERNEL} | sed -e 's|vmlinuz-||')
+
+   Grub_live_autodetect_entry live (autodetect) \
+   $(basename ${DESTDIR_LIVE})/${AMD64_KERNEL} \
+   $(basename ${DESTDIR_LIVE})/${AMD64_INITRD} \
+   $(basename ${DESTDIR_LIVE})/${_486_KERNEL} \
+   $(basename ${DESTDIR_LIVE})/${_486_INITRD}
+fi
+
 # Default entries
 DEFAULT_FLAVOUR=$(echo ${LB_LINUX_FLAVOURS} | awk '{ print $1 }')
 DEFAULT_KERNEL=$(basename chroot/boot/vmlinuz-*${DEFAULT_FLAVOUR})

Bug#757697: RFE: Autodetection of architecture at boot time to load appropiate kernel

2014-08-14 Thread adrian15


El 10/08/14 18:31, Adrian Gibanel Lopez escribió:

Source: live-config
Severity: wishlist
** With Isolinux / Syslinux you should use the ifcpu64.c32 comboot module as
seen in tails:

https://git-tails.immerda.ch/tails/tree/config/binary_local-
hooks/20-syslinux_detect_cpu?id=deb15c765e2b34fe587c96ca590981a59a278922

Upstream documentation: http://www.syslinux.org/wiki/index.php/Ifcpu64.c32

Thank you!


I attach a patch for Isolinux / Syslinux implementation for cpu detection.

Please advise how to improve the implementation so that it can be 
accepted upstream.


Thank you.

adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el software 
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
diff -urN original/usr/lib/live/build/binary_syslinux 
fork_cpu64bit_detection/usr/lib/live/build/binary_syslinux
--- original/usr/lib/live/build/binary_syslinux 2014-08-14 02:42:20.007666770 
+
+++ fork_cpu64bit_detection/usr/lib/live/build/binary_syslinux  2014-08-15 
05:08:58.701948081 +
@@ -161,6 +161,12 @@
;;
 esac
 
+# Copy necessary syslinux modules
+for module in ifcpu64.c32
+do
+   cp chroot/usr/lib/syslinux/${module} ${_TARGET}/
+done
+
 # Configuring files
 if [ -e ${_TARGET}/live.cfg.in ]
 then
@@ -183,6 +189,22 @@
;;
 
*)
+   _AMD64_486_NUMBER=0
+
+   for _FLAVOUR in ${LB_LINUX_FLAVOURS}
+   do
+   if [ ${_FLAVOUR} = amd64 -o ${_FLAVOUR} = 
486 ] ; then
+   
_AMD64_486_NUMBER=$((${_AMD64_486_NUMBER} + 1))
+   fi
+   done
+
+   if [ ${_AMD64_486_NUMBER} -ge 2 ] ; then
+   _AMD64_LABEL=$(cat ${_TARGET}/live.cfg.in | 
grep ^label | grep -v failsafe | sed 's/label //g' | sed -e 
s|@FLAVOUR@|amd64|g)
+   _486_LABEL=$(cat ${_TARGET}/live.cfg.in | 
grep ^label | grep -v failsafe | sed 's/label //g' | sed -e 
s|@FLAVOUR@|486|g)
+   _AUTO_LABEL=$(cat ${_TARGET}/live.cfg.in | 
grep ^label | grep -v failsafe | sed 's/label //g' | sed -e 
s|@FLAVOUR@|autodetect|g)
+   _AUTO_MENU_LABEL=$(cat ${_TARGET}/live.cfg.in 
| grep menu label | grep -v failsafe | sed 's/.*menu label //g' | sed -e 
s|@FLAVOUR@|auto|g)
+   fi
+
_NUMBER=0
 
for _FLAVOUR in ${LB_LINUX_FLAVOURS}
@@ -197,7 +219,22 @@
echo   ${_TARGET}/live.cfg
grep -v 'menu default' 
${_TARGET}/live.cfg.in  ${_TARGET}/live.cfg
else
-   cat ${_TARGET}/live.cfg.in  
${_TARGET}/live.cfg
+   if [ ${_AMD64_486_NUMBER} -ge 2 ] ; 
then
+   cat  EOF  
${_TARGET}/live.cfg
+label ${_AUTO_LABEL}
+   menu label ${_AUTO_MENU_LABEL}
+   com32 ifcpu64.c32
+   append ${_AMD64_LABEL} -- ${_486_LABEL} -- ${_486_LABEL}
+
+EOF
+   fi
+
+
+   if [ ${_AMD64_486_NUMBER} -ge 2 ] ; 
then
+   grep -v 'menu default' 
${_TARGET}/live.cfg.in  ${_TARGET}/live.cfg
+   else
+   cat ${_TARGET}/live.cfg.in  
${_TARGET}/live.cfg
+   fi
fi
 
sed -i -e s|@FLAVOUR@|${_FLAVOUR}|g \

Bug#687099: live-boot: Breaks booting when used from Squeeze

2012-09-09 Thread adrian15

First of all I've managed to fix the problem on the fly inspired from 
the related bug.


So you boot with break=init and I run:

mkdir -p live
mount -t tmpfs tmpfs /live
exit

and the system seems to boot ok.


El 09/09/12 19:14, Daniel Baumann escribió:


On 2012-09-09 18:55, adrian15 wrote:

When building an Squeeze debian live cd inside an Squeeze system and
trying to use live-boot* packages from unstable seems to be broken.


did you use live-build 3.x to build the squeeze images? if not, rebuild
with latest live-build 3.x.
No. I use live-build 2.x because I'm on squeeze but I'll manage to use 
live-build 3.x as per your suggestion.




SID_MIRROR=http://snapshot.debian.org/archive/debian/20120727T111800Z/;


[...]

this is not supported that way anyway.

if you want to use live-{boot,config} 3.x on squeeze, you do need to
rebuild them on squeeze first (and put them into your own repository, or
as local packages into the config tree). live-* 3.x builds different
packages depending on where it was built, and adjust any boot parameters
for 3.x manually within live-builds config tree.
So I need to rebuild them... hummm... that's not quite what I had 
understood you are probably right. It's quite stunning that using apt 
pinning for using 3.x live-boot has worked so well over the last four 
months.


additionally, you need matching live-boot and live-config versions,
mixing random pre-latest-sid versions doesn't work either.
You're right. I should have checked the snapshots date according to many 
packages not just live-boot one.


last but not least, this is a minor bug. live-* 3.x primeraly is for
wheezy, not for squeeze although we try to keep compatibility with one
release before the target release whenever we can.

Ok.

So... I'll try your pieces of advice. I think you can close the bug.

Thank you!


--
To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/504cd309.5010...@gmail.com

Bug#656135: Add findiso boot parametre


El 09/04/12 19:28, Daniel Baumann escribiÃ³:

what i don't get is why the thing is mounted in /root/live/$whatever in
the first place if it is unmounted their afterwards anyway.

or in other words: there should be nothing interfering with /root/*
unless it's staying there after the initramfs-real-system switch, so
the temporary mounting should be somewhere in initramfs, like
/live/$whatever that it was (in parts) before.

..or am i missing something?



According to Michael Prokop (I sent him an email) if findiso option 
works without that code we should remove it. It describes the grml 
live-boot ancestors to be live-initramfs and knoppix. So he means that 
some code might be unneccesary.


Being that fromiso and findiso are very similar in functionality and 
that fromiso does not have similar code I apply for removing it.


Not to say that findiso option has to be tested after removing it just 
to be sure that we aren't breaking anything.


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




--
To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f8a93f4.8000...@gmail.com

Bug#668100: fromiso rewriting based on findiso structure


El 10/04/12 11:59, intrigeri escribiÃ³:

Hi,

adrian15 wrote (09 Apr 2012 18:43:54 GMT) :

I attach the splitted patches.


Thanks!

I've merged:

   * fromiso_001_renaming.patch
   * fromiso_002_use_live_fromiso.patch
   * fromiso_004_fromiso_uses_is_mountpoint_function.patch *but*
 I amended it to s,/root/live/fromiso,/live/fromiso, given I did
 not apply the 003 patch


I am doubting about 003 patch.


So am I.


Why fromiso didn't have in the first place?


No idea. Why should it have it?
Given fromiso= works well without this change AFAIK,
I see no reason to clutter the code with it.
(No, I don't think making the code more similar to findiso= counts here.)


According to Michael Prokop (I sent him an email) if fromiso option 
works without that code we should remove it. It describes the grml 
live-boot ancestors to be live-initramfs and knoppix. So he means that 
some code might be unneccesary.





Why findiso did it? Perhaps because fromiso in the paste did
have it?


No idea, but dba started a discussion about it on #656135.
Try removing this piece of code from findiso= and see what happens?

Shall we consider this action item (fromiso rewriting based on findiso
structure) as done, and close this bug?


If the fromiso option still works I think so too.


Related to this I have found: /live/image and /root/live/image that
do not seem to be used (just rgreped for /live/image). I might open
a new bug for this but I'm not sure.


A new bug is needed if we want to go any further on this road.


Yeah. I have finally found /root/live/image being used in the final 
disk, but not sure if they need to be on live-boot.


If I look up more into it I will open a new bug. Not sure I will have 
time for that.


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




--
To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f8a933b.5070...@gmail.com

Bug#668904: findiso implementation to be improved


Package: live-boot
Version: 3.0~a26-1
Severity: minor

Dear Maintainer,

   Current findiso implementation should be improved.

What needs to be removed (and checked that it does not induces any 
regression) is the part where:


   /live/findiso is mount-moved to /root/live/findiso.

I'll try from my part to test that but not sure when.

This bug comes as a workaround to the suboptimal discussion about this 
issue being held at the closed bug: #656135 .


   Thank you very much!




--
To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f8ad88d.7070...@gmail.com

Bug#668100: fromiso rewriting based on findiso structure


El 15/04/12 12:00, intrigeri escribiÃ³:

Hi,

adrian15 wrote (15 Apr 2012 09:22:03 GMT) :

El 10/04/12 11:59, intrigeri escribiÃÂ³:

Shall we consider this action item (fromiso rewriting based on
findiso structure) as done, and close this bug?



If the fromiso option still works I think so too.


Then please verify it still works and report back.

Cheers,


Fromiso option works for me for the latest git version (debian-next).

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




--
To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f8af064.20...@gmail.com

Bug#656135: Add findiso boot parametre

2012-04-09 Thread adrian15


El 09/04/12 09:46, intrigeri escribiÃ³:

Hi,

adrian15 wrote (08 Apr 2012 20:54:39 GMT) :

But according to current fromiso implementation it would seem that
you have to check exactly the same directory as the one
you're umounting.



I'm not very sure about this reasoning so please take my patch
with caution.


Looks great, but may you please test this patch (against current
debian-next) and confirm it works fine?

Cheers,


I have tested it (toram and findiso boot parametres together) and I 
suppose it works ok because:


* Inside /proc/mounts there's no reference to findiso string.
* Inside /live folder I only find: image, overlay and rofs folders.

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




--
To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f830f47.60...@gmail.com

Bug#668100: fromiso rewriting based on findiso structure

2012-04-09 Thread adrian15


El 09/04/12 18:45, intrigeri escribiÃ³:

I am trying to improve fromiso boot parametre current code.


Great.


I attach a patch that:



   a) Rewrites it to its code structure is as close as findiso one.
  This implies that the /live/fromiso (previously called
  /isofrom) folder is available in the new root filesystem at
  /root/live/fromiso. This was not the case in the
  old implementation.



   b) Rewrites it to use fromiso string instead of isofrom string in
  the code as often as possible.



I would like some feedback before testing it to confirm that this is
right way of coding/improving it.


I'd rather review split patches: one per kind of change.
A Git branch would be perfect, patches output by git format-patch
would do.

Besides, given the code structure of findiso and fromiso end up being
that similar, how hard would it be to factorize common logics somehow?

Cheers,


I attach the splitted patches.

I am doubting about 003 patch. Why fromiso didn't have in the first 
place? Why findiso did it? Perhaps because fromiso in the paste did have it?


Maybe it's some kind of obsolete code.



Related to this I have found: /live/image and /root/live/image that do 
not seem to be used (just rgreped for /live/image). I might open a new 
bug for this but I'm not sure.


adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el software 
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
diff --git a/scripts/live b/scripts/live
index 97f548d..0703af6 100755
--- a/scripts/live
+++ b/scripts/live
@@ -1276,15 +1276,15 @@ check_dev ()
 
 		if [ $ISO_DEVICE = / ]
 		then
-			echo Warning: device for bootoption isofrom= ($FROMISO) not found./live-boot.log
+			echo Warning: device for bootoption fromiso= ($FROMISO) not found./live-boot.log
 		else
 			fs_type=$(get_fstype ${ISO_DEVICE})
 			if is_supported_fs ${fs_type}
 			then
-mkdir /isofrom
-mount -t $fs_type $ISO_DEVICE /isofrom
+mkdir /fromiso
+mount -t $fs_type $ISO_DEVICE /fromiso
 ISO_NAME=$(echo $FROMISO | sed s|$ISO_DEVICE||)
-loopdevname=$(setup_loop /isofrom/${ISO_NAME} loop /sys/block/loop*  '')
+loopdevname=$(setup_loop /fromiso/${ISO_NAME} loop /sys/block/loop*  '')
 devname=${loopdevname}
 			else
 echo Warning: unable to mount $ISO_DEVICE. /live-boot.log
@@ -1617,7 +1617,7 @@ mountroot ()
 	if [ -n $FROMISO ]  [ ${TORAM} ]
 	then
 	  losetup -d /dev/loop0
-	  grep -q /isofrom /proc/mounts  umount /isofrom
+	  grep -q /fromiso /proc/mounts  umount /fromiso
 	fi
 
 	if [ -n ${MODULETORAMFILE} ] || [ -n ${PLAIN_ROOT} ]
diff --git a/scripts/live b/scripts/live
index 0703af6..17b1b30 100755
--- a/scripts/live
+++ b/scripts/live
@@ -1281,10 +1281,10 @@ check_dev ()
 			fs_type=$(get_fstype ${ISO_DEVICE})
 			if is_supported_fs ${fs_type}
 			then
-mkdir /fromiso
-mount -t $fs_type $ISO_DEVICE /fromiso
+mkdir /live/fromiso
+mount -t $fs_type $ISO_DEVICE /live/fromiso
 ISO_NAME=$(echo $FROMISO | sed s|$ISO_DEVICE||)
-loopdevname=$(setup_loop /fromiso/${ISO_NAME} loop /sys/block/loop*  '')
+loopdevname=$(setup_loop /live/fromiso/${ISO_NAME} loop /sys/block/loop*  '')
 devname=${loopdevname}
 			else
 echo Warning: unable to mount $ISO_DEVICE. /live-boot.log
@@ -1617,7 +1617,7 @@ mountroot ()
 	if [ -n $FROMISO ]  [ ${TORAM} ]
 	then
 	  losetup -d /dev/loop0
-	  grep -q /fromiso /proc/mounts  umount /fromiso
+	  grep -q /live/fromiso /proc/mounts  umount /live/fromiso
 	fi
 
 	if [ -n ${MODULETORAMFILE} ] || [ -n ${PLAIN_ROOT} ]
diff --git a/scripts/live b/scripts/live
index 17b1b30..28fcbea 100755
--- a/scripts/live
+++ b/scripts/live
@@ -1611,6 +1611,13 @@ mountroot ()
 		log_end_msg
 	fi
 
+	# Move fromiso directory to the new root filesystem so that programs there can get at it.
+	if [ -d /live/fromiso ]  [ ! -d /root/live/fromiso ]
+	then
+		mkdir -p /root/live/fromiso
+		mount -n --move /live/fromiso /root/live/fromiso
+	fi
+
 	# if we do not unmount the ISO we can't run fsck /dev/ice later on
 	# because the mountpoint is left behind in /proc/mounts, so let's get
 	# rid of it when running from RAM
diff --git a/scripts/live b/scripts/live
index 28fcbea..31df5e4 100755
--- a/scripts/live
+++ b/scripts/live
@@ -1623,8 +1623,14 @@ mountroot ()
 	# rid of it when running from RAM
 	if [ -n $FROMISO ]  [ ${TORAM} ]
 	then
-	  losetup -d /dev/loop0
-	  grep -q /live/fromiso /proc/mounts  umount /live/fromiso
+		losetup -d /dev/loop0
+
+		if is_mountpoint /root/live/fromiso
+		then
+			umount /root/live/fromiso
+			rmdir --ignore-fail-on-non-empty /root/live/fromiso \
+/dev/null 21 || true
+		fi
 	fi
 
 	if [ -n ${MODULETORAMFILE} ] || [ -n ${PLAIN_ROOT} ]

Bug#656135: Add findiso boot parametre


El 08/04/12 07:11, Daniel Baumann escribiÃ³:

On 04/08/2012 12:19 AM, adrian15 wrote:

I rewrote the patch according to intrigeri wishes and with some pieces
of advice from Daniel.


but now you did worsen it a bit compared to the last iteration :)

   * use 'mkdir -p /live/findiso' instead of 'mkdir /live/findiso -p'
 for consistency.

   * use 'if [ -d /live/findiso ]  [ ! -d /root/live/findiso ]'
 instead of 'if [ -d /live/findiso -a ! -d /root/live/findiso ]'
 which is a bashism.

   * don't use 'local' when declaring variables, it's a bashism.

other than that, looks good to me.



I rewrote the patch with your pieces of advice implemented.

adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el software 
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
diff --git a/manpages/en/live-boot.7 b/manpages/en/live-boot.7
index ed66ad7..29c577a 100644
--- a/manpages/en/live-boot.7
+++ b/manpages/en/live-boot.7
@@ -66,6 +66,8 @@ Target target-name
   Lun 0 Path=path-to-your-live-image.iso,Type=fileio,IOMode=ro
   # If you want to boot multiple machines you might want to look at tuning some parameters like
   # Wthreads or MaxConnections
+.IP \fBfindiso\fR=\fI/PATH/TO/IMAGE\fI 4
+Look for the specified ISO file on all disks where it usually looks for the .squashfs file (so you don't have to know the device name as in fromiso=).
 .IP \fBfromiso\fR=\fI/PATH/TO/IMAGE\fI 4
 Allows to use a filesystem from within an iso image that's available on live-media.
 .IP \fBignore_uuid\fR 4
diff --git a/scripts/live b/scripts/live
index e248937..77ca9d1 100755
--- a/scripts/live
+++ b/scripts/live
@@ -1357,6 +1357,21 @@ check_dev ()
 		mount -t ${fstype} -o ro,noatime ${devname} ${mountpoint} || continue
 		[ -n $devuid ]  echo $devuid  $tried
 
+		if [ -n ${FINDISO} ]
+		then
+			if [ -f ${mountpoint}/${FINDISO} ]
+			then
+umount ${mountpoint}
+mkdir -p /live/findiso
+mount -t ${fstype} -o ro,noatime ${devname} /live/findiso
+loopdevname=$(setup_loop /live/findiso/${FINDISO} loop /sys/block/loop* 0 )
+devname=${loopdevname}
+mount -t iso9660 -o ro,noatime ${devname} ${mountpoint}
+			else
+umount ${mountpoint}
+			fi
+		fi
+
 		if is_live_path ${mountpoint}  \
 			([ ${skip_uuid_check} ] || matches_uuid ${mountpoint})
 		then
@@ -1643,6 +1658,26 @@ mountroot ()
 	# when booting FAI, this simple workaround solves it
 	ls /root/* /dev/null 21
 
+	# Move findiso directory to the new root filesystem so that programs there can get at it.
+	if [ -d /live/findiso ]  [ ! -d /root/live/findiso ]
+	then
+		mkdir -p /root/live/findiso
+		mount -n --move /live/findiso /root/live/findiso
+	fi
+
+	# if we do not unmount the ISO we can't run fsck /dev/ice later on
+	# because the mountpoint is left behind in /proc/mounts, so let's get
+	# rid of it when running from RAM
+	if [ -n $FINDISO ]  [ ${TORAM} ]
+	then
+		losetup -d /dev/loop0
+
+		if is_mountpoint /live/findiso
+		then
+			umount /root/live/findiso
+		fi
+	fi
+
 	# copy snapshot configuration if exists
 	if [ -f snapshot.conf ]
 	then
diff --git a/scripts/live-helpers b/scripts/live-helpers
index 889d157..2c943f1 100644
--- a/scripts/live-helpers
+++ b/scripts/live-helpers
@@ -143,6 +143,11 @@ Arguments ()
 export STATICIP
 ;;
 
+			findiso=*)
+FINDISO=${ARGUMENT#findiso=}
+export FINDISO
+;;
+
 			live-getty)
 LIVE_GETTY=1
 export LIVE_GETTY
@@ -1579,3 +1584,15 @@ fix_home_rw_compatibility ()
 /home source=.  ${include_list}
 	fi
 }
+
+is_mountpoint () {
+
+	directory=$1
+
+	if [ $(stat -fc%d:%D ${directory}) != $(stat -fc%d:%D ${directory}/..) ]
+	then
+		return 0
+	else
+		return 1
+	fi
+}

Bug#656135: Add findiso boot parametre


El 08/04/12 13:29, Daniel Baumann escribiÃ³:

On 04/08/2012 12:50 PM, adrian15 wrote:

I rewrote the patch with your pieces of advice implemented.


looks good to me, thanks for you patience with it.

intrigeri, ack for applying it?


This is another patch that would complement the first one.

It includes reducing the is_mountpoint function and making sure that the 
filesystem is not cluttered with unused mountpoint directorios (findiso 
in this specific case).


adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el software 
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
diff --git a/scripts/live b/scripts/live
index 77ca9d1..b7ab159 100755
--- a/scripts/live
+++ b/scripts/live
@@ -1675,6 +1675,7 @@ mountroot ()
 		if is_mountpoint /live/findiso
 		then
 			umount /root/live/findiso
+			rmdir --ignore-fail-on-non-empty /root/live/findiso  /dev/null 21 || true
 		fi
 	fi
 
diff --git a/scripts/live-helpers b/scripts/live-helpers
index 2c943f1..d8e1ca3 100644
--- a/scripts/live-helpers
+++ b/scripts/live-helpers
@@ -1589,10 +1589,6 @@ is_mountpoint () {
 
 	directory=$1
 
-	if [ $(stat -fc%d:%D ${directory}) != $(stat -fc%d:%D ${directory}/..) ]
-	then
-		return 0
-	else
-		return 1
-	fi
+	[ $(stat -fc%d:%D ${directory}) != $(stat -fc%d:%D ${directory}/..) ]
+
 }

Bug#656135: Add findiso boot parametre


El 08/04/12 20:33, intrigeri escribiÃ³:

tags 656135 + fixed-upstream
thanks

Daniel Baumann wrote (08 Apr 2012 11:29:28 GMT) :

intrigeri, ack for applying it?


Applied in Git, with a few improvements as follow-up commits.

Thanks adrian15!

Cheers,


While trying to improve fromiso/isofrom option I've just realised that 
the original grml implementation of findiso checked for: /live/findiso 
on /proc/mounts while what it was unmounted was: /root/live/findiso .


But according to current fromiso implementation it would seem that you 
have to check exactly the same directory as the one you're umounting.


I'm not very sure about this reasoning so please take my patch with caution.

adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el software 
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
diff --git a/scripts/live b/scripts/live
index f4f4059..97f548d 100755
--- a/scripts/live
+++ b/scripts/live
@@ -1670,7 +1670,7 @@ mountroot ()
 	then
 		losetup -d /dev/loop0
 
-		if is_mountpoint /live/findiso
+		if is_mountpoint /root/live/findiso
 		then
 			umount /root/live/findiso
 			rmdir --ignore-fail-on-non-empty /root/live/findiso \

Bug#668100: fromiso rewriting based on findiso structure


Package: live-boot
Version: 3.0~a26-1
Severity: minor

Dear Maintainer,

  I am trying to improve fromiso boot parametre current code.

I attach a patch that:

  a) Rewrites it to its code structure is as close as findiso one. This 
implies that the /live/fromiso (previously called /isofrom) folder is 
available in the new root filesystem at /root/live/fromiso. This was not 
the case in the old implementation.


  b) Rewrites it to use fromiso string instead of isofrom string in the 
code as often as possible.


I would like some feedback before testing it to confirm that this is 
right way of coding/improving it.


  Thank you very much!
diff --git a/scripts/live b/scripts/live
index f4f4059..31df5e4 100755
--- a/scripts/live
+++ b/scripts/live
@@ -1276,15 +1276,15 @@ check_dev ()
 
 		if [ $ISO_DEVICE = / ]
 		then
-			echo Warning: device for bootoption isofrom= ($FROMISO) not found./live-boot.log
+			echo Warning: device for bootoption fromiso= ($FROMISO) not found./live-boot.log
 		else
 			fs_type=$(get_fstype ${ISO_DEVICE})
 			if is_supported_fs ${fs_type}
 			then
-mkdir /isofrom
-mount -t $fs_type $ISO_DEVICE /isofrom
+mkdir /live/fromiso
+mount -t $fs_type $ISO_DEVICE /live/fromiso
 ISO_NAME=$(echo $FROMISO | sed s|$ISO_DEVICE||)
-loopdevname=$(setup_loop /isofrom/${ISO_NAME} loop /sys/block/loop*  '')
+loopdevname=$(setup_loop /live/fromiso/${ISO_NAME} loop /sys/block/loop*  '')
 devname=${loopdevname}
 			else
 echo Warning: unable to mount $ISO_DEVICE. /live-boot.log
@@ -1611,13 +1611,26 @@ mountroot ()
 		log_end_msg
 	fi
 
+	# Move fromiso directory to the new root filesystem so that programs there can get at it.
+	if [ -d /live/fromiso ]  [ ! -d /root/live/fromiso ]
+	then
+		mkdir -p /root/live/fromiso
+		mount -n --move /live/fromiso /root/live/fromiso
+	fi
+
 	# if we do not unmount the ISO we can't run fsck /dev/ice later on
 	# because the mountpoint is left behind in /proc/mounts, so let's get
 	# rid of it when running from RAM
 	if [ -n $FROMISO ]  [ ${TORAM} ]
 	then
-	  losetup -d /dev/loop0
-	  grep -q /isofrom /proc/mounts  umount /isofrom
+		losetup -d /dev/loop0
+
+		if is_mountpoint /root/live/fromiso
+		then
+			umount /root/live/fromiso
+			rmdir --ignore-fail-on-non-empty /root/live/fromiso \
+/dev/null 21 || true
+		fi
 	fi
 
 	if [ -n ${MODULETORAMFILE} ] || [ -n ${PLAIN_ROOT} ]
@@ -1670,7 +1683,7 @@ mountroot ()
 	then
 		losetup -d /dev/loop0
 
-		if is_mountpoint /live/findiso
+		if is_mountpoint /root/live/findiso
 		then
 			umount /root/live/findiso
 			rmdir --ignore-fail-on-non-empty /root/live/findiso \

Bug#668100: fromiso rewriting based on findiso structure