built bootable iso with grub 

http://www.gossamer-threads.com/lists/engine?do=post_view_flat;post=8474;page=1;mh=-1;list=syslinux;sb=post_latest_reply;so=ASC

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

Example 1. File /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.

Re: ISOLINUX boot problem 

> 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.

"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

Re: ISOLINUX boot problem 

Tomas M wrote:

>> 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.

  1. Stage 1 is the kernel setup code. Usually silent, but if you specify "vga=ask" you get a menu from the setup code.
  2. Stage 2 is the kernel decompressor, prints "Uncompressing kernel… done."
  3. Stage 3 is the kernel proper, which prints a number of messages, of course.

-hpa

Re: ISOLINUX boot problem 

> > 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

Re: ISOLINUX boot problem 

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.

mr-roboto at linuxmail

Re: ISOLINUX boot problem 

> 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