Syslinux - Apr 2009 - "keeppxe" broken in 3.74 - short-cycle 3.75

It appears that the 3.74 completely broke the "keeppxe" directive --
not
due to the command-line parser, but due to mishandling of the flag later.

I consider this to be severe enough to do a short-cycle 3.75.  As a
result, I would like help with:

a) are there any other bugs that snuck through?
b) once I have a 3.75-pre1, I would really appreciate help testing it.

The goal is to have 3.75 final before the end of the week.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

On Tue, 14 Apr 2009, H. Peter Anvin wrote:
> It appears that the 3.74 completely broke the "keeppxe" directive
-- not
> due to the command-line parser, but due to mishandling of the flag later.
>
> I consider this to be severe enough to do a short-cycle 3.75.  As a
> result, I would like help with:
>
> a) are there any other bugs that snuck through?
> b) once I have a 3.75-pre1, I would really appreciate help testing it.
>
> The goal is to have 3.75 final before the end of the week.
I think I found one issue with syslinux 3.74 memdisk which we did not have 
with syslinux 3.73 memdisk. When loading the same PCDOS harddisk image 
with 3.74 memdisk using:

----
label pcdoshd
   menu label ^DOS image with updates and drivers (pcdoshd)
   kernel memdisk
   append initrd=img/pcdoshd.imz harddisk
----

it fails with:

----
MEMDISK 3.74 2009-04-09  Copyright 2001-2009 H. Peter Anvin et al
e820: 0000000000000000 000000000009d400 1 [1]
e820: 000000000009d400 0000000000002c00 2 [1]
e820: 00000000000e0000 0000000000020000 2 [1]
e820: 0000000000100000 00000000d7eb0580 1 [1]
e820: 00000000d7fd0000 0000000000030000 2 [1]
e820: 00000000d7fb0580 000000000001fa80 3 [1]
e820: 0000000100000000 0000000128000000 1 [1]
e820: 00000000e0000000 0000000010000000 2 [1]
e820: 00000000fec00000 0000000001400000 2 [1]
Ramdisk at 0xd758d000, length 0x0099590e
Moving compressed data from 0xd758d000 to 0xd661aa00
gzip image: decompressed addr 0xd6fb0400, len 0x01000000: ok
command line: initrd=img/pcdoshd.imz harddisk BOOT_IMAGE=memdisk
Disk is hard disk 0, 16384 K, C/H/S = 16/64/32, EDD on, read-write
Using safe INT 15h access to high memory
Total size needed = 2464 bytes, allocating 3K
Old dos memory at 0x9d400 (map says 0x9d400), loading at 0x9c800
1588: 0xffff  15E801: 0x3c00 0xd5fb
INT 13 08: Success, count = 1, BPT = 0000:0000
old: int13 = f0007853  int15 = f000f859  int1e = f000efc7
new: int13 = 9c80000a  int15 = 9c800391  int1e = f000efc7
Loading boot sector... booting...
Missing operating system
----

while using 3.73 memdisk I get (what's still on screen):

----
MEMDISK 3.73 2009-01-25  Copyright 2001-2009 H. Peter Anvin
e820: 0000000000000000 000000000009d400 1 [1]
e820: 000000000009d400 0000000000002c00 2 [1]
e820: 00000000000e0000 0000000000020000 2 [1]
e820: 0000000000100000 00000000d7eb0580 1 [1]
e820: 00000000d7fd0000 0000000000030000 2 [1]
e820: 00000000d7fb0580 000000000001fa80 3 [1]
e820: 0000000100000000 0000000128000000 1 [1]
e820: 00000000e0000000 0000000010000000 2 [1]
e820: 00000000fec00000 0000000001400000 2 [1]
Ramdisk at 0xd758e000, length 0x0099590e
Moving compressed data from 0xd758e000 to 0xd661aa00
gzip image: decompressed addr 0xd6fb0400, len 0x01000000: ok
command line: initrd=img/pcdoshd.imz harddisk BOOT_IMAGE=memdisk
MEMDISK: Image seems to have fractional end cylinder
Disk is hard disk 0, 16384 K, C/H/S = 32/16/63, EDD on, read-write
Using safe INT 15h access to high memory
Total size needed = 2468 bytes, allocating 3K
Old dos memory at 0x9d400 (map says 0x9d400), loading at 0x9c800
1588: 0xffff  15E801: 0x3C00 0xd5fb
INT 13 08: Success, count = 1, BPT = 0000:0000
old: int13 = f0007853  int15 = f000f859  int1e = f000efc7
new: int13 = 9c80000a  int15 = 9c800392  int1e = f000efc7
Loading boot sector... booting...
Starting PC DOS...
----

Spot the 4 differences :) (Hint: ramdisk location, C/H/S, "Total
size",
new int15)

