Bug#936082: grub-efi-amd64-signed: Add probe module to available modules
Package: grub-efi-amd64-bin Version: 1+2.02+dfsg1+20 Severity: wishlist Dear Maintainer, I'm trying to use Debian-signed secure boot grub binaries with Super Grub2 Disk scripts. Many of the Super Grub2 Disk scripts make use of the probe command. It makes possible to identify partition uuid given the grub partition device so that you can fed the kernel UUID boot parametre. Is it possible to add the probe module and command to the secure boot based grub (both grub-efi-amd64-signed and grub-efi-ia32-signed packages) ? Similar bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928628 and its associated commit: https://salsa.debian.org/grub-team/grub/commit/ed4a71ed6d2617e6916e7a663f9da28ee3699127 . Thank you very much! -- System Information: Debian Release: 10.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect Versions of packages grub-efi-amd64-signed depends on: ii grub-common 2.02+dfsg1-20 Versions of packages grub-efi-amd64-signed recommends: ii shim-signed 1.33+15+1533136590.3beb971-7 grub-efi-amd64-signed suggests no packages. Versions of packages grub-efi-amd64-bin depends on: ii grub-common 2.02+dfsg1-20 Versions of packages grub-efi-amd64-bin recommends: ii efibootmgr 15-1 -- no debconf information
Bug#936009: shim-unsigned:amd64 cannot be installed alongside shim-unsigned:i386
Package: shim-unsigned Version: 15+1533136590.3beb971-7 Severity: normal Dear Maintainer, I want to be able to build a live cd that has both ia32 and x64 Secure Boot UEFI support. So I need both shim-signed:amd64 and shim-signed:i386 installed. Those two packages depend on shim-unsigned:amd64 and shim-unsigned:i386 among other packages. I cannot install those unsigned packages hence neither I can install the signed ones. After adding and apt i386 architecture to an amd64 system if I run: apt-get install shim-unsigned:amd64 shim-unsigned:i386 I get this output: Reading package lists... Done Building dependency tree Reading state information... Done shim-unsigned is already the newest version (15+1533136590.3beb971-7). shim-unsigned set to manually installed. Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: shim-unsigned : Conflicts: shim-unsigned:i386 but 15+1533136590.3beb971-7 is to be installed shim-unsigned:i386 : Conflicts: shim-unsigned but 15+1533136590.3beb971-7 is to be installed E: Unable to correct problems, you have held broken packages. I would like to be able to install both packages at the same time because generated binaries do not collide between them. It would seem those packages are lacking some multi-arch declaration on the package metadata. This same problem was fixed for shim-signed on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928486 and fixed there. Associated commit to that fix: https://salsa.debian.org/efi-team/shim-signed/commit/f3393e69ed073007cda61d57c60e5c907c4faf51 . I suspect that shim-helpers-amd64-signed and shim-helpers-i386-signed packages will need a similar workaround but I'm not sure on this one. Thank you very much! -- System Information: Debian Release: 10.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect -- no debconf information
Bug#928818: pcmanfm-qt does not start as root on Debian live
Package: pcmanfm-qt Severity: important Dear Maintainer, It does not start - without a meaningful message * Expected Behavior it should start as root * Current Behavior It does not start at all as root * Possible Solution Use: lxsudo dbus-launch pcmanfm-qt instead which requires dbus-x11 package to be installed. * Steps to Reproduce (for bugs) ** Get a live ISO (siduction, manjaro, debian buster) ** Start and open a terminal ** lx(sudo) pcmanfm-qt ** lxsudo ends and no window appears * Context I want ot use pcmanfm-qt as root even on live isos - not possible Additional information * Original upstream bug https://github.com/lxqt/libfm-qt/issues/427 . * Add a menu entry to the live cds to start pcmanfm-qt as root if it does not exist yet. -- 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 pcmanfm-qt depends on: ii dbus-user-session [default-dbus-session-bus] 1.10.22-0+deb9u1 ii dbus-x11 [dbus-session-bus] 1.10.22-0+deb9u1 ii libc6 2.24-11+deb9u1 ii libfm-modules 1.2.5-1 pn libfm-qt3 ii libfm41.2.5-1 ii libglib2.0-0 2.50.3-2 ii libqt5core5a 5.7.1+dfsg-3+b1 ii libqt5dbus5 5.7.1+dfsg-3+b1 ii libqt5gui55.7.1+dfsg-3+b1 ii libqt5widgets55.7.1+dfsg-3+b1 ii libqt5x11extras5 5.7.1~20161021-2 ii libstdc++66.3.0-18 ii libxcb1 1.12-1 Versions of packages pcmanfm-qt recommends: ii breeze-icon-theme 4:5.28.0-1 ii eject 2.1.5+deb1+cvs20081104-13.2 ii gksu 2.0.2-9+b1 ii gnome-icon-theme 3.12.0-2 ii gvfs-backends 1.30.4-1 ii oxygen-icon-theme 5:5.28.0-1 pn pcmanfm-qt-l10n Versions of packages pcmanfm-qt suggests: pn cdtool
Bug#928628: grub-efi-amd64-signed: Add cpuid module to available modules
Package: grub-efi-amd64-signed Version: 1+2.02+dfsg1+16 Severity: wishlist Dear Maintainer, live-build generated grub.cfg uses grub's cpuid command when there are two or more kernel flavours. The final user thanks to the add auto option can choose either the amd64 kernel or 686 kernel in an easy manner. Is it possible to add the cpuid module and command to the secure boot based grub (both grub-efi-amd64-signed and grub-efi-ia32-signed packages) ? Thank you very much! -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (x86_64) Foreign Architectures: amd64 Kernel: Linux 4.9.0-4-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages grub-efi-amd64-signed depends on: pn grub-common Versions of packages grub-efi-amd64-signed recommends: pn shim-signed grub-efi-amd64-signed suggests no packages.
Bug#928486: shim-signed:amd64 cannot be installed alongside shim-signed:i386
Package: shim-signed Version: 1.30+15+1533136590.3beb971-5 Severity: normal Dear Maintainer, I want to be able to build a live cd that has both ia32 and x64 Secure Boot UEFI support. So I need both shim-signed:amd64 and shim-signed:i386 installed. After adding and apt amd64 architecture to an i386 system if I run: apt-get install shim-signed:amd64 shim-signed:i386 I get this output: Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: shim-signed : Conflicts: shim-signed:amd64 but 1.30+15+1533136590.3beb971-5 is to be installed shim-signed:amd64 : Depends: shim-helpers-amd64-signed:amd64 (>= 1+15+1533136590.3beb971+5) but it is not going to be installed Depends: mokutil:amd64 but it is not going to be installed Conflicts: shim-signed but 1.30+15+1533136590.3beb971-5 is to be installed E: Unable to correct problems, you have held broken packages. I would like to be able to install both packages at the same time because generated binaries do not collide between them. It would seem those packages are lacking some multi-arch declaration on the package metadata. Other similar packages which probably have the proper multi-arch declaratio might be grub-efi-amd64-bin and grub-efi-ia32-bin packages. Thank you very much! -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (x86_64) Foreign Architectures: amd64 Kernel: Linux 4.9.0-4-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, TAINT_WARN, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages shim-signed depends on: ii debconf [debconf-2.0] 1.5.70 pn grub-efi-amd64-bin pn grub2-common pn mokutil pn shim Versions of packages shim-signed recommends: pn secureboot-db shim-signed suggests no packages.
Bug#927746: debian-live: Add mokutil package
Package: debian-live Severity: wishlist Dear Maintainer, As official Debian Live images are going to be signed by MS keys that will mean that they can be booted in MS Secure Boot enabled hardware. Some people might want to be able to use mokutil binaries from their live cds to enrol new keys. -- 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)
Bug#922251: live-build: support syslinux-efi as (additional) bootloader
El 16/04/19 a las 20:17, Matthijs Kooijman escribió: > I pushed a new version with the above changes to > https://salsa.debian.org/live-team/live-build/merge_requests/19 > > Gr. > > Matthijs 7) Only default to grub-efi for iso* images (47d99222) Looks good to me. 8) Use syslinux-efi for hdd images by default (658c0e2d) Looks good to me. 9) Improve bootloader configuration checks (3e6645a2) Well, the way how defaults.sh checks if anything is valid is kind of antique. In my opinnion binary_syslinux, binary_syslinux-efi, binary_grub-pc and so on... should be able to be sourced and use sort of can_i_boot function where you input architectures, filesystem and if the bootloader is the first bootloader or not. Then the binary_syslinux (or whatever) replies. Anyways... that would be another improvement towards moving live-build into a more Object-Oriented approach. I haven't checked every possible combination you put there I guess it's ok. So, once again looks good to me. adrian15 -- Support free software. Donate to Super Grub Disk. Apoya el software libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
Bug#922251: live-build: support syslinux-efi as (additional) bootloader
ders as you want to. So, you could have something like: --bootloaders syslinux,syslinux-efi,grub-efi which, of course it does not make sense because either syslinux-efi and grub-efi would overwrite each ones code. Anyway what I wanted to say here is that: --bootloaders syslinux,syslinux-efi and --bootloaders syslinux-efi,syslinux are not the same thing. The first one (regarding binary_syslinux) should install special MBR code so that BIOS can chainload into syslinx. The second one (regarding binary_syslinux) should NOT install special MBR code so that BIOS can chainload into syslinux. It should inhibit itself because it is not the first bootloader. Or maybe it should not inhibit but you can do it. Well, I only had to deal with binary_iso when adding multi bootloaders support so I modified the binary_hdd the minimum so that it worked with the new variables. So for the binary_iso part we used: https://salsa.debian.org/live-team/live-build/blob/e4a4d4ae8d6379eae39eacb95486df1e5f028a69/scripts/build/binary_iso#L124-127 . if [ ${BOOTLOADER_NUMBER} -ge 2 ] then XORRISO_OPTIONS="${XORRISO_OPTIONS} -eltorito-alt-boot " fi This means that an extra 'eltorito' is added, so that the new entry at the isos can be recognised. So that a BIOS firmware that supports eltorito specification can choose between booting into the default torito entry or the non default one. I'm not sure there's an equivalent thing that should be added to binary_hdd now that we are at it. Anyways... if we take a look at your untouched binary_hdd: https://salsa.debian.org/live-team/live-build/blob/00eab3a77f3da176f3f0aa807b886206f8f0f0f1/scripts/build/binary_hdd we can see that grub-pc is not supported. I guess I might add it in the future. But grub legacy is supported. (Well, it's not actually not supported.) Assuming grub legacy are available at buster which I'm not totally sure. Anyway... what I want to say is that you should be able to choose: --bootloaders grub,syslinux-efi or (if grub-pc was implemented there) --bootloaders grub-pc,syslinux-efi in a hdd target and 'syslinux' installation should be only triggered if it's the first bootloader. Well, that's exactly how binary_hdd works right now... although the multi bootloader part should be improved to have something better than: https://salsa.debian.org/live-team/live-build/blob/00eab3a77f3da176f3f0aa807b886206f8f0f0f1/scripts/build/binary_hdd#L60-86 All of this above is trying to improve multi bootloader support in the binary_hdd part of live-build. Not sure if you should deal with this prior to adding your code. But if you want to take a look and tell us if binary_hdd should be updated or not (in the end the efi installation is handled by binary_syslinux-efi or binary_grub-efi in the filesystem level and not by binary_hdd). Having to deal with separate bootloaders, what they add or contribute that's another reason why I prefer binary_syslinux and binary_syslinux-efi being in different files. 6.3) Many of your commits seem to need a rebase into the current master branch. Well, that's to be expected. > > Gr. > > Matthijs > adrian15 -- Support free software. Donate to Super Grub Disk. Apoya el software libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
Bug#922251: live-build: support syslinux-efi as (additional) bootloader
not sure this is the right way of doing this. Are other equivalent files already implemented like you are doing? Or is it me finding it out for the first time. 5.4) In "Move syslinux modules into subdirectories (53901001)" you are using: "path modules" here you are using: "PATH /@EFI_DIR@/modules32" . This should be using either "path" in both files or "PATH" in both files. As the rest of the syslinux commands are in non capital letters I suggest using "path". 6) Only default to grub-efi for iso* images (118de99a) Seems good to me. 7) Improve bootloader configuration checks (5fb9ab31) I need to read through these changes another day. Was live-build to be based on python given a compatibility matrix based on nested arrays... this should be easier to implement. 8) Remove --templates from lb_config manpage (371892af) As I said in another mail this option makes more sense in another pull request but I guess you can leave it in this pull request for now. 9) Use syslinux-efi for hdd images by default (4e292ed0) Seems good to me. 10) I think buxy implemented syslinux-efi support back in the day. I guess it wasn't added to live-build because of reasons? Because grub-efi enabled Secure Boot to work? Anyways... Did you ever check buxy's work just in case it has something that you can recycle? I'll try to comment on "Improve bootloader configuration checks (5fb9ab31)" on the next days. I need to be focused on this one :) . Waiting for your feedback on the rest of the points. Hopefully we can agree on the binary_syslinux-efi creation and other points :) . adrian15 -- Support free software. Donate to Super Grub Disk. Apoya el software libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
Bug#922251: live-build: support syslinux-efi as (additional) bootloader
El 10/04/19 a las 09:58, Matthijs Kooijman escribió: > Hi Adrian, > >> 1) What is the rationale behind removing the --templates option >> explanation on manpage? > I wondered about this option and looked around the source for it, but > could not find any implementation for it, so it seemed good to remove > the documentation for it. > > Prompted by your question, I looked a bit further and found that it was > indeed removed: > > https://salsa.debian.org/live-team/live-build/commit/7e633e77f24b6f5ab9a8b22d7d6cf6521454d638 In that case IMO that commit should be in its own pull request and not the current one. That way it can opt to be applied inmediately while the rest of your commits is being studied. adrian15 -- Support free software. Donate to Super Grub Disk. Apoya el software libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
Bug#922251: live-build: support syslinux-efi as (additional) bootloader
El 08/04/19 a las 21:29, Matthijs Kooijman escribió: > Hi Luca & others, > > I've been working on syslinux-efi support in the past weeks and just > submitted a MR with a working implementation, along with some small > bootloader-related cleanups and refactors: > > https://salsa.debian.org/live-team/live-build/merge_requests/19 1) What is the rationale behind removing the --templates option explanation on manpage? Do you remove it in any of your commits? Which one? Or someone else did remove it? Thank you. Note: I will make more comments about this bug later in the week. 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 18/03/19 a las 00:39, adrian15 escribió: > El 09/03/19 a las 18:06, Thomas Schmitt escribió:>> 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. >> >> Consider to stay at least with the idea of a dedicated marker file >> with a not-so-probable constant name. >> >> The double-job of vmlinuz and the existence of an identical path on >> another disk caused the problems in this bug report. If the searched >> path would have been >> /live/this_is_a_debian_live_iso >> then no change of kernel names could interfere. Any incidential path >> equality would be unlikely, unless multiple debian-live ISOs are >> involved. >> >> >>> Hopefully Thomas you are not too bad at me. You seemed to be very >>> excited with all of this earmark implementation ;) . >> >> I am a bystander and tool provider here. Some aspects of the current >> state of Debian ISOs appear sub-optimal to me. E.g. the EFI partition >> inside the ISO filesystem rather than after it. >> >> When the discussion comes to these, then i pop up with my pre-formatted >> opinion. >> >> >> Have a nice day :) >> >> Thomas > > Guess what... my internal tested Rescatux 0.71b2 works flawlessly. The > Secure Boot part works ok finding /.disk/info. And later on the > filesystem.squashfs is found on the usb drive. > > But whenever I boot the laptop with an VGA monitor connnected to it... > live-boot's initrd instead of finding USB's filesystem.squashfs is > finding the internal hard disk's filesystem.squashfs and I am rewarded > with this prompt: > > Progress Linux 1.9 > > Then you take a look at google and you find many people experimenting > these type of problems. > > So I need to talk to live distro build tools developers and distro > remaster tools developers. > > A discussion about liveid (earmark sounds too much as cattle) needs to > be started. > > Not sure how I will do it. Private mailing list, open bug here at > Debian's bugzilla, email with CCs. > > Unless you know a place where distributions discuss with each other and > another place where remaster tool developers discuss with each other. > > > adrian15 I have created a github project for gathering feedback on an hypothetical live id implementation: https://github.com/rescatux/liveid/blob/proposal-v1/README.md I have also sent an email to both Gnu/Live build tools developers and distro remaster tools developers (using BCC to avoid privacy concerns). I'll try to update this bug only for my own patches / pull requests related to implementing liveid on live-build (and probably in live-boot too) which would lead to fixing this bug. 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 18:06, Thomas Schmitt escribió:>> 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. > > Consider to stay at least with the idea of a dedicated marker file > with a not-so-probable constant name. > > The double-job of vmlinuz and the existence of an identical path on > another disk caused the problems in this bug report. If the searched > path would have been > /live/this_is_a_debian_live_iso > then no change of kernel names could interfere. Any incidential path > equality would be unlikely, unless multiple debian-live ISOs are > involved. > > >> Hopefully Thomas you are not too bad at me. You seemed to be very >> excited with all of this earmark implementation ;) . > > I am a bystander and tool provider here. Some aspects of the current > state of Debian ISOs appear sub-optimal to me. E.g. the EFI partition > inside the ISO filesystem rather than after it. > > When the discussion comes to these, then i pop up with my pre-formatted > opinion. > > > Have a nice day :) > > Thomas Guess what... my internal tested Rescatux 0.71b2 works flawlessly. The Secure Boot part works ok finding /.disk/info. And later on the filesystem.squashfs is found on the usb drive. But whenever I boot the laptop with an VGA monitor connnected to it... live-boot's initrd instead of finding USB's filesystem.squashfs is finding the internal hard disk's filesystem.squashfs and I am rewarded with this prompt: Progress Linux 1.9 Then you take a look at google and you find many people experimenting these type of problems. So I need to talk to live distro build tools developers and distro remaster tools developers. A discussion about liveid (earmark sounds too much as cattle) needs to be started. Not sure how I will do it. Private mailing list, open bug here at Debian's bugzilla, email with CCs. Unless you know a place where distributions discuss with each other and another place where remaster tool developers discuss with each other. 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: Foreign architecture package support for linux kernel flavours patch
El 13/03/19 a las 09:01, Raphael Hertzog escribió: > On Tue, 12 Mar 2019, adrian15 wrote: >> Is it ok for merging in Debian GIT or is there anything that I can improve? > > I think it's OK if this was tested and if it doesn't break anything. Yeah, I tested it in various commits from history while I was git bisecting another live-build bug. I must admit I haven't tested default usage of: lb config --architectures i386 --linux-flavours "686" but I'm pretty confident it works well because else my own build which relies in proper LB_LINUX_FLAVOURS variables would have failed. > Do you have commit rights to apply it yourself? No, I don't. > > If not, you might want to submit a merge request. You might want to > improve the commit's description to explain why it's enough to accept > the arch qualifier... i.e. other parts of the code already deal with > it properly. > > Cheers, Ok, here there is my pull request: https://salsa.debian.org/live-team/live-build/merge_requests/18 adrian15 -- Support free software. Donate to Super Grub Disk. Apoya el software libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
Bug#757697: support arch autodetection on bootloader isolinux
Can you any of the new maintainers take a look at this request? I attach an updated patch that adds arch autodetection support to isolinux. I've tried it in actual hardware booting in BIOS-only mode and it works as expected. Thank you very much! Note that the grub2's support arch autodetection is already present in binary_loopback_cfg. So I only want isolinux support to be added. adrian15 -- Support free software. Donate to Super Grub Disk. Apoya el software libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/ >From 13730f7f8db6eb9bdd82a06b5c38148c56b2278d Mon Sep 17 00:00:00 2001 From: Adrian Gibanel Lopez Date: Sun, 7 Dec 2014 17:46:07 +0100 Subject: [PATCH] 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. --- scripts/build/binary_syslinux | 39 ++- 1 file changed, 38 insertions(+), 1 deletion(-) diff --git a/scripts/build/binary_syslinux b/scripts/build/binary_syslinux index bb6658826..24ddbb445 100755 --- a/scripts/build/binary_syslinux +++ b/scripts/build/binary_syslinux @@ -147,6 +147,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 @@ -169,6 +175,22 @@ then ;; *) + _AMD64_686_NUMBER="0" + + for _FLAVOUR in ${LB_LINUX_FLAVOURS} + do +if [ "${_FLAVOUR}" = "amd64" -o "${_FLAVOUR}" = "686" ] ; then + _AMD64_686_NUMBER="$((${_AMD64_686_NUMBER} + 1))" +fi + done + + if [ "${_AMD64_686_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") +_686_LABEL=$(cat "${_TARGET}/live.cfg.in" | grep "^label" | grep -v "failsafe" | sed 's/label //g' | sed -e "s|@FLAVOUR@|""686""|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} @@ -183,7 +205,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_686_NUMBER}" -ge 2 ] ; then + cat << EOF >> "${_TARGET}/live.cfg" +label ${_AUTO_LABEL} + menu label ${_AUTO_MENU_LABEL} + com32 ifcpu64.c32 + append ${_AMD64_LABEL} -- ${_686_LABEL} -- ${_686_LABEL} + +EOF + fi + + + if [ "${_AMD64_686_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#884553: Foreign architecture package support for linux kernel flavours patch
I attach a patch that adds foreign architecture support. Improvements since last patch: * Makes sure a consistent use of the new variable: LB_LINUX_FLAVOURS_WITH_ARCH * Makes a better job of explaining how to use on the manpage . Testing: This patch has been tested by using: --linux-flavours "686 amd64:amd64" in a buster i386 chroot and it works flawlessly. If you want to avoid the grub> prompt with Secure Boot you should apply patch from #924053 bug too. Is it ok for merging in Debian GIT or is there anything that I can improve? Thank you very much! adrian15 -- Support free software. Donate to Super Grub Disk. Apoya el software libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/ >From ad11d1c44909466baa259c2716d126dc9bc54080 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: "686 amd64:amd64" in a i386 system and it will install the amd64 kernel alongside the i386 system's 686 kernel. --- functions/defaults.sh| 24 manpages/en/lb_config.1 | 2 +- scripts/build/chroot_linux-image | 2 +- scripts/build/config | 6 +++--- 4 files changed, 21 insertions(+), 13 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 () ;; *) - LB_LINUX_FLAVOURS="${LB_LINUX_FLAVOURS:-powerpc64 powerpc}" + LB_LINUX_FLAVOURS_WITH_ARCH="${LB_LINUX_FLAVOURS_WITH_ARCH:-powerpc64 powerpc}" ;; esac ;; @@ -464,7 +464,7 @@ Set_defaults () ;; *) - LB_LINUX_FLAVOURS="${LB_LINUX_FLAVOURS:-s390x}" + LB_LINUX_FLAVOURS_WITH_ARCH="${LB_LINUX_FLAVOURS_WITH_ARCH:-s390x}" ;; esac ;; @@ -475,6 +475,14 @@ Set_defaults () ;; esac + LB_LINUX_FLAVOURS="" + for FLAVOUR in ${LB_LINUX_FLAVOURS_WITH_ARCH} + do + ARCH_FILTERED_FLAVOUR="$(echo ${FLAVOUR} | awk -F':' '{print $1}')" + LB_LINUX_FLAVOURS="${LB_LINUX_FLAVOURS} ${ARCH_FILTERED_FLAVOUR}" + done + + # Set linux packages LB_LINUX_PACKAGES="${LB_LINUX_PACKAGES:-linux-image}" diff --git a/manpages/en/lb_config.1 b/manpages/en/lb_config.1 index ac562d209..e46331ec7 100644 --- a/manpages/en/lb_config.1 +++ b/manpages/en/lb_config.1 @@ -360,7 +360,7 @@ sets the eraseblock size for a JFFS2 (Second Journaling Flash File System) files .IP "\fB\-\-keyring\-packages\fR \fIPACKAGE\fI|""\fIPACKAGES\fR""" 4 sets the keyring package or additional keyring packages. By default this is set to debian\-archive\-keyring. .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 boo
Bug#924053: Find /.disk/info patch
I attach a patch that makes Secure Boot minimal image minimal grub.cfg to seach for /disk/.info instead of /live/vmlinuz. This fixes unbootable Secure Boot (even if you boot with Secure Boot turned off) when live-build is setup to build with more than one linux kernel flavour. This has been tested in: * HP250 G6 2X60EA with UEFI Boot and Secure Boot turned off (Boot from UEFI USB) * Tianacore (Boot from UEFI CDROM) ( Note: The actual test had this additional patch: https://github.com/rescatux/live-build/commit/ad11d1c44909466baa259c2716d126dc9bc54080.patch applied to it. This enables the final user to use: --linux-flavours "686 amd64:amd64" ) Thus I conclude it works in binary_iso outputs. The same thing that happens with grub-efi enabled outputs. I never added added grub-efi support for either binary_hdd or binary_netboot and it seems nobody else added it. So I guess, as long as we only support binary_iso it's fine for now to rely on /disk/.info (only generated by xorriso) till we find a better method (like the one suggested by Thomas). 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/ >From 8e5f36048559a00abbd7102ab0f7ecb2f278bf4f Mon Sep 17 00:00:00 2001 From: adrian15 Date: Sat, 9 Mar 2019 14:49:01 +0100 Subject: [PATCH] Detect device media by its /.disk/info file. This fixes Secure Boot boot when internal hard disks have /live/vmlinuz files in it. --- scripts/build/binary_grub-efi | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/scripts/build/binary_grub-efi b/scripts/build/binary_grub-efi index 7afa07eb7..6e402683d 100755 --- a/scripts/build/binary_grub-efi +++ b/scripts/build/binary_grub-efi @@ -215,12 +215,11 @@ esac # look in that partition for a grub.cfg file, and even if it finds it # it will not be able to find the vmlinuz and initrd. # Drop a minimal grub.cfg in the EFI partition that sets the root and prefix -# to whatever partition holds the /live/vmlinuz image, and load the grub +# to whatever partition holds the /.disk/info file, and load the grub # config from that same partition. -# This is what the Ubuntu livecd already does. mkdir -p ${_CHROOT_DIR}/grub-efi-temp-cfg cat >${_CHROOT_DIR}/grub-efi-temp-cfg/grub.cfg <
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. 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
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
( 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#924053: live-build: UEFI shows grub> on HP250 G6 2SX60EA
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. ( ) 050e637b2ceaa1f6735fd9f84b0f7f4676637a79 ONIE: do not use package cache, only runs on host ( ) a0335ac4a42a1b784b054459b2377a0935720d23 ONIE: add Recommends for programs needed by binary_onie ( ) e47652d8412d2ccb2d32c370096580b7019f7655 ONIE: missing dependency on file ( ) 2aff516e1f9713e1c7407f163bc0abc998951bca ONIE: Check_package in the host, not the chroot ( ) 44e0d3520e9440cab692c86536083b3ce19510a2 Update changelog for 1:20180328 release ( ) 919604643bb66a2e2c4ea1cf6a630a6a6e24fbfa Add myself to Uploaders. ( ) 76a90f31b5e84aa630982e1c09df82b0baff1ebe Bump Standards-Version to 4.1.3. ( ) 7f5d8ef9e9704efd962fc8950e7991ca66070fdc Use HTTPS in debian/copyright (policy 4.0.0). ( ) c1948b4183099b37dbc4ebf6b5e16cb6fe885cef ONIE: detect initrd compression instead of hard-coding ( ) 0e91aeea428577b71fa0e2dd21d5cf664a0ebbe9 Add Acquire::AllowInsecureRepositories to fix apt-secure in sid ( ) 46c95969265fff53173a06419db46133c12f42ae Add options to build ONIE images ( ) 8047c2425ac8ca8c89586b76dcce4a4fbe66f303 Add NEWS file to warn users about change of live-boot mount paths ( ) aa1ae83854d5e85901ab56ad291f9e938a0582db UEFI: use uppercase EFI directory name for Tianocore ( CULPRIT grub> ) 035518ff69a97fa5d3fa432e13c9593a9f459a4e UEFI: add support for Secure Boot on amd64 and arm64 ( OK ) ac3ed23638cbc4b10059f9678283d08b4a082136 UEFI: add minimal grub.cfg to fat32 partition ( OK ) 0effdbd8ef12d0f668afee9505d1f50659f892ef Add grub-based UEFI boot support for ARM64 ( N/A ) 06d81b6710373f15faa1324f1f691483fafde8d1 Update changelog ( N/A ) 952ac834e4bf63bccfc84715d6e69bd3fd9b3ff0 Simplify bootstrapping of foreign architectures with qemu-debootstrap ( N/A ) 842e971a65edf049a33dbba738d30c8c7edb85bc Run mksquashfs with nice -n 19 to not overload the system ( N/A ) ee8d06c46cfa30fb0c7d43fde5d4f8dfef3967c4 Merge branch 'fix_offline_repo'
Bug#884553: live-build: Foreign architecture package support for linux kernel flavours in Stretch
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
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 () ;; *) -
Bug#884585: live-build: Grub autodetect option no longer works with 686 kernel
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
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
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 LopezDate: 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
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 LopezDate: 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
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 LopezDate: 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 (add patch tag)
Control: tags -1 + patch 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
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
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.
Bug#803890: chntpw: New samunlock binary. Unlock windows users automatically from cli - Add patch tag
Control: tags -1 + patch adrian15 -- Support free software. Donate to Super Grub Disk. Apoya el software libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
Bug#803888: chntpw: sampasswd not working as it's not writing its hive - Add patch tag
Control: tags -1 + patch adrian15 -- Support free software. Donate to Super Grub Disk. Apoya el software libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
Bug#803884: sampasswd.c: Wrong definition - Add patch tag
Control: tags -1 + patch adrian15 -- Support free software. Donate to Super Grub Disk. Apoya el software libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
Bug#803883: samusrgrp.c: Interactive TYPO - Add patch tag
Control: tags -1 + patch adrian15 -- Support free software. Donate to Super Grub Disk. Apoya el software libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)
El 26/08/16 a las 09:52, Raphael Hertzog escribió: (...) Can you explain to me why such Installation entries are not available in binary_syslinux? Maybe they should be put there also? Well, the menu entries are there by default: $ cat share/bootloaders/isolinux/menu.cfg menu hshift 0 menu width 82 menu title Boot menu include stdmenu.cfg include live.cfg include install.cfg menu begin advanced menu title Advanced options include stdmenu.cfg label mainmenu menu label ^Back.. menu exit include advanced.cfg menu end menu clear $ cat share/bootloaders/isolinux/install.cfg label install menu label ^Install linux /install/vmlinuz initrd /install/initrd.gz append vga=788 @APPEND_INSTALL@ --- quiet label installgui menu label ^Graphical install linux /install/gtk/vmlinuz initrd /install/gtk/initrd.gz append video=vesa:ywrap,mtrr vga=788 @APPEND_INSTALL@ --- quiet In fact I have not found any code to drop those entries when you don't want debian-installer in your live image... so I would rather see the opposite problem. So please add those entries in the grub menu. (...) I guess that some of those issues are not due to your changes, they are probably longstanding issues in the generic grub code but still it would be nice to have this fixed to have a more consistent experience between grub and syslinux. Well, there are some possible solutions to this problem: (...) 3. Commit the patch as is and later on add more patches on the minimal set needed for prettyfing this. I'm ok for this but I would still like you to re-add the installer entries first. Cheers, So, here's my current uefi patch + the installation boot entries. This recycled code from old binary_grub-pc does drop the installation entries if LB_DEBIAN_INSTALLER is false. I don't know how to add Debian Installer to a Debian Live so I have not been able to test it. So your feedback as user of the Debian Installer is welcome. https://github.com/rescatux/live-build/tree/efi_support_based_on_debian_cd_rebased_10 adrian15 -- Support free software. Donate to Super Grub Disk. Apoya el software libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/ >From 01a9df8ce325c5df9762f0db86128614b4d3476c Mon Sep 17 00:00:00 2001 From: Adrian Gibanel Lopez <adrian.giba...@btactic.com> Date: Mon, 18 Jan 2016 03:04:00 + Subject: [PATCH 01/11] functions/default.sh : Define LB_PRIMARY_BOOTLOADER at the Set_defaults function which it's the right place where to do it --- functions/defaults.sh | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/functions/defaults.sh b/functions/defaults.sh index ddf4b19..334984f 100755 --- a/functions/defaults.sh +++ b/functions/defaults.sh @@ -537,6 +537,8 @@ Set_defaults () esac fi + LB_PRIMARY_BOOTLOADER=$(echo "${LB_BOOTLOADERS}" | awk -F, '{ print $1 }') + # Setting checksums case "${LB_MODE}" in progress-linux) @@ -845,9 +847,6 @@ Check_defaults () fi fi - - 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 -- 2.1.4 >From 0624064d44ed811aec5c43fabfd7b928688ed8e1 Mon Sep 17 00:00:00 2001 From: Adrian Gibanel Lopez <adrian.giba...@btactic.com> Date: Wed, 20 Jan 2016 00:53:53 +0100 Subject: [PATCH 02/11] Remove repeated LB_PRIMARY_BOOTLOADER definition --- scripts/build/binary_hdd | 2 -- scripts/build/binary_iso | 2 -- 2 files changed, 4 deletions(-) diff --git a/scripts/build/binary_hdd b/scripts/build/binary_hdd index 407901a..b45b2a9 100755 --- a/scripts/build/binary_hdd +++ b/scripts/build/binary_hdd @@ -67,8 +67,6 @@ do esac done -LB_PRIMARY_BOOTLOADER=$(echo "${LB_BOOTLOADERS}" | awk -F, '{ print $1 }') - case ${LB_PRIMARY_BOOTLOADER} in syslinux) case ${LB_BINARY_FILESYSTEM} in diff --git a/scripts/build/binary_iso b/scripts/build/binary_iso index d8b1553..67dfc85 100755 --- a/scripts/build/binary_iso +++ b/scripts/build/binary_iso @@ -107,8 +107,6 @@ then XORRISO_OPTIONS="${XORRISO_OPTIONS} -V \"${LB_ISO_VOLUME}\"" fi -LB_PRIMARY_BOOTLOADER=$(echo "${LB_BOOTLOADERS}" | awk -F, '{ print $1 }') - # Handle xorriso architecture specific options case "${LB_PRIMARY_BOOTLOADER}" in grub) -- 2.1.4 >From 9d1a983cc8fe12966d1a2c24a6ee0cfb419b3ce5 Mon Sep 17 00:00:00 2001 From: Adrian Gibanel Lopez <adrian.giba...@btactic.com> Date: Mon, 18 Jan 2016 03:07:48 + Subject: [PATCH 03/11] Added new multi bootloader helper functions * Added: functions/bootloaders.sh . This file adds bootloader functions that are heavily used in efi scenarios where a bootloader can act as a first or an extra bootloader. Since the introduction of the new
Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)
El 26/08/16 a las 13:34, Raphael Hertzog escribió: On Fri, 26 Aug 2016, adrian15 wrote: Well, it sucks compared to the default visual appearance of isolinux/syslinux in live-build. I know, but the purpose of my patch is to add UEFI support. Not to improve visual appearance of grub2 so that it matches the isolinux/syslinux one. Well, my initial patch added EFI support on top of syslinux-efi and it thus had a nice visual appearance by default. So for me it's a regression... I consider myself syslinux to be a regression in terms of functionality compared to grub2 but I stick to syslinux because I don't want delta between Rescatux and Debian Live to be too large. I compare this new grub2 appearance to be the same one had the debian-cd when it started to support UEFI back in the day. But I assume it's not a regression in terms of computers supported because I believe that syslinux-efi works for less cases than grub-efi and hence why I did not commit my own patch in the first place. Also I expect that secure boot will be easier to add on top of grub than on top of syslinux. That's true. There does not seem to be a secure boot support in the works in the syslinux side of things. So I agree to apply your patch but I hope that you will stick around to help improve the visual appearance. I will try to check what jnqnfe did but I don't promise anything. I commited myself to work on this bug one year ago and I went silent on this bug for 3 or 4 months. These: /install/vmlinuz and /install/initrd.gz strings seem to be hardcoded. That explains why I did not see them in binary_syslinux . What does happen if you request both x86 and amd64 in your Debian Live? The first kernel gets into the /install/vmlinuz and the second kernel gets discarded? I don't know, I never tried to build images for multiple architectures. It's not a need for me. I see. I will apply those patches as an addendum to my current changes. I don't think it's worth the rebased needed for applying first the changes into the grub-pc code. Fine for me. Ok. 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#731709: grub-efi UEFI support based on debian-cd work complete (repos)
El 26/08/16 a las 09:52, Raphael Hertzog escribió: On Thu, 25 Aug 2016, adrian15 wrote: That's how the grub-pc menu (BIOS) shows currently in live-build. Well, it sucks compared to the default visual appearance of isolinux/syslinux in live-build. I know, but the purpose of my patch is to add UEFI support. Not to improve visual appearance of grub2 so that it matches the isolinux/syslinux one. - there are no menu entries to start debian-installer even though I built my image with "--debian-installer live" There were not such entries in the isolinux menu (BIOS). I already commented such incongruence when I submitted my loopback patch but Daniel (or irl maybe?. It was around the time dba quitted the project) agreed to merge my code. Compared to binary_grub2 script I have removed the installation entries because I did not see any of them in binary_syslinux. Can you explain to me why such Installation entries are not available in binary_syslinux? Maybe they should be put there also? Well, the menu entries are there by default: $ cat share/bootloaders/isolinux/menu.cfg menu hshift 0 menu width 82 menu title Boot menu include stdmenu.cfg include live.cfg include install.cfg menu begin advanced menu title Advanced options include stdmenu.cfg label mainmenu menu label ^Back.. menu exit include advanced.cfg menu end menu clear $ cat share/bootloaders/isolinux/install.cfg label install menu label ^Install linux /install/vmlinuz initrd /install/initrd.gz append vga=788 @APPEND_INSTALL@ --- quiet label installgui menu label ^Graphical install linux /install/gtk/vmlinuz initrd /install/gtk/initrd.gz append video=vesa:ywrap,mtrr vga=788 @APPEND_INSTALL@ --- quiet In fact I have not found any code to drop those entries when you don't want debian-installer in your live image... so I would rather see the opposite problem. So please add those entries in the grub menu. These: /install/vmlinuz and /install/initrd.gz strings seem to be hardcoded. That explains why I did not see them in binary_syslinux . What does happen if you request both x86 and amd64 in your Debian Live? The first kernel gets into the /install/vmlinuz and the second kernel gets discarded? - the menu entries hardcode "Debian GNU/Linux" as name of the project, in the default syslinux configuration the entries are agnostic as in "Live (@FLAVOUR@)". That @FLAVOUR@ is from Debian's live-build? Yes: $ cat share/bootloaders/isolinux/live.cfg.in label live-@FLAVOUR@ menu label ^Live (@FLAVOUR@) menu default linux @LINUX@ initrd @INITRD@ append @APPEND_LIVE@ label live-@FLAVOUR@-failsafe menu label ^Live (@FLAVOUR@ failsafe) linux @LINUX@ initrd @INITRD@ append @APPEND_LIVE_FAILSAFE@ I see. I guess that some of those issues are not due to your changes, they are probably longstanding issues in the generic grub code but still it would be nice to have this fixed to have a more consistent experience between grub and syslinux. Well, there are some possible solutions to this problem: 1. Try to reuse some code from jnqnfe. He did quite some work on improving bootloaders design which I don't think got into GIT: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775322 . His patch set is massive... but yes we should probably review them and merge what's appropriate. Yeah, probably. 2. Try to reuse the debian-cd scripts which try to convert syslinux cfg files into grub ones (including the design). Here: https://anonscm.debian.org/cgit/debian-cd/debian-cd.git/tree/tools/boot/jessie/parse_isolinux Not sure if this is the correct version to use but be warned that Sledge himself warns us that it's not pretty. Yeah, I looked that code in the past and I would not want to rely on this even though the principle would be nice... :) 3. Commit the patch as is and later on add more patches on the minimal set needed for prettyfing this. I'm ok for this but I would still like you to re-add the installer entries first. Although I do not like those hardcoded /install/vmlinuz strings I think I can do that. I will apply those patches as an addendum to my current changes. I don't think it's worth the rebased needed for applying first the changes into the grub-pc code. Cheers, 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#731709: grub-efi UEFI support based on debian-cd work complete (repos)
El 25/08/16 a las 15:36, Raphael Hertzog escribió: Hello Adrian, On Tue, 16 Aug 2016, adrian15 wrote: Kristian Klausen thinks is a good idea to wait for your tests. So your feedback is welcome. I just built a test Kali image with your patch applied. It works: I can boot the live system in UEFI mode. Great! > But I also saw a few problems: - the grub menu looks ugly (see attached picture), it's in plain text mode and the background is not even uniform (sometimes blue, sometimes black) That's how the grub-pc menu (BIOS) shows currently in live-build. - there are no menu entries to start debian-installer even though I built my image with "--debian-installer live" There were not such entries in the isolinux menu (BIOS). I already commented such incongruence when I submitted my loopback patch but Daniel (or irl maybe?. It was around the time dba quitted the project) agreed to merge my code. In my commit: https://anonscm.debian.org/cgit/debian-live/live-build.git/commit/?id=b6771e736022d31b0cb53c552a0f7a42a1028a09 I already said: Compared to binary_grub2 script I have removed the installation entries because I did not see any of them in binary_syslinux. Can you explain to me why such Installation entries are not available in binary_syslinux? Maybe they should be put there also? - the menu entries hardcode "Debian GNU/Linux" as name of the project, in the default syslinux configuration the entries are agnostic as in "Live (@FLAVOUR@)". That @FLAVOUR@ is from Debian's live-build? That was not the case for grub2 (BIOS) files. You have: https://anonscm.debian.org/cgit/debian-live/live-build.git/tree/share/bootloaders/grub-pc/grub.cfg?id=489a09ba92328cef846598a15329e9ff91519e3c LINUX_LIVE and LINUX_INSTALL strings which get replaced by the grub-pc script. https://anonscm.debian.org/cgit/debian-live/live-build.git/tree/scripts/build/binary_grub-pc?id=489a09ba92328cef846598a15329e9ff91519e3c In that case 'Debian Live' is hardcoded. I guess that some of those issues are not due to your changes, they are probably longstanding issues in the generic grub code but still it would be nice to have this fixed to have a more consistent experience between grub and syslinux. Well, there are some possible solutions to this problem: 1. Try to reuse some code from jnqnfe. He did quite some work on improving bootloaders design which I don't think got into GIT: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775322 . 2. Try to reuse the debian-cd scripts which try to convert syslinux cfg files into grub ones (including the design). Here: https://anonscm.debian.org/cgit/debian-cd/debian-cd.git/tree/tools/boot/jessie/parse_isolinux Not sure if this is the correct version to use but be warned that Sledge himself warns us that it's not pretty. 3. Commit the patch as is and later on add more patches on the minimal set needed for prettyfing this. I advocate for commiting the patch as soon as possible so that I can ask new commits such as the Suchanek's ' "support multiple kernel versions with same flavour" to be reworked on over my uefi support. adrian15 -- Support free software. Donate to Super Grub Disk. Apoya el software libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)
El 04/08/16 a las 14:51, Raphael Hertzog escribió: Hi, On Sun, 31 Jul 2016, adrian15 wrote: Is there anyone else than can provide feedback on this patch / branch? Either by: * Installing live-build with this applied patch * Building your iso and check if it boots in both BIOS and UEFI mode. * Check non usual UEFI machines. I suspect it's fine to wait for one week for feedback. After that time I'll try to request a proper pull / insertion into Debian's live-build repo and probably into live-build package binaries. I can give a try to your patchset but I'm currently in vacation so it would not be before the third week of August. This is just FYI but you don't have to wait on my feedback to get your work merged if people are happy with it. Cheers, Hi Raphael, Kristian Klausen thinks is a good idea to wait for your tests. So your feedback is welcome. 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#731709: grub-efi UEFI support based on debian-cd work complete (repos)
El 04/08/16 a las 14:51, Raphael Hertzog escribió: Hi, On Sun, 31 Jul 2016, adrian15 wrote: Is there anyone else than can provide feedback on this patch / branch? Either by: * Installing live-build with this applied patch * Building your iso and check if it boots in both BIOS and UEFI mode. * Check non usual UEFI machines. I suspect it's fine to wait for one week for feedback. After that time I'll try to request a proper pull / insertion into Debian's live-build repo and probably into live-build package binaries. I can give a try to your patchset but I'm currently in vacation so it would not be before the third week of August. This is just FYI but you don't have to wait on my feedback to get your work merged if people are happy with it. Cheers, I have CCed Kristian Klausen whom it's willing to pull/push my patches. By the way my patches are aimed at master branch. Not sure if the current protocol allows to add new changes to master branch. But, well, if I'm not mistaken this is the Jessie branch and we need these changes for Jessie. If it makes sense from the Debian release team point of view of course. Maybe the Jessie's live-build package cannot have any more updates. Can anyone shed light on this concern of mine? The branch to merge would be: https://github.com/rescatux/live-build/tree/efi_support_based_on_debian_cd_rebased_9 . I forward to Kristian Klausen the decision on whether to wait for Raphael Hertzog feedback or not. adrian15 -- Support free software. Donate to Super Grub Disk. Apoya el software libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)
1) I'm glad Michal finally agrees with the overall implementation of multi bootloaders support. 2) I have squashed some commits were it made sense. I have fixed some commits descriptions. I have removed a whitespace. Here's the new rebased branch: https://github.com/rescatux/live-build/tree/efi_support_based_on_debian_cd_rebased_9 git diff betweenefi_support_based_on_debian_cd_rebased_7 and efi_support_based_on_debian_cd_rebased_9 shows only a whitespace as a difference, so I have not even bothered to test this new branch. 3) wCPO from debian-live irc is willing to pull it. Is there anyone else than can provide feedback on this patch / branch? Either by: * Installing live-build with this applied patch * Building your iso and check if it boots in both BIOS and UEFI mode. * Check non usual UEFI machines. I suspect it's fine to wait for one week for feedback. After that time I'll try to request a proper pull / insertion into Debian's live-build repo and probably into live-build package binaries. adrian15 El 31/07/16 a las 10:12, Michal Suchanek escribió: Hello, On 31 July 2016 at 09:35, adrian15 <adrian15...@gmail.com> wrote: This new update tries to implement actual support for multiple bootloaders. It only enforces grub-legacy not to be an extra bootloader because it's current implementation in binary-iso is not compatible (without hacking) with multiple bootloaders. * Branch were I added these last improvement / fixes: https://github.com/rescatux/live-build/tree/efi_support_based_on_debian_cd_michal * Final rebased branched: https://github.com/rescatux/live-build/tree/efi_support_based_on_debian_cd_rebased_7 I skimmed through this final rebased branch and it looks generally good. I would suggest removing the unrelated whitespace changes and squashing commits that rewrite new code with commits introducing said code. I have no idea who can pull this so it can be released in Debian. Thanks Michal -- Support free software. Donate to Super Grub Disk. Apoya el software libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/ >From 01a9df8ce325c5df9762f0db86128614b4d3476c Mon Sep 17 00:00:00 2001 From: Adrian Gibanel Lopez <adrian.giba...@btactic.com> Date: Mon, 18 Jan 2016 03:04:00 + Subject: [PATCH 01/10] functions/default.sh : Define LB_PRIMARY_BOOTLOADER at the Set_defaults function which it's the right place where to do it --- functions/defaults.sh | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/functions/defaults.sh b/functions/defaults.sh index ddf4b19..334984f 100755 --- a/functions/defaults.sh +++ b/functions/defaults.sh @@ -537,6 +537,8 @@ Set_defaults () esac fi + LB_PRIMARY_BOOTLOADER=$(echo "${LB_BOOTLOADERS}" | awk -F, '{ print $1 }') + # Setting checksums case "${LB_MODE}" in progress-linux) @@ -845,9 +847,6 @@ Check_defaults () fi fi - - 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 -- 2.1.4 >From 0624064d44ed811aec5c43fabfd7b928688ed8e1 Mon Sep 17 00:00:00 2001 From: Adrian Gibanel Lopez <adrian.giba...@btactic.com> Date: Wed, 20 Jan 2016 00:53:53 +0100 Subject: [PATCH 02/10] Remove repeated LB_PRIMARY_BOOTLOADER definition --- scripts/build/binary_hdd | 2 -- scripts/build/binary_iso | 2 -- 2 files changed, 4 deletions(-) diff --git a/scripts/build/binary_hdd b/scripts/build/binary_hdd index 407901a..b45b2a9 100755 --- a/scripts/build/binary_hdd +++ b/scripts/build/binary_hdd @@ -67,8 +67,6 @@ do esac done -LB_PRIMARY_BOOTLOADER=$(echo "${LB_BOOTLOADERS}" | awk -F, '{ print $1 }') - case ${LB_PRIMARY_BOOTLOADER} in syslinux) case ${LB_BINARY_FILESYSTEM} in diff --git a/scripts/build/binary_iso b/scripts/build/binary_iso index d8b1553..67dfc85 100755 --- a/scripts/build/binary_iso +++ b/scripts/build/binary_iso @@ -107,8 +107,6 @@ then XORRISO_OPTIONS="${XORRISO_OPTIONS} -V \"${LB_ISO_VOLUME}\"" fi -LB_PRIMARY_BOOTLOADER=$(echo "${LB_BOOTLOADERS}" | awk -F, '{ print $1 }') - # Handle xorriso architecture specific options case "${LB_PRIMARY_BOOTLOADER}" in grub) -- 2.1.4 >From 9d1a983cc8fe12966d1a2c24a6ee0cfb419b3ce5 Mon Sep 17 00:00:00 2001 From: Adrian Gibanel Lopez <adrian.giba...@btactic.com> Date: Mon, 18 Jan 2016 03:07:48 + Subject: [PATCH 03/10] Added new multi bootloader helper functions * Added: functions/bootloaders.sh . This file adds bootloader functions that are heavily used in efi scenarios where a bootloader can act as a first or an extra bootloader. Since the introduction of the new switch: --bootloaders you can setup it like this: --bootloaders=syslinux,grub-efi . This means that syslinux is the first bootloader and grub-efi is the extra bootloader. * Added new bo
Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)
This new update tries to implement actual support for multiple bootloaders. It only enforces grub-legacy not to be an extra bootloader because it's current implementation in binary-iso is not compatible (without hacking) with multiple bootloaders. * Branch were I added these last improvement / fixes: https://github.com/rescatux/live-build/tree/efi_support_based_on_debian_cd_michal * Final rebased branched: https://github.com/rescatux/live-build/tree/efi_support_based_on_debian_cd_rebased_7 Rescatux 0.40 beta 7 has been built with efi_support_based_on_debian_cd_rebased_7 branch and can be found here: http://www.supergrubdisk.org/2016/07/31/rescatux-0-40-beta-7-released/ . As always feedback is welcome. El 22/03/16 a las 07:18, Michal Suchanek escribió: On 21 March 2016 at 23:06, adrian15 <adrian15...@gmail.com> wrote: El 21/03/16 a las 22:19, Michal Suchanek escribió: So please consider either 1) fixing your current patch so there is no primary or first bootloader and all installed bootloaders are equal 2) don't pretend you add support for multiple bootloaders when you are not wiling to do so and just and some option like --bolt-on-grub-efi which installs grub-efi if image type and filesystem is compatible with grub-efi and fails the build otherwise BTW it has been pointed out already that -eltorito-alt-boot is just separator that starts new boot entry so there are no special secondary/extra bootloader options. Any bootloader can be first/second/third/whatever. Thanks Michal -- Support free software. Donate to Super Grub Disk. Apoya el software libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/ >From 723661c38b48d0617c5c660ea140edfaef4699ce Mon Sep 17 00:00:00 2001 From: Adrian Gibanel Lopez <adrian.giba...@btactic.com> Date: Mon, 18 Jan 2016 03:04:00 + Subject: [PATCH 01/13] functions/default.sh : Define LB_PRIMARY_BOOTLOADER at the Set_defaults function which it's the right place where to do it --- functions/defaults.sh | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/functions/defaults.sh b/functions/defaults.sh index ddf4b19..334984f 100755 --- a/functions/defaults.sh +++ b/functions/defaults.sh @@ -537,6 +537,8 @@ Set_defaults () esac fi + LB_PRIMARY_BOOTLOADER=$(echo "${LB_BOOTLOADERS}" | awk -F, '{ print $1 }') + # Setting checksums case "${LB_MODE}" in progress-linux) @@ -845,9 +847,6 @@ Check_defaults () fi fi - - 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 -- 2.1.4 >From a506c9c03d61f9c09d816a9e24285c599c9bacdf Mon Sep 17 00:00:00 2001 From: Adrian Gibanel Lopez <adrian.giba...@btactic.com> Date: Wed, 20 Jan 2016 00:53:53 +0100 Subject: [PATCH 02/13] Remove repeated LB_PRIMARY_BOOTLOADER definition --- scripts/build/binary_hdd | 2 -- scripts/build/binary_iso | 2 -- 2 files changed, 4 deletions(-) diff --git a/scripts/build/binary_hdd b/scripts/build/binary_hdd index 407901a..b45b2a9 100755 --- a/scripts/build/binary_hdd +++ b/scripts/build/binary_hdd @@ -67,8 +67,6 @@ do esac done -LB_PRIMARY_BOOTLOADER=$(echo "${LB_BOOTLOADERS}" | awk -F, '{ print $1 }') - case ${LB_PRIMARY_BOOTLOADER} in syslinux) case ${LB_BINARY_FILESYSTEM} in diff --git a/scripts/build/binary_iso b/scripts/build/binary_iso index d8b1553..67dfc85 100755 --- a/scripts/build/binary_iso +++ b/scripts/build/binary_iso @@ -107,8 +107,6 @@ then XORRISO_OPTIONS="${XORRISO_OPTIONS} -V \"${LB_ISO_VOLUME}\"" fi -LB_PRIMARY_BOOTLOADER=$(echo "${LB_BOOTLOADERS}" | awk -F, '{ print $1 }') - # Handle xorriso architecture specific options case "${LB_PRIMARY_BOOTLOADER}" in grub) -- 2.1.4 >From 06ad8acdc81e6bc2b460954bae57191ddb7d238a Mon Sep 17 00:00:00 2001 From: Adrian Gibanel Lopez <adrian.giba...@btactic.com> Date: Mon, 18 Jan 2016 03:07:48 + Subject: [PATCH 03/13] * Added: functions/bootloaders.sh . It has new bootloader functions that are heavily used in efi scenarios where a bootloader can act as a primary or a secondary bootloader. Since the introduction of the new switch: --bootloaders you can setup it like this: --bootloaders=syslinux,grub-efi . This means that syslinux is the primary bootloader and grub-efi is the secondary bootloader. * Added new bootloader functions: Check_Non_Primary_Bootloader and Check_Non_Secondary_Bootloader. These functions let each one of the bootloaders abort the build because they cannot perform a role either as a primary bootloader or as a secondary bootloader. * Added bootloader functions: Check_Primary_Bootloader_Role, Check_Secondary_Bootloader_Role and Check_Any_Bootloader_Role These functions let bootloaders to force their default role in a single line. --- functions/
Bug#819664: Re-organise the CD / download pages to make them more useful
rior to 2005? . Whenever possible please try the 64-bit image. + link to Debian Install favoured 64-bit image + link to Debian Install favoured 32-bit image NEI.2. Check your ISO. This step ensures the ISO you have downloaded is ok. In order to verify your download you have to... NEF.3. Burn your ISO. That big file needs to be put into a DVD or an USB. Here we show you how. NEI.4. Boot your ISO. In order to boot a Debian Installation Disk you don't usually need to do anything in most recent PCs. However if your previous OSes boot you probably need to press F8,... NEI. 5. Install your ISO. Installing Debian as a single Operating System for your computer is rather simple. If you need additional help on this help you can check our tour "Installing Debian". NEI. 6. Enjoy your Debian We recommend you to discover the most used and famous Debian programs on the Debian Live thanks to our "Discover famous Debian programs" page. NEI. 7. Become a Debianer! Do you enjoy Debian? There's a community out there which needs your help. Check how you can help by checking our: "Debian - Our community" page. Computer Sysadmin - Newbie === CSN.0. Know your Debian You don't know what's Debian yet? We recommend you to test it in a virtual machine prior to install to a phisical machine. Please check: "Debian support on virtualisation systems". CSN.1. Download your ISO. A 32-bit image is probably only need with computers prior to 2005? . Whenever possible please try the 64-bit image. + link to Debian Install favoured 64-bit image + link to Debian Install favoured 32-bit image CSN.2. Check your ISO. This step ensures the ISO you have downloaded is ok. In order to verify your download you have to... CSN.3. Burn your ISO. That big file needs to be put into a DVD or an USB. Here we show you how. CSN.4. Boot your ISO. In order to boot a Debian Installation Disk you don't usually need to do anything in most recent PCs. However if your previous OSes boot you probably need to press F8,... CSN. 5. Install your ISO. Installing Debian as a single Operating System for your computer is rather simple. If you need additional help on this help you can check our tour "Installing Debian". CSN. 6. Enjoy your Debian As per your technical role we recommend you to discover the different blends of Debian which can be applied to normal Debian installation thanks to its metapackages. CSN. 7. Become a Debianer! Do you enjoy Debian? There's a community out there which needs your help. Check how you can help by checking our: "Debian - Our community" page. Computer Sysadmin - Advanced CSA.0. Know your Debian You don't know what's Debian yet? We recommend you to test it in a virtual machine prior to install to a phisical machine. Please check: "Debian support on virtualisation systems". CSA.1. Download your ISO. A 32-bit image is probably only need with computers prior to 2005? . Whenever possible please try the 64-bit image. + link to netinst 64-bit image + link to netinst 32-bit image CSA.2. Check your ISO. This step ensures the ISO you have downloaded is ok. In order to verify your download you have to... CSA.3. Burn your ISO. That big file needs to be put into a DVD or an USB. Here we show you how. CSA.4. Boot your ISO. In order to boot a Debian Installation Disk you don't usually need to do anything in most recent PCs. However if your previous OSes boot you probably need to press F8,... CSA. 5. Install your ISO. Installing Debian as a single Operating System for your computer is rather simple. If you need additional help on this help you can check our tour "Installing Debian". CSA. 6. Enjoy your Debian As per your technical role we recommend you to discover the different blends of Debian which can be applied to normal Debian installation thanks to its metapackages. CSA. 7. Become a Debianer! Do you enjoy Debian? There's a community out there which needs your help. Check how you can help by checking our: "Debian - Our community" page adrian15 -- Support free software. Donate to Super Grub Disk. Apoya el software libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)
El 21/03/16 a las 22:19, Michal Suchanek escribió: Hello, On 21 March 2016 at 21:09, adrian15 <adrian15...@gmail.com> wrote: The branch which include specifically the commits I attach here as patches is: https://github.com/rescatux/live-build/tree/efi_support_based_on_debian_cd_rebased_5 . About the variable names issue: I think the new terms: first and extra are ok because they are not implying some sort of rank while explaining what's the difference between them. Also, notice, that these are internal variables which final user of live-build does not see. I think we should focus on other aspects of my patch if there are more problems for it. The problem is not with the name of the variable. The problem is that you use it at all. In most places when you check for primary or secondary bootloader you should just loop all bootloaders and check each. In fact, in the previous batch of patches I found no place where checking for primary or secondary bootloader made any sense. If you think that the way bootloaders is currently managed by live-build is wrong please file up a new bug and send there your patch with your improvements so that it's get discussed. The bootloader support in live-build is limited. With your patches it becomes wrong. eg. compatibility of bootloader with selected filesystem and image type is only checked for first bootloader and EFI support is added only when grub-efi extra bootloader but not when it is the first bootloader. This is not fixed by renaming the variables. Thanks Michal Ok, what about now? Actually from my former email I only added one additional patch (0011) with some sort of modular support for bootloaders. There probably needs some work to be done on binary_hdd but I first wanted to gather information on what to improve on this last patch. https://github.com/rescatux/live-build/tree/efi_support_based_on_debian_cd_rebased_6 adrian15 -- Support free software. Donate to Super Grub Disk. Apoya el software libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/ >From ff8206aea1985760dfea9ec94b93686a242f137e Mon Sep 17 00:00:00 2001 From: Adrian Gibanel Lopez <adrian.giba...@btactic.com> Date: Mon, 18 Jan 2016 03:04:00 + Subject: [PATCH 01/11] functions/default.sh : Define LB_PRIMARY_BOOTLOADER at the Set_defaults function which it's the right place where to do it --- functions/defaults.sh | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/functions/defaults.sh b/functions/defaults.sh index ddf4b19..334984f 100755 --- a/functions/defaults.sh +++ b/functions/defaults.sh @@ -537,6 +537,8 @@ Set_defaults () esac fi + LB_PRIMARY_BOOTLOADER=$(echo "${LB_BOOTLOADERS}" | awk -F, '{ print $1 }') + # Setting checksums case "${LB_MODE}" in progress-linux) @@ -845,9 +847,6 @@ Check_defaults () fi fi - - 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 -- 2.1.4 >From f895f653dffb614639fa37a318e62c51104a4b2d Mon Sep 17 00:00:00 2001 From: Adrian Gibanel Lopez <adrian.giba...@btactic.com> Date: Wed, 20 Jan 2016 00:53:53 +0100 Subject: [PATCH 02/11] Remove repeated LB_PRIMARY_BOOTLOADER definition --- scripts/build/binary_hdd | 2 -- scripts/build/binary_iso | 2 -- 2 files changed, 4 deletions(-) diff --git a/scripts/build/binary_hdd b/scripts/build/binary_hdd index d0db382..0c9c5af 100755 --- a/scripts/build/binary_hdd +++ b/scripts/build/binary_hdd @@ -67,8 +67,6 @@ do esac done -LB_PRIMARY_BOOTLOADER=$(echo "${LB_BOOTLOADERS}" | awk -F, '{ print $1 }') - case ${LB_PRIMARY_BOOTLOADER} in syslinux) case ${LB_BINARY_FILESYSTEM} in diff --git a/scripts/build/binary_iso b/scripts/build/binary_iso index d8b1553..67dfc85 100755 --- a/scripts/build/binary_iso +++ b/scripts/build/binary_iso @@ -107,8 +107,6 @@ then XORRISO_OPTIONS="${XORRISO_OPTIONS} -V \"${LB_ISO_VOLUME}\"" fi -LB_PRIMARY_BOOTLOADER=$(echo "${LB_BOOTLOADERS}" | awk -F, '{ print $1 }') - # Handle xorriso architecture specific options case "${LB_PRIMARY_BOOTLOADER}" in grub) -- 2.1.4 >From 9175a624b7d88bfea80448a5a1e6ac1b11d651aa Mon Sep 17 00:00:00 2001 From: Adrian Gibanel Lopez <adrian.giba...@btactic.com> Date: Mon, 18 Jan 2016 03:07:48 + Subject: [PATCH 03/11] * Added: functions/bootloaders.sh . It has new bootloader functions that are heavily used in efi scenarios where a bootloader can act as a primary or a secondary bootloader. Since the introduction of the new switch: --bootloaders you can setup it like this: --bootloaders=syslinux,grub-efi . This means that syslinux is the primary bootloader and grub-efi is the secondary bootloader. * Added new bootloader functions: Check_Non_Primary_Bootloader and Check_Non_Secondar
Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)
El 21/03/16 a las 22:19, Michal Suchanek escribió: Hello, On 21 March 2016 at 21:09, adrian15 <adrian15...@gmail.com> wrote: The branch which include specifically the commits I attach here as patches is: https://github.com/rescatux/live-build/tree/efi_support_based_on_debian_cd_rebased_5 . About the variable names issue: I think the new terms: first and extra are ok because they are not implying some sort of rank while explaining what's the difference between them. Also, notice, that these are internal variables which final user of live-build does not see. I think we should focus on other aspects of my patch if there are more problems for it. The problem is not with the name of the variable. The problem is that you use it at all. In most places when you check for primary or secondary bootloader you should just loop all bootloaders and check each. In fact, in the previous batch of patches I found no place where checking for primary or secondary bootloader made any sense. If you think that the way bootloaders is currently managed by live-build is wrong please file up a new bug and send there your patch with your improvements so that it's get discussed. The bootloader support in live-build is limited. With your patches it becomes wrong. eg. compatibility of bootloader with selected filesystem and image type is only checked for first bootloader and EFI support is added only when grub-efi extra bootloader but not when it is the first bootloader. This is not fixed by renaming the variables. Ok. So I recognise that my patch: * Adds a limited support of UEFI only available when it's used as an extra bootloader * Does not check compatibility with selected filesystem in the extra bootloader because it blindly relies on selected filesystem selected in first bootloader being compatible with the extra bootloader too. * It does not work for hdd binaries (only iso binaries) and it does in addition to what live-build already did. I also think that my patch does not remove the current live-build functionality and if that happens I want to know about it. Yes, my patch does not bring UEFI complete support, but a minimal one. So according to you the many changes I make on the bootloader functions do not compensate the minimal UEFI support I add to live-build? 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#731709: grub-efi UEFI support based on debian-cd work complete (repos)
This is my updated set of patches. Changes since last set of patches: * Renamed primary and secondary to first and extra terms. * Forced insmod all_video command in grub.cfg to avoid problems in UEFI mode. * Minor changes Rescatux 0.40b6 which I will release soon will feature this branch which include these changes: https://github.com/rescatux/live-build/tree/rescatux-0.40b6 . The branch which include specifically the commits I attach here as patches is: https://github.com/rescatux/live-build/tree/efi_support_based_on_debian_cd_rebased_5 . About the variable names issue: I think the new terms: first and extra are ok because they are not implying some sort of rank while explaining what's the difference between them. Also, notice, that these are internal variables which final user of live-build does not see. I think we should focus on other aspects of my patch if there are more problems for it. If you think that the way bootloaders is currently managed by live-build is wrong please file up a new bug and send there your patch with your improvements so that it's get discussed. Then, if it gets approved I can improve my patch over yours. My patch tries to make the minimum improvements so that other live-build functionality does not get affected by it. Let's please focus on getting this set of patches accepted. Don't get me wrong I'm not asking for a carte blanche but, let's focus on other aspects from the patch. (E.g. please test it on actual hardware, in your distro builds, even if you don't use UEFI does the ISO boot as always in BIOS mode?) And give us feedback on 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/ >From ff8206aea1985760dfea9ec94b93686a242f137e Mon Sep 17 00:00:00 2001 From: Adrian Gibanel Lopez <adrian.giba...@btactic.com> Date: Mon, 18 Jan 2016 03:04:00 + Subject: [PATCH 01/10] functions/default.sh : Define LB_PRIMARY_BOOTLOADER at the Set_defaults function which it's the right place where to do it --- functions/defaults.sh | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/functions/defaults.sh b/functions/defaults.sh index ddf4b19..334984f 100755 --- a/functions/defaults.sh +++ b/functions/defaults.sh @@ -537,6 +537,8 @@ Set_defaults () esac fi + LB_PRIMARY_BOOTLOADER=$(echo "${LB_BOOTLOADERS}" | awk -F, '{ print $1 }') + # Setting checksums case "${LB_MODE}" in progress-linux) @@ -845,9 +847,6 @@ Check_defaults () fi fi - - 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 -- 2.1.4 >From f895f653dffb614639fa37a318e62c51104a4b2d Mon Sep 17 00:00:00 2001 From: Adrian Gibanel Lopez <adrian.giba...@btactic.com> Date: Wed, 20 Jan 2016 00:53:53 +0100 Subject: [PATCH 02/10] Remove repeated LB_PRIMARY_BOOTLOADER definition --- scripts/build/binary_hdd | 2 -- scripts/build/binary_iso | 2 -- 2 files changed, 4 deletions(-) diff --git a/scripts/build/binary_hdd b/scripts/build/binary_hdd index d0db382..0c9c5af 100755 --- a/scripts/build/binary_hdd +++ b/scripts/build/binary_hdd @@ -67,8 +67,6 @@ do esac done -LB_PRIMARY_BOOTLOADER=$(echo "${LB_BOOTLOADERS}" | awk -F, '{ print $1 }') - case ${LB_PRIMARY_BOOTLOADER} in syslinux) case ${LB_BINARY_FILESYSTEM} in diff --git a/scripts/build/binary_iso b/scripts/build/binary_iso index d8b1553..67dfc85 100755 --- a/scripts/build/binary_iso +++ b/scripts/build/binary_iso @@ -107,8 +107,6 @@ then XORRISO_OPTIONS="${XORRISO_OPTIONS} -V \"${LB_ISO_VOLUME}\"" fi -LB_PRIMARY_BOOTLOADER=$(echo "${LB_BOOTLOADERS}" | awk -F, '{ print $1 }') - # Handle xorriso architecture specific options case "${LB_PRIMARY_BOOTLOADER}" in grub) -- 2.1.4 >From 9175a624b7d88bfea80448a5a1e6ac1b11d651aa Mon Sep 17 00:00:00 2001 From: Adrian Gibanel Lopez <adrian.giba...@btactic.com> Date: Mon, 18 Jan 2016 03:07:48 + Subject: [PATCH 03/10] * Added: functions/bootloaders.sh . It has new bootloader functions that are heavily used in efi scenarios where a bootloader can act as a primary or a secondary bootloader. Since the introduction of the new switch: --bootloaders you can setup it like this: --bootloaders=syslinux,grub-efi . This means that syslinux is the primary bootloader and grub-efi is the secondary bootloader. * Added new bootloader functions: Check_Non_Primary_Bootloader and Check_Non_Secondary_Bootloader. These functions let each one of the bootloaders abort the build because they cannot perform a role either as a primary bootloader or as a secondary bootloader. * Added bootloader functions: Check_Primary_Bootloader_Role, Check_Secondary_Bootloader_Role and Check_A
Bug#818916: live-build: Wrong version extracted from os-release in binary-syslinux
Package: live-build Version: 5.0~a11-1 Severity: minor Dear Maintainer, * What led up to the situation? I was trying to use @VERSION@ string in splash.svg. * What exactly did you do (or not do) that was effective (or ineffective)? I used @VERSION@ string in splash.svg. * What was the outcome of this action? @VERSION@ was replaced by: 5.0~a11-1 which it's the live-build package version. * What outcome did you expect instead? @VERSION@ should have been replaced by: 8 (The version read from os-release for my build) which it's the distro, in this case Debian, version. Additional information. I attach a trivial patch which solves the problem. -- System Information: Debian Release: 8.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) >From b516d2defaeda72a03400dbd1a17b91d6bca7e31 Mon Sep 17 00:00:00 2001 From: Adrian Gibanel LopezDate: Mon, 21 Mar 2016 18:44:38 +0100 Subject: [PATCH] @VERSION@ now its equal to VERSION_ID variable. Fixes a typo. --- scripts/build/binary_syslinux | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/build/binary_syslinux b/scripts/build/binary_syslinux index 024b563..66c14a0 100755 --- a/scripts/build/binary_syslinux +++ b/scripts/build/binary_syslinux @@ -248,7 +248,7 @@ then _VERSION="$(. chroot/etc/os-release && echo ${VERSION_ID})" fi -_VERSION="${VERSION:-none}" +_VERSION="${_VERSION:-none}" _DISTRIBUTION="${LB_DISTRIBUTION}" _ARCHITECTURE="${LB_ARCHITECTURES}" -- 2.1.4
Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)
reason we want BIOS record first is Inside the binary_bootloader file by running a function that shows that warning. The author of the binary_bootloader it's who decides where it's advised to go. The final place where it goes depends on the order here: --bootloaders="syslinux,grub-efi" I mean, the final user can decide the order but if it's not optimal he gets a warning. 1) some tools for butchering bootable CDs expect it to be first. 2) it's the traditional place for it (since it was the only record for a long time) and some ancient BIOSes might potentially break if it's not first because somebody missed there *can* be multiple entries when coding them. So it only has to do with the fact that syslinux is our only well supported BIOS loader that syslinux should go first. If grub-pc was installed as BIOS loader it should go first instead. And then you would have to duplicate that check in grub-pc. I don't see a problem here. I can do that thanks to the magic of functions that let me repeat code with only one line. I already did that in the last version of the patch. ( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731709#233 - In that version I thought I had to enforce boot order because not doing so it was going to produce non bootable isos. Now I'm convinced that using non standard boot order do not produce non bootable isos thus a warning instead of stopping live build is ok. ) Let's not repeat the current binary_iso design which has many references to the different available binary_bootloaders available. What's wrong with referencing variables we have so that we know what's going on in l-b? Thanks Michal Well, basically, my design rationale behind this is that with the current way of doing things you need to update binary_iso file each time a new bootloader is added. With what I'm proposing you you wouldn't have to update it. And if a new bootloader might ever need binary_iso to be modified then every bootloader might benefit from that architecture enhancement. adrian15 -- Support free software. Donate to Super Grub Disk. Apoya el software libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)
El 25/01/16 a las 16:12, Michal Suchanek escribió: On 25 January 2016 at 03:05, adrian15 <adrian15...@gmail.com> wrote: El 24/01/16 a las 16:51, Michal Suchanek escribió: What you are describing here is what it's actually implemented in my patch (Well, actually the first patch version because the current one enforces bootloader roles). Actually, no. Nowhere in the description is any bootloader designated primary or secondary or first or second. On purpose. Neither it is on my patch (initial implementation). Yes, the term PRIMARY_BOOTLOADER is used there for reusing old code. But using: --bootloaders=syslinux,grub-efi did not enforce syslinux to be in the first place or grub-efi to be in the second place. That's the specific part I meant. So what about primary and secondary terms? Or first or second terms? Both are broken and confusing. Ok... These terms are used in two places: * Internal variables and functions to handle bootloaders * Information shown to the final user I'm most convinced to use the first and non-first notation. So that the old code that referred to LB_BOOTLOADER can just refer to: LB_FIRST_BOOTLOADER. For what piece of code we have does it make sense to reference LB_FIRST_BOOTLOADER when not also referencing LB_SECOND_BOOTLOADER? Will that be extended to LB_THIRD_BOOTLOADER once x86 grows support for coreboot or l-b grows support for some other platform with many firmware variants? If you set bootloaders like LB_BOOTLOADERS="syslinux grub-efi" then you can just do for bootloader in $LB_BOOTLOADERS ; do some $bootloader foo Mostly what current path does but with commas instead. after you check that you have at most two bootloaders and if you have more than one then only the latter one ends with -efi. This is not a good approach. You are requesting the bootloaders to end in "-efi". The current approach is to name them based on the Debian package name. These packages do not need to end in "-efi". My use case is the following one. The final user requests: --bootloaders=grub-efi,syslinux so I show him: "Warning. You are using: syslinux as a non first bootloader. This might work but it is not advised." How do I know that I have to output this message? Because I compare the internal variable: LB_FIRST_BOOTLOADER="grub-efi" with the bootloader name "syslinux" and I see they are not the same one. So, as you see I need to use: "non first bootloader" term and LB_FIRST_BOOTLOADER variable. So... 1) I don't mind renaming "non first bootloader" or LB_FIRST_BOOTLOADER to another terminology which makes more technical sense. 2) I prefer this approach over yours (Michal) because it's the own bootloader which decides if it is more suited for "first bootloader" or not. Let's not repeat the current binary_iso design which has many references to the different available binary_bootloaders available. 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/
Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)
El 24/01/16 a las 16:51, Michal Suchanek escribió: The model does not imply any ranking. "First", "Second", "Third" could be justified, because there are lists in El Torito and partition tables where the boot entries have to line up in sequence. For my taste, "Main" or "Primary" too much implies a rank. So... what about using: FIRST_BOOTLOADER and SECOND_BOOTLOADER instead of my current: PRIMARY_BOOTLOADER and SECONDARY_BOOTLOADER why not BOOTLOADERS? The concept of being primary or secondary is just broken. You can store 64 el-torito catalog entries on a CD. The different entries are separated by -eltorito-alt-boot option. When you put the CD with a BIOS and EFI entry in a machine that prefers UEFI the efi entry is primary even when there is a CSM. When you put the CD into a machine with legacy BIOS the BIOS entry is primary in the EFI one useless. There are some technical details like it is desirable to put the BIOS entry before the EFI entry. This may be either enforced by reordering the bootloader list automagically or just by setting the default to syslinux,grub-efi and explaining in the docs that this is the usual order and changing the order may potentially cause issues. There are more technical details like the bootloader for i386 and amd64 BIOS is the same one and on EFI it's two different binaries. Or that when there is an EFI bootloader it's desirable to create another e-torito entry for it as APM to boot on Macs. The technical details of creating multiple partitions, boot entries, and whatnot are implementation details. It's nice to document these details somewhere for people who want to further butcher the created medium, add support for more bootloaders, etc. So basically what we have is support for two PC firmware types: BIOS EFI and two bootloader alternatives for each firmware type syslinux grub and for simlicity only one bootloader for one firmware type is supported on single medium. Since booting on BIOS platform is well supported with syslinux and booting on EFI platform is well-supported with grub it is desirable to have the option to specify different bootloader type for each supported platform and make it the default. So rather than BOOTLOADER=syslinux BOOT_FIRMWARE=bios,efi we have BOOTLOADERS=syslinux,grub-efi That is the bootloader name encodes the whole bootloader-firmware pair. There is no need to specify more. It is well possible to specify to not include 32bit efi binaries when building a 64bit CD build but that's *-efi installation option and not a separate bootloader type. This means the user can have 1-2 bootloaders on a single medium. And if coreboot or whatnot support is added in the future there is potential to have more. Thanks Michal What you are describing here is what it's actually implemented in my patch (Well, actually the first patch version because the current one enforces bootloader roles). So what about primary and secondary terms? Or first or second terms? These terms are used in two places: * Internal variables and functions to handle bootloaders * Information shown to the final user I'm most convinced to use the first and non-first notation. So that the old code that referred to LB_BOOTLOADER can just refer to: LB_FIRST_BOOTLOADER. Later on, if we want to improve this old code we can modify it so that it handles LB_BOOTLOADERS thanks to the bootloader functions directly. I agree with you that a good approach would be to document the different supported or suggested bootloader combinations rather than trying to enforce it by code. That would match my last thoughts which I quote here: And, well, I have some ideas on how to add some special functions to binary_bootloader files so that we have some sort of Object-Oriented / Hook programming when defining what goes into the mkisofs options. If you check current: binary_iso file it just relies on existing binary_bootloaders without having an agnostic bootloader approach. Here it's what I'm talking about: https://github.com/adrian15/live-build/blob/5eba3dff5a16a34c3c1eb5d54e3767339654e2d0/scripts/build/binary_iso#L111-L145 case "${LB_PRIMARY_BOOTLOADER}" in grub) (...) grub-pc) (...) esac We could just invent the: grub-pc-xorriso-options() or syslinux-xorriso-options() functions which would be defined in: binary_grub-pc or binary_syslinux files and handle all of these with only 3 or 4 lines of code. E.g. binary_iso would add '-eltorito-alt-boot' just before a second bootloader so that the bootloader only needs to take care of their own boot options. Is there anyone opposed to such a big change on live-build handling of bootloaders? adrian15 -- Support free software. Donate to Super Grub Disk. Apoya el software libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)
El 23/01/16 a las 09:21, Thomas Schmitt escribió: There is a fourth dimension to be expressed: Bootloader. Then there is the dimension of ISO filesystem objects. A user wish would contain at least ISO-Object, Bootloader, Medium, Firmware, Architecture E.g. Appended Partition, with GRUB2 content, for CDROM and HDD, via EFI, on i386 ISO Data File, with SYSLINUX content, for HDD, via BIOS, on i386 and amd64 I am not sure whether this list of more or less combinable dimensions is complete yet. Further one will want to express whether the gaps between partitions should be filled, which kinds of partition tables shall emerge, ... These properties are global to the ISO, not specific to a single boot image. Some are combinable, some are mutally exclusive. (Maybe it is time to break out an UML editor.) I propose you to send these concerns to live-wrapper project which has just begun and it's advertised as highly modular by Iain. It would be quite nice if all these concerns were properly addressed by Iain's tool. I am not saying that they are not welcomed to live-build but, right now, I think we should focus on making UEFI to boot and not re-thinking all the bootloader handling. grub-mkrescue layout is rarely used for distro ISOs. I blame this on the existing SYSLINUX based production software for distro ISOs. In principle, a pure GRUB2 or a pure SYSLINUX equipment appears to be the more reasonable choice. I once asked in a Debconf why the people were so stubborn to use syslinux instead of using grub2 (which seems technically superior to me). It would seem that the same people that maintain syslinux happen to maintain the kernel boot stack (or whatever it is called, I mean what happens just after the bootloader handling the execution to the kernel). So, that means, it's far easier to them to debug why the kernel is refusing to boot. I am personally in a favour of GRUB2-only Live CDs so that it's much easier to have native Super Grub2 Disk in them :) . Maybe we can just name them as: "Main bootloader" and "Alternate bootloader". The model does not imply any ranking. "First", "Second", "Third" could be justified, because there are lists in El Torito and partition tables where the boot entries have to line up in sequence. For my taste, "Main" or "Primary" too much implies a rank. So... what about using: FIRST_BOOTLOADER and SECOND_BOOTLOADER instead of my current: PRIMARY_BOOTLOADER and SECONDARY_BOOTLOADER ? I could even add a third bootloader if needed. And, well, I have some ideas on how to add some special functions to binary_bootloader files so that we have some sort of Object-Oriented / Hook programming when defining what goes into the mkisofs options. If you check current: binary_iso file it just relies on existing binary_bootloaders without having an agnostic bootloader approach. Here it's what I'm talking about: https://github.com/adrian15/live-build/blob/5eba3dff5a16a34c3c1eb5d54e3767339654e2d0/scripts/build/binary_iso#L111-L145 case "${LB_PRIMARY_BOOTLOADER}" in grub) (...) grub-pc) (...) esac We could just invent the: grub-pc-xorriso-options() or syslinux-xorriso-options() functions which would be defined in: binary_grub-pc or binary_syslinux files and handle all of these with only 3 or 4 lines of code. E.g. binary_iso would add '-eltorito-alt-boot' just before a second bootloader so that the bootloader only needs to take care of their own boot options. Is there anyone opposed to such a big change on live-build handling of bootloaders? adrian15 -- Support free software. Donate to Super Grub Disk. Apoya el software libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)
El 21/01/16 a las 10:13, Thomas Schmitt escribió: Hi, For the nomenclature: "USB" alone is misleading because there are also optical drives attachable to USB. Better distinguish the boot media families CDROM (CD, DVD, BD) and HDD (hard disk, USB stick, memory card, ...). Sorry. I was refering to USB stick then. adrian15 wrote: Grub-pc would be the one installed to be boot but syslinux files would be there for Multi-USB tools to know how to understand the iso and put it into an USB. You mean the capability to boot the ISO via BIOS from USB stick ? (Known with SYSLINUX as "isohybrid".) grub-pc is supposed to be bootable that way too. Have a look at the result of grub-mkrescue. When running xorriso -as mkisofs, the decisive trick of grub-mkrescue for BIOS bootability from HDD is: --grub2-mbr /usr/lib/grub/i386-pc/boot_hybrid.img (It is obvious that only one bootloader can put its MBR at the start of the ISO. So additional -isohybrid-mbr for SYSLINUX would conflict.) CDROM bootability via BIOS is caused by -b boot/grub/i386-pc/eltorito.img \ -no-emul-boot -boot-load-size 4 -boot-info-table \ --grub2-boot-info (Options learned from grub-mkrescue tests on Debian Sid.) Well, yes, I know that you can use grub-pc to be able to boot a single image that boots from either a hard disk / USB stick / CDROM media in a BIOS system. I did use that setup for building earlier versions of Rescatux (which included native Super Grub2 Disk in them). My first will on putting both syslinux and grub-pc in the same media had not the purpose of making it bootable with two methods but rather to: * Default boot into Grub2 (so that Super Grub2 Disk could be used natively). * Confuse multi usb stick tools such as yumi to think that the iso was actually isolinux based. That way they can easily extract iso contents and put it into a multi usb stick device. As I said before this was the original idea that made me add the primary and secondary bootloaders concept to live-build. --bootloaders="syslinux,grub-efi,syslinux-efi" Here i wonder whether (or how) your syslinux-efi boots out of an ISO 9660 filesystem. My current knowledge is that SYSLINUX cannot do this. Yeah, you are right. You can take a look at what I have left from Hertzog patch here: https://github.com/adrian15/live-build/commit/1397b6fc3dbf7d7f1e6a077a37b9f2e6ee7d7f39 His workaround for syslinux-efi not being able to boot out of an ISO 9660 filesystem is to put the bootloader files, kernel and initrd on the efi image. That way the efi image should be able to load the initrd in the ram so that the rest of the system can be found. (Back in the day in some old systems you had to do this trick, e.g., add these files to the old IDE attached disk because BIOS was unable to boot the SATA attached disk. But the initrd, yes, knew how to handle it.) Now primary means: "First lure" and secondary means "Second lure" by your definition. There are normally two lures per firmware-hardware combination. Depending on the medium, the lures are recognized in El Torito, or in MBR, or in partition tables. In general we have theses dimensions {Medium: CDROM, HDD} x {Firmware: BIOS, EFI, ... exotic others ...} x {Hardware: i386, amd64, ... exotic others ...} Not all tuples chosen from these sets are valid and not all valid tuples can be combined in one ISO filesystem. But the 8 main combinations for PC hardware are valid and combinable. I would avoid ranking terms like "first" or "primary". Job descriptions for bootloaders could rather look like (CDROM + HDD, BIOS, i386 + amd64) (HDD, EFI, i386) (HDD, EFI, amd64) Some of them can hardly be separated from each other. E.g. (HDD, BIOS, i386) and (HDD, BIOS, amd64) have identical technical properties. I am sorry. I agree with you but I'm not going to change my current naming without further input. I would need a patch from you or a concrete new naming system with examples that replace the current names. It seems you are proposing to add like three tags: Medium?, Firmware?, Architecture? but I don't get how that would transform into options that the final user can use. And, well, how would you go into enabling or not a given bootloader given a Medium?, Firmware?, Architecture? combination. I mean, don't get me wrong, I want to code this right but I'm not sure I understand why we need this. I mean, I know that the medium already choosing by either binary_hdd or binary_iso . And, the architectures can also be choosen if needed (LB_ARCHITECTURES if I'm not mistaken). Not sure why you want to question of all that out of a sudden. Anyway, as I said, maybe giving me concrete examples might make me change my mind. If we are going to implement UEFI support into live-build let's do it right. Given the way that both grub-efi and syslinux-efi use: /efi/boot/bootia32.efi and /efi/boo
Bug#812358: debian-live: Please add gparted
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/
Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)
El 21/01/16 a las 12:57, Thomas Schmitt escribió: adrian15 wrote: Do you mean if you have: xorriso bunch-of-options-1 -eltorito-alt-boot bunch-of-options-2 you could just re-arrange them as: xorriso bunch-of-options-2 -eltorito-alt-boot bunch-of-options-1 and it would be fine? From the view of xorriso and El Torito specs this is ok. You have to keep the modifier options (e.g. -boot-info-table) in the same -eltorito-alt-boot department as their main options (e.g. -b). The program isohybrid of SYSLINUX expects BIOS in El Torito catalog entry 1, EFI in entry 2, and HFS+ in entry 3. So with genisoimage + isohybrid, you'd have to keep the sequence. One never knows what firmware does with such changes. Normally it should accept any sequence. But tradition is: BIOS first, EFI second. I see. So when using syslinux it's better for it to be the primary bootloader. Ok. And, if I'm not mistaken doing a: --bootloaders="grub-efi" should be quite easy. That way people that want EFI only images would be able to make them. In order to do that I would just need to implement the primary bootloader behaviour of grub-efi and, well, remove the current grub-efi as a secondary bootloader role enforcement. I might finally do that. I wonder what EFI firmware would hop on an MBR partition of type 0x01. An EFI System Partition in MBR should have type 0xef to be recognized. That needs to be asked to Hertzog. I just tried to use his original work. Did you try whether it boots via EFI if no BIOS boot equipment is in the ISO ? Well, I tried: kvm -bios /usr/share/ovmf/OVMF.fd -boot d -cdrom file.iso . I probably need to do more tests later. If I'm not mistaken Hertzog removed that option because you suggested to remove it on: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731709#66 Are you requesting to put this option back ? Only if you augment the boot equipment by a third boot image that contains a small HFS+ filesystem. (See Fedora Live CD.) As long as there is no HFS+, the option -isohybrid-apm-hfsplus is inappropriate but seems to do no harm. (See Debian amd64 netinst.) I see. So the Fedora Live CD would seem even better. I wonder why the debian-cd team did not consider adding this third boot image with a small HFS+ filesystem. I'll probably ask them in the irc. There are two ways known to me how to get a boot path via HFS+: The debian-cd method is one of them? Or is it not? debian-cd has no HFS+ boot image. This makes it different from Fedora Live CD. Understood. The xorriso run could be easily adapted to include a HFS+ image. But i do not know how Matthew Garrett produced this image. I was doing some research on SElinux support and I found these set of tools for creating the Fedora Live CDs: https://github.com/rhinstaller/livecd-tools It's quite nice learning how other build their own live cd systems. Anyways, back to the main subject, I have no idea if Matthew Garrett used this tool or not. One would have to investigate its content and find some Mac filesystem tool to produce such content. Probably. The current debian-cd ( debian-8.2.0-amd64-i386-netinst.iso ) xorriso options are: [well known from file /.disk/mkisofs in the ISO] where you can see they use: -isohybrid-apm-hfsplus So... this is not useful for creating an HFS+ image file? No. It just announces the EFI boot image in an Apple Partition Map. This might be of use for GRUB2 if no other partition table points to that image. But debian-cd has an MBR partition 0xef and a GPT partition which point to that EFI boot image. (The GPT is to be ignored by all sane EFI implementations.) Ok. Did you mean "NOT to be ignored"? What does this option do instead then? It is surplus, currently. Maybe I'm just repeating what you are going to saying later in this email about how Grub2 handles boot in Mac systems. Regreattably i can only forward the rumor that Some (TM) Macs do not boot without HFS+ and its blessed files. They are in the time window between Apple Inc. giving up PowerPC and Apple Inc. adopting EFI. I have one of them in that window. I'm not sure about the blessing being needed though. Maybe I have disabled it. Not sure. A) Are you complaining about syslinux-efi on: -append_partition 2 0x01 that should be: -append_partition 2 0xef instead? Yes. UEFI 2.4 5.2.2 says about booting from MBR partitions: "* 0xEF (i.e., UEFI System Partition) defines a UEFI system partition." The presence of GPT would have to be announced by a "protective MBR" partition of type 0xee with start at LBA 1. Any MBR partition type other than 0x00 and 0xee prevents the recognition of GPT. Maybe that's why the syslinux-efi does not boot. I could give it a try changing the partition type and see what happens. grub-mkrescue -o output.iso minimal_dir Last time I checked it did not work ok in Debian because the commit the grub package was based was too old. I recently teste
Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)
El 21/01/16 a las 10:13, Thomas Schmitt escribió: Now primary means: "First lure" and secondary means "Second lure" by your definition. There are normally two lures per firmware-hardware combination. Depending on the medium, the lures are recognized in El Torito, or in MBR, or in partition tables. In general we have theses dimensions {Medium: CDROM, HDD} x {Firmware: BIOS, EFI, ... exotic others ...} x {Hardware: i386, amd64, ... exotic others ...} Not all tuples chosen from these sets are valid and not all valid tuples can be combined in one ISO filesystem. But the 8 main combinations for PC hardware are valid and combinable. I would avoid ranking terms like "first" or "primary". Job descriptions for bootloaders could rather look like (CDROM + HDD, BIOS, i386 + amd64) (HDD, EFI, i386) (HDD, EFI, amd64) Some of them can hardly be separated from each other. E.g. (HDD, BIOS, i386) and (HDD, BIOS, amd64) have identical technical properties. I was thinking on this. So... what if there is a fourth dimension for choosing if the job description goes first or second in the mkisofs command? E.g.: xorriso bunch-of-options-1 -eltorito-alt-boot bunch-of-options-2 versus xorriso bunch-of-options-2 -eltorito-alt-boot bunch-of-options-1 So you don't like the primary or secondary terms. How does xorriso name them? Given that man xorrisofs talks about: -eltorito-alt-boot maybe we can just name them as: "Main bootloader" and "Alternate bootloader". Or maybe even better: "Main eltorito entry" and "Alternate eltorito entry" ? So that we can force a given bootloader to be used only as a "Main eltorito entry" ? What do you think about this idea? adrian15 -- Support free software. Donate to Super Grub Disk. Apoya el software libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)
Despite of being discussing how to implement all of these properly. I feel it's right to show you my current work so that you can comment on it. I attach my updated patches. 1) The main differences from my original patches are: * I use more additional bootloader functions * The code ensures that each bootloader can be used in its role, being it a primary bootloader o a secondary bootloader. That way we avoid the user being able to generate non bootable isos. 2) For the time being I am not maintaining the syslinux-efi branch till we manage to get a consensus on this one. Then I will rebase it, change the partition type and re-test it. 3) As I have mentioned in another message I plan to work on giving the user the ability of creating isos using: --bootloaders="grub-efi" thus using grub-efi as a primary bootloader. 4) The patches can be found as a git branch (based on live-build master branch) here: https://github.com/adrian15/live-build/tree/efi_support_based_on_debian_cd_rebased_4 adrian15 -- Support free software. Donate to Super Grub Disk. Apoya el software libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/ commit ff8206aea1985760dfea9ec94b93686a242f137e Author: Adrian Gibanel Lopez <adrian.giba...@btactic.com> Date: Mon Jan 18 03:04:00 2016 + functions/default.sh : Define LB_PRIMARY_BOOTLOADER at the Set_defaults function which it's the right place where to do it diff --git a/functions/defaults.sh b/functions/defaults.sh index ddf4b19..334984f 100755 --- a/functions/defaults.sh +++ b/functions/defaults.sh @@ -537,6 +537,8 @@ Set_defaults () esac fi + LB_PRIMARY_BOOTLOADER=$(echo "${LB_BOOTLOADERS}" | awk -F, '{ print $1 }') + # Setting checksums case "${LB_MODE}" in progress-linux) @@ -845,9 +847,6 @@ Check_defaults () fi fi - - 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 commit b3ec155600f79b6ac078ae8003e806735044a372 Author: Adrian Gibanel Lopez <adrian.giba...@btactic.com> Date: Wed Jan 20 00:53:53 2016 +0100 Remove repeated LB_PRIMARY_BOOTLOADER definition diff --git a/scripts/build/binary_hdd b/scripts/build/binary_hdd index d0db382..0c9c5af 100755 --- a/scripts/build/binary_hdd +++ b/scripts/build/binary_hdd @@ -67,8 +67,6 @@ do esac done -LB_PRIMARY_BOOTLOADER=$(echo "${LB_BOOTLOADERS}" | awk -F, '{ print $1 }') - case ${LB_PRIMARY_BOOTLOADER} in syslinux) case ${LB_BINARY_FILESYSTEM} in diff --git a/scripts/build/binary_iso b/scripts/build/binary_iso index d8b1553..67dfc85 100755 --- a/scripts/build/binary_iso +++ b/scripts/build/binary_iso @@ -107,8 +107,6 @@ then XORRISO_OPTIONS="${XORRISO_OPTIONS} -V \"${LB_ISO_VOLUME}\"" fi -LB_PRIMARY_BOOTLOADER=$(echo "${LB_BOOTLOADERS}" | awk -F, '{ print $1 }') - # Handle xorriso architecture specific options case "${LB_PRIMARY_BOOTLOADER}" in grub) commit e0abb8214b9ff71630220a24564a8770cea8658e Author: Adrian Gibanel Lopez <adrian.giba...@btactic.com> Date: Mon Jan 18 03:07:48 2016 + * Added: functions/bootloaders.sh . It has new bootloader functions that are heavily used in efi scenarios where a bootloader can act as a primary or a secondary bootloader. Since the introduction of the new switch: --bootloaders you can setup it like this: --bootloaders=syslinux,grub-efi . This means that syslinux is the primary bootloader and grub-efi is the secondary bootloader. * Added new bootloader functions: Check_Non_Primary_Bootloader and Check_Non_Secondary_Bootloader. These functions let each one of the bootloaders abort the build because they cannot perform a role either as a primary bootloader or as a secondary bootloader. * Added bootloader functions: Check_Primary_Bootloader_Role, Check_Secondary_Bootloader_Role and Check_Any_Bootloader_Role These functions let bootloaders to force their default role in a single line. diff --git a/functions/bootloaders.sh b/functions/bootloaders.sh new file mode 100644 index 000..0829903 --- /dev/null +++ b/functions/bootloaders.sh @@ -0,0 +1,128 @@ +#!/bin/sh + +## live-build(7) - System Build Scripts +## Copyright (C) 2016 Adrian Gibanel Lopez <adrian15...@gmail.com> +## +## 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. + +Is_Primary_Bootloader () +{ + EVAL_PRIMARY_BOOTLOADER="${1}" + + if [ &q
Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)
El 18/01/16 a las 12:57, Michal Suchanek escribió: Unless the user requests two bootloaders that are incompatible the medium can be created. Ignoring bootloaders is not a good idea. If the user requested something that is not possible the build should report an error and stop. Yeah, that it's hard to implement from the perspective of a single bootloader script. So I decided not to implement it. You could add an additional script or function named: check_compatible_bootable_pairs (as you propose) but then you need to maintain that fictional database each time a new bootloader gets in. That's why I decide to avoid it using it. What it's straight-forward to implement is one of the only-secondary bootloaders finding themselves as a primary bootloader and outputting a warning message. But, I'm not sure what to put there as a warning. Any suggestion? Unsupported bootloader combination or whatever. It should not be a warning however. The script should avoid making unbootable medium. Thanks Michal I have implemented: Check_Primary_Bootloader_Role, Check_Secondary_Bootloader_Role functions for avoiding non supported bootloader combinations on: https://github.com/adrian15/live-build/tree/efi_support_based_on_debian_cd_rebased So that part is solved. (I'll send a proper rebased set of patches in the future). adrian15 -- Support free software. Donate to Super Grub Disk. Apoya el software libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)
El 18/01/16 a las 13:38, Thomas Schmitt escribió: Hi, adrian15 wrote: * What is it a secondary bootloader? It's what happens when you request mkisofs that your bootloader to be boot in second place or as a second partition. I don't know how it actually works. An ISO may contain several lures for boot firmware. If it is booted from CD/DVD/BD, then the lures are in the El Torito boot catalog. In case of debian-cd it contains two entries which point to boot images. One entry is marked as suitable for BIOS and one marked as suitable for EFI. The boot firmware then picks what it deems right and starts it, or offers it to the user for starting. Interesting. If the ISO is presented on USB stick or alike, then BIOS looks for the magic number of an MBR and if so, mindlessly executes the x86 machine code that starts at byte 0 of the ISO. This code then hops onto the same boot code that is advertised by El Torito (because xorriso or isohybrid patched its block address into the MBR code). Aha. EFI looks on USB stick for an MBR partition of type 0xef or for a single partition of type 0xee. In the latter case it assumes the presence of GPT and looks for a GPT partition with type GUID 28732ac11ff8d211ba4b00a0c93ec93b. Inside the found partition it expects a FAT filesystem and particular binaries for each supported processor archictecture. E.g. \EFI\BOOT\BOOTX64.EFI The El Torito EFI boot image has the same content specification as the EFI System Partition. Therefore both boot paths can share the same data. My cheat sheet is at http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/view/head:/doc/boot_sectors.txt Great! I want to document the different ways of how BIOS boot, UEFI boot and Secure Boot work and that might be helpful. - So, I guess the -eltorito-alt-boot does the magic but I'm not sure. Maybe someone else can explain it better than me. -eltorito-alt-boot is simply a separator between the options of El Torito boot images. I assume your first boot image is announced by -b and gets the usual options -no-emul-boot -boot-load-size 4 -boot-info-table Before the announcement of the EFI boot image begins, option -eltorito-alt-boot is needed to protect your -b and its helpers from being overwritten. That it's quite interesting. Do you mean if you have: xorriso bunch-of-options-1 -eltorito-alt-boot bunch-of-options-2 you could just re-arrange them as: xorriso bunch-of-options-2 -eltorito-alt-boot bunch-of-options-1 and it would be fine? So that it's not strictly necessary for syslinux or grub-pc to be a primary bootloader (or first lure in your definition) ? That would also simplify my contributed code to live-build by not needing to handle if a bootloader is primary/secondary or not. So in grub-efi we just add to the xorriso options: -eltorito-alt-boot \ -e boot/grub/efi.img \ -no-emul-boot \ -isohybrid-gpt-basdat \ -isohybrid-apm-hfsplus Here a second boot image gets announced by -e and the next three options apply to it. Ok. And in syslinux-efi (currently) we add: -eltorito-alt-boot \ --efi-boot boot/efi.img \ Option --efi-boot is a shortcut for -eltorito-alt-boot -e ... -no-emul-boot -eltorito-alt-boot normally used by grub-mkrescue. The SYSLINUX community prefers -e. Knowing that I will probably expand that so that the syslinux-efi and grub-efi options are more similar and we can compare them in a more easy manner. -append_partition 2 0x01 \ binary/boot/efi.img I wonder what EFI firmware would hop on an MBR partition of type 0x01. An EFI System Partition in MBR should have type 0xef to be recognized. That needs to be asked to Hertzog. I just tried to use his original work. It looks like this variant will not get GPT. That's fully compliant to UEFI 2.4. Just the MBR partition type should be 0xef. (Does "syslinux-efi" mean that you can boot from ISO via EFI and SYSLINUX stuff to an operating system ? That would be new.) I don't know what you mean by 'SYLINUX stuff to an operating system. I understand that Hertzog work let's you boot into the cd booting by the means of EFI. The EFI image needs to include the configuration file (as opossed to the grub-efi implementation which only stores its configuration file in the CD/DVD/BD media). --- Above options do not produce HFS+ with blessing. Option -isohybrid-apm-hfsplus causes an Apple Partition Map entry which points to the data content of boot/grub/efi.img. If I'm not mistaken Hertzog removed that option because you suggested to remove it on: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731709#66 Are you requesting to put this option back ? There are two ways known to me how to get a boot path via HFS+: Fedora Live CD as of Matthew Garrett or grub-mkrescue as of Vladimir Serbinenko. The debian-cd method is o
Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)
El 18/01/16 a las 14:00, Thomas Schmitt escribió: So any bootloader is made primary by leaving out -eltorito-alt-boot. There is no "primary" or "secondary" on the level of boot images and loaders. (Of course you may call them this way in your project.) There are first, second, third ... El Torito boot images or MBR, GPT, APM partition entries. The sequence is just needed because not all can be first in the list. The boot firmware inspects the medium for its known lures, picks a tasty one, and follows it to the boot loader or kernel. So, yes, I'm the one who invented the term primary for live-build. Actually, it was not meant for alt El Torito boot entries (or non first entries as you clarify). The first idea was to add both syslinux and grub-pc in the same image. Grub-pc would be the one installed to be boot but syslinux files would be there for Multi-USB tools to know how to understand the iso and put it into an USB. The Grub-pc bits were thought in first place for Super Grub2 Disk (which it is Grub2 cfg files mainly). (Now that I think of the current 'check primary bootloader role' functions unable me to perform that Super Grub2 Disk Debian Live that included the Syslinux bits too. Anyways I'll find a workaround for that in the future. Not a priority right now.) Now primary means: "First lure" and secondary means "Second lure" by your definition. Currently there's no way to stop you from requesting: --bootloaders="syslinux,grub-efi,syslinux-efi" Given the way that both grub-efi and syslinux-efi use: /efi/boot/bootia32.efi and /efi/boot/bootx64.efi the last one to be run would overwrite the first one efi files. You can probably use only one legacy bootloader but syslinux-efi and grub-efi use different files so it should be possible to install both. I am not sure how selecting one or the other would work, though. You can offer several EL Torito boot images for BIOS, indeed. It will depend on your BIOS what it does in this case. Interesting. There can be only one MBR, though. So you would have to hop by MBR x86 code to a standalone program which chooses among the BIOS suitable El Torito boot images. With EFI it makes few sense to offer more than one El Torito boot image or EFI System Partition. UEFI 2.4 rather prescribes to handle all alternatives inside the FAT filesystem. The firmware will start the \EFI\BOOT\BOOT*.EFI binary which it deems suitable for its processor type. This binary is quite free in its further proceedings. So... How would you go about for a: --bootloaders="syslinux,grub-efi,syslinux-efi" to make sense if, as I have stated earlier (although I might have missed something there) they would overwrite their /efi/boot/boot*efi files ? adrian15 -- Support free software. Donate to Super Grub Disk. Apoya el software libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)
A quick update on my grub-efi work: 1) I have noticed I have missed to give execution permissions to many files when I rebased. These are: scripts/build/binary_grub-efi scripts/build/binary_syslinux-efi scripts/build/efi-image scripts/build/grub-cpmodules You can find additional commits to fix this situation on: https://github.com/adrian15/live-build/tree/efi_support_based_on_debian_cd_rebased and https://github.com/adrian15/live-build/commits/syslinux-efi-2016 . (I will probably do another rebase in another branch in the future with other of your suggestions and these fixes.) 2) I have released Rescatux 0.40 beta 5 based on: https://github.com/adrian15/live-build/tree/rescatux-0.40b5 (The patches you have already seen + execution permissions fixed) . It is built by using: --bootloaders="syslinux,grub-efi" . You can find more information about it and download links on: http://www.supergrubdisk.org/2016/01/18/rescatux-0-40-beta-5-released/ Remember that if you want to test it into a USB drive you need to do the 'dd' if you want it to work ok and that means DESTROYING your data in the USB drive. adrian15 -- Support free software. Donate to Super Grub Disk. Apoya el software libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)
El 18/01/16 a las 07:31, Michal Suchanek escribió: Hello, thanks for working on this. On 18 January 2016 at 05:24, adrian15 <adrian15...@gmail.com> wrote: In my last message I forgot to CC many people who are involved in this bug so I'm going to refer to my former message, CC some people and finally point you to my repo/branches where you might find interesting commits. 1) My original message with attached patches (which you can download to your email program and reply from there) can be found at: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731709#153 2) Repo / Branches: * efi_support_based_on_debian_cd ( https://github.com/adrian15/live-build/tree/efi_support_based_on_debian_cd ) : Original dirty branch where I worked in both syslinux-efi and grub-efi bootloaders at the same time * efi_support_based_on_debian_cd_rebased ( https://github.com/adrian15/live-build/tree/efi_support_based_on_debian_cd_rebased ) : The same branch rebased to have minimal useful commits. syslinux-efi was removed from it because it did not boot. I have checked what EFI platforms I have and it seems neither would be bootable with this. 1) a Windows tablet that needs signed bootloader - signed grub is available as non-free package (because it cannot be modified to not break the signature) and presumably allows booting on such systems without going through the unlocking stuff which may break your windows installation. Yeah, that's the Microsoft Secure Boot. debian-cd people are working on bringing it into official Debian CDs. There is not a fixed date for that but everything points that it will be finished within 2016. Once they manage to do so I'll see how easy it is to port into this work. You can always try virtual systems. This is how I currently test this: kdesudo "kvm -bios /usr/share/ovmf/OVMF.fd -cdrom rescatux-0.40b3.iso -boot d -m 512" . 2) a mac mini which probably needs a GPT and the bootloader stored on a HFS+ volume or something. Also the bootloader needs to be 'blessed'. Command for that exists in grub and crashes. Never got this working on an USB stick. Well, I have not mentioned that this implementation (based on debian-cd team work) also would support intel based mac systems because it has an additional HFS+ volume. I also have a mac book pro myself and the 'hybrid' version of Super Grub2 Disk 2.02s3 works for me (when using ALT key at boot). I don't remember having blessed it so... I'm unsure about the need (or not) to bless it. So, the 'hybrid' Super Grub2 Disk 2.02s3 also has an additional HFS+ partition (as our current implementation here in these patches) put in place for mac book compatibility so I guess that this build will also boot in my system but I still need to test it. As to the primary and secondary bootloader - how is the efi bootloader secondary? It boots the same as the legacy bootloader. You probably want a concept of compatible bootloaders - that is pairs of bootloaders that can be installed alongside on the same medium. * What is it a secondary bootloader? It's what happens when you request mkisofs that your bootloader to be boot in second place or as a second partition. I don't know how it actually works. So in grub-efi we just add to the xorriso options: -eltorito-alt-boot \ -e boot/grub/efi.img \ -no-emul-boot \ -isohybrid-gpt-basdat \ -isohybrid-apm-hfsplus And in syslinux-efi (currently) we add: -eltorito-alt-boot \ --efi-boot boot/efi.img \ -append_partition 2 0x01 \ binary/boot/efi.img . So, I guess the -eltorito-alt-boot does the magic but I'm not sure. Maybe someone else can explain it better than me. * About current compatible bootloaders. The technology is there. I mean. This is what it's currently available: binary_grub-efi : Secondary bootloader binary_grub-legacy : Primary bootloader binary_grub-pc : Primary bootloader binary_syslinux : Primary bootloader binary_syslinux-efi : Secondary bootloader so that means, in theory you can request one of these 9 combinations: grub-legacy grub-pc syslinux grub-legacy,grub-efi grub-pc,grub-efi syslinux,grub-efi grub-legacy,syslinux-efi grub-pc,syslinux-efi syslinux,syslinux-efi Why can't you request: grub-efi or grub-efi,syslinux-efi ? Because nobody has coded grub-efi installed as a primary bootloader yet. But the 'framework' is there. You either need to improve binary_grub-efi or create another script file that does its job when ' Is_Primary_Bootloader "grub-efi" ' is true. Unless the user requests two bootloaders that are incompatible the medium can be created. Ignoring bootloaders is not a good idea. If the user requested something that is not possible the build should report an error and stop. Yeah, that it's hard to implement from the perspective of a single bootloader script. So I decided not to implement it. You could add an additional script or function named: check_compatible_bootable_pairs (as you propose) but
Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)
In my last message I forgot to CC many people who are involved in this bug so I'm going to refer to my former message, CC some people and finally point you to my repo/branches where you might find interesting commits. 1) My original message with attached patches (which you can download to your email program and reply from there) can be found at: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731709#153 2) Repo / Branches: * efi_support_based_on_debian_cd ( https://github.com/adrian15/live-build/tree/efi_support_based_on_debian_cd ) : Original dirty branch where I worked in both syslinux-efi and grub-efi bootloaders at the same time * efi_support_based_on_debian_cd_rebased ( https://github.com/adrian15/live-build/tree/efi_support_based_on_debian_cd_rebased ) : The same branch rebased to have minimal useful commits. syslinux-efi was removed from it because it did not boot. * syslinux-efi-2016 ( https://github.com/adrian15/live-build/tree/syslinux-efi-2016 ) : This branch adds and enables the latest version of syslinux-efi (rebased) but it does not boot. adrian15 -- Support free software. Donate to Super Grub Disk. Apoya el software libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
Bug#731709: binary_syslinux-efi based on latest work on live-build master branch for grub-efi support
So this is the patch from Raphael Hertzog that you all know but adapted to be used from my last work. Unfortunately it does not seem to boot in my virtual machine test. Raphael can you take a look at it just in case it's a minor problem? I'm also interested in being able to make cdroms with syslinux-efi. The quick and dirty branch where I worked on both grub-efi and syslinux-efi is here: https://github.com/adrian15/live-build/tree/efi_support_based_on_debian_cd That branch is handy to understand the changes between Raphael's original patch and what I present here. adrian15 -- Support free software. Donate to Super Grub Disk. Apoya el software libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/ commit 1397b6fc3dbf7d7f1e6a077a37b9f2e6ee7d7f39 Author: Adrian Gibanel Lopez <adrian.giba...@btactic.com> Date: Mon Jan 18 03:37:01 2016 + Initial implementation of: binary_syslinux-efi based on latest work on live-build master branch for grub-efi support. In order to test this new script you need to specify at lb config: --bootloaders=syslinux,syslinux-efi . This work is based on this original patch: https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=103;bug=731709;att=1;filename=Add-support-for-EFI-boot-with-syslinux-efi.patch This is currently not working in my EFI test virtual machine. Let's hope the original author of the patch can take a look and, maybe fix a minor bug. diff --git a/manpages/en/lb_config.1 b/manpages/en/lb_config.1 index 7e3c956..830965d 100644 --- a/manpages/en/lb_config.1 +++ b/manpages/en/lb_config.1 @@ -39,7 +39,7 @@ .br [\fB\-\-bootappend\-live\fR \fIPARAMETER\fR|\fI"PARAMETERS"\fR] .br - [\fB\-\-bootloader\fR grub|grub2|syslinux|grub-efi] + [\fB\-\-bootloader\fR grub|grub2|syslinux|grub-efi|syslinux-efi] .br [\fB\-\-cache\fR true|false] .br @@ -263,7 +263,7 @@ defines the filesystem to be used in the image type. This only has an effect if sets boot parameters specific to debian\-installer, if included. .IP "\fB\-\-bootappend\-live\fR \fIPARAMETER\fR|""\fIPARAMETERS\fR""" 4 sets boot parameters specific to debian\-live. A complete list of boot parameters can be found in the \fIlive\-boot\fR(7) and \fIlive\-config\fR(7) manual pages. -.IP "\fB\-\-bootloader\fR grub|grub2|syslinux|grub-efi" 4 +.IP "\fB\-\-bootloader\fR grub|grub2|syslinux|syslinux-efi" 4 defines which bootloader is being used in the generated image. This has only an effect if the selected binary image type does allow to choose the bootloader. For example, if you build a iso, always syslinux (or more precise, isolinux) is being used. Also note that some combinations of binary images types and bootloaders may be possible but live\-build does not support them yet. \fBlb config\fR will fail to create such a not yet supported configuration and give a explanation about it. For hdd images on amd64 and i386, the default is syslinux. .IP "\fB\-\-cache\fR true|false" 4 defines globally if any cache should be used at all. Different caches can be controlled through the their own options. diff --git a/scripts/build/binary b/scripts/build/binary index 7b0d743..7e30f27 100755 --- a/scripts/build/binary +++ b/scripts/build/binary @@ -70,6 +70,7 @@ lb binary_win32-loader ${@} lb binary_includes ${@} lb binary_hooks ${@} lb binary_grub-efi ${@} +lb binary_syslinux-efi ${@} lb binary_checksums ${@} if [ "${LB_BUILD_WITH_CHROOT}" != "true" ] diff --git a/scripts/build/binary_iso b/scripts/build/binary_iso index 5d612b5..41331a1 100755 --- a/scripts/build/binary_iso +++ b/scripts/build/binary_iso @@ -157,6 +157,23 @@ then fi fi +if Is_Secondary_Bootloader "syslinux-efi" +then + if [ -e binary/boot/efi.img ] + then + Echo "Using older EFI command line for xorriso $XORRISO_VER" + # Tell xorriso to create a secondary ElTorito boot record for the + # EFI bootloader + XORRISO_OPTIONS="${XORRISO_OPTIONS} -eltorito-alt-boot --efi-boot boot/efi.img" + # Add the efi image as a FAT partition too, so our CD image will + # also boot on a USB key (like isohybrid, just implemented + # differently) + XORRISO_OPTIONS="${XORRISO_OPTIONS} -append_partition 2 0x01 binary/boot/efi.img" + else + Echo "No EFI boot code to include in the ISO" + fi +fi + #if [ "${LB_DEBIAN_INSTALLER}" != "live" ] #then # XORRISO_OPTIONS="${XORRISO_OPTIONS} -m ${XORRISO_EXCLUDE}" diff --git a/scripts/build/binary_syslinux-efi b/scripts/build/binary_syslinux-efi new file mode 100644 index 000..d70e0fd --- /dev/null +++ b/scripts/build/binary_syslinux-efi @@ -0
Bug#731709: grub-efi UEFI support based on debian-cd work complete
These patches apply to current live-build master branch. Each of one the patches have their own explanation based on a git commit. Maybe I have missed to say that the grub-efi UEFI support which it's based on Debian-CD work not only supports to boot from UEFI 64 bit systems but also from UEFI 32 bit systems. I have not tested myself if UEFI 32 bit boots or not but I don't know why it should not. Feedback is welcome. As most email programs would show the attached text ready for you to quote I don't think I need to explain too much more about them. The reason why I have up to 7 patches is because either each one of them focus in one task or I have thought you might want to use it or not (Well, it's mainly: 007-syslinux-grub-efi-default-bootloaders.diff which enforces every ISO to have UEFI support). Finally loopback_cfg which renders grub.cfg shows us a blue raw grub menu which it's not fun but it's functional. Maybe we could reuse some work from jnqnfe from #775322 but I'm not going to do that. Maybe in the future for using in Rescatux but not in the short term. The other option is trying to reuse debian-cd or debian-installer scripts which let you translate syslinux configuration files into grub configuration files. Feedback is welcome! P.S.: I am going to release soon: Rescatux 0.40b3 which will be based on these commits so you will be able to see how it would perform the final product. adrian15 -- Support free software. Donate to Super Grub Disk. Apoya el software libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/ commit 40d86ad27d48a0d00318b7f3ec088704778c67ad Author: Adrian Gibanel Lopez <adrian.giba...@btactic.com> Date: Mon Jan 18 03:01:15 2016 + Stolen efi-image and grub-cpmodules from src:live-installer These two scripts simplify the creation of efi images based on grub-efi. I have decided to simply steal them. If I had to include them thanks to a source package that would have mean that an src repo would have to be defined by default. TODO: Ask in a bug a RFE so that these two scripts are put into a binary that could be consumed by both live-installer and live-build packages. diff --git a/scripts/build/efi-image b/scripts/build/efi-image new file mode 100644 index 000..724095f --- /dev/null +++ b/scripts/build/efi-image @@ -0,0 +1,85 @@ +#! /bin/sh +set -e + +# Copyright (C) 2010, 2011 Canonical Ltd. +# Author: Colin Watson <cjwat...@ubuntu.com> +# +# This program is free software; you can redistribute it and/or modify it +# under the terms of the GNU General Public License as published by the Free +# Software Foundation; either version 2, or (at your option) any later +# version. +# +# This program is distributed in the hope that it will be useful, but +# WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY +# or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +# for more details. +# +# You should have received a copy of the GNU General Public License along +# with this program; if not, write to the Free Software Foundation, Inc., +# 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA. + +# Make an EFI boot image. + +if [ -z "$1" ] || [ -z "$2" ]; then + echo "usage: $0 OUTPUT-DIRECTORY GRUB-PLATFORM EFI-NAME NETBOOT-PREFIX" + exit 1 +fi + +outdir="$1" +platform="$2" +efi_name="$3" +netboot_prefix="$4" + +memdisk_img= +workdir= + +cleanup () { + [ -z "$memdisk_img" ] || rm -f "$memdisk_img" + [ -z "$workdir" ] || rm -rf "$workdir" +} +trap cleanup EXIT HUP INT QUIT TERM + +rm -rf "$outdir" +mkdir -p "$outdir" + +memdisk_img="$(mktemp efi-image.XX)" +workdir="$(mktemp -d efi-image.XX)" + +# Skeleton configuration file which finds the real boot disk. +mkdir -p "$workdir/boot/grub" +cat >"$workdir/boot/grub/grub.cfg" <"$outdir/boot/grub/$platform/grub.cfg" + +# Build the core image. +(cd "$workdir"; tar -cf - boot) >"$memdisk_img" +grub-mkimage -O "$platform" -m "$memdisk_img" \ + -o "$workdir/boot$efi_name.efi" -p '(memdisk)/boot/grub' \ + search iso9660 configfile normal memdisk tar part_msdos part_gpt fat + +grub-mkimage -O "$platform" \ + -o "$outdir/bootnet$efi_name.efi" -p "$netboot_prefix/grub" \ + search configfile normal efinet tftp net + +# Stuff it into a FAT filesystem, making it as small as possible. 24KiB +# headroom seems to be enough; (x+31)/32*32 rounds up to multiple of 32. +mkfs.msdos -C "$outdir/efi.img" \ + $(( ($(stat -c %s "$workdir/boot$efi_name.efi") / 1024 + 55) \ + / 32 * 32 )) +mmd -i "$outdir/efi.img" ::efi +mmd -i "$outdir/efi.img" ::efi/boot +mcopy
Bug#731709: Updated EFI patch
I attach a patch based on your work (which I have not tested so feedback is welcome). You can find the specific modifications to your original commit/patch (which I had to cherry-pick) on branch: https://github.com/adrian15/live-build/tree/efi_support_based_on_debian_cd Now I'm going to work on grub-efi support based on debian-cd / Lernstick work so that we can probably have also Secure Boot by default. So, to make it clear, after my changes you would need to add or modify live config parametres to have: --bootloaders="syslinux,syslinux-efi" in order for it to work. Do not expect me not to improve this patch even more because I'm going to add 'grub-efi' which it's going to be based on debian-cd. And that means some conflicts in the way of doing the final ISO. And, well, then the final idea is to have the syslinux-efi as a backup method and the grub-efi would be the default one. I will make an specific commit for it. So, yes, feedback is welcome for this patch and for my other ideas. El 11/12/14 a las 10:58, Raphael Hertzog escribió: Attached is an updated patch that works on top of 4.0.4 (change needed to replace LIVE_IMAGE_ARCHITECTURE with LB_ARCHITECTURES). Cheers, 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/lb_config.1 b/manpages/en/lb_config.1 index 8e1f4f7..e3482b2 100644 --- a/manpages/en/lb_config.1 +++ b/manpages/en/lb_config.1 @@ -39,7 +39,7 @@ .br [\fB\-\-bootappend\-live\fR \fIPARAMETER\fR|\fI"PARAMETERS"\fR] .br - [\fB\-\-bootloader\fR grub|grub2|syslinux] + [\fB\-\-bootloader\fR grub|grub2|syslinux|syslinux-efi] .br [\fB\-\-cache\fR true|false] .br @@ -263,7 +263,7 @@ defines the filesystem to be used in the image type. This only has an effect if sets boot parameters specific to debian\-installer, if included. .IP "\fB\-\-bootappend\-live\fR \fIPARAMETER\fR|""\fIPARAMETERS\fR""" 4 sets boot parameters specific to debian\-live. A complete list of boot parameters can be found in the \fIlive\-boot\fR(7) and \fIlive\-config\fR(7) manual pages. -.IP "\fB\-\-bootloader\fR grub|grub2|syslinux" 4 +.IP "\fB\-\-bootloader\fR grub|grub2|syslinux|syslinux-efi" 4 defines which bootloader is being used in the generated image. This has only an effect if the selected binary image type does allow to choose the bootloader. For example, if you build a iso, always syslinux (or more precise, isolinux) is being used. Also note that some combinations of binary images types and bootloaders may be possible but live\-build does not support them yet. \fBlb config\fR will fail to create such a not yet supported configuration and give a explanation about it. For hdd images on amd64 and i386, the default is syslinux. .IP "\fB\-\-cache\fR true|false" 4 defines globally if any cache should be used at all. Different caches can be controlled through the their own options. diff --git a/scripts/build/binary b/scripts/build/binary index 56c7bf8..1668b8c 100755 --- a/scripts/build/binary +++ b/scripts/build/binary @@ -69,6 +69,9 @@ lb binary_loadlin ${@} lb binary_win32-loader ${@} lb binary_includes ${@} lb binary_hooks ${@} +lb binary_syslinux-efi ${@} # After includes/hooks because it copies in efi.img + # files that can be overriden by binary_includes and + # modified by binary_hooks lb binary_checksums ${@} if [ "${LB_BUILD_WITH_CHROOT}" != "true" ] diff --git a/scripts/build/binary_iso b/scripts/build/binary_iso index d8b1553..2b52938 100755 --- a/scripts/build/binary_iso +++ b/scripts/build/binary_iso @@ -140,12 +140,25 @@ case "${LB_PRIMARY_BOOTLOADER}" in ;; *) - Echo_warning "Bootloader on your architecture not yet supported by live-build." + Echo_warning "Bootloader on your architecture not yet supported by live-build as the primary bootloader." Echo_warning "This will produce a most likely not bootable image (Continuing in 5 seconds)." sleep 5 ;; esac +if [ -e binary/boot/efi.img ]; then + Echo "Using older EFI command line for xorriso $XORRISO_VER" + # Tell xorriso to create a secondary ElTorito boot record for the + # EFI bootloader + XORRISO_OPTIONS="${XORRISO_OPTIONS} -eltorito-alt-boot --efi-boot boot/efi.img" + # Add the efi image as a FAT partition too, so our CD image will + # also boot on a USB key (like isohybrid, just implemented + # differently) + XORRISO_OPTIONS="${XORRISO_OPTIONS} -append_partition 2 0x01 binary/boot/efi.img" +else + Echo "No EFI boot code to include in the ISO" +fi + #if [ "${LB_DEBIAN_INSTALLER}" != "live" ] #then # XORRISO_OPTIONS="${XORRISO_OPTIONS} -m ${XORRISO_EXCLUDE}" diff --git a/scripts/build/binary_syslinux-efi b/scripts/build/binary_syslinux-efi ne
Bug#803883: samusrgrp.c: Interactive TYPO
Package: chntpw Version: 1.0-1 Severity: minor Dear Maintainer, "Command line utility, non-inreractive to add or remove a user to/from" on samusrgrp.c file. It should be: "non-interactive" instead of "non-inreractive". Patch to upstream code which solves this issue can be found at: https://github.com/adrian15/chntpw/commit/684d32504e4875fcb647544cb83903b375f22505 Additional note: I already contacted upstream author but received no answer for about half a year, so I guess it's fine pushing this to Debian. -- System Information: Debian Release: 8.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#803890: chntpw: New samunlock binary. Unlock windows users automatically from cli
Package: chntpw Version: 1.0-1 Severity: wishlist Dear Maintainer, * What exactly did you do (or not do) that was effective (or ineffective)? I wanted to be able to unlock a user from within an script. * What was the outcome of this action? Package did not offer an appropiated binary to do such task. * What outcome did you expect instead? To have a binary that allows me to unlock a windows user from the command line. The two patches that allows the new samunlock binary are: https://github.com/adrian15/chntpw/commit/b24f36061493ae674dbbcf815e314c6c90103311 https://github.com/adrian15/chntpw/commit/3ac8fb06e2817da812fc9addf819f251c11127e3 Additional note: I already contacted upstream author but received no answer for about half a year, so I guess it's fine pushing this to Debian. -- System Information: Debian Release: 8.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#803888: chntpw: sampasswd not working as it's not writing its hive
Package: chntpw Version: 1.0-1 Severity: normal Dear Maintainer, * What led up to the situation? Trying to use sampasswd to change a password automatically. * What exactly did you do (or not do) that was effective (or ineffective)? sampasswd -E -r -u "0x${CHOOSEN_USER}" ${SAM_FILE}; * What was the outcome of this action? The windows user password was not changed. * What outcome did you expect instead? I expected the user password to be changed. You can find the patch that solves this problem in upstream here: https://github.com/adrian15/chntpw/commit/dcab306dbf49ace2e38e6874ce46bef10ee604da Additional information: I already contacted upstream author but received no answer for about half a year, so I guess it's fine pushing this to Debian. -- System Information: Debian Release: 8.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#803884: sampasswd.c: Wrong definition
Package: chntpw Version: 1.0-1 Severity: minor Dear Maintainer, "sampasswd.c - SAM database, add or remove user in a group" on sampasswd.c file. It should be: "sampasswd.c - SAM database, reset user password or account bits" instead. Patch to upstream code which solves this issue can be found at: https://github.com/adrian15/chntpw/commit/dc1c6edf135d9d628ab4230605bd778efd7c5dba Additional note: I already contacted upstream author but received no answer for about half a year, so I guess it's fine pushing this to Debian. -- System Information: Debian Release: 8.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#724931: Please include the patch in git
El 18/08/15 a las 19:28, Andreas Cadhalpun escribió: Hi adrian15, On 18.08.2015 10:47, adrian15 wrote: Can you please explain why you are using: get_fstype () function which it's based on blkid instead of just using the old method of relying in auto function from the kernel itself? The reason is simply that 'mount -tauto' didn't work, while explicitly specifying the type found with blkid works fine. Doing some archeology reveals the relevant error messages from syslog: With 'mount -tauto': kernel: [ 109.257009] UDF-fs: warning (device sda9): udf_fill_super: No partition found (1) kernel: [ 109.378443] FAT-fs (sda9): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! main-menu[550]: (process:4539): mount: mounting /dev/sda9 on /media failed: Invalid argument With blkid: [ 80.943104] EXT4-fs (sda9): mounted filesystem with ordered data mode. Opts: (null) These happened during check_missing_firmware, i.e. this comes from mountmedia. I think that convinced me not to use 'mount -t auto' in cdrom-detect. However, that was two years ago. Much could have changed in the meantime. Ok, I will try to reproduce it and see if it still happens. This is used in both cdrom-detect.patch and mountmedia.patch. Please, be aware, that I'm not telling you your approach is incorrect. It seems we are lacking the explanation or rationale on why you made that decision in order to evaluate that change in a fair manner. I'm curious: Why are you asking that now? I'm in debconf15 trying to push forward some improvements that I'm interested of as this one. Having around real people to speed things helps but don't raise your expectations too early. Best regards, Andreas adrian15 -- Support free software. Donate to Super Grub Disk. Apoya el software libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
Bug#724931: Re: Bug#724931: Please include the patch in git
El 08/03/14 a las 18:11, Andreas Cadhalpun escribió: I fixed a few things in my previous patch (see attachments): * Fix typo in finish-install.d/10apt-cdrom-setup: cdrom/$j - cdrom$j * Always test for other CDs, except if it is a netinst CD. Otherwise one can't use CD-2 together with debian-testing-amd64-kde-CD-1.iso of type full_cd/single. (Maybe I didn't get how this is supposed to work?) * Mount further ISOs if at least four parts (seperated by -) of the name are the same. Example: a) debian-testing-amd64-CD-1.iso b) debian-testing-amd64-kde-CD-1.iso c) debian-testing-amd64-CD-2.iso d) debian-testing-amd64-CD-2-local-changes.iso e) debian-testing-i386-CD-2.iso a) and b) would load c) or d), but not e). * Fix crash, if the filesystem is not know (e.g. unpartitioned). Pease add the attached patches on top of current git, even if you don't want to apply the patch now and instead move it to another branch. Best regards, Andreas Can you please explain why you are using: get_fstype () function which it's based on blkid instead of just using the old method of relying in auto function from the kernel itself? This is used in both cdrom-detect.patch and mountmedia.patch. Please, be aware, that I'm not telling you your approach is incorrect. It seems we are lacking the explanation or rationale on why you made that decision in order to evaluate that change in a fair manner. Thank you very much! adrian15 -- Support free software. Donate to Super Grub Disk. Apoya el software libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
Bug#757883: support for loopback.cfg file
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
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775322: Bootloader code issues and improvements
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
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
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774910: grub-common should depend on mtools package
Package: grub-common Version: 2.02~beta2-20 Severity: normal Dear Maintainer, * Summary grub-common not being dependent on mtools package breaks the build of EFI based ISOs (thanks to grub-mkrescue) for those of us who did not have mtools package installed in first place. * What led up to the situation? This happened in a Jessie chroot which did not have mtools package installed. It also had installed: grub-efi-amd64-bin package because I wanted to build an EFI based image. * What exactly did you do (or not do) that was effective (or ineffective)? I was trying to run: grub-mkrescue --output=/tmp/prueba.iso * What was the outcome of this action? xorriso : FAILURE : Cannot find path '/efi.img' in loaded ISO image * What outcome did you expect instead? Either the image built ok or grub-mkrescue complained about mformat or mcopy executables missings. * About grub-mkrescue complaining about mformat and mcopy missing This is not the object of this bug. For this particular problem I have opened a bug upstream: https://savannah.gnu.org/bugs/index.php?43957 * About mformat and mcopy not being present in the first place That's what this bug is about. If grub-common (I ignore if grub-mkrescue is present in other grub binary Debian packages, please check them also) would have been dependent on: mtools the problem would not have happened. * Workaround As you might expect my current workaround is to install mtools package. Once you install it the ISO is generated ok. -- Package-specific info: *** BEGIN /proc/mounts /dev/sdb3 / ext4 rw,relatime,errors=remount-ro,data=ordered 0 0 /dev/sdb1 /home ext4 rw,relatime,data=ordered 0 0 /dev/sdb3 /home/adrian/quantal_chroot/var/lib/dbus ext4 rw,relatime,errors=remount-ro,data=ordered 0 0 /dev/sdb3 /home/adrian/quantal_chroot/tmp ext4 rw,relatime,errors=remount-ro,data=ordered 0 0 /dev/sdb1 /home/adrian/quantal_chroot/home ext4 rw,relatime,data=ordered 0 0 /dev/sdb3 /home/adrian/lucid_chroot/var/lib/dbus ext4 rw,relatime,errors=remount-ro,data=ordered 0 0 /dev/sdb3 /home/adrian/lucid_chroot/tmp ext4 rw,relatime,errors=remount-ro,data=ordered 0 0 /dev/sdb1 /home/adrian/lucid_chroot/home ext4 rw,relatime,data=ordered 0 0 /dev/sdb3 /home/adrian/gnu/rescatux/wheezy_chroot/var/lib/dbus ext4 rw,relatime,errors=remount-ro,data=ordered 0 0 /dev/sdb1 /home/adrian/gnu/rescatux/wheezy_chroot/home ext4 rw,relatime,data=ordered 0 0 /dev/sdb1 /home/adrian/gnu/rescatux/jessie_chroot/home ext4 rw,relatime,data=ordered 0 0 /dev/sdb1 /home/adrian_ssd/sgd_chroot_testing_amd64/home ext4 rw,relatime,data=ordered 0 0 /dev/sdb1 /var/cache/approx ext4 rw,relatime,data=ordered 0 0 /dev/sdb1 /var/spool/apt-mirror ext4 rw,relatime,data=ordered 0 0 /dev/sda9 /mnt/ssd ext4 rw,relatime,data=ordered 0 0 /dev/sdb1 /mnt/ssd/adrian_sata/sgd_chroot_sid_amd64/home ext4 rw,relatime,data=ordered 0 0 /dev/sda1 /boot/efi vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=utf8,shortname=mixed,errors=remount-ro 0 0 *** END /proc/mounts *** BEGIN /boot/grub/device.map (hd0) /dev/disk/by-id/ata-ST9320325ASG_5VD61TLN *** END /boot/grub/device.map *** BEGIN /boot/grub/grub.cfg # # DO NOT EDIT THIS FILE # # It is automatically generated by grub-mkconfig using templates # from /etc/grub.d and settings from /etc/default/grub # ### BEGIN /etc/grub.d/00_header ### if [ -s $prefix/grubenv ]; then set have_grubenv=true load_env fi if [ ${next_entry} ] ; then set default=${next_entry} set next_entry= save_env next_entry set boot_once=true else set default=0 fi if [ x${feature_menuentry_id} = xy ]; then menuentry_id_option=--id else menuentry_id_option= fi export menuentry_id_option if [ ${prev_saved_entry} ]; then set saved_entry=${prev_saved_entry} save_env saved_entry set prev_saved_entry= save_env prev_saved_entry set boot_once=true fi function savedefault { if [ -z ${boot_once} ]; then saved_entry=${chosen} save_env saved_entry fi } function load_video { if [ x$feature_all_video_module = xy ]; then insmod all_video else insmod efi_gop insmod efi_uga insmod ieee1275_fb insmod vbe insmod vga insmod video_bochs insmod video_cirrus fi } if [ x$feature_default_font_path = xy ] ; then font=unicode else insmod part_gpt insmod ext2 set root='hd1,gpt3' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-bios=hd1,gpt3 --hint-efi=hd1,gpt3 --hint-baremetal=ahci1,gpt3 dec2d1f0-9638-4719-83c2-d8b9f9e50814 else search --no-floppy --fs-uuid --set=root dec2d1f0-9638-4719-83c2-d8b9f9e50814 fi font=/usr/share/grub/unicode.pf2 fi if loadfont $font ; then set gfxmode=auto load_video insmod gfxterm set locale_dir=$prefix/locale set lang=es_ES insmod gettext fi terminal_output gfxterm if [ ${recordfail} =
Bug#757697: RFE: Autodetection of architecture at boot time to load appropiate kernel
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
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757883: Patch for Loopback cfg support
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#757883: Patch for Loopback cfg support
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757697: RFE: Autodetection of architecture at boot time to load appropiate kernel
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757883: Patch for Loopback cfg support
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759406: Re: debian-cd: Merge iso images into usb drive thanks to cat
a tool would be needed so that the user can mount its Debian CD 2 from its USB as easier as possible (Maybe a noauto entry in fstab). fstab could contain lines for /target/mnt/fat and /target/mnt/apt*. Yes, the thing is making sure that the path to the isos in the installer are the same one as the installed system paths. You know like the installer using /extraisos directory and then finding the usb partition in the installed system like /media/UUID-1234-... . I haven't checked it in #bug 724931 yet. They might not have sorted it out in a proper way. For Windows people it would be nice to have a GUI where you can select (always with CD 1 as the first one) all the cds you want and then concatenate them into a USB device. The normal MS File Manager could populate the mounted FAT filesystem. I agree. As you might suspect you need to know the iso size in advance so that this works in a reasonable way. Not if the ISOs are data files inside a filesystem. You are right. Do you think it's something that it's easy to implement ? Not really. I get the impression that you plan to create a kindof minimal filesystem. My main objection is that suitable filesystems already exist and are supported by a wide range of operating systems and tools. Outside my personal scope is the motivation for your proposal. A Debian person might ask: What are the use cases where it will be of help ? When someone want to use CD1, CD2 and CD3 from the same usb. E.g. giving the usb to someone else who is offline. What benefits would it have for Debian's ISO production and download sites ? You won't need to release one file per each one of the GB-sized usbs. As I said above: You do not have to release 1 GB, 2 GB and 4 GB size images for each one of the usb media size you want to provide to. Have a nice day :) Thomas Thank your for input. Somehow I thought that my 4 GB hard disk test after dding the ~ 500 GB image would have been detected as a 500 GB size only hard disk. 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759744: debian-cd: loopback.cfg support for booting ISOs from within GRUB
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759406: debian-cd: Merge iso images into usb drive thanks to cat
MB you will build it to have 890 MB, then you will pad 10 MB at its end so that it is 900 MB. If the build happens to have: 892 MB, then you only need to add 8 MB. Of course, the padding needs to be done in bytes not in megabytes. == Feedback from Debian-CD / Debian-Installer people == Do you think it's something that it's easy to implement ? Will you need help even if it's easy to implement ? I hope that this new hack (I think nobody has thought about using mount's offset option in a such a way) lets Debian shrink its Debian CD archive size. El 27/08/14 03:08, Adrian Gibanel Lopez escribió: I will try to make some tests in the next days to prove if the minimal functionality needed actually works or if it would need hacks on how Gnu/Linux kernel reads devices bigger than its partition table suggested size. 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757883: Patch for Loopback cfg support
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
Bug#757697: CPU detection patch for grub2 attached
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
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
Package: live-boot Version: 3.0~b2-1 Severity: important When building an Squeeze debian live cd inside an Squeeze system and trying to use live-boot* packages from unstable seems to be broken. When I boot I get: Loading, please wait..., run-init: nuking initramfs contents: Directory not empty. Kernel panic - not syncing: Attempted to kill init. How to reproduce a minimal bootable iso: --- #!/bin/bash RESCATUX_STR=rescatux TEMP_FOLDER=/tmp/${RESCATUX_STR}-tmp-build-$$ SID_CHROOT_CONFIG=config/chroot_sources/sid.chroot CHROOT_SOURCES_FOLDER=config/chroot_sources APT_PREFERENCES=config/chroot_apt/preferences CHROOT_APT_CONFIG_FOLDER=config/chroot_apt SID_MIRROR=http://snapshot.debian.org/archive/debian/20120727T111800Z/; mkdir --parents $TEMP_FOLDER/${CHROOT_SOURCES_FOLDER} mkdir --parents $TEMP_FOLDER/${CHROOT_APT_CONFIG_FOLDER} echo -e -n deb ${SID_MIRROR} sid main $TEMP_FOLDER/${SID_CHROOT_CONFIG} cat $TEMP_FOLDER/${APT_PREFERENCES} END Package: live-boot Pin: release n=sid Pin-Priority: 600 Package: live-boot-initramfs-tools Pin: release n=sid Pin-Priority: 600 Package: live-config Pin: release n=sid Pin-Priority: 600 Package: live-config-sysvinit Pin: release n=sid Pin-Priority: 600 Package: * Pin: release n=sid Pin-Priority: 1 END cd $TEMP_FOLDER lh config -d squeeze \ --apt-options --yes -o Acquire::Check-Valid-Until=false sudo lb build echo -e -n \nLocalizacion: ${TEMP_FOLDER}\n How to reproduce a minimal NON bootable iso: #!/bin/bash RESCATUX_STR=rescatux TEMP_FOLDER=/tmp/${RESCATUX_STR}-tmp-build-$$ SID_CHROOT_CONFIG=config/chroot_sources/sid.chroot CHROOT_SOURCES_FOLDER=config/chroot_sources APT_PREFERENCES=config/chroot_apt/preferences CHROOT_APT_CONFIG_FOLDER=config/chroot_apt SID_MIRROR=http://ftp.de.debian.org/debian/; mkdir --parents $TEMP_FOLDER/${CHROOT_SOURCES_FOLDER} mkdir --parents $TEMP_FOLDER/${CHROOT_APT_CONFIG_FOLDER} echo -e -n deb ${SID_MIRROR} sid main $TEMP_FOLDER/${SID_CHROOT_CONFIG} cat $TEMP_FOLDER/${APT_PREFERENCES} END Package: live-boot Pin: release n=sid Pin-Priority: 600 Package: live-boot-initramfs-tools Pin: release n=sid Pin-Priority: 600 Package: live-config Pin: release n=sid Pin-Priority: 600 Package: live-config-sysvinit Pin: release n=sid Pin-Priority: 600 Package: * Pin: release n=sid Pin-Priority: 1 END cd $TEMP_FOLDER lh config -d squeeze sudo lb build echo -e -n \nLocalizacion: ${TEMP_FOLDER}\n --- When I force the old version from snapshots.debian.org which it is 3.0~a38-1 it boots without any problem.. If I use the current version which it is 3.0~b2-1 then I get the kernel panic error. This error is quite probably related to: #685375 because it gets the same kernel error. -- Package-specific info: -- System Information: Debian Release: 6.0.5 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (x86_64) Kernel: Linux 3.2.21 (SMP w/4 CPU cores) Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#687099: live-boot: Breaks booting when used from Squeeze
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652745: RFP: razor-qt -- simple qt-based desktop window manager
El 10/05/12 16:22, Maia Kozheva escribió: Any progress on this? I'm interested in seeing razor-qt in Debian (and Ubuntu), so I'd be happy to help with the packaging. Feel free to do it yourself. I'm lacking time for focusing on this package right now. I just hope that my findings about what doesn't work on stable make easier your work. 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656532: lxde-core: Random black background after login
My current workaround for this bug is to run at the end of my script: pcmanfm --desktop disown So let's inspect config files: /home/user/.config/pcmanfm/LXDE.conf has lxde_blue.jpg (INCORRECT ONE) as background. /home/user/.config/pcmanfm/pcmanfm.conf has background.png (CORRECT ONE) as background. That fits into Case A. Not sure what causes this bug yet. El 20/01/12 00:28, adrian15 escribió: I have done more tests and this is what I have found: Case A: When I get a black background: == /home/user/.config/pcmanfm/LXDE.conf has lxde_blue.jpg (INCORRECT ONE) as background. /home/user/.config/pcmanfm/pcmanfm.conf has background.png (CORRECT ONE) as background. If I logout and login both pcmanfm.conf and LXDE.conf refer to correct background. Case B: When I don't get a black backround: === /home/user/.config/pcmanfm/LXDE.conf has background.png (CORRECT ONE) as background. /home/user/.config/pcmanfm/pcmanfm.conf file does not exist. If I logout and login both pcmanfm.conf is not still there and LXDE.conf refers to correct background. So that means that no change at all happens. I have checked startlxde script again and it does not create any pcmanfm.conf file at all. It only creates LXDE.conf. I suspect that the SuSE patch tries to convince pcmanfm not to write the /home/user/.config/pcmanfm/pcmanfm.conf file by telling it that this file is already found at: /home/user/.config/pcmanfm/default/pcmanfm.conf although I am not very sure. Just hope that all of this helps you to kill the bug. Thank you again! 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org