Mailing List Archive

Peter Bartke wrote:
> Hi,
>
> I am trying to track down a ISOLINUX boot problem on my workhorse computer.
> Booting slax-6.0.0-rc5.iso from www.slax.org (a live distro) from CD gives the
> following messages:
>
> Loading /boot/vmlinuz ...........
> Loading /boot/initrd.gz ............
> Ready.
> _
>
> Silence. The next message should be, but does not appear:
> Uncompressing Linux ...........
> This message appears with the same CD on an old Pentium III, so the CD is not
> broken, it boots perfectly on the old PC. I discussed the problem on the Slax
> forum but I seem to be the only one with this problem.

You are aware that burnable CDs don't necessarily "work" or "not work";
it's fairly common for them to be marginal so that they work in some
machines, but not others, right?

Since you can boot the offending machine, I would try to dd the CD to an
image *on the failing machine* and compare it to the raw image. That
doesn't necessarily imply things are hunky-dory, but it's something.

> The computer is a P4 on ASUS P5GD2, 1GB RAM, AMI BIOS, 3 SATA disks, DVD-ROM,
> CD-RW. It _successfully_ boots from disk several SuSE distros, Slackware 12
> and the unchanged content of the incriminated CD, written to an empty
> partition, with the following GRUB-menu.lst entry:
>
> title Slax 6.0 RC5
> root (hd1,5)
> kernel (hd1,5)/boot/vmlinuz init=linuxrc vga=0x31a splash=verbose \
> load_ramdisk=1 ramdisk_size=6666 root=/dev/ram0 rw
> initrd (hd1,5)/boot/initrd.gz
>
> So I know the kernel on the failing CD is bootable. The corresponding
> isolinux.cfg entry on the CD is
>
> LABEL slax
> MENU LABEL Slax Text mode
> KERNEL /boot/vmlinuz
> APPEND vga=normal initrd=/boot/initrd.gz ramdisk_size=6666 root=/dev/ram0 rw
>
> I tried isolinux.bin from three versions of syslinux, including the newest. I
> tried to get more info by running isolinux-debug.bin from syslinux-3.51,
> resulting in permanently the same messages (see above) and a boot stall
> afterwards.
>
> I would very much appreciate any hints how to proceed further isolating the
> cause of the failure.

What it looks like to me is that ISOLINUX reads the data in question,
but gets corruption from the BIOS. What kernel version are you trying
to boot?

-hpa

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

H. Peter Anvin schrieb am Thu, Jul 26, 2007 at 12:30:21PM -0700:
> Peter Bartke wrote:
> > Hi,
> >
> > I am trying to track down a ISOLINUX boot problem on my workhorse computer.
> > Booting slax-6.0.0-rc5.iso from www.slax.org (a live distro) from CD gives the
> > following messages:
> >
> > Loading /boot/vmlinuz ...........
> > Loading /boot/initrd.gz ............
> > Ready.
> > _
> >
> > Silence. The next message should be, but does not appear:
> > Uncompressing Linux ...........
> > This message appears with the same CD on an old Pentium III, so the CD is not
> > broken, it boots perfectly on the old PC. I discussed the problem on the Slax
> > forum but I seem to be the only one with this problem.
>
> You are aware that burnable CDs don't necessarily "work" or "not work";
> it's fairly common for them to be marginal so that they work in some
> machines, but not others, right?

Ok, but I burnt at least 5 different CDs with different isolinux.bin, so
probability theory would help me :-)

>
> Since you can boot the offending machine, I would try to dd the CD to an
> image *on the failing machine* and compare it to the raw image. That
> doesn't necessarily imply things are hunky-dory, but it's something.
>

OK, I'll check that.

> > The computer is a P4 on ASUS P5GD2, 1GB RAM, AMI BIOS, 3 SATA disks, DVD-ROM,
> > CD-RW. It _successfully_ boots from disk several SuSE distros, Slackware 12
> > and the unchanged content of the incriminated CD, written to an empty
> > partition, with the following GRUB-menu.lst entry:
> >
> > title Slax 6.0 RC5
> > root (hd1,5)
> > kernel (hd1,5)/boot/vmlinuz init=linuxrc vga=0x31a splash=verbose \
> > load_ramdisk=1 ramdisk_size=6666 root=/dev/ram0 rw
> > initrd (hd1,5)/boot/initrd.gz
> >
> > So I know the kernel on the failing CD is bootable. The corresponding
> > isolinux.cfg entry on the CD is
> >
> > LABEL slax
> > MENU LABEL Slax Text mode
> > KERNEL /boot/vmlinuz
> > APPEND vga=normal initrd=/boot/initrd.gz ramdisk_size=6666 root=/dev/ram0 rw
> >
> > I tried isolinux.bin from three versions of syslinux, including the newest. I
> > tried to get more info by running isolinux-debug.bin from syslinux-3.51,
> > resulting in permanently the same messages (see above) and a boot stall
> > afterwards.
> >
> > I would very much appreciate any hints how to proceed further isolating the
> > cause of the failure.
>
> What it looks like to me is that ISOLINUX reads the data in question,
> but gets corruption from the BIOS. What kernel version are you trying
> to boot?

