I'm getting the same problem
( FATAL: int13_cdrom: function 42. Can't use 64bits lba )
with hd0, hd1, hd2, hd3, and worse:
* hd2,msdos5
ls (hd2,msdos5)/
Is this a bug?
adrian15
El 16/03/14 06:26, adrian15 escribió:
I use a for loop for detecting Operating systems like this one:
for dev in (*); do
echo $dev
done
but it hangs !!!
So some clues:
* Using 2.02~beta2-7 from Debian Unstable.
* The disk is an hybrid one (x86_64_efi + i386_pc).
* The error only happens when using Virtualbox in a non-EFI setup.
So some questions:
* Is it a bug that a non seekable device like (cd,apple4) or (cd,gpt1)
is available in non-EFI mode?
* Is it perhaps a Virtualbox bug?
* I cannot catch these fatal error as if they were exceptions inside a
try-catch. Or can I?
I will probably improve my searchindevices functions so that it also
filters these (cdsomething) devices as a workaround.
Thank you.
These are the minimal tests:
--- Using Qemu as EFI gives no problem:
echo (*)
(fd0) ... (cd) ... (cd,apple2),... (cd,gpt2)
ls (cd,apple4)/
error: unknown filesystem.
ls (cd,gpt1)/
error: unknown filesystem.
--- Using Virtualbox as BIOS (Ex. 1) (Problem):
echo (*)
(fd0) ... (cd) ... (cd,apple2),... (cd,gpt2)
ls (cd,apple4)/
FATAL: int13_cdrom: function 42. Can't use 64bits lba
--- Using Virtualbox as BIOS (Ex. 2) (No problem):
echo (*)
(fd0) ... (cd) ... (cd,apple2),... (cd,gpt2)
ls (cd,gpt4)/
error: unknown filesystem.
--- Using Virtualbox as BIOS (Ex. 3) (Problem):
echo (*)
(fd0) ... (cd) ... (cd,apple2),... (cd,gpt2)
ls (cd,gpt1)/
FATAL: int13_cdrom: function 42. Can't use 64bits lba
adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel