Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)
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, ...).
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.)
> --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.
> 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.
> 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 could combine bootia32.efi from the one boot loader and
bootx64.efi from the other boot loader, if you find a use case
for that stunt.
Without such a use case, i would decide for one boot loader per
firmware. Just to keep things simple.
> So... How would you go about for a:
> --bootloaders="syslinux,grub-efi,syslinux-efi"
I'd state that you don't need syslinux-efi if you have grub-efi
which is much better exercised with ISO 9660.
As said, nobody ever reported about success of SYSLINUX from
CDROM via EFI. I dimly remember that hpa, the author of SYSLINUX,
once stated on sysli...@zytor.com that the capability was missing
in SYSLINUX EFI to hop from the FAT filesystem into the ISO filesystem.
> they would overwrite their /efi/boot/boot*efi files ?
The EFI startup binaries of grub-efi and syslinux-efi would conflict
inside your FAT filesystem, indeed. There are supposed to be ways to
solve this conflict and offer the choice at boot time. For that you'd
need to have own EFI startup binaries which then hop on the programs
of one of the offered boot loaders.
But, well, what would be the use case for such a choice ?
Have a nice day :)
Thomas
Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)
Hi, i wrote: > http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/view/head:/doc/boot_sectors.txt adrian15 wrote: > I want to document the different ways of how BIOS boot, UEFI boot and > Secure Boot work and that might be helpful. Secure Boot is not covered. (I am not sure whether it belongs there. Actually i don't know enough about it.) 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 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 ? Raphaël ? Can you shed light on this ? Does the 0x01 partition stem from the "Firmware Partition" of mini.iso ? (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776317 reports about quite unintentional boot success via that partition.) > > (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. Afaik, SYSLINUX begins to boot from an EFI System Partition inside or after the ISO filesystem. It does not get to booting the operating system files in the ISO filesystem, though. > The EFI image needs to include the configuration file Given the reports on sysli...@zytor.com i'd expect that enough of operating system has to reside in the FAT filesystem so it is able to boot to the capability to find and read the ISO filesystem. But in practice, all EFI bootable ISOs known to me use GRUB for the job. (One may boot a kernel directly from EFI, without intermediate boot loader. Examples are rare but seem to work.) > 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.) > > 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. The xorriso run could be easily adapted to include a HFS+ image. But i do not know how Matthew Garrett produced this image. One would have to investigate its content and find some Mac filesystem tool to produce such content. > 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.) > 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. > > (Options picked out of proposal of > > xorriso -hfsplus on \ > > -indev Fedora-Live-Xfce-x86_64-rawhide-20150704.iso \ > > -report_el_torito as_mkisofs > Interesting. I did not know that you could request what an ISO > 'layout/configuration' was. This is a xorriso feature which is present in the Sid package xorriso-1.4.2 but not in xorriso-1.3.2 as of Debian 8. You can request a listing of the boot equipment xorriso -hfsplus on -indev ...iso \ -report_el_torito plain -report_system_area plain and you can request option proposals by above -report_el_torito as_mkisofs > A) Are you complaining ab
Ihre neue Heizung: kostenlos dank staatlicher Förderung
Guten Tag, möchten Sie Ihre Heizung erneuern, kostenlos dank staatlicher Förderung? Die Bundesregierung unterstützt den Erwerb von neuen, ökologischen Heizungen – das sollten Sie nutzen! Ihre Heizung wird kostenlos erneuert - Sie bekommen zusätzlich eine staatliche Förderung von bis zu 11.000 Euro zur freien Verfügung. Diese Aktion ist für Sie vollkommen kostenlos und unverbindlich – auch wir werden aus Fördermitteln bezahlt. Bitte informieren Sie sich hier: heizung-aktion.com Mit freundlichen Grüßen, Heizungsbau Franke
Bug#812224: IndexError: list index out of range
Package: wicd-curses Version: 1.7.3-2 Severity: grave Justification: renders package unusable Dear Maintainer, the new version of wicd is rather crashy. > ERROR:dbus.connection:Exception in handler for D-Bus signal: > Traceback (most recent call last): > File "/usr/lib/python2.7/dist-packages/dbus/connection.py", line 230, in > maybe_handle_message > self._handler(*args, **kwargs) > File "/usr/share/wicd/curses/wicd-curses.py", line 97, in wrapper > return func(*args, **kargs) > File "/usr/share/wicd/curses/wicd-curses.py", line 850, in update_netlist > self.wiredCB.get_body().set_list(wiredL) > File "/usr/share/wicd/curses/wicd-curses.py", line 469, in set_list > wired.ReadWiredNetworkProfile(self.get_selected_profile()) > File "/usr/share/wicd/curses/wicd-curses.py", line 535, in > get_selected_profile > return self.theList[loc] > IndexError: list index out of range This happens every time, without doing anything at all. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.4.0f (SMP w/4 CPU cores; PREEMPT) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages wicd-curses depends on: ii python-urwid 1.3.1-2 pn python:any ii wicd-daemon 1.7.3-2 Versions of packages wicd-curses recommends: ii sudo 1.8.15-1.1 wicd-curses suggests no packages. Versions of packages wicd-daemon depends on: ii adduser 3.113+nmu3 ii dbus 1.10.6-1 ii debconf 1.5.58 ii ethtool 1:4.2-1 ii iproute2 4.3.0-1 ii iputils-ping 3:20121221-5+b2 ii isc-dhcp-client 4.3.3-5 ii lsb-base 9.20160110 ii net-tools1.60+git20150829.73cef8a-2 ii psmisc 22.21-2.1+b1 ii python-dbus 1.2.0-3 ii python-gobject 3.18.2-2 ii python-wicd 1.7.3-2 pn python:any ii wireless-tools 30~pre9-8 ii wpasupplicant2.3-2.3 Versions of packages wicd-daemon recommends: ii rfkill 0.5-1 Versions of packages wicd-daemon suggests: pn pm-utils Versions of packages python-wicd depends on: pn python:any -- debconf information excluded
Processed (with 1 error): closing 788506
Processing commands for cont...@bugs.debian.org: > NMU contains patch in this bug Unknown command or malformed arguments to command. > close 788506 4.7.4-3 Bug #788506 [src:link-grammar] link-grammar: Java architectures out of date Marked as fixed in versions link-grammar/4.7.4-3. Bug #788506 [src:link-grammar] link-grammar: Java architectures out of date Marked Bug as done > thanks Stopping processing here. Please contact me if you need assistance. -- 788506: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788506 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#812224: IndexError: list index out of range
Control: tag -1 + unreproducible Hi Salvo, Salvo Tomaselli wrote: > the new version of wicd is rather crashy. Indeed. I had to add a patch or two already due to that. > > ERROR:dbus.connection:Exception in handler for D-Bus signal: > > Traceback (most recent call last): > > File "/usr/lib/python2.7/dist-packages/dbus/connection.py", line 230, in > > maybe_handle_message > > self._handler(*args, **kwargs) > > File "/usr/share/wicd/curses/wicd-curses.py", line 97, in wrapper > > return func(*args, **kargs) > > File "/usr/share/wicd/curses/wicd-curses.py", line 850, in update_netlist > > self.wiredCB.get_body().set_list(wiredL) > > File "/usr/share/wicd/curses/wicd-curses.py", line 469, in set_list > > wired.ReadWiredNetworkProfile(self.get_selected_profile()) > > File "/usr/share/wicd/curses/wicd-curses.py", line 535, in > > get_selected_profile > > return self.theList[loc] > > IndexError: list index out of range > > This happens every time, without doing anything at all. Hrm, not for me. I use mostly wicd-curses, too, and it works fine for me. The question is now: What's the difference? Do you have e.g. multiple wired connection profiles or such? Regards, Axel -- ,''`. | Axel Beckert , http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Processed: Re: Bug#812224: IndexError: list index out of range
Processing control commands: > tag -1 + unreproducible Bug #812224 [wicd-curses] IndexError: list index out of range Added tag(s) unreproducible. -- 812224: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812224 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: Bug#812224: IndexError: list index out of range
Processing control commands: > tag -1 - unreproducible Bug #812224 [wicd-curses] IndexError: list index out of range Removed tag(s) unreproducible. -- 812224: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812224 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#812224: IndexError: list index out of range
Control: tag -1 - unreproducible Hi Salvo, Axel Beckert wrote: > > > ERROR:dbus.connection:Exception in handler for D-Bus signal: > > > Traceback (most recent call last): > > > File "/usr/lib/python2.7/dist-packages/dbus/connection.py", line 230, > > > in maybe_handle_message > > > self._handler(*args, **kwargs) > > > File "/usr/share/wicd/curses/wicd-curses.py", line 97, in wrapper > > > return func(*args, **kargs) > > > File "/usr/share/wicd/curses/wicd-curses.py", line 850, in > > > update_netlist > > > self.wiredCB.get_body().set_list(wiredL) > > > File "/usr/share/wicd/curses/wicd-curses.py", line 469, in set_list > > > wired.ReadWiredNetworkProfile(self.get_selected_profile()) > > > File "/usr/share/wicd/curses/wicd-curses.py", line 535, in > > > get_selected_profile > > > return self.theList[loc] > > > IndexError: list index out of range > > > > This happens every time, without doing anything at all. > > Hrm, not for me. I use mostly wicd-curses, too, and it works fine for > me. I suspect the relevant "workaround" is to switch on "Always show wired interface". At least I was able to reproduce that crash a few times (but by far not always) if I turn that option off and there are no wireless networks available either, i.e. the list of networks to connect to is rather empty. Pressing "R" in that situation also raises the chance of getting this error. Regards, Axel -- ,''`. | Axel Beckert , http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#812231: analog FTCBFS: uses build architecture compiler
Source: analog Version: 2:6.0-21 Tags: patch User: helm...@debian.org Usertags: rebootstrap Hi, analog fails to cross build from source, because it uses the build architecture compiler. This is noticed at the end of the build when dh_strip fails to strip the build architecture executables. I am attaching a patch that passes the correct compiler to the Makefile. Helmut diff --minimal -Nru analog-6.0/debian/changelog analog-6.0/debian/changelog --- analog-6.0/debian/changelog 2015-07-18 20:43:37.0 +0200 +++ analog-6.0/debian/changelog 2016-01-21 19:45:49.0 +0100 @@ -1,3 +1,10 @@ +analog (2:6.0-21.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Pass cross compiler to Makefile. (Closes: #-1) + + -- Helmut Grohne Thu, 21 Jan 2016 19:45:25 +0100 + analog (2:6.0-21) unstable; urgency=medium * QA upload. diff --minimal -Nru analog-6.0/debian/rules analog-6.0/debian/rules --- analog-6.0/debian/rules 2015-07-18 20:43:37.0 +0200 +++ analog-6.0/debian/rules 2016-01-21 19:45:17.0 +0100 @@ -1,6 +1,10 @@ #!/usr/bin/make -f +include /usr/share/dpkg/architecture.mk export BUILD_DATE = $(shell LC_ALL=C date -u --date="`dpkg-parsechangelog -SDate`" +'%b %e %Y %H:%M:%S') +ifeq ($(origin CC),default) +CC := $(DEB_HOST_GNU_TYPE)-gcc +endif %: dh $@ @@ -22,6 +26,7 @@ -DHEADERDIR=\"\" \ -DLOCKDIR=\"/var/lock/\" \ -DDEFAULTCONFIGFILE=\"/etc/analog.cfg\"' \ + CC=$(CC) \ analog # nothing to do