I'm also suspicious of the BIOS of the ASUS P5GD2 board.
This is the output of `lshw':
description: BIOS
vendor: American Megatrends Inc.
physical id: 0
version: 1005.009 (02/03/2005)
size: 64KB
capacity: 448KB
capabilities: isa pci pnp apm upgrade shadowing escd cdboot
bootselect socketedrom edd int13floppy1200 int13floppy720
int13floppy2880 int5printscreen int9keyboard int14serial int17printer
int10video acpi usb agp ls120boot zipboot biosbootspecification

The Kernel is 2.6.21.5. slax-6.0.0-rc5.iso with this kernel apparently
boots for a lot of people.

The first lines of the successful boot form harddisk are:

Jul 25 20:41:01 ravel kernel: Linux version 2.6.21.5-smp (root@midas)
(gcc version 4.1.2) #2 SMP Tue Jun 19 14:58:11 CDT 2007
Jul 25 20:41:01 ravel kernel: BIOS-provided physical RAM map:
Jul 25 20:41:01 ravel kernel: 127MB HIGHMEM available.
Jul 25 20:41:01 ravel kernel: 896MB LOWMEM available.
Jul 25 20:41:01 ravel kernel: found SMP MP-table at 000ff780

Could there lurk a memory fragmentation problem as in ancient ages?

>
> -hpa
>

Peter
> _______________________________________________
> SYSLINUX mailing list
> Submissions to SYSLINUX@zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
> Please do not send private replies to mailing list traffic.
>

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Peter Bartke wrote:
>
> I'm also suspicious of the BIOS of the ASUS P5GD2 board.
> This is the output of `lshw':
> description: BIOS
> vendor: American Megatrends Inc.
> physical id: 0
> version: 1005.009 (02/03/2005)
> size: 64KB
> capacity: 448KB
> capabilities: isa pci pnp apm upgrade shadowing escd cdboot
> bootselect socketedrom edd int13floppy1200 int13floppy720
> int13floppy2880 int5printscreen int9keyboard int14serial int17printer
> int10video acpi usb agp ls120boot zipboot biosbootspecification
>
> The Kernel is 2.6.21.5. slax-6.0.0-rc5.iso with this kernel apparently
> boots for a lot of people.

The BIOS is almost certainly chief suspect #1. There are BIOSes which
have been known to be sensitive to the exact location to the kernel
image on the CD -- why, I don't know (my best guess would involve
inappropriate timeouts; CDs can take a long time seeking.) That is part
of why I recommend trying to force mkisofs to put the kernel and the
isolinux file near the start of the disc.

> The first lines of the successful boot form harddisk are:
>
> Jul 25 20:41:01 ravel kernel: Linux version 2.6.21.5-smp (root@midas)
> (gcc version 4.1.2) #2 SMP Tue Jun 19 14:58:11 CDT 2007
> Jul 25 20:41:01 ravel kernel: BIOS-provided physical RAM map:
> Jul 25 20:41:01 ravel kernel: 127MB HIGHMEM available.
> Jul 25 20:41:01 ravel kernel: 896MB LOWMEM available.
> Jul 25 20:41:01 ravel kernel: found SMP MP-table at 000ff780
>
> Could there lurk a memory fragmentation problem as in ancient ages?

No, that's a pretty typical readout for a 1 GB machine.

However, tweaking a mem= option might answer that for sure, e.g. mem=800M.

-hpa

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

H. Peter Anvin schrieb am Thu, Jul 26, 2007 at 12:30:21PM -0700:
> Peter Bartke wrote:
[..]

> Since you can boot the offending machine, I would try to dd the CD to an
> image *on the failing machine* and compare it to the raw image. That
> doesn't necessarily imply things are hunky-dory, but it's something.
>

I made a fresh CD copy, dd from /dev/cdrom and diff'ed to the .iso.
The files were the same, the md5sums as well. All done on the failing
machine.

I booted the fresh copy, resulting in the same boot stall. I boot selected
with F8 (boot selection menu) the CD-RW for booting, same effect on the
other drive.

Peter

[..]
> _______________________________________________
> SYSLINUX mailing list
> Submissions to SYSLINUX@zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
> Please do not send private replies to mailing list traffic.
>

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

