UBCD5.00 (beta7) grub4dos menu External links Options

[Icecube]

Have you burned the iso or are you using grub4dos iso emulation?
If you use grub4dos iso emulation, it is normal that it doesn't work.
If you use it, press e at the Parted Magic entry that you want to boot and add iso_location=/ubcd50b11-grub4dos.iso (change to the correct path of the UBCD iso) to the end of the kernel line.

The Parted Magic menu can use some fine tuning, I know.

Avira antivirus will not work with grub4dos iso emulation (won't scan, because it can't find the definitions). Extract the /antivir/ dir from the iso and place it on the root of your partition or CD.

If you find any boot entries that don't work, let me know.

Can anyone test if Memory ==> Windows Memory Diagnostic in the isolinux menu works in VMware, without the ro bigraw parameter (press TAB to change it)? I tested it in qemu and VirtualBox and it works fine without it, but according to Victor, it doesn't work in VMware (he didn't tried the last version). Also test if it works with the grub4dos menu. Test if the ro bigraw parameter is needed on real hardware too.

[tinybit]

Add an extra parameter to the color command.

CODE

color cyan/black black/light-gray green/black

The original color has this syntax: color NORMAL [ HIGHLIGHT ]

Note that HIGHLIGHT is optional. So if we add the third argument, then HIGHLIGHT must be specified. Consider someone do not want to specify HIGHLIGHT.

Any other suggestions?

@ Tinybit:
Do you have any idea, why the initrds have to be loaded in a certain order, to get loaded correctly?

The original syslinux way seems to also load initrds in a certain order. I suspect the Linux kernel requires the proper order, or the contents of the initrds make differences, I mean, if both initrds contain a file/dir with the same filename/dirname, then last one loaded will take effect.

With

CODE

initrd FILE1 FILE2 ... FILEn

grub4dos will load FILEn first, and FILE1 last(in reverse order), because in this way the coding is simple and easy.

[Icecube]

The original color has this syntax: color NORMAL [ HIGHLIGHT ]

Note that HIGHLIGHT is optional. So if we add the third argument, then HIGHLIGHT must be specified. Consider someone do not want to specify HIGHLIGHT.

I know that the HIGHLIGHT parameter is optional. But I think that, when someone wants to specify the help text color, it isn't that rude to require that HIGHLIGHT needs to be specified too. (Now when HIGHLIGHT isn't given, it is implicitly declared, based on the color values of NORMAL.)
I think, it would be a bit stupid to add a complete new variable for it.

An (ugly) alternative would be, to add a extra parameter to color:
All parameters specified:

CODE

color cyan/black black/light-gray -helptext green/black

CODE

color cyan/black black/light-gray green/black

Normal and help text color specified:

CODE

color cyan/black  -helptext green/black

But I think that the following will be still the best way (won't break existing configurations and doesn't look so ugly):

CODE

color cyan/black black/light-gray green/black

Another question. Why can't you use all 16 colors for the background (not that I need the other 8 ones for UBCD)? Isolinux/syslinux can use the following colors as foreground and background color: black, dark grey, dark blue, bright blue, dark green, bright green, dark cyan, bright cyan, dark red, bright red, dark purple, bright purple, brown, yellow, light grey and white.

With

CODE

initrd FILE1 FILE2 ... FILEn

grub4dos will load FILEn first, and FILE1 last(in reverse order), because in this way the coding is simple and easy.

Can you add this to the documentation, please? Mention that the initrds need to be specified in reverse order compared with isolinux/syslinux.

[was_jaclaz]

An (ugly) alternative would be, to add a extra parameter to color:
All parameters specified:

CODE

color cyan/black black/light-gray -helptext green/black

It may be ugly, but it is remarkably clear, as I see it.

Would it be possible, leaving the color command as is, for compatibility with existing menues/GRUB ones, and add a new command, possibly spelled "properly" as "colour" with the new syntax?
As in:

colour --text cyan/black --highlight black/light-gray --helptext green/black

for the "enhanced" new menues?

jaclaz

[Icecube]

@ tinybit
I found a bug in grub4dos.

I used ubcd50b11 with the xdelta patch applied (size of UBCD iso = 238MB):

CODE

# Memory mapped UBCD50b11 iso
title UBCD50b11 Grub4dos (--mem)
find --set-root /ubcd50b11-grub4dos.iso
map --mem /ubcd50b11-grub4dos.iso (hd32)
map --hook
root (hd32)
configfile /ubcd/menus/grub4dos/main.lst

# Not memory mapped UBCD50b11 iso
# can't test this on real hardware (problem of making files continuous on linux)
# tested in Virtualbox
title UBCD50b11 Grub4dos
find --set-root /ubcd50b11-grub4dos.iso
map /ubcd50b11-grub4dos.iso (hd32)
map --hook
root (hd32)
configfile /ubcd/menus/grub4dos/main.lst

When I boot Offline password and registry editor from the memory mapped iso:

CODE

title Offline NT Password & Registry Editor 080802
kernel /ubcd/boot/offline/vmlinuz rw vga=1 init=/linuxrc
initrd /ubcd/boot/offline/scsi.cgz /ubcd/boot/offline/initrd.cgz

I get the following error (VirtualBox and on real hardware):

Checking if image is initramfs ... it isn't (bad gzip magic numbers); look like an initrd
....
RAMDISK: Compressed image found at block 0
List: of all partitions:
No filesystem could mount root, tried ext2 msdos vfat iso9660 fuseblk
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,1)

When I use the following entry to boot Offline password and registry editor from the memory mapped iso, it boots:

CODE

title Offline NT Password & Registry Editor 080802
kernel /ubcd/boot/offline/vmlinuz rw vga=1 init=/linuxrc
initrd /ubcd/boot/offline/initrd.cgz

When I boot Offline password and registry editor from the direct mapped iso, it boots fine in VirtualBox, not on real hardware:

CODE

title Offline NT Password & Registry Editor 080802
kernel /ubcd/boot/offline/vmlinuz rw vga=1 init=/linuxrc
initrd /ubcd/boot/offline/scsi.cgz /ubcd/boot/offline/initrd.cgz

When I put the vmlinuz, scsi.cgz and initrd.cgz files on my hard disk, it boots fine in VirtualBox, but not on real hardware.

CODE

title Offline NT Password & Registry Editor 080802
kernel /ubcd/boot/offline/vmlinuz rw vga=1 init=/linuxrc
initrd /ubcd/boot/offline/scsi.cgz /ubcd/boot/offline/initrd.cgz

The following does boot in VirtualBox and on real hardware.

CODE

title Offline NT Password & Registry Editor 080802
kernel /ubcd/boot/offline/vmlinuz rw vga=1 init=/linuxrc
initrd /ubcd/boot/offline/initrd.cgz

Booting the isolinux menu entry of Offline NT Password & Registry Editor on a memory mapped iso works in VirtualBox and on real hardware.

I also burned the iso to a CD-RW. The grub4dos menu entry for Offline NT Password & Registry Editor did give a kernel panic on real hardware.


I don't know if it is a feature of a bug:
When you boot an entry which has a help text, you see the following, when booting this entry:

CODE

Booting 'Memtest86 V3.4a
Thorough, stand alone memory test for x86 architecture computers. It executes
a series of numbered test sections to check for errors. These test sections
consist of a combination of test algorithm, data pattern and cache setting.
The execution order were arranged so that errors will be detected rapidly.'

instead of the old behavior:

CODE

Booting 'Memtest86 V3.4a'

I rather want to see the last, but maybe some other people will like the current look.
@ all
Can anyone confirm this behavior?

[tinybit]

@ tinybit
I found a bug in grub4dos.

I used ubcd50b11 with the xdelta patch applied (size of UBCD iso = 238MB):

CODE

# Memory mapped UBCD50b11 iso
title UBCD50b11 Grub4dos (--mem)
find --set-root /ubcd50b11-grub4dos.iso
map --mem /ubcd50b11-grub4dos.iso (hd32)
map --hook
root (hd32)
configfile /ubcd/menus/grub4dos/main.lst

# Not memory mapped UBCD50b11 iso
# can't test this on real hardware (problem of making files continuous on linux)
# tested in Virtualbox
title UBCD50b11 Grub4dos
find --set-root /ubcd50b11-grub4dos.iso
map /ubcd50b11-grub4dos.iso (hd32)
map --hook
root (hd32)
configfile /ubcd/menus/grub4dos/main.lst

When I boot Offline password and registry editor from the memory mapped iso:

CODE

title Offline NT Password & Registry Editor 080802
kernel /ubcd/boot/offline/vmlinuz rw vga=1 init=/linuxrc
initrd /ubcd/boot/offline/scsi.cgz /ubcd/boot/offline/initrd.cgz

