Re: live-manual is marked for autoremoval from testing

[Luca Boccassi]

On Mon, 4 Apr 2022 at 14:33, Roland Clobus  wrote:
>
> Hello list,
>
> On 04/04/2022 06:39, Debian testing autoremoval watch wrote:
> > live-manual 2:20151217.1 is marked for autoremoval from testing on 
> > 2022-05-09
> >
> > It (build-)depends on packages with these RC bugs:
> > 1008405: sisu: "sisu-complete: fails to run with Ruby 3.0"
> >   https://bugs.debian.org/1008405
>
> 'apt-cache rdepends sisu-complete' shows that live-manual is the
> last/only dependency for SiSU.
>
> I see 3 options:
> 1) Abandon SiSU in favour of some other format, e.g. asciidoc or
> markdown (each has po4a-support)
> 2) Wait for or help SiSU with the release of a Ruby 3-compatible version
> 3) Remove live-manual from the Debian repository and keep only the
> git-based most recent version
>
> I'm tempted to go for option 3.
> What's your opinion?
>
> With kind regards,
> Roland Clobus

We really want to ship documentation in the distribution, it's needed
for accessibility, offline usage, and so on.

Kind regards,
Luca Boccassi

Re: Porting the standard image from live-wrapper to live-build

[Luca Boccassi]

On Tue, 2020-11-17 at 09:59 +0100, Raphael Hertzog wrote:
> Hi Roland,
> 
> thanks for your efforts! I would very much welcome if you could submit
> gradually your live-build changes to the official repository so that you
> don't have to keep a big fork.

Ditto!

> On Wed, 11 Nov 2020, Roland Clobus wrote:

<...>

> > live-build:
> > * /EFI/boot contains a 32-bit EFI image on the amd64 iso.
> > ** AP: Is this needed/correct?
> 
> Pass, I don't know.

IIRC yes - it's rare, but I think there is hardware out there with
32bit EFI and 64bit CPUs.

-- 
Kind regards,
Luca Boccassi


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

Re: Add data partition to a livecd on Windows

[Luca Boccassi]

On Wed, 2020-03-18 at 14:59 +0100, Thomas Schmitt wrote:
> Hi,
> 
> cagnulein wrote:
> > I send the message here because i guess live-build should change
> > the way of
> > building the EFI iso, don't you think?
> 
> I agree. Somebody with Debian Developer power should implement my
> proposals made in
>   https://lists.debian.org/debian-cd/2019/07/msg7.html

Hi,

No special powers are needed - anybody can register a guest account on
Salsa, fork the repository/ies and send merge requests:

https://salsa.debian.org/live-team
https://signup.salsa.debian.org/

Alternatively, patches can be sent to this very same mailing list.
Alternatively, bugs can be opened against the relevant packages, with
patches attached.

-- 
Kind regards,
Luca Boccassi


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

Bug#953957: [live-build] W: Download is performed unsandboxed as root as file '.dsc' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)

[Luca Boccassi]