H. Peter Anvin schrieb am Thu, Jul 26, 2007 at 02:06:49PM -0700:
> Peter Bartke wrote:
> >
> > I'm also suspicious of the BIOS of the ASUS P5GD2 board.
> > This is the output of `lshw':
> > description: BIOS
> > vendor: American Megatrends Inc.
> > physical id: 0
> > version: 1005.009 (02/03/2005)
> > size: 64KB
> > capacity: 448KB
> > capabilities: isa pci pnp apm upgrade shadowing escd cdboot
> > bootselect socketedrom edd int13floppy1200 int13floppy720
> > int13floppy2880 int5printscreen int9keyboard int14serial int17printer
> > int10video acpi usb agp ls120boot zipboot biosbootspecification
> >
> > The Kernel is 2.6.21.5. slax-6.0.0-rc5.iso with this kernel apparently
> > boots for a lot of people.
>
> The BIOS is almost certainly chief suspect #1. There are BIOSes which
> have been known to be sensitive to the exact location to the kernel
> image on the CD -- why, I don't know (my best guess would involve
> inappropriate timeouts; CDs can take a long time seeking.) That is part
> of why I recommend trying to force mkisofs to put the kernel and the
> isolinux file near the start of the disc.
>

This is a Live CD which starts from RAM-disk. Please correct me, if I'm
wrong - after seeing the message `Ready.', isolinux.bin transfers control
to the vmlinuz in RAM. And the kernel has its initial boot disk in RAM.
To me this seems more a RAM problem (finding the entry point?) than a CD
read problem. By the way, I made a complete mem86 RAM test to exclude
dirty bits.

Peter

> > The first lines of the successful boot form harddisk are:
> >
> > Jul 25 20:41:01 ravel kernel: Linux version 2.6.21.5-smp (root@midas)
> > (gcc version 4.1.2) #2 SMP Tue Jun 19 14:58:11 CDT 2007
> > Jul 25 20:41:01 ravel kernel: BIOS-provided physical RAM map:
> > Jul 25 20:41:01 ravel kernel: 127MB HIGHMEM available.
> > Jul 25 20:41:01 ravel kernel: 896MB LOWMEM available.
> > Jul 25 20:41:01 ravel kernel: found SMP MP-table at 000ff780
> >
> > Could there lurk a memory fragmentation problem as in ancient ages?
>
> No, that's a pretty typical readout for a 1 GB machine.
>
> However, tweaking a mem= option might answer that for sure, e.g. mem=800M.

I'll try that as well.

>
> -hpa
>
> _______________________________________________
> SYSLINUX mailing list
> Submissions to SYSLINUX@zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
> Please do not send private replies to mailing list traffic.
>

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

H. Peter Anvin schrieb am Thu, Jul 26, 2007 at 02:06:49PM -0700:
> Peter Bartke wrote:
> >
> > I'm also suspicious of the BIOS of the ASUS P5GD2 board.
> > This is the output of `lshw':
> > description: BIOS
> > vendor: American Megatrends Inc.
> > physical id: 0
> > version: 1005.009 (02/03/2005)
> > size: 64KB
> > capacity: 448KB
> > capabilities: isa pci pnp apm upgrade shadowing escd cdboot
> > bootselect socketedrom edd int13floppy1200 int13floppy720
> > int13floppy2880 int5printscreen int9keyboard int14serial int17printer
> > int10video acpi usb agp ls120boot zipboot biosbootspecification
> >
> > The Kernel is 2.6.21.5. slax-6.0.0-rc5.iso with this kernel apparently
> > boots for a lot of people.
>
> The BIOS is almost certainly chief suspect #1. There are BIOSes which
> have been known to be sensitive to the exact location to the kernel
> image on the CD -- why, I don't know (my best guess would involve
> inappropriate timeouts; CDs can take a long time seeking.) That is part
> of why I recommend trying to force mkisofs to put the kernel and the
> isolinux file near the start of the disc.
>
> > The first lines of the successful boot form harddisk are:
> >
> > Jul 25 20:41:01 ravel kernel: Linux version 2.6.21.5-smp (root@midas)
> > (gcc version 4.1.2) #2 SMP Tue Jun 19 14:58:11 CDT 2007
> > Jul 25 20:41:01 ravel kernel: BIOS-provided physical RAM map:
> > Jul 25 20:41:01 ravel kernel: 127MB HIGHMEM available.
> > Jul 25 20:41:01 ravel kernel: 896MB LOWMEM available.
> > Jul 25 20:41:01 ravel kernel: found SMP MP-table at 000ff780
> >
> > Could there lurk a memory fragmentation problem as in ancient ages?
>
> No, that's a pretty typical readout for a 1 GB machine.
>
> However, tweaking a mem= option might answer that for sure, e.g. mem=800M.

Sorry, this doesn't cure the problem. The pile of failing CDs grows ;-)
Very irritating that such a lot of CDs (SuSE, Slackware, ...) booted
without problems on this computer and this one fails.

Peter
>
> -hpa
>
> _______________________________________________
> SYSLINUX mailing list
> Submissions to SYSLINUX@zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
> Please do not send private replies to mailing list traffic.
>

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Peter Bartke wrote:
>
> This is a Live CD which starts from RAM-disk. Please correct me, if I'm
> wrong - after seeing the message `Ready.', isolinux.bin transfers control
> to the vmlinuz in RAM. And the kernel has its initial boot disk in RAM.
> To me this seems more a RAM problem (finding the entry point?) than a CD
> read problem. By the way, I made a complete mem86 RAM test to exclude
> dirty bits.
>

"Ready." is indeed the point at which we transfer control to the kernel
setup code. It might be interesting to put "vga=ask" on the kernel
command line; that should give you some interaction with the kernel
setup code, which runs in real mode before the kernel is decompressed.
That will help narrow down the problem.

