attempt to read or write outside of disk 'hd0'

[Joe]

I've just done the first upgrades for months on a netbook and a USB
hard drive, both containing sid installations. Yes, I know that's
risky, but the longer you leave it, the riskier it gets...

The netbook was fine. The hard drive installation completed an apt-get
update and apt-get upgrade while booted on a two-year-old laptop. I
thought I'd reboot before the dist-upgrade, as I usually do this, and
lo and behold, I'm dropped to a grub rescue> prompt after the message
in the subject line...

I can list the (hd0,1)/boot/ directory, but insmod normal gives the
illegal access message again.

The Net mostly reckons this is due to using too large a drive on an old
BIOS, but since this very drive has booted on this very computer many
dozens of times, without change in the partition structure, that is not
the case here.

I plugged it into the netbook, where it has also worked many times,
with the same result. I booted the netbook itself, chrooted, did an
update-grub followed by a grub-install to the *correct* drive, no
errors found, no change in boot behaviour. As far as I can tell from
fdisk, the partition table looks right, or at least not wildly
incorrect as it would need to be to cause this.

I'm assuming this is not a kernel issue, as grub is failing to read its
own modules from partition 1 correctly, and has not come close to
displaying its kernel menu. Am I right? There is a new kernel, 4.7, and
that and later kernels certainly have issues on my main workstation.
It's an i386 installation, though I can't see that being relevant,
apt-get really shouldn't have put in any 64-bit-only stuff.

This is not a particularly valuable installation, it's no big deal to
reinstall, but that seems a very Windows thing to do. I'd like to fix
it, if anyone has any ideas.

--
Joe

[Pascal Hambourg]

Le 05/05/2017 à 23:39, Joe a écrit :
>
> lo and behold, I'm dropped to a grub rescue> prompt after the message
> in the subject line...
>
> I can list the (hd0,1)/boot/ directory, but insmod normal gives the
> illegal access message again.
>
> The Net mostly reckons this is due to using too large a drive on an old
> BIOS, but since this very drive has booted on this very computer many
> dozens of times, without change in the partition structure, that is not
> the case here.

It can still be the case, but you may have been lucky until now if GRUB
files were written into the area accessible through the BIOS. Then there
was an upgrade which wrote the files outside this area.

You can check the sizes of the disk and the partition as viewed by GRUB
with the following commands :

ls (hd0)
ls (hd0,1)

[Joe]

The netbook is about seven years old, but the laptop is a two-year-old
HP running Windows 8. Its hard drive is 500GB of which the Win partition
is about 400GB.

The USB hard drive is physically 120GB, with the single Linux partition
being physically the first at just over 10GB. It is an i386 installation
with all modules, specifically in order to boot on practically
anything, and it does. The only computer I own which does not boot it
is, not surprisingly, my ARM-based Raspberry Pi. At least, until
yesterday's upgrade.

I don't think it is a BIOS issue, the laptop and netbook architectures
being utterly different, and the laptop being fairly new. Somehow, grub2
is reading a wildly inaccurate number from somewhere outside its own
boot code, or possibly, the grub2 update and installation software has
an obscure calculation bug.

--
Joe

[Pascal Hambourg]

Le 06/05/2017 à 10:35, Joe a écrit :

> Pascal Hambourg <pas...@plouf.fr.eu.org> wrote:
>>
>> You can check the sizes of the disk and the partition as viewed by
>> GRUB with the following commands :
>>
>> ls (hd0)
>> ls (hd0,1)
>
> The netbook is about seven years old, but the laptop is a two-year-old
> HP running Windows 8. Its hard drive is 500GB of which the Win partition
> is about 400GB.
>
> The USB hard drive is physically 120GB, with the single Linux partition
> being physically the first at just over 10GB.

(...)

> I don't think it is a BIOS issue

Indeed with such disk and partition sizes, it is unlikely that the issue
is caused by a BIOS limitation, even on a 7-year old PC.

However, the ls command I suggested may still be useful to check GRUB's
idea of the sizes.

[Joe]

ls (hd0)
(hd0): Filesystem is unknown.

