From: adrian15 <adrian15sgd@gmail.com>
To: Andrey Borzenkov <arvidjaar@gmail.com>,
The development of GNU GRUB <grub-devel@gnu.org>
Subject: Re: How to deal with fatal device seeks?
Date: Sun, 16 Mar 2014 18:16:19 +0100 [thread overview]
Message-ID: <5325DC63.3070405@gmail.com> (raw)
In-Reply-To: <20140316204341.46f20ebb@opensuse.site>
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/
next prev parent reply other threads:[~2014-03-16 17:16 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-16 5:26 How to deal with fatal device seeks? adrian15
2014-03-16 16:05 ` adrian15
2014-03-16 16:43 ` Andrey Borzenkov
2014-03-16 17:16 ` adrian15 [this message]
2014-03-16 18:05 ` adrian15
2014-03-16 18:40 ` adrian15
2014-03-16 22:19 ` Vladimir 'φ-coder/phcoder' Serbinenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5325DC63.3070405@gmail.com \
--to=adrian15sgd@gmail.com \
--cc=arvidjaar@gmail.com \
--cc=grub-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.