-hpa

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Peter Bartke wrote:
>>
>> However, tweaking a mem= option might answer that for sure, e.g. mem=800M.
>
> Sorry, this doesn't cure the problem. The pile of failing CDs grows ;-)
> Very irritating that such a lot of CDs (SuSE, Slackware, ...) booted
> without problems on this computer and this one fails.
>

You know you can tweak the options at the boot: prompt; no need to burn
a new CD.

-hpa

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Hallo, Peter,

Du (bartke) meintest am 26.07.07:

> I made a fresh CD copy, dd from /dev/cdrom and diff'ed to the .iso.
> The files were the same, the md5sums as well. All done on the failing
> machine.

> I booted the fresh copy, resulting in the same boot stall. I boot
> selected with F8 (boot selection menu) the CD-RW for booting, same
> effect on the other drive.

Just for checking CDs and burner: can you please burn a Knoppix CD (or
some other usable CD) and try it?

ftp://ftp.kernel.org/pub/dist/knoppix/KNOPPIX_V5.1.1CD-2007-01-04-DE.iso

Viele Gruesse!
Helmut

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Hi Helmut,

Helmut Hullen schrieb am Fri, Jul 27, 2007 at 09:20:00AM +0200:
> Hallo, Peter,
>
> Du (bartke) meintest am 26.07.07:
>
> > I made a fresh CD copy, dd from /dev/cdrom and diff'ed to the .iso.
> > The files were the same, the md5sums as well. All done on the failing
> > machine.
>
> > I booted the fresh copy, resulting in the same boot stall. I boot
> > selected with F8 (boot selection menu) the CD-RW for booting, same
> > effect on the other drive.
>
> Just for checking CDs and burner: can you please burn a Knoppix CD (or
> some other usable CD) and try it?
>
> ftp://ftp.kernel.org/pub/dist/knoppix/KNOPPIX_V5.1.1CD-2007-01-04-DE.iso

Remember, I installed on this computer SUSE 9.3/10.1/10.2, the first two
by DVD, the last by 5 openSuSE CDs, Slackware 11/Slackware 12 were
installed by 3 CD's. The Slax Distribution 5.1.8 Live CD starts without
problems. Only Slax 6.0RC4 and Slax 6.0RC5 showed this problem. Thus I
discussed it first on the Slax forum with main developer Tomas. Finally
I came here. After analyzing I can only suspect a combination of
isolinux.bin and kernel 2.6.21.5 guilty. This very kernel boots
perfectly by Grub from disk!

Liebe Gruesse zurueck,

Peter

>
> Viele Gruesse!
> Helmut
>
> _______________________________________________
> SYSLINUX mailing list
> Submissions to SYSLINUX@zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
> Please do not send private replies to mailing list traffic.
>

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

H. Peter Anvin schrieb am Thu, Jul 26, 2007 at 03:57:27PM -0700:
> Peter Bartke wrote:
> >
> > This is a Live CD which starts from RAM-disk. Please correct me, if I'm
> > wrong - after seeing the message `Ready.', isolinux.bin transfers control
> > to the vmlinuz in RAM. And the kernel has its initial boot disk in RAM.
> > To me this seems more a RAM problem (finding the entry point?) than a CD
> > read problem. By the way, I made a complete mem86 RAM test to exclude
> > dirty bits.
> >
>
> "Ready." is indeed the point at which we transfer control to the kernel
> setup code. It might be interesting to put "vga=ask" on the kernel
> command line; that should give you some interaction with the kernel
> setup code, which runs in real mode before the kernel is decompressed.
> That will help narrow down the problem.
>

I see the message `Press <RETURN> to see the video modes' with a list
of 6 video modes, then `Enter mode number or `scan':'. I tried `scan',
which led to losing the video signal for nearly a minute, then it came
back with a cleared screen and a list of 7 video modes. After entering
number 1 I got `the famous boot stall'.

Does this vga=ask action come from isolinux.bin code or from vmlinuz
code? Do you have any other suggestions for command line twiddling?

Peter

>
> _______________________________________________
> SYSLINUX mailing list
> Submissions to SYSLINUX@zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
> Please do not send private replies to mailing list traffic.
>

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Hallo, Peter,

Du (bartke) meintest am 27.07.07:

>> Just for checking CDs and burner: can you please burn a Knoppix CD
>> (or some other usable CD) and try it?

> Remember, I installed on this computer SUSE 9.3/10.1/10.2, the first
> two by DVD, the last by 5 openSuSE CDs, Slackware 11/Slackware 12
> were installed by 3 CD's.

Yes - I had seen.
But I haven't read that you had used other self burned CDs without
problems - even burners may die.

> After analyzing I can only suspect a combination of isolinux.bin and
> kernel 2.6.21.5 guilty. This very kernel boots perfectly by Grub from
> disk!

Ok - I'm warned!

Viele Gruesse!
Helmut

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

> What it looks like to me is that ISOLINUX reads the data in question,
> but gets corruption from the BIOS. What kernel version are you trying
> to boot?