I get the following error (VirtualBox and on real hardware):

When I use the following entry to boot Offline password and registry editor from the memory mapped iso, it boots:

CODE

title Offline NT Password & Registry Editor 080802
kernel /ubcd/boot/offline/vmlinuz rw vga=1 init=/linuxrc
initrd /ubcd/boot/offline/initrd.cgz

When I boot Offline password and registry editor from the direct mapped iso, it boots fine in VirtualBox, not on real hardware:

CODE

title Offline NT Password & Registry Editor 080802
kernel /ubcd/boot/offline/vmlinuz rw vga=1 init=/linuxrc
initrd /ubcd/boot/offline/scsi.cgz /ubcd/boot/offline/initrd.cgz

When I put the vmlinuz, scsi.cgz and initrd.cgz files on my hard disk, it boots fine in VirtualBox, but not on real hardware.

CODE

title Offline NT Password & Registry Editor 080802
kernel /ubcd/boot/offline/vmlinuz rw vga=1 init=/linuxrc
initrd /ubcd/boot/offline/scsi.cgz /ubcd/boot/offline/initrd.cgz

The following does boot in VirtualBox and on real hardware.

CODE

title Offline NT Password & Registry Editor 080802
kernel /ubcd/boot/offline/vmlinuz rw vga=1 init=/linuxrc
initrd /ubcd/boot/offline/initrd.cgz

Booting the isolinux menu entry of Offline NT Password & Registry Editor on a memory mapped iso works in VirtualBox and on real hardware.

I also burned the iso to a CD-RW. The grub4dos menu entry for Offline NT Password & Registry Editor did give a kernel panic on real hardware.

You have found a big problem of memory conflicts between "map" and Linux/initrd. It need some time to solve. Extremely grateful to you.

I don't know if it is a feature of a bug:
When you boot an entry which has a help text, you see the following, when booting this entry:

CODE

Booting 'Memtest86 V3.4a
Thorough, stand alone memory test for x86 architecture computers. It executes
a series of numbered test sections to check for errors. These test sections
consist of a combination of test algorithm, data pattern and cache setting.
The execution order were arranged so that errors will be detected rapidly.'

instead of the old behavior:

CODE

Booting 'Memtest86 V3.4a'

I rather want to see the last, but maybe some other people will like the current look.

It is not a feature. It is a bug. Thank you once more.

[tinybit]

just uploaded a build at http://download.gna.org/grub4dos/

Please check if the Linux boot problem solved.

This time the order of the initrds follows the syslinux way. I am sorry about this change.

[Icecube]

I am now at home (other PC).

On this PC, the old grub4dos version (11 february 2009) works when I burned the iso to a CD-RW. It also works with the memory mapped iso.
The last grub4dos version (13 february 2009) works also on this PC (only tested memory mapped iso).

Sunday I can test it, on the problematic PC. I had problems with booting "Offline password and recovery," without iso mapping, on this PC. Any suggestions?

This time the order of the initrds follows the syslinux way. I am sorry about this change.

I already wanted to ask you, to change the order .

@ all
Has anybody else problems with booting Offline password and recovery (normal CD boot, mapped iso (not to memory) or memory mapped iso)?

[tinybit]

I looked in the syslinux archive. It contains also a ldlinux.bin, besides the ldlinux.sys file.

I could let it partially work.

The 'Boot error' is a text that is available in ldlinux.bin, so it works at least partially. In fact, the bootsector works (512 first bytes = contents of ldlinux.bss, the rest is ldlinux.sys).

Without the help from the syslinux author, I suspect we could hardly go further than print the "Boot error" message.

Related thread for reference:
http://www.boot-land.net/forums/index.php?showtopic=7013

[Icecube]

Grub4dos version 15 febuari 2009.

Offline password and registry editor works now on the 'bad' PC:

Direct loading (vmlinuz, initrd.cgz and scsi.cgz on HDD) (didn't work before on this PC):

CODE

kernel /ubcd/boot/offline/vmlinuz rw vga=1 init=/linuxrc
initrd /ubcd/boot/offline/initrd.cgz /ubcd/boot/offline/scsi.cgz

WORKS!

Memory mapped and normal mapped iso work now on the bad PC and in Virtualbox.

I still find it strange that direct loading did work on Virtualbox and my PC at home and not on the other PC . But it works now! Thanks again, tinybit.