On Sun, 2020-03-15 at 18:20 +, jnq...@gmail.com wrote:
> On Sun, 2020-03-15 at 11:34 +0000, Luca Boccassi wrote:
> > The reason I asked for the change and I wasn't comfortable with
> > making
> > the download directory 777 is that live-build is routinely used in
> > automated production systems to create images. I do not want to
> > introduce the risk of a rogue, unprivileged process to be able to
> > mess
> > with the downloaded files after apt has ran, if it's just to fix a
> > harmless warning.
> > 
> > If it can be fixed without introducing risk - great! If not, I
> > would
> > recommend to document it and leave it.
> 
> I hope that my bug report did not make you feel that I was being
> critical of your decision. That is not the case, I very much agree
> with
> whying away from 777. I was just trying to document the details of
> what
> worked and what did not. :)
> 
> FWIW I care greatly about security and as mentioned in the MR, I need
> to refresh my mind (I'll  look it up shortly) as to what protections
> parent directory permissions give to subdirs as I might have been
> mistakenly thinking that the parent having root:root 755 permissions
> would prevent malicious outside access to this directory, but I'm
> probably wrong. (a long time since I last referenced that fundamental
> detail).
> 
> I'm not so sure that we could consider the warning harmless. I would
> expect that apt is warning that it was unable to drop root privileges
> to do verification of the file or something, which means that a
> malicious file from a MITM hijack could trigger a bug if there were
> one
> in apt and gain root privileges rather than user.
> 
> Anyway, I'm getting a little off topic...
> 
> ---
> 
> Regarding the bug itself, I had an epiphany last night which I just
> checked out and confirmed. The problem is simply that we're
> performing
> the chown from the host level whilst running apt-get within the
> chroot,
> and there's no guarantee that the _apt user will have the same UID
> between the two. To fix the problem all we need to do is run chown
> within the chroot environment too, thus actually assigning the
> correct
> UID to the folder.
> 
> I just tested this and it works :D
> I'll post an MR in a moment.

Great, thanks for fixing that - just wanted to ensure all details were
in the bug report

-- 
Kind regards,
Luca Boccassi


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

Bug#953957: [live-build] W: Download is performed unsandboxed as root as file '.dsc' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)

[Luca Boccassi]

On Sun, 2020-03-15 at 00:25 +, jnq...@gmail.com wrote:
> Package: live-build
> Version: 1:20191221
> 
> 744141c60f55144b4d8944ba0d745adcc4b34116 (from MR #97) tried to fix
> the
> bug of the source stage generating permissions related warnings when
> downloading source packages.
> 
> the original fix submitted in the MR was to set the permissions of
> the
> download directory to 777. the reviewer requested that instead
> ownership be set to _apt:root, which was the version of the commit
> that
> then got merged.
> 
> unfortunately this modified solution does not work. i do not know why
> this was not caught at the time, whether i did not bother to test
> since
> it seemed so obvious that it should work, or whether something went
> wrong with conducting a fresh test, but re-running the source stage
> now
> i see that the problem still exists.
> 
> i have been playing around with trying to figure out a suitable
> alternative to properly solve this but not been successful so far.
> 
> submitting this as a bug report to ensure that a record is made in
> case
> i don't find a solution / i end up forgetting about this / someone
> else
> can find a solution in the meantime.

The reason I asked for the change and I wasn't comfortable with making
the download directory 777 is that live-build is routinely used in
automated production systems to create images. I do not want to
introduce the risk of a rogue, unprivileged process to be able to mess
with the downloaded files after apt has ran, if it's just to fix a
harmless warning.

If it can be fixed without introducing risk - great! If not, I would
recommend to document it and leave it.

-- 
Kind regards,
Luca Boccassi


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

Re: [live-build] "E: Unable to find a source package for syslinux,grub-efi"

[Luca Boccassi]

On Sun, 2020-03-15 at 10:58 +0900, John Crawley wrote:
> On 2020-03-14 13:27, jnq...@gmail.com wrote:
> > On Sat, 2020-03-14 at 14:59 +1100, David wrote:
> > > On Wed, 11 Mar 2020 at 02:39,  wrote:
> > > > obviously it seems to be treating "syslinux,grub-efi" as a
> > > > single
> > > > package name which is wrong. this string originates from
> > > > LB_BOOTLOADERS.
> > > > 
> > > > the code that should be handling this in source_debian looks to
> > > > be
> > > > the
> > > > following:
> > > > ```
> > > > echo "${LB_BOOTLOADERS}" | \
> > > > while IFS="," read -r BOOTLOADER
> > > > do
> > > >  echo "${BOOTLOADER}" >> source-selection.txt
> > > > done
> > > > ```
> > > > 
> > > > which is correctly specifying a comma as the separator, so if
> > > > this
> > > > is
> > > > where the problem originates, I don't know why...
> > > 
> > > If you just need to parse comma-separated tokens from a string,
> > > then maybe this code will work for you:
> > > 
> > > Demo code:
> > > 
> > > #!/bin/sh
> > > s="a1,a2,a3,a4"
> > > while [ -n "${s}" ] ; do
> > >  # get $v = leading word of $s, by strip first comma and all
> > > following
> > >  v=${s%%,*}
> > >  # update $s according to $v
> > >  if [ "${v}" != "${s}" ] ; then
> > >  # update $s by remove leading $v and a comma from $s
> > >  s=${s#${v},}
> > >  else
> > >  # $v=$s, so nothing was stripped, so nothing more to do
> > >  s=''
> > >  fi
> > >  printf 'v=%s\n' "${v}"
> > > done
> > > 
> > > The above demo code tested produces output:
> > > v=a1
> > > v=a2
> > > v=a3
> > > v=a4
> > 
> > Thankyou, I appreciate the effort you've put into this but an
> > explanation of why the existing implementation did not work was
> > supplied by John Crawley, and I went ahead already with an actual
> > solution of:
> > ```
> > for BOOTLOADER in $(echo "${LB_BOOTLOADERS}" | tr "," "\n"); do
> > echo "${BOOTLOADER}" >> source-selection.txt
> > done
> > ```
> > 
> > which is ideally neat and simple, even if it is piping to a binary
> > rather than achieving the goal within the shell.
> > 
> > your solution on the other hand, whilst I appreciate the effort put
> > into it, and possibly of interest to people to understand how you
> > accomplished it, is very much inferior imho considering how big and
> > complex it is relatively speaking. thank you again though.
> 
> I think "very much inferior" might be overstating the case. David's
> pure 
> shell implementation might look bigger, but it's probably faster,
> which 
> might matter in some situations, and avoids calling outside
> utilities.
> 
> This isn't a shell scripting mailing list, but FWIW here's yet
> another 
> way. It's been tested on dash and posh, but does the work in a
> subshell 
> which is fine if you just want to echo strings but won't allow you
> to 
> set variables. It's a function:
> 
> echo_strings()(
>  local loader
>  IFS=,
>  set -- $*
>  for loader
>  do
>  echo "$loader"
>  done
> )
> 
> LB_BOOTLOADERS='first bootloader,second one'
> echo_strings "$LB_BOOTLOADERS"
> first bootloader
> second one
> 
> But the pipe to tr is probably fine for this case.

Risking to state the obvious: if this snippet is ran once at setup,
then keep it readable, short and maintainable.
If it's in the "hot path" and ran a gazillion times per build, then by
all means optimize away - but document it clearly.

-- 
Kind regards,
Luca Boccassi


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

Bug#928096: systemd does not play well with nfs root - unable to shutdown/reboot

[Luca Boccassi]

On Wed, 2019-06-05 at 11:56 +0200, Gianluigi Tiesi wrote:
> On 4/28/19 8:14 PM, Luca Boccassi wrote:
> > If you have tried with debian live iso too, I don't think this has
> > anything to do with live-build?
> 
> Isn't debian live iso made using live-build?
> Unfortunately I was not able to make a non systemd live iso

It does not, it uses live-wrapper. Did you see this problem with
official debian live images? Or custom-built with live-build?

-- 
Kind regards,
Luca Boccassi


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

Bug#928840: boot hangs forever at live-config when libnss-systemd in image

[Luca Boccassi]

On Sat, 2019-05-11 at 20:29 -0700, Steven Monai wrote:
> Package: live-config
> Version: 5.20190415
> Severity: normal
> 
> Dear Maintainer,
> 
> When the package 'libnss-systemd' is included in a debian-live image,
> all attempts to boot the image fail, hanging forever at a particular
> point in the boot process. The following message appears in the
> console (all on one line), with the kinetic red "cylon" effect on the
> left, and a time counter counting up towards infinity on the right:
> 
> ``[ ***   ] A start job is running for live-config contains the
> components that configure a live system during the boot process
> (late userspace). (10min 1s / no limit)''
> 
> If it matters: I build my debian-live images with 'live-build', and
> I include all Standard priority packages with the one-line package
> list macro "! Packages Priority standard". In order to work around
> this hanging-boot problem, I have been blocking the 'libnss-systemd'
> package from my debian-live images via apt pinning.
> 
> I have tried adding "live-config.debug" to the boot command
> line, but no additional useful information appears in the console.
> And, furthermore, I cannot access the debug logs in the live
> system, since tty consoles are not yet available at the point that
> the live-config service hangs the boot sequence.
> 
> I have tried booting in both legacy/BIOS mode and in UEFI mode
> (with secure boot disabled), and the behaviour is the always the
> same: hanging boot.
> 
> I maintain a number of debian-live build recipes in salsa. The
> following one can be used to create an ISO image that exhibits the
> hanging boot problem (just remove the pin in 'config/apt/preferences'
> before running the 'make.sh' script):
> 
> https://salsa.debian.org/smonaica-guest/sid-standard-live.git
> 
> 
> Best regards,
> -S.M.

Hi,

This has been reported upstream:

https://github.com/systemd/systemd/issues/12492

-- 
Kind regards,
Luca Boccassi


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

Re: Please activate the pipelines in salsa.debian.org

[Luca Boccassi]

On Thu, 2019-05-09 at 15:23 +0200, Roland Clobus wrote:
> Hello live team,
> 
> recently I've added the file 'gitlab-ci.yml' in the debian directory
> of
> live-build and live-boot.
> With this file, and a configuration change in salsa.debian.org, the
> latest-and-greatest packages will be automatically built.
> 
> The documentation for the yml file can be found on:
> https://wiki.debian.org/Salsa/Doc#Running_Continuous_Integration_.28CI.29_tests
> 
> 
> On salsa.debian.org, in 'Settings|CI/CD Settings|General pipelines'
> set
> 'Custom CI config path' to debian/gitlab-ci.yml
> 
> When the pipeline has run (which automatically happens on each
> commit),
> the (unsigned) packages are available for anyone to install.
> 
> The end user needs to add the following line to
> '/etc/apt/sources.list':
> deb [allow-insecure=yes] 
> https://live-team.pages.debian.net/live-boot/
> 
> autobuilt main
> 
> The individual files can be inspected at:
> https://live-team.pages.debian.net/live-boot/
> 
> (modify live-boot to match each of the git-repos)
> 
> Can you activate the pipeline for live-boot? (For live-build it is
> running already)
> Should I create merge requests for the remaining git-repos? (The yml
> file does not need modification for the diffrerent repos)
> 
> With kind regards,
> Roland Clobus

Updated for live-boot - I don't really work on projects other than
live-boot and live-build, so I'll let other maintainers and
collaborators comment on whether they'd like the CI activated.

Thanks for your work!

-- 
Kind regards,
Luca Boccassi


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

Bug#928096: systemd does not play well with nfs root - unable to shutdown/reboot

[Luca Boccassi]

On Sun, 2019-04-28 at 00:08 +0200, Gianluigi Tiesi wrote:
> Package: live-build
> Version: 1:20190311
> Severity: normal
> 
> Hi, I'm playing with images using nfs root, my host is debian sid
> amd64,
> I build images for buster amd64
> 
> I'm using qemu:
> 
> kvm \
> -m 2048 \
> -vga qxl \
> -serial stdio \
> -usb -device usb-tablet \
> -soundhw hda \
> -netdev
> user,id=net0,host=192.168.76.1,net=192.168.76.0/24,dhcpstart=192.168.
> 76.9 \
> -device e1000,netdev=net0 \
> -drive file=disk.img,if=ide,format=qcow2 \
> -kernel binary/live/vmlinuz \
> -initrd binary/live/initrd.img \
> -append "boot=live persistence components netboot=nfs
> locales=it_IT.UTF-8 nfsroot=192.168.76.1:/home/sherpya/live-
> default/binary console=ttyS0,115200 console=tty"
> 
> 
> /etc/exports:
> 
> /home/sherpya/live-default/binary
> *(ro,async,no_root_squash,no_subtree_check,insecure)
> 
> The system works fine but I'm unable to shutdown or reboot:
> 
> [  OK  ] Reached target Reboot.
> [   72.684441] systemd-shutdow: 51 output lines suppressed due to
> ratelimiting
> [   77.162859] nfs: server 192.168.76.1 not responding, still trying
> [   77.164759] nfs: server 192.168.76.1 not responding, still trying
> [   77.170156] nfs: server 192.168.76.1 not responding, still trying
> [  116.073320] systemd-journald[517]: Failed to send WATCHDOG=1
> notification message: Connection refused
> [  236.055922] systemd-journald[517]: Failed to send WATCHDOG=1
> notification message: Transport endpoint is not connected
> [  242.509427] INFO: task systemd-shutdow:1 blocked for more than 120
> seconds.
> [  242.513657]   Not tainted 4.19.0-4-amd64 #1 Debian 4.19.28-2
> [  242.516653] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
> disables this message.
> [  242.520144] systemd-shutdow D0 1  0 0x
> [  242.522682] Call Trace:
> [  242.523495]  ? __schedule+0x2a2/0x870
> [  242.524414]  schedule+0x28/0x80
> [  242.525263]  io_schedule+0x12/0x40
> [  242.526140]  __lock_page_or_retry+0x305/0x340
> [  242.527137]  ? page_cache_tree_insert+0xe0/0xe0
> [  242.528157]  filemap_fault+0x18d/0x770
> [  242.529136]  ? alloc_set_pte+0x494/0x560
> [  242.530229]  ? filemap_map_pages+0x139/0x3a0
> [  242.531329]  ext4_filemap_fault+0x2c/0x40 [ext4]
> [  242.532422]  __do_fault+0x36/0x130
> [  242.533341]  __handle_mm_fault+0xe6f/0x1280
> [  242.534325]  ? isolate_lru_page+0x1c7/0x260
> [  242.535299]  handle_mm_fault+0xda/0x200
> [  242.536332]  __get_user_pages+0x240/0x6d0
> [  242.537369]  populate_vma_page_range+0x6d/0x70
> [  242.538413]  __mm_populate+0x9d/0x140
> [  242.539315]  __x64_sys_mlockall+0xf1/0x180
> [  242.540298]  do_syscall_64+0x53/0x100
> [  242.541210]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> [  242.542361] RIP: 0033:0x7ff5f7803717
> [  242.543360] Code: Bad RIP value.
> [  242.544234] RSP: 002b:7ffea0b288f8 EFLAGS: 0246 ORIG_RAX:
> 0097
> [  242.545776] RAX: ffda RBX:  RCX:
> 7ff5f7803717
> [  242.547204] RDX: 0007 RSI: 55b0fbbd028e RDI:
> 0003
> [  242.548865] RBP: 55b0fbbd3420 R08: 021f R09:
> 55b0fd399290
> [  242.550633] R10:  R11: 0246 R12:
> 
> [  242.553432] R13: 7ffea0b28c80 R14:  R15:
> 
> [  296.047709] systemd-journald[517]: Failed to send WATCHDOG=1
> notification message: Transport endpoint is not connected
> 
> In a previous build (some days ago) it was working.
> I have the same problem using files from debian live iso
> 
> I suppose the system cannot shutdown ethernet if the root is on nfs,
> and nfs live mount cannot
> be unmounted.
> 
> I've seen around someone suggesting to make systemd ignore interface
> shutdown problems

If you have tried with debian live iso too, I don't think this has
anything to do with live-build?

-- 
Kind regards,
Luca Boccassi

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

Re: Offer to help updating the manual

[Luca Boccassi]

On Sun, 2019-04-07 at 13:50 +0200, Roland Clobus wrote:
> On 06/04/2019 20:22, Luca Boccassi wrote:
> > Please feel free to send merge requests on Salsa:
> > 
> > https://salsa.debian.org/live-team/live-manual
> > 
> 
> Thank you accepting the first (tiny) merge request.
> 
> Regarding workflow:
> 
> Do you prefer to receive merge request for each single issue (e.g. as
> listed below) or do you like to cherry-pick from my branch?

Please send merge requests - up to you how you split them

> Encountered issues/Need for information:
> 
> During the updating of the links I've seen the following, for which I
> need input from the team members who might know what happened/needs
> to
> be done:
> 
> * The search functionality on
> https://live-team.pages.debian.net/live-manual/
> 
> In commit 939ed4a829aa009294689a2ad311f3d9f9880e5f the search form
> was
> disabled. Can I remove references to the search functionality?

I'm not sure what would it take to fix the search for the new live
pages, if it cannot or nobody volunteers to do so then I think it makes
sense to remove references to it

> * The page with legal information on
> http://debian-live.alioth.debian.org/project/legal/
>  is gone now.
> Is there a replacement page with similar information?

I'm not sure what was on that page

> * Homepage for Live Systems Project (in the upper left corner of the
> documentation)
> Do you prefer a link to the team page in salsa [A], or to the Debian
> Wiki [B]/[C]/[D]? Looking at the pages, I would prefer [D].
> 
> [A] 
> https://salsa.debian.org/live-team
> 
> [B] 
> https://www.debian.org/devel/debian-live/
> 
> [C] 
> https://wiki.debian.org/DebianLive
> 
> [D] 
> https://www.debian.org/CD/live

live-manual applies to live-build, and debian live cds are not build
with live-build, so I'd say either A or C

> * The manual refers to the live-build-cgi server (See also #807957)
> The repository that is mentioned in the ticket is also not reachable
> any
> more. Should I remove references to that service for now?

I think so, same as above.

> * I'll first adapt the English translation. I have noticed that
> several
> translations contain links to even older locations of the project.
> What
> is your workflow? Should I contacts all translators for permission to
> update the URLs? (I'm asking, because I've recently seen a discussion
> on
> the gnome-i18n mailing list regarding developers changing
> translations)

Not sure, sorry

> * The live manual is currently automatically built on salsa. With
> merge
> request!7 the translated pages will become available on
> https://live-team.pages.debian.net/live-manual/
> 
> I think that handles ticket #807954.
> While preparing this mail, the merge request was already accepted.
> 
> With kind regards,
> Roland Clobus
> 
> 
-- 
Kind regards,
Luca Boccassi


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

Re: Offer to help updating the manual

[Luca Boccassi]

On Sat, 2019-04-06 at 11:13 +0200, Roland Clobus wrote:
> Hello maintainers of the live-manual package,
> 
> I've noticed that the live-manual documentation (partly) still refers
> to
> alioth.debian.org. The new git repository is however hosted on
> salsa.debian.org
> 
> I am interested in using the live package, and can provide a patch
> that
> fixes these broken links.
> Are you interested in such patch?
> 
> With kind regards,
> Roland Clobus
> DM for pioneers

Hi,

Please feel free to send merge requests on Salsa:

https://salsa.debian.org/live-team/live-manual

You can register a guest account here if you don't have one:

https://signup.salsa.debian.org/register/guest/

-- 
Kind regards,
Luca Boccassi

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

Bug#922251: live-build: support syslinux-efi as (additional) bootloader

[Luca Boccassi]

On Thu, 2019-02-14 at 18:35 +, Luca Boccassi wrote:
> On Thu, 2019-02-14 at 17:18 +0100, Matthijs Kooijman wrote:
> > Hey Luca,
> > 
> > > At a quick glance it all sounds good to me, although I can't say
> > > I
> > > have
> > > a lot of experience with syslinux.
> > 
> > Ok.
> > 
> > > For feature parity, I'd encourage to look into supporting Secure
> > > Boot
> > > like the grub-efi implementation does, since we are preparing to
> > > ship
> > > that in Debian 10. It's not much extra work on top of adding the
> > > rest
> > > anyway.
> > 
> > Can you elaborate a bit on how grub-efi supports Secure Boot
> > exactly?
> > I
> > can't really find anything about this in the code?
> > 
> > Looking at build/scripts/binary_grub-efi and build/scripts/efi-
> > image, 
> > I
> > see that a new efi firmware binary is built using grub-mkimage, so
> > I
> > suppose that that image is not already signed, and there is nothing
> > suggesting that image is be signed at that time. Looking at
> > binary_iso
> > there is also no reference to signing or secure boot.
> > 
> > AFAIU, to support secure boot, you need to sign the bootloader,
> > typically using a key from MS. I've read about the Shim bootloader,
> > which is signed and typically used to then load grub or other
> > bootloaders (signed by the Debian key or other keys included in
> > Shim).
> > However, I can see no reference to shim either.
> > 
> > Looking at the grub package more closely, I *think* that it
> > installs
> > shim
> > alongside grub when using grub-install, but that is not used here?
> > 
> > Regardless, how would you suggest we "support Secure Boot" with
> > syslinux-efi exactly? AFAICT there is no syslinux-efi image
> > available
> > signed with the MS key, and I suspect it is not signed with the
> > Debian
> > key or any other key used by shim (also, since syslinux does not
> > seem
> > to
> > support key verification on kernels, I guess there is no secure way
> > to
> > get syslinux booting under secure boot without compromising secure
> > boot,
> > but I might be missing an important point about SB here...).
> 
> So for the secure boot case in binary_grub-efi, what we do is that if
> the signed monolithic EFI binaries are available we copy those
> instead
> of building a new image. As you correctly mentioned these have to be
> signed already, so we can't do that when building the image, but they
> are already available in the Debian archive as packages.
> 
> Here we check if they are available:
> 
> https://salsa.debian.org/live-team/live-build/blob/master/scripts/bui
> ld/binary_grub-efi#L79
> 
> Here we copy the binaries in the right places:
> 
> https://salsa.debian.org/live-team/live-build/blob/master/scripts/bui
> ld/binary_grub-efi#L164

Ah silly me, I forgot something simple but quite fundamental: the point
of syslinux is to avoid using grub entirely.

Then disregard anything I've said. D'oh!

-- 
Kind regards,
Luca Boccassi

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

Bug#922251: live-build: support syslinux-efi as (additional) bootloader

[Luca Boccassi]

On Thu, 2019-02-14 at 17:18 +0100, Matthijs Kooijman wrote:
> Hey Luca,
> 
> > At a quick glance it all sounds good to me, although I can't say I
> > have
> > a lot of experience with syslinux.
> 
> Ok.
> 
> > For feature parity, I'd encourage to look into supporting Secure
> > Boot
> > like the grub-efi implementation does, since we are preparing to
> > ship
> > that in Debian 10. It's not much extra work on top of adding the
> > rest
> > anyway.
> 
> Can you elaborate a bit on how grub-efi supports Secure Boot exactly?
> I
> can't really find anything about this in the code?
> 
> Looking at build/scripts/binary_grub-efi and build/scripts/efi-image, 
> I
> see that a new efi firmware binary is built using grub-mkimage, so I
> suppose that that image is not already signed, and there is nothing
> suggesting that image is be signed at that time. Looking at
> binary_iso
> there is also no reference to signing or secure boot.
> 
> AFAIU, to support secure boot, you need to sign the bootloader,
> typically using a key from MS. I've read about the Shim bootloader,
> which is signed and typically used to then load grub or other
> bootloaders (signed by the Debian key or other keys included in
> Shim).
> However, I can see no reference to shim either.
> 
> Looking at the grub package more closely, I *think* that it installs
> shim
> alongside grub when using grub-install, but that is not used here?
> 
> Regardless, how would you suggest we "support Secure Boot" with
> syslinux-efi exactly? AFAICT there is no syslinux-efi image available
> signed with the MS key, and I suspect it is not signed with the
> Debian
> key or any other key used by shim (also, since syslinux does not seem
> to
> support key verification on kernels, I guess there is no secure way
> to
> get syslinux booting under secure boot without compromising secure
> boot,
> but I might be missing an important point about SB here...).

So for the secure boot case in binary_grub-efi, what we do is that if
the signed monolithic EFI binaries are available we copy those instead
of building a new image. As you correctly mentioned these have to be
signed already, so we can't do that when building the image, but they
are already available in the Debian archive as packages.

Here we check if they are available:

https://salsa.debian.org/live-team/live-build/blob/master/scripts/build/binary_grub-efi#L79

Here we copy the binaries in the right places:

https://salsa.debian.org/live-team/live-build/blob/master/scripts/build/binary_grub-efi#L164

> > > Since config sharing is easy and syslinux-efi is a matter of
> > > adding
> > > some files to the existing image, it would make sense to add
> > > syslinux-efi by default on normal syslinux hdd images (perhaps
> > > adding a new option to disable this?).
> 
> I just noticed that lb config has a --bootloaders that supports
> *multiple* bootloaders, so that would be perfect way to support this.
> E.g. --bootloaders syslinux,syslinux-efi to have combined image
> (which
> would also become the default for hdd images), or an explicit
> --bootloaders syslinux or --bootloaders syslinux-efi to choose either
> one individually.
> 
> Gr.
> 
> Matthijs

Yes we do support that - although not all combinations work IIRC.

-- 
Kind regards,
Luca Boccassi

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

Bug#922251: live-build: support syslinux-efi as (additional) bootloader

[Luca Boccassi]

On Wed, 2019-02-13 at 20:57 +0100, Matthijs Kooijman wrote:
> Package: live-build
> Version: 1:20180925
> Severity: wishlist
> 
> Hi folks,
> 
> currently, live-build seems to only support EFI systems using the
> grub-efi bootloader, but not for netboot or hdd images (effectively
> only
> for iso images, I believe).
> 
> Syslinux also has an EFI version, that can be installed through
> the syslinux-efi package. It would be useful for live-build to
> support
> this. I need this for a client, so I'm planning to implement support
> in
> the coming weeks. This report serves to track progress and discuss
> the implementation.
> 
> I've done some experiments by adding syslinux-efi to an existing
> image
> manually (not with a full live-build image, but with my own hdd image
> that at least uses live-build for building the image, so should be
> representative in this area). This shows that adding syslinux-efi is
> fairly easy. The existing FAT partition can function as an ESP (EFI
> System Partition) as it is now.
> 
> Installing the bootloader is a matter of dumping some files in the
> EFI/BOOT directory. This lets the bootloader be detected as a
> fallback
> bootloader, which is AFAIU intended for removable media. Syslinux
> needs
> some additional files (ldlinux, additional modules, configuration)
> which
> can live in that same directory.
> 
> Both 32-bit and 64-bit EFI can be supported at the same time, by
> installing both versions of syslinux-efi (named bootx64.efi and
> bootia32.efi respectively). One caveat is that syslinux needs
> different
> .c32 modules for both architectures (though they are both named .c32
> and
> are explicitly referenced in the config file). This means either
> duplicating the bootloader configuration file for 32 and 64 bit
> (which
> hinders modifications to the config), or putting the modules in
> subdirectories and using the PATH config directive to point to either
> directive before including the common configuration. I have not tried
> this latter approach but it is described here (though currently
> syslinux.org seems to be unavailable, I tried the Google cache):
> 
> https://www.syslinux.org/archives/2014-August/022545.html
> 
> (subject: syslinux efi configuration file name proposal)
> 
> I've also tried to let the syslinux-efi config file include the
> normal
> syslinux configuration file (or at least the bulk that is in
> live.cfg),
> which seems to work just fine.
> 
> Since config sharing is easy and syslinux-efi is a matter of adding
> some
> files to the existing image, it would make sense to add syslinux-efi
> by
> default on normal syslinux hdd images (perhaps adding a new option to
> disable this?). This also seems to hold for ISO9660 images, where
> it seems isohybrid can include a small FAT filesystem with the
> bootloader files. This might need some additional work to generate
> the
> filesystem image and/or pass options when generating the iso. See:
> 
> https://www.syslinux.org/wiki/index.php?title=Isohybrid#UEFI
> 
> 
> Using syslinux-efi exclusively (e.g. passing it to --bootloader and
> not
> installing normal syslinux) might also be an extra option. However,
> I'm
> not much interested in this case, so I will likely not implement it
> (I'll try not to make it too hard to add it later).
> 
> 
> In terms of code, this is probably best implemented in the existing
> binary_syslinux script. The bulk of what needs to happen is
> essentially
> copying bootloader files from config/bootloaders into binary, taking
> care to resolve symlinks. I'm planning to put the code that does that
> into a shell function, so it can be called at the current place and
> then
> a second time for syslinux-efi later.
> 
> I think it would be good to copy files *from*
> config/bootloaders/syslinux-efi-addon or something similar, to leave
> config/bootloaders/syslinux-efi available for an EFI-only image.
> These
> two directories would be identical in terms of syslinux binary files,
> but the configurations would differ (the addon would include the
> normal
> boot/syslinux/syslinux.cfg, while the standalone version would
> contain
> the complete config).
> 
> I haven't really looked at the iso version yet (which is also not my
> primary interest, but I think it would be good to handle as well).
> 
> Happy to hear any thoughts :-)
> 
> Gr.
> 
> Matthijs

Hi,

At a quick glance it all sounds good to me, although I can't say I have
a lot of experience with syslinux.

For feature parity, I'd encourage to look into supporting Secure Boot
like the grub-efi implementation does, since we are preparing to ship
that in Debian 10. It's not much extra work on top of adding the rest
anyway.

-- 
Kind regards,
Luca Boccassi

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

Re: New install of Live Build on Buster E: debootstrap - command not found

[Luca Boccassi]

In a chroot:

# mkdir lb
# cd lb
# lb clean
[2018-11-06 16:54:35] lb clean 
P: Cleaning chroot
# lb config
[2018-11-06 16:54:38] lb config 
P: Creating config tree for a debian/stretch/amd64 system
P: Symlinking hooks...
# lb build
[2018-11-06 16:54:40] lb build 
P: live-build 1:20180925
P: Building config tree for a debian/stretch/amd64 system
[2018-11-06 16:54:40] lb bootstrap 
P: Setting up cleanup function
[2018-11-06 16:54:40] lb bootstrap_cache restore
P: Restoring bootstrap stage from cache...
[2018-11-06 16:54:40] lb bootstrap_debootstrap 
P: Begin bootstrapping system...
P: If the following stage fails, the most likely cause of the problem
is with your mirror configuration or a caching proxy.
P: Running debootstrap (download-only)... 
I: Retrieving InRelease 
I: Retrieving Release 
I: Retrieving Release.gpg 
I: Checking Release signature
I: Valid Release signature (key id
067E3C456BAE240ACEE88F6FEF0F382A1A7B6500)
I: Retrieving Packages 
I: Validating Packages 
...


Are you sure you've got debootstrap installed? Can you run it manually?

On Tue, 2018-11-06 at 10:18 +1100, Michael . wrote:
> Ok I thought I'd go through the process again, without reinstalling
> the OS itself, and this is the outcome. Everything done via command
> line instead of creating the folders via the file manager.
> 
> michael@michael-desktop:~$ cat /etc/debian_version
> buster/sid
> michael@michael-desktop:~$ mkdir LiveBuild
> michael@michael-desktop:~$ cd LiveBuild
> michael@michael-desktop:~/LiveBuild$ mkdir x86-64
> michael@michael-desktop:~/LiveBuild$ cd x86-64
> michael@michael-desktop:~/LiveBuild/x86-64$ su
> Password:
> root@michael-desktop:/home/michael/LiveBuild/x86-64# lb clean
> [2018-11-06 10:12:57] lb clean
> P: Cleaning chroot
> root@michael-desktop:/home/michael/LiveBuild/x86-64# lb config
> [2018-11-06 10:13:03] lb config
> P: Creating config tree for a debian/stretch/amd64 system
> P: Symlinking hooks...
> root@michael-desktop:/home/michael/LiveBuild/x86-64# lb build
> [2018-11-06 10:13:12] lb build
> P: live-build 1:20180925
> P: Building config tree for a debian/stretch/amd64 system
> [2018-11-06 10:13:12] lb bootstrap
> P: Setting up cleanup function
> [2018-11-06 10:13:12] lb bootstrap_cache restore
> P: Restoring bootstrap stage from cache...
> [2018-11-06 10:13:12] lb bootstrap_debootstrap
> E: debootstrap - command not found
> I: debootstrap can be obtained from
> http://ftp.debian.org/debian/pool/main/d/debootstrap/
> I: On Debian based systems, debootstrap can be installed with 'apt-
> get
> install debootstrap'.
> P: Begin unmounting filesystems...
> P: Saving caches...
> /usr/lib/live/build/bootstrap: 35: /usr/lib/live/build/bootstrap:
> chroot: not found
> root@michael-desktop:/home/michael/LiveBuild/x86-64#
> 
> Totally new folders, totally new config created by Live Build itself.
> My system is Buster but Live Build is reverting to Stretch. I believe
> this is what is causing the problem.
> 
> 
> On 06/11/2018, Michael .  wrote:
> > Thank you for your reply Luca, now I know it should be working.
> > As I said in my original message it was a totally new install and
> > everything was new. I purged the system of live-* packages and
> > reinstalled them only to have the problem again. I have done the
> > same
> > thing this morning and still get the same issue. I will continue to
> > work on it now I know it should be working and when I find what the
> > issue is I will report back.
> > Cheers.
> > Michael.
> > 
> > On 06/11/2018, Luca Boccassi  wrote:
> > > Just tried on a sid chroot, it seems to work just fine, so I'd
> > > suggest
> > > to check your configuration:
> > > 
> > > # lb clean
> > > [2018-11-05 22:29:13] lb clean
> > > P: Executing auto/clean script.
> > > [2018-11-05 22:29:13] lb clean noauto
> > > P: Cleaning chroot
> > > # lb config
> > > [2018-11-05 22:29:15] lb config
> > > P: Executing auto/config script.
> > > [2018-11-05 22:29:15] lb config noauto --apt apt --apt-recommends 
> > > false
> > > --apt-indices false --apt-source-archives false --apt-options --
> > > yes -o
> > > Acquire::Check-Valid-Until=false --bootappend-live boot=live
> > > components
> > > splash username=root console=tty0 console=ttyS0 --bootappend-
> > > live-
> > > failsafe boot=live components username=root debug live-boot.debug
> > > memtest noapic noapm nodma nomce nolapic nomodeset nosmp nosplash
> > > vga=normal console=tty0 console=ttyS0 --bootloaders
> > > syslinux,grub-efi
> > > --cache-indices false --checksums md5 sha256 --chroot-filesystem
> > > squashfs -

Re: New install of Live Build on Buster E: debootstrap - command not found

[Luca Boccassi]

or use on Buster yet? (because it creates
> this output "P: Updating config tree for a debian/stretch/amd64
> system"
> 2. Is there a clash with Live-build and debootstrap somewhere making
> live-build not "see" debootstrap even though it is installed?
> 
> > From memory live-build used to detect the version it was installed
> > on
> 
> and build an iso based on that unless it had been told to do
> something
> different in the auto/config file. This one is reverting back to
> stretch even though it is installed on a buster system.
> 
> Cheers.
> Michael.
> 
-- 
Kind regards,
Luca Boccassi

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

Re: Unmet dependency with --backports=true on Debian stable

[Luca Boccassi]

On Mon, 2018-11-05 at 01:00 +0100, Thierry wrote:
> Hi,
> 
> a regression appeared recently in live-build in stretch: if i enable
> "--backports=true" in lb_config, i can not build the live anymore,
> since
> i got the following error:
> 
> > The following packages have unmet dependencies:
> >   network-manager-config-connectivity-debian : Depends: network-
> > manager (>= 1.14.4-2~bpo9+1) but 1.6.2-3 is to be installed
> 
> Surprisingly, it seems that nothing depends on
> network-manager-config-connectivity-debian as i got (from my own
> computer running stretch as well and with backports enabled):
> 
> > $ apt-cache rdepends network-manager-config-connectivity-debian
> > network-manager-config-connectivity-debian
> > Reverse Depends:
> 
> So, my questions are: what triggers the installation of
> network-manager-config-connectivity-debian in live-build, and how to
> fix
> the issue ?
> 
> Best regards,
> Thierry

Hi,

What configuration are you building with? I just tried a build with --
backports=true and it worked just fine.

-- 
Kind regards,
Luca Boccassi

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

Re: Dead links throughout the packages and manual

[Luca Boccassi]

No idea sorry, maybe someone else can help.

On Thu, 2018-08-09 at 12:39 +0200, Moritz Schlarb wrote:
> Hi Luca,
> 
> thanks for your quick response - do you happen to know what
> could/should
> be done about the previous Project/Team page at the root of
> http://debian-live.alioth.debian.org/ or live.debian.net?
> 
> Other dead URLs are:
> - http://debian-live.alioth.debian.org/project/legal/
> - http://debian-live.alioth.debian.org/cdimage/release/current/
> - http://debian-live.alioth.debian.org/build/
> - http://debian-live.alioth.debian.org/debian/
> 
> Some content might still be found at https://github.com/debian-live..
> .
> 
> On 09.08.2018 12:12, Luca Boccassi wrote:
> > On Thu, 2018-08-09 at 11:54 +0200, Moritz Schlarb wrote:
> > > Hi everyone,
> > > 
> > > while searching for all kinds of documentation on the live-*
> > > ecosystem,
> > > I found many, many dead links - especially ones to live-
> > > systems.org,
> > > to
> > > live.debian.net and to the old Alioth project page.
> > > 
> > > I have opened a merge request on Salsa to fix some of the obvious
> > > URLs
> > > in the english version of the manual, but it would be great if
> > > someone
> > > with internal knowledge about the (old) Project pages could check
> > > all
> > > URLs and update or remove them...
> > > 
> > > Thanks,
> > 
> > Thanks, the migration was done quickly and crudely as Alioth was
> > going
> > away, I'm sure there's more broken stuff, if you find it please
> > open
> > more PRs.
> > 
> 
> 

-- 
Kind regards,
Luca Boccassi

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

Re: Dead links throughout the packages and manual

[Luca Boccassi]

On Thu, 2018-08-09 at 11:54 +0200, Moritz Schlarb wrote:
> Hi everyone,
> 
> while searching for all kinds of documentation on the live-*
> ecosystem,
> I found many, many dead links - especially ones to live-systems.org,
> to
> live.debian.net and to the old Alioth project page.
> 
> I have opened a merge request on Salsa to fix some of the obvious
> URLs
> in the english version of the manual, but it would be great if
> someone
> with internal knowledge about the (old) Project pages could check all
> URLs and update or remove them...
> 
> Thanks,

Thanks, the migration was done quickly and crudely as Alioth was going
away, I'm sure there's more broken stuff, if you find it please open
more PRs.

-- 
Kind regards,
Luca Boccassi

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

Bug#902992: live-build broken due subversion recommends

[Luca Boccassi]

Control: severity -1 minor

On Fri, 2018-07-06 at 08:59 -0400, PICCORO McKAY Lenz wrote:
> pufff you dont understand! i called with "--apt-recommends false"
> Lenz McKAY Gerardo (PICCORO)
> http://qgqlochekone.blogspot.com

Then the problem is not with "recommends", given they are not
installed.

What is _exactly_ the problem, and how do you reproduce it? Are you
sure you didn't set conflicting dependencies?

> 2018-07-05 8:00 GMT-04:00 Luca Boccassi :
> > On Wed, 4 Jul 2018 12:04:54 -0400 PICCORO McKAY Lenz  > gmai
> > l.com> wrote:
> > > Package: live-build
> > > Version: 1:20171207
> > > Severity: grave
> > > 
> > > we need a mechanish to avoid bad or abuse of recommends in apt,
> > > this
> > > problem avoit the automatization of the process
> > > 
> > > if we list the package subversion-tools, that recomends exim4
> > > over
> > 
> > any
> > > other, take preference to a specific package
> > > 
> > > root@pc-desk-w32:/vnx/osposos/debianlive8# aptitude why exim4
> > > i   subversion-tools Recomienda exim4 | mail-transport-agent
> > > 
> > > so then process end with this:
> > > 
> > > The following packages have unmet dependencies:
> > >  courier-mta : Conflicts: mail-transport-agent
> > >  exim4-config : Conflicts: courier-mta but 0.76.3-5 is to be
> > 
> > installed
> > >  exim4-daemon-light : Conflicts: mail-transport-agent
> > > 
> > > and lb build fails, with a only solution to make interactive
> > > shell
> > 
> > and
> > > avoiting automatization of the process
> > > 
> > > we need the mechanish due we cannot track all packages that abuse
> > > or
> > > are bad mantained due policy violations!
> > > 
> > > Lenz McKAY Gerardo (PICCORO)
> > > http://qgqlochekone.blogspot.com
> > 
> > There's already an option, call lb config with "--apt-recommends
> > false"
> > and recommends will not be installed.
> > 
> > --
> > Kind regards,
> > Luca Boccassi
> 
> 

-- 
Kind regards,
Luca Boccassi

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

Bug#902992: live-build broken due subversion recommends

[Luca Boccassi]

On Wed, 4 Jul 2018 12:04:54 -0400 PICCORO McKAY Lenz  wrote:
> Package: live-build
> Version: 1:20171207
> Severity: grave
> 
> we need a mechanish to avoid bad or abuse of recommends in apt, this
> problem avoit the automatization of the process
> 
> if we list the package subversion-tools, that recomends exim4 over
any
> other, take preference to a specific package
> 
> root@pc-desk-w32:/vnx/osposos/debianlive8# aptitude why exim4
> i   subversion-tools Recomienda exim4 | mail-transport-agent
> 
> so then process end with this:
> 
> The following packages have unmet dependencies:
>  courier-mta : Conflicts: mail-transport-agent
>  exim4-config : Conflicts: courier-mta but 0.76.3-5 is to be
installed
>  exim4-daemon-light : Conflicts: mail-transport-agent
> 
> and lb build fails, with a only solution to make interactive shell
and
> avoiting automatization of the process
> 
> we need the mechanish due we cannot track all packages that abuse or
> are bad mantained due policy violations!
> 
> Lenz McKAY Gerardo (PICCORO)
> http://qgqlochekone.blogspot.com

There's already an option, call lb config with "--apt-recommends false"
and recommends will not be installed.

-- 
Kind regards,
Luca Boccassi

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

Bug#900688: live-tools: Needs to be adjusted to live-boot's new mountpoints

[Luca Boccassi]

On Sun, 2018-06-03 at 15:56 +0200, intrig...@debian.org wrote:
> Package: live-tools
> Version: 1:20171207
> Severity: normal
> X-Debbugs-Cc: benjamin.dr...@profitbricks.com
> User: tails-...@boum.org
> Usertags: for-buster
> 
> Hi!
> 
> since 1:20180328 live-boot uses /run/live instead of /lib/live/mount
> (#886328). But at least 5 scripts shipped in live-tools still use the
> old paths. I did not test what's the exact impact yet but I suspect
> it breaks some of live-tools functionality.

They should indeed be updated, but note that we ship a mount point to
provide backward-compatibility for Buster, so nothing should be broken
for the moment.

-- 
Kind regards,
Luca Boccassi

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

Re: grub efi package on live-build

[Luca Boccassi]

On Thu, 2018-05-03 at 15:17 -0300, Fernando Toledo wrote:
> I'm generate a iso image with live-build,
> which grub package must be add to packages list, to get grub-pc +
> grub-efi in the binary part.
> 
> I try to install on a efi machine and end of debian installer (at
> bootloader install stage) fail wich "Cannot install grub-efi"
> i search in the binary pool and the package do not exist.
> 
> thanks!

grub-efi-amd64-bin
grub-efi-ia32-bin
grub-pc-bin

-- 
Kind regards,
Luca Boccassi

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

Re: Booting squashfs from local filesystem

[Luca Boccassi]

On Tue, 2018-04-24 at 18:01 +0200, Paul Hänsch wrote:
> Hello there,
> 
> I have set up an infrastructure that boots squashfs from the network
> via nbd.
> Now I am trying to integrate notebooks into the same infrastructure.
> 
> The notebooks should boot the same image as the desktop computers,
> but since
> they cannot be relied on to be on the network all the time, what I
> intend to
> do is:
> 
>  * Set up a small ext3 partition on the notebook
>  * copy the squashfs onto the ext3 partition
>  * set up extlinux on the notebook
>  * load the squashfs locally, instead of loading from nbd
> 
> I am confident that I can build a squashfs in a way, that it works in
> both
> setups. I am also at a point where I have installed the partition and
> got
> extlinux working. I am an experienced user of pxelinux/syslinux
> suite. The
> initramfs is built using the live-boot package. Squashfs-support is
> also
> enabled.
> 
> The problem: I cannot figure out the right boot command line, to load
> the
> squashfs root image from an ext3 partition.
> Digging through the boot scripts I have come up with:
> 
> (from /proc/cmdline)
> BOOT_IMAGE=vmlinuz initrd=initrd.img boot=live \
>   plainroot fromiso=/dev/sda1 root=stretch.squash
> 
> or
> 
> BOOT_IMAGE=vmlinuz initrd=initrd.img boot=live \
>   plainroot bootfrom=/dev/sda1 root=stretch.squash
> 
> however when I am dropped off in the initramfs shell, I find
> /live/medium to
> be empty and /dev/sda1 not mounted. I can mount the fs manually. I
> can also
> see a successful mount attempt scrolling through during the boot, but
> in the
> end the script does not find the squash image residing in the fs
> root.
> 
> Before I go crazy over the entangled variables, functions, and
> branches in
> /var/live/boot, is anyone on this list familiar enough with the
> system to tell
> me what would be the correct boot line here?
> 
> Thank you very much.

Have you tried findiso=/fs/path/to/stretch.squash ?

-- 
Kind regards,
Luca Boccassi

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

Re: Boot .iso with GRUB2

[Luca Boccassi]

On Thu, 2018-04-05 at 10:01 +0200, Narcis Garcia wrote:
> Has anybody reached to boot a Debian ISO image?
> For example, installing GRUB2 on a USB stick with .iso files.
> 
> I've tried this with no luck*:*
> 
> submenu "debian-live-9.4.0-amd64-gnome.iso" {
>     iso_path="/debian-live-9.4.0-amd64-gnome.iso"
>     search --set=root --file $iso_path
>     loopback --delete loop
>     loopback loop $iso_path
>     root=(loop)
>     menuentry "Debian GNU/Linux Live (kernel 4.9.0-6-amd64) [grub]" {
>   linux  /live/vmlinuz-4.9.0-6-amd64 boot=live components
> "${loopback}"
>   initrd /live/initrd.img-4.9.0-6-amd64
>     }
> }
> 
> Results in*:*
> 
> [...] ... mounted filesystem...
> [...] random: crng init done
> Busybox ...
> (initramfs) Unable to find a medium containing a live file system

How are you installing the ISO on the USB stick? Did you build the
image yourself, if not where is it from?

-- 
Kind regards,
Luca Boccassi

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

Accepted live-build 1:20180328 (source) into unstable

[Luca Boccassi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Wed, 28 Mar 2018 20:20:46 +0100
Source: live-build
Binary: live-build
Architecture: source
Version: 1:20180328
Distribution: unstable
Urgency: low
Maintainer: Debian Live <debian-live@lists.debian.org>
Changed-By: Luca Boccassi <bl...@debian.org>
Description:
 live-build - Live System Build Components
Closes: 821084 847919 867539 884585 884588 884591 885692 887278 891206 892406
Changes:
 live-build (1:20180328) unstable; urgency=low
 .
   [ Raphaël Hertzog ]
   * Restore i386/amd64 autodetection in grub after rename of
 i386 kernel from -486 to -686. Closes: #884585
 Thanks to Adrian Gibanel Lopez for the patch.
   * Fix handling of multiple kernels in binary_loopback_cfg.
 Closes: #884588 Thanks to Adrian Gibanel Lopez for the patch.
   * Rework failsafe entries in grub configuration to be more
 consistent with the i386/amd64 autodetection entries.
 Closes: #884591 Thanks to Adrian Gibanel Lopez for the patch.
   * Add e2fsprogs to Suggests along with mtd-utils, parted. Closes: #887278
   * Fix Check_package invocation in binary_hdd for ntfs-3g
 (/sbin/mkfs.nfts -> /sbin/mkfs.ntfs)
   * Run mksquashfs with nice -n 19 to not overload the system.
 Thanks to Ronny Standtke for the patch. (Closes: #867539)
 .
   [ Luca Boccassi ]
   * Fix build with local offline mirrors (Closes: #891206)
 .
   [ Rohan Garg ]
   * Simplify bootstrapping of foreign architectures with qemu-debootstrap
 (Closes: #847919)
 .
   [ Steven Shiau ]
   * Add grub-based UEFI boot support for ARM64 (Closes: #885692)
 .
   [ Luca Boccassi ]
   * UEFI: add minimal grub.cfg to fat32 partition (Closes: #892406)
   * UEFI: add support for Secure Boot on amd64 and arm64 (Closes: #821084)
   * UEFI: use uppercase EFI directory name for Tianocore
   * Add NEWS file to warn users about change of live-boot mount paths
   * Add options to build ONIE images
   * Add Acquire::AllowInsecureRepositories to fix apt-secure in sid
   * Use HTTPS in debian/copyright (policy 4.0.0).
   * Bump Standards-Version to 4.1.3.
   * Add myself to Uploaders.
Checksums-Sha1:
 2bb91698935a037d60f0a29481fab9d0f23c1715 1387 live-build_20180328.dsc
 46bc43789d84dda51ed03fa059d142c0f0c7fadb 361620 live-build_20180328.tar.xz
 806775a55de3524ba3d671db826f001deaea7c00 6195 
live-build_20180328_source.buildinfo
Checksums-Sha256:
 1812e471b280f5b36daa3d2f07771a31ce62298857f0bfdf6f1548aa254d6f60 1387 
live-build_20180328.dsc
 478633fba556169327836bc10c4dfae2f6b27f0291aa1b9fc3e25e05b4e6c77a 361620 
live-build_20180328.tar.xz
 f5417efb2bf5fd04c5bccd2c9c7d923284dcb090415b3bc40c81fe53d838bf7b 6195 
live-build_20180328_source.buildinfo
Files:
 79278be4a1d1ec649c27e281da782e2f 1387 misc optional live-build_20180328.dsc
 5cec1435c31ae22664d6e7a8a814d4bc 361620 misc optional 
live-build_20180328.tar.xz
 5a49e94985ce25005db7dbf4b4765865 6195 misc optional 
live-build_20180328_source.buildinfo

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEE6g0RLAGYhL9yp9G8SylmgFB4UWIFAlq765ARHGJsdWNhQGRl
Ymlhbi5vcmcACgkQSylmgFB4UWL6mwf+OiR/mBMjfYJRlfVqp/hi18r4l3rk8HH/
EKAgx4k/367RfmeKziT14Kbc7AdvYLmsDit83YCbS+SWrgIHlbd8Gnl6OsJ7Cdnw
/N0qnmAEdjDEHYXGyoJZ/+SiZ2WGf7KbN7FJ8icTNQPcaHFm7CCibyhA5v7bNjv1
EVsk+NTPRVBL4OfHzmN8BJgPraI9K4BRfrkSPNSU8uRxynjSzsXyePqZOi+4kT68
RHPdrWlKRSHdOK40ISZ4slMt+o1CcfuQIbntFtXAjEE8E8ZTEydzGAVSXE33B6lI
PuoFHhtSlq39PGviaoLUlC9JNAN7Ac55atQtQcJIJNmel6myoyUZrg==
=CNnt
-END PGP SIGNATURE-

Accepted live-boot 1:20180328 (source) into unstable

[Luca Boccassi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Wed, 28 Mar 2018 20:07:39 +0100
Source: live-boot
Binary: live-boot live-boot-doc live-boot-initramfs-tools
Architecture: source
Version: 1:20180328
Distribution: unstable
Urgency: low
Maintainer: Live Systems Maintainers <debian-live@lists.debian.org>
Changed-By: Luca Boccassi <bl...@debian.org>
Description:
 live-boot  - Live System Boot Components
 live-boot-doc - Live System Boot Components (documentation)
 live-boot-initramfs-tools - Live System Boot Components (initramfs-tools 
backend)
Closes: 856482 868559 86 884355 884886 885453 885455 885466 886328 886337 
892772
Changes:
 live-boot (1:20180328) unstable; urgency=low
 .
   [ Raphaël Hertzog ]
   * Fix read-only persistence mode with overlayfs. Closes: #86
 Thanks to Ronny Standtke <ronny.stand...@fhnw.ch> for the patch.
   * Add a small warning in the long description that the
 package must not be installed on a regular system, but only in
 a live image. Closes: #884886
   * Strip comments from checksums files passed to "shaXsum -c"
 Thanks to Andreas Heinlein for the report (Closes: #856482)
 .
   [ Steve McIntyre ]
   * Repo moved to salsa
 .
   [ Benjamin Drung ]
   * Don't replace busybox's wget by the true wget.
 It was likely done for https support but since buster the busybox
 provided wget has https support too. We save a lot of space by
 doing so (8 Mb). (Closes: #885455)
   * Avoid double slashes in some paths (Closes: #885453)
   * Support setting upperdir tmpfs size with overlay-size boot parameter
 (Closes: #885466)
   * Simplify mount point handling by using /run/live instead of /lib/live/mount
 (Closes: #886328)
   * Add configuration variables to build a stripped down initrd
 (Closes: #886337)
 .
   [ Daniel Reichelt ]
   * Use klibc's mount again for fuse mounts (Closes: #868559)
 .
   [ raizo62 ]
   * Update DNSFILE even if DNSFILE contains only commented or empty lines
 .
   [ Sameer Agrawal ]
   * Fix ifconfig parsing (Closes: #892772)
 .
   [ Chas Williams ]
   * Add back persistence fsck option
   * Remove workaround for ipconfig issues
 .
   [ Benjamin Drung ]
   * Remove sourcing /scripts/functions in components
   * Support live-{top,premount,bottom} hooks (Closes: #884355)
 .
   [ Luca Boccassi ]
   * Add backward compatibility rbind mount /lib/live/mount -> /run/live.
 The paths used in the current released versions of live-boot are a
 form of public API, and existing applications and scripts might rely
 on them. Do a recursive bind mount of the new path on the previous one
 so that they do not break on upgrade (see #886328).
 This backward-compatible mount point will be deprecated and removed
 before the Bullseye (Debian 11) release. Users are recommended to start
 migrating to the new /run/live path as soon as possible.
 .
   [ Erik Ziegenbalg ]
   * fromiso: add support for local ISO (ONIE)
 .
   [ Luca Boccassi ]
   * Clarify FROMISO documentation in live-boot manpage
   * Use HTTPS in debian/copyright (policy 4.0.0).
   * Remove dead link to live-systems.org from debian/copyright.
   * Bump Standards-Version to 4.1.3, no changes.
   * Add myself to Uploaders.
Checksums-Sha1:
 3f5b3c5a5ad40b6a5d59b5595174ea234c5c0178 1548 live-boot_20180328.dsc
 c7251bc1398cea57cc3ce08759a8cfd08c87d602 101172 live-boot_20180328.tar.xz
 4d9ab1a3a5a8ce3cfeab09ea4acd0f3d7c2fb62a 6110 
live-boot_20180328_source.buildinfo
Checksums-Sha256:
 a94801aa0bc428bf21c57ba382ab8e5a6e8a5128275ff925b389d65fc651a49c 1548 
live-boot_20180328.dsc
 58acb3a961c40707350f7cd61e58f255d330f6dfdad9022b2962e4335a29c469 101172 
live-boot_20180328.tar.xz
 232fa4dfc580417be8f267e4b1abe7f1046190c638ad1941ee6ba17cf1b2cfa4 6110 
live-boot_20180328_source.buildinfo
Files:
 50529a169e238d221981166260b34fbb 1548 misc optional live-boot_20180328.dsc
 43184c037c144665bd3e96710850c0a5 101172 misc optional live-boot_20180328.tar.xz
 a1adbcdd7e789312055c0498aedc5fa1 6110 misc optional 
live-boot_20180328_source.buildinfo

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEE6g0RLAGYhL9yp9G8SylmgFB4UWIFAlq76koRHGJsdWNhQGRl
Ymlhbi5vcmcACgkQSylmgFB4UWIwVQgAmIk7GLLWbSGkyCTfJUSNTEpLgHPY6SJv
0TlDP69ndXMNl8FxKBG9pUpByZ4sCmEtjkktV2s3pIHyG2YuhXeLXiZOo0BYUA/t
r10jnYDTfRn3qxHKtluEJgX2JIU4S1fEa5sWQ2TV9rTsihV8vpl4KvryQZmRW/Qu
OsB4j4N4tp0WYiEl8ZJFJdnXvYZhsq4a7XUESOkAqaUkvUbqwPVVuatIe/2m6c1P
u7Kj5qhIyQOM2oOVvG4YZnyJl5gKD6XcfZEmBBx37o0IXu6ZCRlju23uE8wus9sZ
dGJfSCZblItwRMfgC1IM3EfFYlV9rqdbQyQM/26eF6eC0bKuV96sjA==
=6rI8
-END PGP SIGNATURE-

Re: Adding support for ONIE to Debian Live

[Luca Boccassi]

On Fri, 2018-03-23 at 11:44 +, Luca Boccassi wrote:
> On Fri, 2018-03-23 at 08:27 +0800, Steven Shiau wrote:
> > On 3/20/2018 AM 06:14, Luca Boccassi wrote:
> > > I hope this can be useful for others
> > 
> > Yes, exactly! This is great! We recently need this feature and you
> > have 
> > made it and share that. Cool!
> > BTW, did you have the same experience about booting ARM32 ONIE
> > switch? 
> > Some of the switches listed on the ONIE website are ARM32 CPU:
> > http://www.opencompute.org/wiki/Networking/ONIE/HW_Status
> > We submitted a patch to Debian live ARM64 last month, but did not
> > go 
> > further to make that for ARM32.
> > Besides, did you have any experience to boot the Debian live system
> > from 
> > USB of ONIE switch? If so, could you please also share the
> > experience.
> > Thank you very much.
> > 
> > Steven
> 
> Glad it can be helpful :-)
> 
> It was Erik who worked with the hardware, I'll ask him if he can
> comment - I just used the VM as mentioned in the first email to port
> and test.
> 
> We have not done anything with ARM32 so I'm afraid I can't provide
> info
> on that.
> 
> The diffset that was merged has one x86-specific bit when repacking
> the
> initrd (parameters passed to xz), so to use it on ARM you'll probably
> want to detect at build time and parameterise them. Please send a PR
> once you have it working!
> 
> Specifically this line:
> 
> find . | cpio -o -H newc | xz --check=crc32 --x86 --lzma2=dict=512KiB 
> > ${WORKDIR}/initrd.img
> 
> Also you might need to support other compression formats than xz.

Actually I realised that hard-coding those parameters at build time was
wrong, so I went ahead and fixed it myself:

https://salsa.debian.org/live-team/live-build/merge_requests/8

With those changes it should work on other architectures out of the
box!

-- 
Kind regards,
Luca Boccassi

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

Re: Adding support for ONIE to Debian Live

[Luca Boccassi]

On Fri, 2018-03-23 at 08:27 +0800, Steven Shiau wrote:
> On 3/20/2018 AM 06:14, Luca Boccassi wrote:
> > I hope this can be useful for others
> 
> Yes, exactly! This is great! We recently need this feature and you
> have 
> made it and share that. Cool!
> BTW, did you have the same experience about booting ARM32 ONIE
> switch? 
> Some of the switches listed on the ONIE website are ARM32 CPU:
> http://www.opencompute.org/wiki/Networking/ONIE/HW_Status
> We submitted a patch to Debian live ARM64 last month, but did not go 
> further to make that for ARM32.
> Besides, did you have any experience to boot the Debian live system
> from 
> USB of ONIE switch? If so, could you please also share the
> experience.
> Thank you very much.
> 
> Steven

Glad it can be helpful :-)

It was Erik who worked with the hardware, I'll ask him if he can
comment - I just used the VM as mentioned in the first email to port
and test.

We have not done anything with ARM32 so I'm afraid I can't provide info
on that.

The diffset that was merged has one x86-specific bit when repacking the
initrd (parameters passed to xz), so to use it on ARM you'll probably
want to detect at build time and parameterise them. Please send a PR
once you have it working!

Specifically this line:

find . | cpio -o -H newc | xz --check=crc32 --x86 --lzma2=dict=512KiB > 
${WORKDIR}/initrd.img

Also you might need to support other compression formats than xz.

-- 
Kind regards,
Luca Boccassi

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

Adding support for ONIE to Debian Live

[Luca Boccassi]

Hi all,

I've got a feature that we developed at $work to contribute. Most of
the work was done by my colleague at Vyatta, Erik (CC'ed). I've rebased
and refreshed and re-tested the patches.

The feature is native support for the ONIE environment.

Open Network Install Environment is an open image format used by
networking vendor to ship a standardised image for networking white box
switches that can be deployed in an automated fashion and so on.

ONIE hardware takes this image at boot and the embedded script will
chain load into the final environment via kexec. We can support Debian
and derivatives on such systems by packing an ISO which then gets
unpacked, kexec'ed and live-booted as described.

A base ONIE system can be tested in QEMU by building a VM following
these instrunctions:

https://github.com/opencomputeproject/onie/blob/master/machine/kvm_x86_64/INSTALL

Once built, boot onie-recovery-x86_64-kvm_x86_64-r0.iso in QEMU/libvirt
and on the console there will be the terminal prompt. Check the IP
assigned by libvirt and then scp the live image (ssh access is enabled
as root without password...). Then the .bin can be booted with:
  ONIE-RECOVERY:/ # onie-nos-install /tmp/live.hybrid.iso-ONIE.bin

I hope this can be useful for others. For example I know Cumulus Linux
is Debian-based, and they are one of the main sponsors behind this
project.

The major change is in live-build:

https://salsa.debian.org/live-team/live-build/merge_requests/4

A new optional binary script is added. It is completely self-contained, 
apart from the usual boilerplate to add the option.

A small fix is also necessary in live-boot, to make it happy to boot a
local ISO:

https://salsa.debian.org/live-team/live-boot/merge_requests/8

I am of course happy to maintain the new binary_onie script going
forward with any future bug fix.

-- 
Kind regards,
Luca Boccassi

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

Bug#886328: live-boot: Please use /run/live instead of /lib/live/mount

[Luca Boccassi]

On Tue, 2018-03-13 at 15:05 +0100, Raphael Hertzog wrote:
> Hi,
> 
> On Tue, 13 Mar 2018, Luca Boccassi wrote:
> > > > Or maybe have a backward-compatible symlinks?
> > > 
> > > This seems entirely reasonable. Can you work on this?
> > 
> > Yes no problem, I'll give it a shot and send a PR for review before
> > the
> > end of the week.
> 
> Great.
> 
> > > BTW, given your vested interested in the various live tools,
> > > would
> > > you like to join the maintenance team?
> > 
> > Certainly, I'm more than happy to help! We use the live tools in
> > our
> > derivative (Vyatta) so I can dedicate time at work to it.
> 
> I have added you to the live-team group on salsa as master. Welcome
> on
> board!
> 
> Use your best judgment when merging someone's else work and ask for
> review
> when you have doubts about your own work. And tested code is always
> better
> ;-)
> 
> Cheers,

Great, will do, thank you very much!

-- 
Kind regards,
Luca Boccassi

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

Bug#886328: live-boot: Please use /run/live instead of /lib/live/mount

[Luca Boccassi]

On Tue, 2018-03-13 at 10:49 +0100, Raphael Hertzog wrote:
> Hi,
> 
> On Mon, 12 Mar 2018, Luca Boccassi wrote:
> > That is certainly the case for myself at $work - we have a lot of
> > scripts to deal with installing images, I've tested it,
> > and
> > they all break due to this change. In my case it's a derivative
> > with
> > proprietary bits, so I understand if that is treated as less
> > important.
> > But would it be possible to make this change optional, please?
> 
> Making this change optional would not be logical. It would complexify
> the
> code to support two different layouts when the goal was to simplify
> it.

Ok, makes sense.

> > Or maybe have a backward-compatible symlinks?
> 
> This seems entirely reasonable. Can you work on this?

Yes no problem, I'll give it a shot and send a PR for review before the
end of the week.

> BTW, given your vested interested in the various live tools, would
> you
> like to join the maintenance team?
> 
> Myself I am working on live tools only because I need them for the
> derivative I work on (Kali) and it would be nice to share the
> workload
> with other people.

Certainly, I'm more than happy to help! We use the live tools in our
derivative (Vyatta) so I can dedicate time at work to it.

-- 
Kind regards,
Luca Boccassi

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

Bug#892772: live-boot: do_netsetup fails to detect ip address with ifconfig

[Luca Boccassi]

Package: live-boot
Version: 1:20170213
Severity: normal
Tags: patch

Dear Maintainer,

The do_netsetup function in components/9990-networking.sh parses
ifconfig to check if an IP address has been assigned. But the pattern
matching does not work anymore on Stretch, so it always fails.

I have opened a Merge Request on Salsa [1] with a fix from Sameer, a
colleague of mine at $work.

Thank you!

-- 
Kind regards,
Luca Boccassi

[1] https://salsa.debian.org/live-team/live-boot/merge_requests/3

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

Bug#892406: live-build: UEFI boot fails on SuperMicro dev board with AMI bios

[Luca Boccassi]

On Sun, 2018-03-11 at 19:05 +0100, Thomas Schmitt wrote:
> Hi,
> 
> i managed to build a live-build ISO.
> Its /boot/grub/efi.img contains
>   /efi/boot/bootia32.efi
>   /efi/boot/bootx64.efi
> which both show by "strings" the embedded configuration with
>   search --file --set=root /.disk/info
> The ISO 9660 filesystem contains a file
>   /.disk/info
> 
> So the riddle is why this does not get into effect with that
> particular
> EFI implementation, and why a grub.cfg in the EFI System Partition
> solves the problem.
> 
> Does a debian-cd ISO boot properly on that EFI ?
> E.g.
>   https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-9.
> 4.0-amd64-netinst.iso
> 
> 
> I meanwhile found out that the efi.img of debian-cd stems from
> debian-cd_info.tar.gz created by
>    https://anonscm.debian.org/git/d-i/debian-installer.git/tree/build
> /util/efi-image
> and that its grub-mkimage run needs no -c option because it has an -m
> option
> with a grub.cfg file in the "memdisk" tarball. It's quite the same
> tarball
> as created by live-build in
>    https://salsa.debian.org/bluca/live-build/blob/master/scripts/buil
> d/efi-image
> 
> So it might be that debian-cd is affected as well.
> If not, then differences between both ISOs might give hints about the
> cause.
> 
> 
> Have a nice day :)
> 
> Thomas

I am not sure why that EFI firmware is so picky - I'll try to find time
and test a vanilla Debian image.

Nevertheless, adding that grub.cfg file is necessary when using Secure
Boot - the monolithic grub EFI image does not contain that string. It
is built by this script in the grub2 repository:

https://salsa.debian.org/grub-team/grub/blob/master/debian/build-efi-images

Using that image is necessary with Secure Boot as that's what gets
signed. Ubuntu has the same workaround in place.

-- 
Kind regards,
Luca Boccassi

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

Bug#892406: live-build: UEFI boot fails on SuperMicro dev board with AMI bios

[Luca Boccassi]

On Fri, 2018-03-09 at 14:28 +0100, Thomas Schmitt wrote:
> Hi,
> 
> Raphael Hertzog wrote:
> > I assume that the above image has been
> > built with live-wrapper and here the bug report and the patch is
> > about
> > live-build
> 
> I silently assumed live-wrapper because my examples
>   debian-live-8.4.0-i386-standard.iso
>   debian-live-8.4.0-amd64-standard.iso
> both tell
>   Preparer Id  : LIVE-BUILD 4.0.5-1; HTTP://LIVE-
> SYSTEMS.ORG/DEVEL/LIVE-BUILD
> but bear only a single partition which marks the ISO 9660 filesystem.
> 
> 
> @Luca Boccassi:
> Is there an example ISO available which has that FAT32 partition ?
> (If it gets produced by xorriso then i need one for regression
> tests.)
> 
> What i do not understand without example is from where GRUB was
> started
> if not from an EFI System Partition with a BOOTX86.EFI, as in debian-
> cd
> ISOs.
> 
> 
> Have a nice day :)
> 
> Thomas

Hi,

Raphael is right, I am not using live-wrapper at all, only live-build.
You can build such an image with the default configuration, as grub-efi 
is enabled by default, and then if you dd it to a disk or mount it and
then mount boot/grub/efi.img you'll see that there is no grub.cfg in
there, hence this bug report.

I am not entirely sure how the UEFI implementation on this machine
works, as it is third party and closed source. I did not encounter this
issue with Tianocore which is very annoying but entirely expected with
"industry standards" :-)

-- 
Kind regards,
Luca Boccassi

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

Bug#892406: live-build: UEFI boot fails on SuperMicro dev board with AMI bios

[Luca Boccassi]

Package: live-build
Version: 1:20171207
Tags: patch
Severity: minor

Dear Maintainer,

On some UEFI implementations, like the AMI found on the SuperMicro
X10SDV-TP8F dev board, the fat32 partition will be loaded first and so
Grub will set it the root, and then drop to the console as it cannot
find any config on it.

A solution is to have a minimal grub.cfg that just finds the ISO 9660
partition with the main grub.cfg and loads it. A Merge Request with
this implementation, which has been tested on the above platform, has
been sent to Salsa. [1]

This minimal grub.cfg will also be useful for Secure Boot support,
which has been implemented in a separate commit, in the same Merge
Request.

Thanks!

-- 
Kind regards,
Luca Boccassi

[1] https://salsa.debian.org/live-team/live-build/merge_requests/3

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

Bug#891206: live-build: using local offline mirrors fails due to regression

[Luca Boccassi]

Package: live-build
Version: 1:20161202
Tags: patch
Severity: normal

Dear Maintainer,

Commit a15b5796 (#775989) [1] dropped an early exit from the
chroot_archives remove step in case the parent mirror chroot and binary
parameters are the same and unfortunately introduced a regression in an
(infrequent) corner case, as with the following live-build now fails
when the parent mirror is using a file:/ local apt repository (for
example when the build worker is offline and uses a pre-built cache of
packages).

Example config:

lb config --mirror-bootstrap "file:/pkgs" \
--mirror-chroot "file:/pkgs/" \
--mirror-binary "file:/pkgs" \
--parent-mirror-bootstrap "file:/pkgs" \
--parent-mirror-chroot "file:/pkgs/" \
--parent-mirror-binary "file:/pkgs" \
...

with /pkgs being a directory with the packages for the installation and
the apt metadata (Packages/Sources/Release).

The problem is that, with such a setup, the /pkgs directory is bind
mounted inside the chroot as an optimisation in the install step,
and umounted as one of the first actions in the remove step for
chroot_archives.

Before that fix, the script terminated immediately. But now it
progresses and at the end it tries to run apt update inside the chroot
which will fail since the repository directory has been umounted, and
thus the packages and the apt metadata are no longer available, while
still being listed in /etc/apt/sources.list.

The proposed solution is to avoid running apt update in the chroot at
the end of the chroot_archives remove step if the repository is local
and has been umounted.

A PR [2] has been opened on Salsa with the proposed fix. Please let me
know if you'd like more information or a different solution.

Thanks!

-- 
Kind regards,
Luca Boccassi

[1] 
https://salsa.debian.org/live-team/live-build/commit/a15b579652e64317fbcc0597a1ea1012fb1d3ba8
[2] https://salsa.debian.org/live-team/live-build/merge_requests/1

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