I think I can answer this question, as the author of Slax6rc5 :)
The kernel is 2.6.21.5

A question, what shows the "uncompressing kernel" message? isolinux or
kernel itself?


Tomas M

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

H. Peter Anvin schrieb am Thu, Jul 26, 2007 at 03:57:27PM -0700:
> Peter Bartke wrote:
> >
> > This is a Live CD which starts from RAM-disk. Please correct me, if I'm
> > wrong - after seeing the message `Ready.', isolinux.bin transfers control
> > to the vmlinuz in RAM. And the kernel has its initial boot disk in RAM.
> > To me this seems more a RAM problem (finding the entry point?) than a CD
> > read problem. By the way, I made a complete mem86 RAM test to exclude
> > dirty bits.
> >
>
> "Ready." is indeed the point at which we transfer control to the kernel
> setup code. It might be interesting to put "vga=ask" on the kernel
> command line; that should give you some interaction with the kernel
> setup code, which runs in real mode before the kernel is decompressed.
> That will help narrow down the problem.
>

To further isolate the problem I took slax-6.0.0-rc5.iso - which is one
of those two that produce the boot stall under investigation - and
replaced the isolinux boot machinery on this disk by the following
minimal grub files:

/boot/grub/stage2_eltorito
/boot/grub/menu.lst:
default 0
timeout 60
color cyan/blue white/blue
title Slax 6.0 RC5
root (cd)
kernel (cd)/boot/vmlinuz init=linuxrc vga=0x31a splash=0 load_ramdisk=1 ramdisk_size=6666 root=/dev/ram0 rw
initrd=/boot/initrd.gz

The line
mkisofs -R -b boot/grub/stage2_eltorito -no-emul-boot -boot-load-size 4 \
-boot-info-table -o slax-6rc5-grub.iso grubcd
built a perfectly bootable iso file!

May I conclude that isolinux.bin (several tested versions up to the
newest) in combination with a linux-2.6.21.5 kernel from the Slax
distribution (Slax 6 RC4/RC5) produces _on some hardware (mine)_ a boot
stall. The other bootloader succeeds on the same hardware.

I should mention that I have really no preferences for any boot loader.
By the way, the used grub in this experiment was the legacy one, `flawed
by design' ...

Peter
> _______________________________________________
> SYSLINUX mailing list
> Submissions to SYSLINUX@zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
> Please do not send private replies to mailing list traffic.
>

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Tomas M wrote:
>> What it looks like to me is that ISOLINUX reads the data in question,
>> but gets corruption from the BIOS. What kernel version are you trying
>> to boot?
>
> I think I can answer this question, as the author of Slax6rc5 :)
> The kernel is 2.6.21.5
>
> A question, what shows the "uncompressing kernel" message? isolinux or
> kernel itself?
>

"Uncompressing kernel..." comes from the kernel decompressor, which is
the second of three stages embedded in the kernel image.

Stage 1 is the kernel setup code. Usually silent, but if you specify
"vga=ask" you get a menu from the setup code.

Stage 2 is the kernel decompressor, prints "Uncompressing kernel... done."

Stage 3 is the kernel proper, which prints a number of messages, of course.

-hpa

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Peter Bartke wrote:
>
> Remember, I installed on this computer SUSE 9.3/10.1/10.2, the first two
> by DVD, the last by 5 openSuSE CDs, Slackware 11/Slackware 12 were
> installed by 3 CD's. The Slax Distribution 5.1.8 Live CD starts without
> problems. Only Slax 6.0RC4 and Slax 6.0RC5 showed this problem. Thus I
> discussed it first on the Slax forum with main developer Tomas. Finally
> I came here. After analyzing I can only suspect a combination of
> isolinux.bin and kernel 2.6.21.5 guilty. This very kernel boots
> perfectly by Grub from disk!
>

It probably isn't the kernel so much as the exact alignment mkisofs ends
up using to put it on the CD, i.e. it depends mostly on other files.
This has been reported a number of times; I just haven't found a
workaround for it. It's a massive problem that the BIOS doesn't report
an error, but instead fail silently. This makes it very, very hard for
ISOLINUX to know that a workaround is needed.

Since you happen to have a very reproducible case even when isolinux.bin
is changed, this might be very valuable. I'm about to embark a plane,
but I will think about what kind of workarounds could possibly help.

-hpa

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

H. Peter Anvin schrieb am Fri, Jul 27, 2007 at 07:19:36AM -0700:
> Tomas M wrote:
> > A question, what shows the "uncompressing kernel" message? isolinux or
> > kernel itself?
> >
>
> "Uncompressing kernel..." comes from the kernel decompressor, which is
> the second of three stages embedded in the kernel image.
>
> Stage 1 is the kernel setup code. Usually silent, but if you specify
> "vga=ask" you get a menu from the setup code.
>
> Stage 2 is the kernel decompressor, prints "Uncompressing kernel... done."
>
> Stage 3 is the kernel proper, which prints a number of messages, of course.
>

Now it's clear that the boot process on my machine silently stops at
kernel stage 2. I could see the messages from stage 1 (see earlier post).

Peter

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

H. Peter Anvin schrieb am Fri, Jul 27, 2007 at 07:25:00AM -0700:
>
> It probably isn't the kernel so much as the exact alignment mkisofs ends
> up using to put it on the CD, i.e. it depends mostly on other files.
> This has been reported a number of times; I just haven't found a
> workaround for it. It's a massive problem that the BIOS doesn't report
> an error, but instead fail silently. This makes it very, very hard for
> ISOLINUX to know that a workaround is needed.
>
> Since you happen to have a very reproducible case even when isolinux.bin
> is changed, this might be very valuable. I'm about to embark a plane,
> but I will think about what kind of workarounds could possibly help.

Please tell when you have got ideas for testing this case.

What I am trying now: systematically playing with `mkisofs' options to
look for a bootable combination.

Peter

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Peter Bartke wrote:
> H. Peter Anvin schrieb am Fri, Jul 27, 2007 at 07:25:00AM -0700:
>> It probably isn't the kernel so much as the exact alignment mkisofs ends
>> up using to put it on the CD, i.e. it depends mostly on other files.
>> This has been reported a number of times; I just haven't found a
>> workaround for it. It's a massive problem that the BIOS doesn't report
>> an error, but instead fail silently. This makes it very, very hard for
>> ISOLINUX to know that a workaround is needed.
>>
>> Since you happen to have a very reproducible case even when isolinux.bin
>> is changed, this might be very valuable. I'm about to embark a plane,
>> but I will think about what kind of workarounds could possibly help.
>
> Please tell when you have got ideas for testing this case.
>
> What I am trying now: systematically playing with `mkisofs' options to
> look for a bootable combination.

That is probably wise, especially the -sort option.

-hpa

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Peter Bartke wrote:
> H. Peter Anvin schrieb am Fri, Jul 27, 2007 at 07:19:36AM -0700:
>> Tomas M wrote:
>>> A question, what shows the "uncompressing kernel" message? isolinux or
>>> kernel itself?
>>>
>> "Uncompressing kernel..." comes from the kernel decompressor, which is
>> the second of three stages embedded in the kernel image.
>>
>> Stage 1 is the kernel setup code. Usually silent, but if you specify
>> "vga=ask" you get a menu from the setup code.
>>
>> Stage 2 is the kernel decompressor, prints "Uncompressing kernel... done."
>>
>> Stage 3 is the kernel proper, which prints a number of messages, of course.
>>
>
> Now it's clear that the boot process on my machine silently stops at
> kernel stage 2. I could see the messages from stage 1 (see earlier post).
>

As in "before", "during" or "after"?

-hpa

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

> Date: Fri, 27 Jul 2007 07:25:00 -0700
> From: "H. Peter Anvin" <hpa@zytor.com>
> Subject: Re: [syslinux] ISOLINUX boot problem: request for help
> To: For discussion of SYSLINUX and tftp-hpa <syslinux@zytor.com>
> Message-ID: <46AA003C.7030203@zytor.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Peter Bartke wrote:
> >
> > Remember, I installed on this computer SUSE 9.3/10.1/10.2, the first two
> > by DVD, the last by 5 openSuSE CDs, Slackware 11/Slackware 12 were
> > installed by 3 CD's. The Slax Distribution 5.1.8 Live CD starts without
> > problems. Only Slax 6.0RC4 and Slax 6.0RC5 showed this problem. Thus I
> > discussed it first on the Slax forum with main developer Tomas. Finally
> > I came here. After analyzing I can only suspect a combination of
> > isolinux.bin and kernel 2.6.21.5 guilty. This very kernel boots
> > perfectly by Grub from disk!
>
> It probably isn't the kernel so much as the exact alignment mkisofs ends
> up using to put it on the CD, i.e. it depends mostly on other files.
> This has been reported a number of times; I just haven't found a
> workaround for it. It's a massive problem that the BIOS doesn't report
> an error, but instead fail silently. This makes it very, very hard for
> ISOLINUX to know that a workaround is needed.
>
> Since you happen to have a very reproducible case even when isolinux.bin
> is changed, this might be very valuable. I'm about to embark a plane,
> but I will think about what kind of workarounds could possibly help.
>
> -hpa
>
>

Gentlemen: I have extensive experience using ISOLINUX and all rec
versions of Slax (incl Slax-6-RC5) and have never had a single
"phantom" problem w/ the pair. In fact, I just made my 1st RC5 disc
on Fri and it worked flawlessly, as expected.

When things don't work, they're usu attributable to a couple of things:

1) the -boot-info-table option: the absence of this cmd-line option
can cause discs to work fine on one PC and fail in bizarre (ie. different)
ways on other PCs. Personally, I use a commercial GUI program (in Windows)
for creating my ISOs, but K3B is available, esp if you remaster on a PC
that has more than one optical drive (one to boot with, one to burn with.)
Actually, one could use the version of K3B under RC5 to create an ISO or
burn directly to disc. Moreover, the make_iso script provided on the
Slax CD definitely works.

