utils/sha1pass | 4 2 + 2 - 0 !
1 file changed, 2 insertions(+), 2 deletions(-)

 use digest::sha for utils/sha1pass (closes: #625812).

com32/gfxboot/gfxboot.c | 16 10 + 6 - 0 !
1 file changed, 10 insertions(+), 6 deletions(-)

 Allow boot entry to start with label instead of menu_label.
 .
 menu_ptr->menu_label is human-readable (perhaps even translatable!) text if
 the MENU LABEL command is used, which isn't very convenient at the start of
 a boot entry.  Allow the entry to start with menu_ptr->label (an
 identifier) as an alternative.

man/extlinux.1 | 8 4 + 4 - 0 !
1 file changed, 4 insertions(+), 4 deletions(-)

 Updating list of supported filesystems in extlinux manpage (Closes: #692844).

efi/clean-gnu-efi.sh | 5 0 + 5 - 0 !
1 file changed, 5 deletions(-)

 use embedded copy of gnu-efi.

com32/lib/syslinux/load_linux.c | 4 2 + 2 - 0 !
1 file changed, 2 insertions(+), 2 deletions(-)

 load_linux: correct a type
 Correct base's type to match its initialization from prot_mode_base and
 passage to syslinux_memmap_find(). Tested with extlinux.

com32/lib/syslinux/load_linux.c | 1 1 + 0 - 0 !
1 file changed, 1 insertion(+)

 load_linux: relocate protected-mode code as intended
 If the kernel is relocatable and the protected mode code will not fit
 in the initially determined location, that code will be moved to the
 next available location. However, beginning with commit 8f470e7b, the
 code is moved to the initially determined location instead of the next
 available location because prot_mode_base is no longer updated to the
 correct location. Since whdr->code32_start is updated, it is pointing
 to the wrong execution start location, random code is executed and
 the machine is rebooted.
 .
 Restore the old behavior by assigning prot_mode_base the value of
 base. Tested on a machine that exposed this behavior.

com32/elflink/ldlinux/readconfig.c | 2 1 + 1 - 0 !
com32/menu/readconfig.c | 2 1 + 1 - 0 !
core/sysappend.c | 2 1 + 1 - 0 !
3 files changed, 3 insertions(+), 3 deletions(-)

 sysappend: fix space stripping
 The description of SYSAPPEND for the DMI information states that the spaces
 are replaced by underscores, but this replacement does not occur in 6.03 (Closes: #795596).

core/i386/syslinux.ld | 6 3 + 3 - 0 !
core/x86_64/syslinux.ld | 6 3 + 3 - 0 !
2 files changed, 6 insertions(+), 6 deletions(-)

---

com32/hdt/Makefile | 2 1 + 1 - 0 !
com32/sysdump/Makefile | 2 1 + 1 - 0 !
efi/Makefile | 8 4 + 4 - 0 !
3 files changed, 6 insertions(+), 6 deletions(-)

 sort object files for reproducible linking order

gpxe/src/Makefile | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 fix ftbfs when gcc configured with --enable-default-pie
Bug-Ubuntu: https://bugs.launchpad.net/bugs/1579023

core/i386/syslinux.ld | 63 12 + 51 - 0 !
core/x86_64/syslinux.ld | 63 12 + 51 - 0 !
2 files changed, 24 insertions(+), 102 deletions(-)

 [patch] bios: don't try to guess the sections alignment

For the compression / decompression to succeed, the sections layout must
be the same between the virtual memory and load memory. The section
alignment was kept in sync by introducing aligment that should be
greater or equal to the actual section alignment.

This patch compute the load memory addresses of the sections so that
the layout is the same as the virtual memory addresses.

Signed-off-by: Sylvain Gault <sylvain.gault@gmail.com>
Tested-by: poma <pomidorabelisima@gmail.com>
Signed-off-by: Paulo Alcantara <pcacjr@zytor.com>

com32/elflink/ldlinux/cli.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 [patch] ldlinux: fix return pointer to local data

The command-line parsing used to return a pointer to a local array. The
code used to work by chance, but now, gcc 5 is able to detect it and
return a NULL pointer instead.

The buffer is now marked static. This shouldn't be a problem as only one
command line can be read at a time.

Signed-off-by: Sylvain Gault <sylvain.gault@gmail.com>
Tested-by: poma <pomidorabelisima at gmail.com>
Signed-off-by: Paulo Alcantara <pcacjr@zytor.com>

extlinux/main.c | 1 1 + 0 - 0 !
1 file changed, 1 insertion(+)

 [patch] extlinux: pull in sys/sysmacros.h for major/minor/makedev

These functions are defined in sys/sysmacros.h, so add the include to
main.c.  This is already handled correctly in mountinfo.c.  Otherwise
we get build failures like:

main.o: In function 'find_device_sysfs':
extlinux/main.c:1131: undefined reference to 'minor'

Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Gene Cumm <gene.cumm@gmail.com>

core/Makefile | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

---

core/fs/btrfs/btrfs.c | 49 33 + 16 - 0 !
core/fs/btrfs/btrfs.h | 2 2 + 0 - 0 !
2 files changed, 35 insertions(+), 16 deletions(-)

 btrfs: fix logical to physical block address mapping

The current btrfs support did not handled multiple stripes stored in
chunk items, hence skipping the physical addresses that were needed to
do the mapping.

Besides, the chunk tree may contain DEV_ITEM keys which store
information on all of the underlying block devices, so we must skip them
instead of finishing lookup.

The bug was reproduced with btrfs-progs v4.2.2.

Cc: Gene Cumm <gene.cumm@gmail.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Paulo Alcantara <pcacjr@zytor.com>

mbr/isohdpfx.S | 10 6 + 4 - 0 !
1 file changed, 6 insertions(+), 4 deletions(-)

 mbr/isohdpfx.s: correct stack for heads/sectors

Heads and sectors were pushed in reverse order per isolinux.asm
(bb519a95 reversed the order of heads/sectors on the stack).

If anything goes wrong, clear CX in case it contains garbage.

Signed-off-by: Gene Cumm <gene.cumm@gmail.com>

Bug-Debian: https://bugs.debian.org/879004

core/fs/ext2/ext2.c | 23 14 + 9 - 0 !
core/fs/ext2/ext2_fs.h | 1 1 + 0 - 0 !
2 files changed, 15 insertions(+), 9 deletions(-)

 ext4: fix 64bit feature

As per ext4 specification:

> In ext2, ext3, and ext4 (when the 64bit feature is not enabled), the
> block group descriptor was only 32 bytes long and therefore ends at
> bg_checksum. On an ext4 filesystem with the 64bit feature enabled, the
> block group descriptor expands to at least the 64 bytes described below;
> the size is stored in the superblock.

Since block group descriptor has been expanded to 64 bytes long (when 64
bit feature is enabled), we cannot index ext2_group_desc and return it
*directly* -- as we did it in ext2_get_group_desc -- it's still 32 bytes
long.

Instead, use s_desc_size field from superblock to correctly index and
return block group descriptors.

Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Gene Cumm <gene.cumm@gmail.com>
Signed-off-by: Paulo Alcantara <pcacjr@zytor.com>

Bug-Debian: https://bugs.debian.org/833057