How to deal with fatal device seeks?

How to deal with fatal device seeks?

[adrian15]

   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/

Re: How to deal with fatal device seeks?

[adrian15]

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/

Re: How to deal with fatal device seeks?

[Andrey Borzenkov]

В Sun, 16 Mar 2014 17:05:53 +0100
adrian15 <adrian15sgd@gmail.com> пишет:

> 
> I'm getting the same problem
> ( FATAL: int13_cdrom: function 42. Can't use 64bits lba )
> 

This message does not exist in grub sources, so it likely comes from
firmware. 64 bit LBA would mean size over 2TB. So the first question -
what size of disks do you have?

> with hd0, hd1, hd2, hd3, and worse:
> 
> * hd2,msdos5
> 
> ls (hd2,msdos5)/
> 
> Is this a bug?
> 

Hard to tell. Do you actually have working filesystem(s) on these
partitions? The message itself simply means that grub attempts to read
very high offset. I wonder if it can be somehow byte order related.

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

Re: How to deal with fatal device seeks?

[adrian15]

El 16/03/14 17:43, Andrey Borzenkov escribió:
> В Sun, 16 Mar 2014 17:05:53 +0100
> adrian15 <adrian15sgd@gmail.com> пишет:
>
>>
>> I'm getting the same problem
>> ( FATAL: int13_cdrom: function 42. Can't use 64bits lba )
>>
>
> This message does not exist in grub sources, so it likely comes from
> firmware. 64 bit LBA would mean size over 2TB. So the first question -
> what size of disks do you have?

SATA 0: 200 GB (Windows 7)
SATA 1: 1 GB (Rescatux USB. E.g. Grub mkrescue disk)
SATA 2: 20 GB (SteamOS E.g. Debian)

>
>> with hd0, hd1, hd2, hd3, and worse:
>>
>> * hd2,msdos5
>>
>> ls (hd2,msdos5)/
>>
>> Is this a bug?
>>
>
> Hard to tell. Do you actually have working filesystem(s) on these
> partitions? The message itself simply means that grub attempts to read
> very high offset. I wonder if it can be somehow byte order related.

 From GRUB point of view:

* (hd2,msdos1) is Gnu/Linux root filesystem
* (hd2,msdos2) No such partition
* (hd2,msdos3) No such partition
* (hd2,msdos4) No such partition
* (hd2,msdos5) FATAL: int13_cdrom: function 42. Can't use 64bits lba

 From GNU/Linux point of view:

Disk /dev/sdc: 21.5 GB, 21474836480 bytes
255 heads, 63 sectors/track, 2610 cylinders, total 41943040 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00068a9f

    Device Boot      Start         End      Blocks   Id  System
/dev/sdc1   *        2048    40136703    20067328   83  Linux
/dev/sdc2        40138750    41940991      901121    5  Extended
/dev/sdc5        40138752    41940991      901120   82  Linux swap / Solaris


If I try:

ls (hd2,msdos5)/

from a 2.00-15 system mkrescue image (Super Grub2 Disk 2.00s1-beta6) I get:

error: unknown filesystem.

So, it's ok, because it is not a fatal error.
It would seem that somewhere between 2.00-15 and 2.02~beta2-7 (Debian 
version) the bug arises.

Or maybe the error was before because grub did actually to arise a FATAL 
error and it didn't.


Thank you for any indication on how to make more tests.

adrian15
-- 
Support free software. Donate to Super Grub Disk. Apoya el software 
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/

Re: How to deal with fatal device seeks?

[adrian15]

El 16/03/14 18:16, adrian15 escribió:
> If I try:
>
> ls (hd2,msdos5)/
>
> from a 2.00-15 system mkrescue image (Super Grub2 Disk 2.00s1-beta6) I get:
>
> error: unknown filesystem.
>
> So, it's ok, because it is not a fatal error.
> It would seem that somewhere between 2.00-15 and 2.02~beta2-7 (Debian
> version) the bug arises.
>
> Or maybe the error was before because grub did actually to arise a FATAL
> error and it didn't.

2.00-22 does not have the error.

So it narrows the search between 2.00-22 and 2.02~beta2-7.

adrian15

> Thank you for any indication on how to make more tests.
>
> adrian15

-- 
Support free software. Donate to Super Grub Disk. Apoya el software 
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/

Re: How to deal with fatal device seeks?

[adrian15]

I have digged the git log for partition related commits just in case you 
might think that they have something to do with my problem

(From 2.00 release to current head on master branch).

I have tried to filter them. So I have removed the ones related with 
strange table partitions or emulation code.

Here there are the commits:

http://git.savannah.gnu.org/cgit/grub.git/commit/?id=e88f0420b90c2565637962754cc26fa8a4ed9256
http://git.savannah.gnu.org/cgit/grub.git/commit/?id=4bad23a15fc129218f611f51dcb268c246b207f1
http://git.savannah.gnu.org/cgit/grub.git/commit/?id=25fc51a87929262c1cc132bc29cc083ce98f0e0e
http://git.savannah.gnu.org/cgit/grub.git/commit/?id=df6da5a52dc2ec424203c0f8001903435b177fa8
http://git.savannah.gnu.org/cgit/grub.git/commit/?id=b7b78edb1ca05f30dd07ebed4bcb3d5a39aa5358
http://git.savannah.gnu.org/cgit/grub.git/commit/?id=258f43b7d7bf4b03799b6cd3004b5372e082d01b
http://git.savannah.gnu.org/cgit/grub.git/commit/?id=86d08fdb18b0142c1ce1b95db1aae989502956c5


Just hope that you, that deal with GRUB source code every day, can find 
what might be the faulty commit so that I can test that the special 
commit source code and reproduce it (or not to reproduce it).

Thank you for any idea!

adrian15

El 16/03/14 19:05, adrian15 escribió:
> El 16/03/14 18:16, adrian15 escribió:
>> If I try:
>>
>> ls (hd2,msdos5)/
>>
>> from a 2.00-15 system mkrescue image (Super Grub2 Disk 2.00s1-beta6) I
>> get:
>>
>> error: unknown filesystem.
>>
>> So, it's ok, because it is not a fatal error.
>> It would seem that somewhere between 2.00-15 and 2.02~beta2-7 (Debian
>> version) the bug arises.
>>
>> Or maybe the error was before because grub did actually to arise a FATAL
>> error and it didn't.
>
> 2.00-22 does not have the error.
>
> So it narrows the search between 2.00-22 and 2.02~beta2-7.
>
> adrian15
>
>> Thank you for any indication on how to make more tests.
>>
>> adrian15
>

-- 
Support free software. Donate to Super Grub Disk. Apoya el software 
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/

Re: How to deal with fatal device seeks?

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 761 bytes --]

On 17.03.2014 05:05, adrian15 wrote:
> El 16/03/14 18:16, adrian15 escribió:
>> If I try:
>>
>> ls (hd2,msdos5)/
>>
>> from a 2.00-15 system mkrescue image (Super Grub2 Disk 2.00s1-beta6) I
>> get:
>>
>> error: unknown filesystem.
>>
>> So, it's ok, because it is not a fatal error.
>> It would seem that somewhere between 2.00-15 and 2.02~beta2-7 (Debian
>> version) the bug arises.
>>
>> Or maybe the error was before because grub did actually to arise a FATAL
>> error and it didn't.
> 
> 2.00-22 does not have the error.
> 
> So it narrows the search between 2.00-22 and 2.02~beta2-7.
> 
Use git bisect to find exact commit please.
> adrian15
> 
>> Thank you for any indication on how to make more tests.
>>
>> adrian15
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 274 bytes --]