2) single-session CDs: Bec Slax is relatively small and bec I've
extended other CD projects using multiple sessions, I "thought" this mite
be possible w/ Slax. No. One must close (finalize) -boot-info-table
discs for them to work reliably on multiple PCs. Have wasted many CD-Rs
in pursuit of this goal and it's simply too unreliable, so I would strongly
discourage this practice. The final straw for me was when I tried a newly
burned-remastered RC3 (also open) disc on a client's PC. Had been working
on everything else, but the open RC3 disc failed immed trying to load the
kernel and dropped rite back to the 'boot:' prompt.

3) no CD-RWs: After doing this sort of thing for several years and having
noticed a reference to this in one of your replies: NO CD-RWs !
If you need test a remastered live CD project, use QEMU, Virtual Box, or
VMWare. You can also use the 'from=' parameter to load the contents of your
custom filesystem (ie. /boot and /slax) from a sub-dir on your hdrive (eg.
/mnt/hda1/rc5), then boot using something like 'from=/mnt/hda1/rc5' appended
to the ISOLINUX cmd-line.

I've made literally dozens of bootable CDs/DVDs using ISOLINUX as the sole
bootloader, in the past year and most incorporate Slax 5 or 6. I've even
started a discussion forum on the subj called Super-Disc:
http://www.msfn.org/board/index.php?showtopic=94398

In theory, this issue could represent the emergence of a new BIOS
incompatibility, but one mite consider these factors first.

Hope this helps....


=
Omron Blood Pressure Monitor On Sale
Top Ranking By Top Consumer Magazine. Free, Fast Delivery. All Models.
http://a8-asy.a8ww.net/a8-ads/adftrclick?redirectid=931e3c326a4ce77ecbd03a66c2415a7e


--
Powered by Outblaze

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

H. Peter Anvin schrieb am Sat, Jul 28, 2007 at 07:49:29PM -0700:
> Peter Bartke wrote:
> > H. Peter Anvin schrieb am Fri, Jul 27, 2007 at 07:19:36AM -0700:
> >> Tomas M wrote:
> >>> A question, what shows the "uncompressing kernel" message? isolinux or
> >>> kernel itself?
> >>>
> >> "Uncompressing kernel..." comes from the kernel decompressor, which is
> >> the second of three stages embedded in the kernel image.
> >>
> >> Stage 1 is the kernel setup code. Usually silent, but if you specify
> >> "vga=ask" you get a menu from the setup code.
> >>
> >> Stage 2 is the kernel decompressor, prints "Uncompressing kernel... done."
> >>
> >> Stage 3 is the kernel proper, which prints a number of messages, of course.
> >>
> >
> > Now it's clear that the boot process on my machine silently stops at
> > kernel stage 2. I could see the messages from stage 1 (see earlier post).
> >
>
> As in "before", "during" or "after"?
>

If vga=ask is given I can interactively decide on the video mode. After
giving the video mode, eg mode number 1 an pressing RET, cursor goes to
the next line. From this point in time there is no input possible and no
sign of running stage 2 is to be seen.

Peter

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

H. Peter Anvin schrieb am Sat, Jul 28, 2007 at 07:48:51PM -0700:
> Peter Bartke wrote:
> > H. Peter Anvin schrieb am Fri, Jul 27, 2007 at 07:25:00AM -0700:
> >> It probably isn't the kernel so much as the exact alignment mkisofs ends
> >> up using to put it on the CD, i.e. it depends mostly on other files.
> >> This has been reported a number of times; I just haven't found a
> >> workaround for it. It's a massive problem that the BIOS doesn't report
> >> an error, but instead fail silently. This makes it very, very hard for
> >> ISOLINUX to know that a workaround is needed.
> >>
> >> Since you happen to have a very reproducible case even when isolinux.bin
> >> is changed, this might be very valuable. I'm about to embark a plane,
> >> but I will think about what kind of workarounds could possibly help.
> >
> > Please tell when you have got ideas for testing this case.
> >
> > What I am trying now: systematically playing with `mkisofs' options to
> > look for a bootable combination.
>
> That is probably wise, especially the -sort option.
>

I needed some time and changed the options of the mkisofs invocation in
Tomas' make_iso.sh script, leaving all other factors the same,
especially I always reburnt with K3B the same brand (Sony) of CD:

mkisofs -o "$ISONAME" -v -J -R -D -A "$CDLABEL" -V "$CDLABEL" \
-no-emul-boot -boot-info-table -boot-load-size 4 \
-b boot/isolinux/isolinux.bin -c boot/isolinux/isolinux.boot ../.

1) Leaving out -D and -J in any combination - no boot
2) I installed from source the newest alpha version of the cdrtools
- and stumbled over all this mess with cdrecord/wodim. Then I
used mkisofs-2.01.01a31 from schily with the original options
- no boot.
3) I made file slsort
boot 2500
slax 2000
boot/isolinux/isolinux.bin 2900
boot/isolinux/isolinux.boot 2890
boot/isolinux/isolinux.cfg 2880
boot/vmlinuz 2800
boot/initrd.gz 2790
slax/base/001-core.lzm 2690
slax/base/002-apps.lzm 2680
slax/base/003-network.lzm 2670
slax/base/004-xorg.lzm 2660
slax/base/005-xapdeps.lzm 2650
slax/base/006-kde.lzm 2640
slax/base/007-kdeapps.lzm 2630
slax/base/008-office.lzm 2620
slax/base/009-devel.lzm 2610
and inserted option -sort slsort into the above command.
To my opinion this should place the boot machinery contiguous to
the beginning of the track - no boot.

I am now on the edge giving up with this problem. The most probable
cause may be not finding the drive/file in stage 2 for uncompressing.
But I ran out of creative ideas. Perhaps tomorrow I try as a last
resort a hardware change: swapping Master and Slave on IDE bus. Maybe
this has some effect on an eventually buggy BIOS.

Peter

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Duke McAllister schrieb am Sun, Jul 29, 2007 at 12:39:01PM -0500:
[..]
> Gentlemen: I have extensive experience using ISOLINUX and all rec
> versions of Slax (incl Slax-6-RC5) and have never had a single
> "phantom" problem w/ the pair. In fact, I just made my 1st RC5 disc
> on Fri and it worked flawlessly, as expected.

Now finally the person is found who can convince me that this is a
non-problem ;-). You are kindly invited to come here :-) and see that
there exists (maybe exactly) one exception to your extensive experience.

>
> When things don't work, they're usu attributable to a couple of things:
>
> 1) the -boot-info-table option: the absence of this cmd-line option
> can cause discs to work fine on one PC and fail in bizarre (ie. different)
> ways on other PCs. Personally, I use a commercial GUI program (in Windows)
> for creating my ISOs, but K3B is available, esp if you remaster on a PC
> that has more than one optical drive (one to boot with, one to burn with.)
> Actually, one could use the version of K3B under RC5 to create an ISO or
> burn directly to disc. Moreover, the make_iso script provided on the
> Slax CD definitely works.
>
> 2) single-session CDs: Bec Slax is relatively small and bec I've
> extended other CD projects using multiple sessions, I "thought" this mite
> be possible w/ Slax. No. One must close (finalize) -boot-info-table
> discs for them to work reliably on multiple PCs. Have wasted many CD-Rs
> in pursuit of this goal and it's simply too unreliable, so I would strongly
> discourage this practice. The final straw for me was when I tried a newly
> burned-remastered RC3 (also open) disc on a client's PC. Had been working
> on everything else, but the open RC3 disc failed immed trying to load the
> kernel and dropped rite back to the 'boot:' prompt.
>
> 3) no CD-RWs: After doing this sort of thing for several years and having
> noticed a reference to this in one of your replies: NO CD-RWs !
> If you need test a remastered live CD project, use QEMU, Virtual Box, or
> VMWare. You can also use the 'from=' parameter to load the contents of your
> custom filesystem (ie. /boot and /slax) from a sub-dir on your hdrive (eg.
> /mnt/hda1/rc5), then boot using something like 'from=/mnt/hda1/rc5' appended
> to the ISOLINUX cmd-line.
>
> I've made literally dozens of bootable CDs/DVDs using ISOLINUX as the sole
> bootloader, in the past year and most incorporate Slax 5 or 6. I've even
> started a discussion forum on the subj called Super-Disc:
> http://www.msfn.org/board/index.php?showtopic=94398
>
> In theory, this issue could represent the emergence of a new BIOS
> incompatibility, but one mite consider these factors first.
>

1) 2) 3) were always fullfilled.

> Hope this helps....
Sorry, not really ...

If you had followed the whole discussion, you would know:
- I know that these ISOs work without problems for most people.
- I used unchanged ISOs from www.slax.org: 6.0 RC4/5/6 didn't
boot, 5.1.8 booted.
- The boot stall appears after stage 1 of running vmlinuz.
- It is reproducible even if I use the CD-RW drive as a boot drive by
BIOS boot change. The DVD-ROM drive has booted numerous other
(Live or Install) CDs perfectly.
- All systematically changed ISOs were made with the script make_iso.sh
from the Slax-CD, using the command
mkisofs -o "$ISONAME" -v -J -R -D -A "$CDLABEL" -V "$CDLABEL" \
-no-emul-boot -boot-info-table -boot-load-size 4 \
-b boot/isolinux/isolinux.bin -c boot/isolinux/isolinux.boot ../.
- I tried various versions of isolinux.bin up to the newest.

These really time consuming tests led to the conclusion that the
problem is determined by three conditions:
- the (eventually buggy?) hard- and firmware of my P4/ASUS PGGD2 computer
- patched Kernel 2.6.21.5 from Slax RC4/5/6
- Boot from CD by syslinux with isolinux.bin
If one or more of these conditions are not met, the CD boots.

Please be assured that I've really no intent to prove something against
ISOLINUX or Slax. I made clear that the Grub test only served as a
test that the problem also depends on ISOLINUX somehow.

If computers work somehow deterministically, there should be a cause for
the problem. I would really like to find it.

Peter


_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.