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.
> 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
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.
-hpa
> > 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 ../.
I installed from source the newest alpha version of the cdrtools
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
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:
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
> 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:
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 ../.
These really time consuming tests led to the conclusion that the problem is determined by three conditions:
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