Tested on 3 different systems (x3650, x3850m2 and a blade HS20).
If needed I can share the pcdoshd image with you. I hope this is useful.

Kind regards,
-- 
--   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
[Any errors in spelling, tact or fact are transmission errors]

FWIW, I just pushed out 3.75-pre1.  It does not fix the memdisk geometry 
issue, however.

	-hpa

----- Original Message ----- 
From: "H. Peter Anvin" <hpa at zytor.com>
To: "SYSLINUX Mailing list" <syslinux at zytor.com>
Sent: Tuesday, April 14, 2009 5:54 PM
Subject: [syslinux] "keeppxe" broken in 3.74 - short-cycle 3.75

> It appears that the 3.74 completely broke the "keeppxe" directive
-- not
> due to the command-line parser, but due to mishandling of the flag later.
>
> I consider this to be severe enough to do a short-cycle 3.75.  As a
> result, I would like help with:
>
> a) are there any other bugs that snuck through?
extlinux --reset-adv is broken
It display the usage message (with --reset-adv include)
(syslinux installed directly using make install)

thank for MENU SAVE
That work fine but work differently from grub savedefault.

grub savedefault work under the title (grub)/label(syslinux) level when
extlinux MENU SAVE is global to the menu. So with grub, you could save some
selection and not some others.
This is not possible with MENU SAVE working globally.
That's not a big problem.

We have 4 labels on the menu and some of them may not need to save the entry
selected.
To be clear the menu look like that  ( MENU SAVE could be added anywhere,
before any label or under a label, the behavior is the same)

LABEL ipcop
  MENU default
  MENU LABEL IPCop
  KERNEL vmlinuz
  APPEND mode=normal initrd=ipcoprd.img root=ROOT_DEV ro panic=10

LABEL noacpi
  MENU LABEL IPCop (ACPI disabled)
  KERNEL vmlinuz
  APPEND mode=normal initrd=ipcoprd.img root=ROOT_DEV acpi=off ro panic=10

LABEL memtest
  MENU LABEL Memory Test
  KERNEL memtest
  APPEND -

LABEL rescue
  MENU LABEL Rescue
  KERNEL vmlinuz
  APPEND mode=rescue initrd=ipcoprd.img root=ROOT_DEV ro panic=10 nodma

There is no need in our context to save rescue or memtest label selection.

    Gilles

The double ! in the patch look suspicious to me
-      m->allowedit = atoi(skipspace(p+12));
+      m->allowedit = !!atoi(skipspace(p+12));

Unrelated, I look at extlinux/main.c on git tree
On HEAD, 'const char *program;' is duplicated (line 59 and 184) and line
184
should be removed.

Gilles

On Wed, 15 Apr 2009, H. Peter Anvin wrote:
> Dag Wieers wrote:
>
>>  Erwan has some important changes to HDT which without it fails to
start on
>>  certain hardware (eg. x3850m2). Would it be possible to add them to
the
>>  3.75 release even when they are not critical to the core ?
>>
>>  I noticed HDT is already added to eg. RIPLinux 8.0, so if 3.76 is
months
>>  away I would like to prevent people bumping into known and fixed
issues.
>
> OK, this is in -- 3.75-pre4 pushed out.
>
> Absolutely last call.
I will have to test tomorrow at work. Already created 3.75-pre2 packages 
for testing purposes, but redid 3.75-pre4 RPMs just yet and they build 
fine (RH9, EL3, EL4, EL5). If you can hold this for about 12 hours I can 
retest on some real iron.

-- 
--   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
[Any errors in spelling, tact or fact are transmission errors]