ls (hd0,1)
(hd0,1): Filesystem is ext2. (after several seconds' pause)

I'm only getting the grub rescue> prompt, not the grub> prompt. Most of
grub2 isn't there yet. I believe that 'insmod normal' would bring the
full grub2 environment, but that command is hitting the illegal access
barrier.

--
Joe

[Pascal Hambourg]

Le 06/05/2017 à 17:19, Joe a écrit :
>>
>> However, the ls command I suggested may still be useful to check
>> GRUB's idea of the sizes.
>
> ls (hd0)
> (hd0): Filesystem is unknown.
>
> ls (hd0,1)
> (hd0,1): Filesystem is ext2. (after several seconds' pause)
>
> I'm only getting the grub rescue> prompt, not the grub> prompt.

I expected that "ls" would be the same in normal and rescue mode.
Obviously I was wrong.

If the GRUB version on the internal disk is the same, you could boot
from it while the USB disk is connected, and if the BIOS exposes the USB
disk even though it is not the boot disk (some BIOS do, others don't),
then you could use the "ls" command in normal mode to check (hd1) and
(hd1,1).

Also, if you want to check the partition table on the USB disk more
thoroughly, you can print it (p) in expert mode (x) with fdisk to
display both LBA and CHS parameters. CHS parameters cannot be used
beyond 8 GiB and should contain 1023/254/63.

[Joe]

Thanks, I'll have a go at that later. I'm currently bogged down in a
completely unrelated grub issue on a different (wheezy) machine: I have
an ext4 filesystem which passes fsck fine, to which I can write, but
which grub2 cannot see.

The same grub rescue> prompt, ls can see the partitions, but grub2
cannot read the root one, says 'unknown filesystem'. An attempt to
reload after a chroot assures me that grub-probe cannot read it,
either. The grub-probe installed in the current Knoppix sees it as
'ext2', which may be as much as I can hope for, but wheezy's
grub-probe cannot see it at all, presumably ext4 is too recent for it.

I'm not going to mess about any more, I'll recreate the partition as
ext3. No doubt grub will find a new and interesting error for me then.

--
Joe

[Pascal Hambourg]

Le 06/05/2017 à 20:06, Joe a écrit :
>
> Thanks, I'll have a go at that later. I'm currently bogged down in a
> completely unrelated grub issue on a different (wheezy) machine: I have
> an ext4 filesystem which passes fsck fine, to which I can write, but
> which grub2 cannot see.
>
> The same grub rescue> prompt, ls can see the partitions, but grub2
> cannot read the root one, says 'unknown filesystem'. An attempt to
> reload after a chroot assures me that grub-probe cannot read it,
> either. The grub-probe installed in the current Knoppix sees it as
> 'ext2', which may be as much as I can hope for, but wheezy's
> grub-probe cannot see it at all, presumably ext4 is too recent for it.

Ext4 was already the default filesystem type in Wheezy, and I have
happily used Wheezy and GRUB (1.99) on ext4 without any issue.

GRUB just report any ext2/3/4 filesystem as ext2.

[Joe]

Yes, I realise that wheezy knows ext4, which is why it didn't occur to
me not to use it, but grub did say 'unknown filesystem', and it did work
when I switched to an ext3 root partition. The Net seems to indicate a
troubled relationship between grub-probe and ext4.

Well, it didn't work actually, it gave me a new and interesting error:
'bad filename' when I tried ls. But it accepted 'insmod normal', and
then the 'normal' command gave me a kernel menu.

All is somewhat well now, except that this machine was to be a testbed
for a wheezy->jessie upgrade. The upgrade went reasonably well, but
several important daemons (most notably samba and exim4) need new
configuration files and options, so it's pretty much a migration rather
than an upgrade anyway. Apache2 was easier than expected, initially it
would not run at all, but all it needed was a '+' sign in a crucial
place. Fussy. But it's 9PM now and I've had enough for today... many
thanks for your help and encouragement.

--
Joe

[Joe]

On Sat, 6 May 2017 18:12:03 +0200
Pascal Hambourg <pas...@plouf.fr.eu.org> wrote:

> Le 06/05/2017 à 17:19, Joe a écrit :
> >>
> >> However, the ls command I suggested may still be useful to check
> >> GRUB's idea of the sizes.
> >
> > ls (hd0)
> > (hd0): Filesystem is unknown.
> >
> > ls (hd0,1)
> > (hd0,1): Filesystem is ext2. (after several seconds' pause)
> >
> > I'm only getting the grub rescue> prompt, not the grub> prompt.
>
> I expected that "ls" would be the same in normal and rescue mode.
> Obviously I was wrong.
>
> If the GRUB version on the internal disk is the same, you could boot
> from it while the USB disk is connected, and if the BIOS exposes the
> USB disk even though it is not the boot disk (some BIOS do, others
> don't), then you could use the "ls" command in normal mode to check
> (hd1) and (hd1,1).

Yes, that works, and looks right:

Device hd1: No known filesystem detected - Sector size 512B - Total
size 117220824KiB

Partition hd1,1: Filesystem type ext* - (Last mod time, UUID)
Partition start at 1024KiB - Total size 10485760KiB

However, (still from the host machine's grub):

grub> ls (hd1,1)/boot
< reasonable listing >

grub> set root=(hd1,1)
grub> linux /boot/vmlinuz-4.6.0-1-686-pae root=/dev/sdb1

gets me: error: "attempt to read or write outside of disk 'hd1'."

This result, from a second grub installation, suggests a broken
filesystem, despite the partition being readable and writeable when
mounted. I had already copied /etc from the drive, and was trying one
last attempt to boot to obtain a dpkg --get-selections in preparation
for a reinstall. A quick fsck /dev/sdb1 from the host confirms this,
and a couple of fsck -y runs (what have I to lose?) gets it booting
again. So --get-selections saved, and now to try the long-delayed
dist-upgrade...

Thanks again.

--
Joe