Discussion:
Grub rescue
(too old to reply)
David WE Roberts
2013-03-24 16:14:48 UTC
Permalink
Should grub rescue started from an MBR disc be able to see GPT partitions?
David WE Roberts
2013-03-24 16:58:55 UTC
Permalink
Post by David WE Roberts
Should grub rescue started from an MBR disc be able to see GPT
partitions?
More detail now I think I have my posting sorted out :-)

What I have:

/dev/sda 64GB MBR SSD with Windows 7 64 bit, and GRUB2 as boot loader.
/dev/sdb 750GB MBR HDD with Ubuntu installed - GRUB2 chain loads from /dev/
sda. /boot/grub is on this drive.

What I want to have

/dev/sda 64GB MBR SSD with Windows 7 64 bit, and GRUB2 as boot loader.
/dev/sdb 3.0TB GPT HDD with Ubuntu installed - GRUB2 chain loads from /dev/
sda. /boot/grub is on this drive.

What I have done so far:
[various mis-steps left out]
Set up the 3TB HDD in Windows 7 as GPT.
Created the ext2 and swap partitions on the 3TB drive using gparted
Copied the partitions from the 750GB drive to the 3TB drive.
Unplugged the 750GB drive.

When I boot, I get (no surprise) the grub rescue prompt.

However when I search for partitions to boot from I can only see the MBR
disc.
I cannot see any partitions on the GPT disc.

I can see in grub.cfg (from /dev/sdb)

insmod part_msdos
insmod part_ext2
set root=(`hd1,msdos1)`

which I think may mean that grub is only looking for MBR drives but I'm
still getting into all this.

My main problem is that I would expect grub rescue to list all the
partitions it could see (at least all the partitions with an OS installed)
so I could then select the correct partition and boot up into Linux, then
run grub-update (and possibly `grub-install /dev/sda`) to get the new
drive properly identified.

So can someone please tell me if what I am doing is not catered for, or
which simple step I've missed out.

Thanks

David
Andrey Borzenkov
2013-03-24 19:47:24 UTC
Permalink
В Sun, 24 Mar 2013 16:58:55 +0000 (UTC)
Post by David WE Roberts
Post by David WE Roberts
Should grub rescue started from an MBR disc be able to see GPT partitions?
In rescue mode grub has only drivers that are built into core.img. If
you used grub-install, core.img contains only enough drivers to enable
access to grub partition (where /boot/grub is located).
Post by David WE Roberts
/dev/sda 64GB MBR SSD with Windows 7 64 bit, and GRUB2 as boot loader.
/dev/sdb 750GB MBR HDD with Ubuntu installed - GRUB2 chain loads from /dev/
sda. /boot/grub is on this drive.
So core.img will have only MBR handler.
Post by David WE Roberts
My main problem is that I would expect grub rescue to list all the
partitions it could see
Which is exactly what it does. It can see (or better, parse) only MBR.
Post by David WE Roberts
So can someone please tell me if what I am doing is not catered for, or
which simple step I've missed out.
If you still can boot in original configuration, reinstall grub while
explicitly adding part_gpt:

grub-install --modules=part_gpt ...

If you cannot return to original configuration - just follow boot
recovery procedure for your distro.
David WE Roberts
2013-03-24 19:56:53 UTC
Permalink
Post by Andrey Borzenkov
В Sun, 24 Mar 2013 16:58:55 +0000 (UTC)
Post by David WE Roberts
Post by David WE Roberts
Should grub rescue started from an MBR disc be able to see GPT partitions?
In rescue mode grub has only drivers that are built into core.img. If
you used grub-install, core.img contains only enough drivers to enable
access to grub partition (where /boot/grub is located).
Post by David WE Roberts
/dev/sda 64GB MBR SSD with Windows 7 64 bit, and GRUB2 as boot loader.
/dev/sdb 750GB MBR HDD with Ubuntu installed - GRUB2 chain loads from /dev/
sda. /boot/grub is on this drive.
So core.img will have only MBR handler.
Post by David WE Roberts
My main problem is that I would expect grub rescue to list all the
partitions it could see
Which is exactly what it does. It can see (or better, parse) only MBR.
Post by David WE Roberts
So can someone please tell me if what I am doing is not catered for, or
which simple step I've missed out.
If you still can boot in original configuration, reinstall grub while
grub-install --modules=part_gpt ...
If you cannot return to original configuration - just follow boot
recovery procedure for your distro.
Thanks Andrey - simple when you know how!

Is there any reason why GPT support could not be included as standard?

I am probably swimming in a very restricted pool, but it seems that the
main two disc partitioning schemes at the moment are MBR and GPT so if I
can update core.img with a GPT handler then it mustn't be too hard to ship
this as standard.

Whatever, I will give this a go.

My main problem has been that 95% (or more) of the online documentation
has started at the point where you have located the grub configuration and
started loading extra information.

Perhaps nobody else is trying to add a big disc to a dual boot
configuration and change it from MBR to GPT.

Thanks

David
Andrey Borzenkov
2013-03-24 20:28:00 UTC
Permalink
В Sun, 24 Mar 2013 19:56:53 +0000 (UTC)
Post by David WE Roberts
Is there any reason why GPT support could not be included as standard?
core.img is aimed to be as small as possible to increase chances it
can be embedded. And having cross-disk installation is always fragile.
Post by David WE Roberts
I am probably swimming in a very restricted pool, but it seems that the
main two disc partitioning schemes at the moment are MBR and GPT so if I
can update core.img with a GPT handler then it mustn't be too hard to ship
this as standard.
core.img is built on the fly, it is not shipped with grub.
Chris Murphy
2013-03-24 21:51:46 UTC
Permalink
Post by David WE Roberts
Is there any reason why GPT support could not be included as standard?
I am probably swimming in a very restricted pool, but it seems that the
main two disc partitioning schemes at the moment are MBR and GPT so if I
can update core.img with a GPT handler then it mustn't be too hard to ship
this as standard.
What you're talking about is more practical on UEFI systems where core.img appears as an EFI boot services application. Since the resulting grubx64.efi is stored as a file on the EFI System partition, it's limited to the free space on that partition, which is between 100MB-200 typically. Whereas the MBR gap on MBR disks is at best 1MB with a modern partitioner. And on GPT, the issue is you need to prequalify the specific BIOS with GPT since some BIOS firmware implementations get sand in their crack over GPT.
Post by David WE Roberts
Perhaps nobody else is trying to add a big disc to a dual boot
configuration and change it from MBR to GPT.
If the big disk is just a data disk, it should be GPT from the outset. Conversion may have some slight benefit as GPT is more well specified than MBR, has backup structures, and use CRC to validate the header. But as a boot disk, unless otherwise tested, on BIOS hardware MBR should be used. On UEFI hardware GPT should be used. Depending on firmware, you have a totally different core.img anyway.


Chris Murphy
David WE Roberts
2013-03-24 22:19:45 UTC
Permalink
On Mar 24, 2013, at 1:56 PM, David WE Roberts
Post by David WE Roberts
Is there any reason why GPT support could not be included as standard?
I am probably swimming in a very restricted pool, but it seems that the
main two disc partitioning schemes at the moment are MBR and GPT so if
I can update core.img with a GPT handler then it mustn't be too hard to
ship this as standard.
What you're talking about is more practical on UEFI systems where
core.img appears as an EFI boot services application. Since the
resulting grubx64.efi is stored as a file on the EFI System partition,
it's limited to the free space on that partition, which is between
100MB-200 typically. Whereas the MBR gap on MBR disks is at best 1MB
with a modern partitioner. And on GPT, the issue is you need to
prequalify the specific BIOS with GPT since some BIOS firmware
implementations get sand in their crack over GPT.
Post by David WE Roberts
Perhaps nobody else is trying to add a big disc to a dual boot
configuration and change it from MBR to GPT.
If the big disk is just a data disk, it should be GPT from the outset.
Conversion may have some slight benefit as GPT is more well specified
than MBR, has backup structures, and use CRC to validate the header. But
as a boot disk, unless otherwise tested, on BIOS hardware MBR should be
used. On UEFI hardware GPT should be used. Depending on firmware, you
have a totally different core.img anyway.
Chris Murphy
Thanks for that.

A whole new world of complications has opened up before me :-)

The hardware in question has EFI capability but is running at the moment
in legacy mode.

The big disc has been formatted as GPT because it is mainly intended for
data and that seems the way to go for the reasons you stated.

However the primary MBR SSD has really only space for one operating
system, which is Windows 7, so I need to be able to boot my luxuries off
the GPT disc.

However I don't want at the moment to get into UEFI booting off GPT discs
- just be able to fire up the initial bits of Grub from my MBR disc and
have the option of booting Windows 7 off MBR or Ububtu off GPT.

Oh, to be clear the current configuration has a 750GB 2.5" disc destined
for my laptop but pressed into temporary service as the second disc on my
new(ish) build.

Now the 3TB [when did the notation move from GB to GiB?] permanent data
disc has turned up I need to move my partitions across from an MBR disc to
a GPT disc but keep the booting organisation effectively the same.

So I seem to be stuck in a transition between old and new disc formats,
and old and new BIOS formats.

I could start all over again, have the 3TB disc as my main disc, UEFI
booting with GPT, and use the SSD as a cache.

However, shan't!

;-)

I think I am in the usual position of the traditional Irish directions:

"If I was going there I wouldn't start from here."

I am starting to suffer temptation to convert the SSD from MBR to GPT,
change the BIOS settings to UEFI, and go all modern.

Time for bed, I think.

Cheers

David
Chris Murphy
2013-03-25 01:23:49 UTC
Permalink
Post by David WE Roberts
The hardware in question has EFI capability but is running at the moment
in legacy mode.
That sucks. Almost invariably that means no native AHCI-SATA support due to the typical CSM implementation limiting what the hardware can do. You'll probably get IDE like speeds from disks, almost disqualifying for SSD usage, or RAID, and maybe it even affects the performance of a single recent HDD as those speeds are now regularly above 150MB/s even for laptop drives. So I'd re-evaluate this. The CSM-BIOS is desperation, for running things like Windows XP. It's not for running a reasonably recent linux distribution.
Post by David WE Roberts
However the primary MBR SSD has really only space for one operating
system, which is Windows 7, so I need to be able to boot my luxuries off
the GPT disc.
Windows 7 only boots from MBR disks on BIOS hardware. Windows 7 only boots from GPT disks on UEFI hardware.

Realize you're limiting the performance of that SSD by running the firmware in legacy mode.
Post by David WE Roberts
However I don't want at the moment to get into UEFI booting off GPT discs
- just be able to fire up the initial bits of Grub from my MBR disc and
have the option of booting Windows 7 off MBR or Ububtu off GPT.
Dual boot on BIOS is inherently limited because only one OS can "own" the MBR bootstrap code region, and thus there is only one bootloader. Yes, GRUB can chainload the Windows bootloader, so that's how you'd have to do it.

The alternative, which I think is much easier for narrow use cases, on UEFI: UEFI install Windows 7 and Linux. And instead of GRUB EFI, use either gummiboot or rEFInd as the EFI boot manager. Either one will run the Windows boot loader which then boots Windows; and can be configured to scan dynamically for a linux kernel. Since kernel 3.3.0 there is a built-in boot loader called EFI STUB, and gummiboot and rEFInd can directly boot linux using EFI STUB. You don't need another boot loader. And the configuration files are straightforward.
Post by David WE Roberts
Now the 3TB [when did the notation move from GB to GiB?] permanent data
disc has turned up I need to move my partitions across from an MBR disc to
a GPT disc but keep the booting organisation effectively the same.
Windows will not boot from a 3TB drive on BIOS computers. Period. You have to enable UEFI and reinstall Windows 7 to use that 3TB drive. Or use MBR and forgo 1TB.
Post by David WE Roberts
I could start all over again, have the 3TB disc as my main disc, UEFI
booting with GPT, and use the SSD as a cache.
Make the SSD bootable, and put apps on there as well. Use the 3TB for big files like music, pictures, movies, for which the HDD speed is plenty.
Post by David WE Roberts
I am starting to suffer temptation to convert the SSD from MBR to GPT,
change the BIOS settings to UEFI, and go all modern.
Time for bed, I think.
Yeah. You'll want to find out what the state of EFI support was for Windows 7. It first appeared in Vista, wasn't so great apparently. And I guess it's hit or miss with Windows 7. e.g. there's a sizable group trying to get Windows 7 to EFI boot on Macs, instead of using the CSM-BIOS (sometimes referred to as Boot Camp, in part) and it's much more difficult to hack and make it work, than Windows 8 EFI booting on the same Apple hardware. So there's some improvement with Windows 8 and UEFI, but I don't know more than this. Windows 7 EFI ought to work though.


Chris Murphy
Jordan Uggla
2013-03-25 04:19:17 UTC
Permalink
Post by David WE Roberts
Now the 3TB [when did the notation move from GB to GiB?] permanent data
disc has turned up I need to move my partitions across from an MBR disc to
a GPT disc but keep the booting organisation effectively the same.
So I seem to be stuck in a transition between old and new disc formats,
and old and new BIOS formats.
The normal procedure is to just run grub-install and (if needed)
grub-mkconfig after making whatever partitioning changes you want. Is
there any reason you can't do that?
--
Jordan Uggla (Jordan_U on irc.freenode.net)
Andrey Borzenkov
2013-03-25 05:36:45 UTC
Permalink
Post by Jordan Uggla
Post by David WE Roberts
Now the 3TB [when did the notation move from GB to GiB?] permanent data
disc has turned up I need to move my partitions across from an MBR disc to
a GPT disc but keep the booting organisation effectively the same.
So I seem to be stuck in a transition between old and new disc formats,
and old and new BIOS formats.
The normal procedure is to just run grub-install and (if needed)
grub-mkconfig after making whatever partitioning changes you want. Is
there any reason you can't do that?
To run grub-install you need to boot first, and to boot you need
access to /boot/grub and to access /boot/grub you need part_gpt. Which
is not available until you can access /boot/grub. Catch 22.
David WE Roberts
2013-03-25 09:41:48 UTC
Permalink
On Mon, Mar 25, 2013 at 8:19 AM, Jordan Uggla
On Sun, Mar 24, 2013 at 3:19 PM, David WE Roberts
Post by David WE Roberts
Now the 3TB [when did the notation move from GB to GiB?] permanent
data disc has turned up I need to move my partitions across from an
MBR disc to a GPT disc but keep the booting organisation effectively
the same.
So I seem to be stuck in a transition between old and new disc
formats, and old and new BIOS formats.
The normal procedure is to just run grub-install and (if needed)
grub-mkconfig after making whatever partitioning changes you want. Is
there any reason you can't do that?
To run grub-install you need to boot first, and to boot you need access
to /boot/grub and to access /boot/grub you need part_gpt. Which is not
available until you can access /boot/grub. Catch 22.
Yeah - summary of my problem to date.

Presumably enabling GPT with grub-install will allow me to use the grub
rescue prompt to get the copy of Ubuntu on the GPT disc booted up.

All I need now is the correct set of grub rescue commands to achieve this.

Cheers

Dave R
Chris Murphy
2013-03-25 16:08:17 UTC
Permalink
Post by David WE Roberts
Presumably enabling GPT with grub-install will allow me to use the grub
rescue prompt to get the copy of Ubuntu on the GPT disc booted up.
All I need now is the correct set of grub rescue commands to achieve this.
set and ls are your friend in rescue mode. Use ls to list the drives and their partitions. Use set to find out where grub thinks it should be looking for grub modules and grub.cfg, which is clearly wrong or it would have found them. The goal is to get rescue to load normal.mod, and then you can get it to execute grub.cfg which will load additional needed modules.

http://www.gnu.org/software/grub/manual/html_node/GRUB-only-offers-a-rescue-shell.html


Chris Murphy
Jordan Uggla
2013-03-25 17:05:31 UTC
Permalink
Post by Andrey Borzenkov
Post by Jordan Uggla
Post by David WE Roberts
Now the 3TB [when did the notation move from GB to GiB?] permanent data
disc has turned up I need to move my partitions across from an MBR disc to
a GPT disc but keep the booting organisation effectively the same.
So I seem to be stuck in a transition between old and new disc formats,
and old and new BIOS formats.
The normal procedure is to just run grub-install and (if needed)
grub-mkconfig after making whatever partitioning changes you want. Is
there any reason you can't do that?
To run grub-install you need to boot first, and to boot you need
access to /boot/grub and to access /boot/grub you need part_gpt. Which
is not available until you can access /boot/grub. Catch 22.
To change from an msdos label to a GPT label you need to be booted
into an OS. If you're booted into an OS you can run grub-install.
Where is the catch?
--
Jordan Uggla (Jordan_U on irc.freenode.net)
David WE Roberts
2013-03-24 20:17:32 UTC
Permalink
Post by Andrey Borzenkov
В Sun, 24 Mar 2013 16:58:55 +0000 (UTC)
Post by David WE Roberts
Post by David WE Roberts
Should grub rescue started from an MBR disc be able to see GPT partitions?
In rescue mode grub has only drivers that are built into core.img. If
you used grub-install, core.img contains only enough drivers to enable
access to grub partition (where /boot/grub is located).
Post by David WE Roberts
/dev/sda 64GB MBR SSD with Windows 7 64 bit, and GRUB2 as boot loader.
/dev/sdb 750GB MBR HDD with Ubuntu installed - GRUB2 chain loads from /dev/
sda. /boot/grub is on this drive.
So core.img will have only MBR handler.
Post by David WE Roberts
My main problem is that I would expect grub rescue to list all the
partitions it could see
Which is exactly what it does. It can see (or better, parse) only MBR.
Post by David WE Roberts
So can someone please tell me if what I am doing is not catered for, or
which simple step I've missed out.
If you still can boot in original configuration, reinstall grub while
grub-install --modules=part_gpt ...
If you cannot return to original configuration - just follow boot
recovery procedure for your distro.
Just to double check - if I use

grub-install --modules=part_gpt /dev/sda

does this add support for GPT as well as MBR or does it add support for GPT
instead of MBR?

Cheers

David
Andrey Borzenkov
2013-03-24 20:21:07 UTC
Permalink
В Sun, 24 Mar 2013 20:17:32 +0000 (UTC)
Post by David WE Roberts
Just to double check - if I use
grub-install --modules=part_gpt /dev/sda
does this add support for GPT as well as MBR or does it add support for GPT
instead of MBR?
It adds named modules in addition to whatever it put there by default.
So you will have both MBR and GPT (as long as your /boot/grub is on MBR
disk).
David WE Roberts
2013-03-26 11:57:36 UTC
Permalink
Post by Andrey Borzenkov
В Sun, 24 Mar 2013 20:17:32 +0000 (UTC)
Post by David WE Roberts
Just to double check - if I use
grub-install --modules=part_gpt /dev/sda
does this add support for GPT as well as MBR or does it add support for
GPT instead of MBR?
It adds named modules in addition to whatever it put there by default.
So you will have both MBR and GPT (as long as your /boot/grub is on MBR
disk).
Oops!

/boot/grub is on GPT disc, as part of the Ubuntu install.

I am experimenting further, but is it an absolute constraint that if you
are booting grub off an MBR disc then /boot/grub must be on an MBR disc?

Digging myself in ever deeper.

David
David WE Roberts
2013-03-26 11:46:41 UTC
Permalink
Post by Andrey Borzenkov
В Sun, 24 Mar 2013 16:58:55 +0000 (UTC)
Post by David WE Roberts
Should grub rescue started from an MBR disc be able to see GPT partitions?
<snip>
Post by Andrey Borzenkov
If you still can boot in original configuration, reinstall grub while
grub-install --modules=part_gpt ...
If you cannot return to original configuration - just follow boot
recovery procedure for your distro.
Done that.

When I disconnect the original MBR data drive and connect the new GPT data
drive and boot grub of the MBR disc and go into grub rescue

I still find that 'ls' can only see one drive, the one with the MSDOS
partitions on.

If I 'insmod part_gpt' it does not complain, but still can't see the GPT
drive.

Not enough in core.img to chain load Windows either.

Cheers

Dave R
David WE Roberts
2013-03-26 12:38:51 UTC
Permalink
Post by David WE Roberts
Post by Andrey Borzenkov
В Sun, 24 Mar 2013 16:58:55 +0000 (UTC)
Post by David WE Roberts
Should grub rescue started from an MBR disc be able to see GPT partitions?
<snip>
Post by Andrey Borzenkov
If you still can boot in original configuration, reinstall grub while
grub-install --modules=part_gpt ...
If you cannot return to original configuration - just follow boot
recovery procedure for your distro.
Done that.
When I disconnect the original MBR data drive and connect the new GPT
data drive and boot grub of the MBR disc and go into grub rescue
I still find that 'ls' can only see one drive, the one with the MSDOS
partitions on.
If I 'insmod part_gpt' it does not complain, but still can't see the GPT
drive.
Not enough in core.img to chain load Windows either.
Test #2

Boot from Ubuntu 12.04 Live CD into 'Try'

startup Terminal

sudo bash

mount /dev/sdb2/ /mnt/

[ls to confirm correct filestore mounted]

grub-install --boot-directory=/mnt/boot /dev/sda

reboot, and get

error: no such device: 28ba1903-0731-40e2*8ce2-55e5597293c2
Post by David WE Roberts
set
prefix=(hd0,2)/boot/grub

root=hd0,2
Post by David WE Roberts
ls
(hd0)


So as far as I can see grub-install has installed grub on /dev/sda and set
up core.img to cope with a GPT disc and correctly identified the disc and
that /boot/grub and /root are on partition 2 of the disc.

When the initial bit of grub starts to load, it is unable to see the GPT
disc (no such device:) and reverts to the only disc it can see, the MBR
disc.

However it hasn't got the module 'part_msdos' included so it can't even
see the partitions on the MBR disc.

[I checked this - at the grub rescue> prompt insmode part_gpt worked,
insmod part_msdos failed.]

So I think this is a bug not a feature.

It looks as though currently the only way that I can get my GPT disc up
and running using grub2 from an MBR disc is to have /boot/grub in a
separate mini-partition on the MBR disc. Assuming even that works.

I will try a full install of Ubuntu 12.04 onto the GPT disc, nominating
the MBR disc as the location for grub, and see what happens.
However I fully expect the same failure.

Bug: grub 2 on initial boot does not correctly support GPT discs with the
module 'part_gpt'.
It fails to recognise the disc or the partitions.

Note that the discs are configured in AHCI mode.

Regards

Dave R
David WE Roberts
2013-03-26 13:50:08 UTC
Permalink
Post by David WE Roberts
Post by David WE Roberts
Post by Andrey Borzenkov
В Sun, 24 Mar 2013 16:58:55 +0000 (UTC)
Post by David WE Roberts
Should grub rescue started from an MBR disc be able to see GPT partitions?
<snip>
Post by Andrey Borzenkov
If you still can boot in original configuration, reinstall grub while
grub-install --modules=part_gpt ...
If you cannot return to original configuration - just follow boot
recovery procedure for your distro.
Done that.
When I disconnect the original MBR data drive and connect the new GPT
data drive and boot grub of the MBR disc and go into grub rescue
I still find that 'ls' can only see one drive, the one with the MSDOS
partitions on.
If I 'insmod part_gpt' it does not complain, but still can't see the
GPT drive.
Not enough in core.img to chain load Windows either.
Test #2
Boot from Ubuntu 12.04 Live CD into 'Try'
startup Terminal
sudo bash
mount /dev/sdb2/ /mnt/
[ls to confirm correct filestore mounted]
grub-install --boot-directory=/mnt/boot /dev/sda
reboot, and get
error: no such device: 28ba1903-0731-40e2*8ce2-55e5597293c2
Post by David WE Roberts
set
prefix=(hd0,2)/boot/grub
root=hd0,2
Post by David WE Roberts
ls
(hd0)
So as far as I can see grub-install has installed grub on /dev/sda and
set up core.img to cope with a GPT disc and correctly identified the
disc and that /boot/grub and /root are on partition 2 of the disc.
When the initial bit of grub starts to load, it is unable to see the GPT
disc (no such device:) and reverts to the only disc it can see, the MBR
disc.
However it hasn't got the module 'part_msdos' included so it can't even
see the partitions on the MBR disc.
[I checked this - at the grub rescue> prompt insmode part_gpt worked,
insmod part_msdos failed.]
So I think this is a bug not a feature.
It looks as though currently the only way that I can get my GPT disc up
and running using grub2 from an MBR disc is to have /boot/grub in a
separate mini-partition on the MBR disc. Assuming even that works.
I will try a full install of Ubuntu 12.04 onto the GPT disc, nominating
the MBR disc as the location for grub, and see what happens.
However I fully expect the same failure.
Bug: grub 2 on initial boot does not correctly support GPT discs with
the module 'part_gpt'.
It fails to recognise the disc or the partitions.
Note that the discs are configured in AHCI mode.
Test #3

Installed Ubuntu 12.04 64 bit to the partition on the GPT drive where it
was previously installed.

Nominated MBR drive as boot drive.

Same failure as Test #2.

Now, of course, I can't boot anything because when I revert back to a full
MBR configuration core.img is set up for GPT partitions so can't see the
MBR partitions, although it can see both MBR discs.

About to rerun Test #2 on the MBR configuration to reset core.img (I hope).

Cheers

Dave R
Jordan Uggla
2013-03-26 19:07:59 UTC
Permalink
Post by David WE Roberts
Test #3
Installed Ubuntu 12.04 64 bit to the partition on the GPT drive where it
was previously installed.
Nominated MBR drive as boot drive.
Same failure as Test #2.
Now, of course, I can't boot anything because when I revert back to a full
MBR configuration core.img is set up for GPT partitions so can't see the
MBR partitions, although it can see both MBR discs.
About to rerun Test #2 on the MBR configuration to reset core.img (I hope).
I am very confused about what you're trying to accomplish, and even
more confused about what you've done up to this point. There is no
reason that you should need to get stuck at a grub rescue shell when
transitioning from an msdos label to a GPT label if you run
grub-install properly (meaning, passing the device whose boot sector
your BIOS is going to load, and if needed a proper --boot-directory
argument, no --modules argument should ever be necessary) after making
any partitioning changes. Please re-run grub-install (without
--modules) and note down the exact command you ran, as well as the
output of "mount" when you ran grub-install, and post both. If after
that grub-install command you're still not able to boot, please run
boot info script http://bootinfoscript.sourceforge.net/ from a
LiveCD/USB or other working GNU/Linux installation and post the
RESULTS.txt that it produces.
--
Jordan Uggla (Jordan_U on irc.freenode.net)
David WE Roberts
2013-03-26 19:46:35 UTC
Permalink
On Tue, Mar 26, 2013 at 6:50 AM, David WE Roberts
Post by David WE Roberts
Test #3
Installed Ubuntu 12.04 64 bit to the partition on the GPT drive where
it was previously installed.
Nominated MBR drive as boot drive.
Same failure as Test #2.
Now, of course, I can't boot anything because when I revert back to a
full MBR configuration core.img is set up for GPT partitions so can't
see the MBR partitions, although it can see both MBR discs.
About to rerun Test #2 on the MBR configuration to reset core.img (I hope).
I am very confused about what you're trying to accomplish, and even more
confused about what you've done up to this point. There is no reason
that you should need to get stuck at a grub rescue shell when
transitioning from an msdos label to a GPT label if you run grub-install
properly (meaning, passing the device whose boot sector your BIOS is
going to load, and if needed a proper --boot-directory argument, no
--modules argument should ever be necessary) after making any
partitioning changes. Please re-run grub-install (without --modules) and
note down the exact command you ran, as well as the output of "mount"
when you ran grub-install, and post both. If after that grub-install
command you're still not able to boot, please run boot info script
http://bootinfoscript.sourceforge.net/ from a LiveCD/USB or other
working GNU/Linux installation and post the RESULTS.txt that it
produces.
Will do.

However to me what I am doing is very simple.

I am booting grub from MBR on disc /dev/sda.

It is loading the main part of grub from /dev/sdb1 on MBR disc /dev/sdb.

/dev/sdb1 is an ext2 partition which is the root mount point for my Ubuntu
filestore; /boot/grub is also on /dev/sdb1 as an integral part of the
filestore.

All this works fine.

However I am moving my /dev/sdb from a 750GiB MBR drive to a 3GiB GPT
drive.

Because of the extra partition automatically created at the start of a GPT
drive the first useable partition on the GPT drive is /dev/sdb2.

So (in the simplest example) I am installing a brand new instance of Ubuntu
12.04 64 bit on /dev/sdb2 which contains both the / (root) filestore and
also /boot/grub.

I am still booting initially (first bits of grub) off MBR disc /dev/sda
with the expectation that grub will be able to see /dev/sdb2 on the GPT
disc and find /boot/grub with all the information it requires to complete
booting.

I have assumed that this is what 'part_gpt' is supposed to do. i.e. it
should be able to recognise a GPT disc, recognise the partitions within
that disc, and then enable grub to access data from one of the partitions.

As I understand it this is what 'part_msdos' does with MBR discs.

The problem I have is that with 'part_gpt' in core.cfg grub cannot see any
partitions (although it sees the MBR disc(s).

With both 'part_gpt' and 'part_msdos' in core.cfg grub can see the MBR
discs and partitions but still cannot see the GPT disc - so obviously
cannot see the GPT partitions either.

Bottom line - grub seems unable to recognise my GPT disc even when I have
installed a new version of Ubuntu in an ext2 partition on the GPT disc and
told it to put grub in the MBR of my MBR disc.

Regards

David
Chris Murphy
2013-03-26 20:48:35 UTC
Permalink
Post by David WE Roberts
However to me what I am doing is very simple.
I am booting grub from MBR on disc /dev/sda.
It is loading the main part of grub from /dev/sdb1 on MBR disc /dev/sdb.
I can't imagine this is workable at all ever.

a.) the jump code on sda's MBR I don't think can jump to another device entirely, just to another LBA on that drive.

b.) Installing grub to ext partitions isn't recommended, hence I don't expect it's supported. The only way to get it there would be if core.img is already in /boot/grub on sdb1, and you use --force with grub-install to place the blocklist into the ext VBR.

In any case there isn't a way for grub-install to put the MBR jump code on one drive but install core.img somewhere else. The prescribed manner is they both go on the same disk, and core.img goes in the MBR gap.
Post by David WE Roberts
However I am moving my /dev/sdb from a 750GiB MBR drive to a 3GiB GPT
drive.
In that case the GPT drive needs a new partition, 1MB in size is fine, using either gdisk code EF02, or parted flag biosboot. Either method creates a BIOS Boot partition that grub-install will embed core.img into. That's where this code belongs on GPT disks. Not in a file systems's VBR. It doesn't matter where it is on the disk, grub-install will find BIOS Boot partitions and use it.
Post by David WE Roberts
I am still booting initially (first bits of grub) off MBR disc /dev/sda
with the expectation that grub will be able to see /dev/sdb2 on the GPT
disc and find /boot/grub with all the information it requires to complete
booting.
Expectations are flawed.
Post by David WE Roberts
I have assumed that this is what 'part_gpt' is supposed to do. i.e. it
should be able to recognise a GPT disc, recognise the partitions within
that disc, and then enable grub to access data from one of the partitions.
According to your ls, it's not even seeing the 2nd disk at all let alone its partitions. It's only seeing (hd0) and that indicates a BIOS limitation.


Chris Murphy
Jordan Uggla
2013-03-26 21:01:35 UTC
Permalink
Post by Chris Murphy
Post by David WE Roberts
However to me what I am doing is very simple.
I am booting grub from MBR on disc /dev/sda.
It is loading the main part of grub from /dev/sdb1 on MBR disc /dev/sdb.
I can't imagine this is workable at all ever.
It is workable if you consider the "main part" of grub to be the files
in /boot/grub/. As you later mentioned, if the core.img is embedded in
sda, that core.img can read /boot/grub/ from a GPT partition on sdb
without any issue. It should just work. So I think that your technical
understanding is good, but I interpreted David's sentence differently.
A big thing to remember is that grub-install completed without any
errors and without any --force argument, which means that, barring
misconfiguration (installing to the wrong boot sector) or BIOS bugs
(or grub bugs, though I don't expect we're hitting one here), the
resulting install should be reliable.
Post by Chris Murphy
a.) the jump code on sda's MBR I don't think can jump to another device entirely, just to another LBA on that drive.
Indeed, while it's technically possible, it would be incredibly
unreliable, there's just not enough space in 446 bytes to do this
reliably. Because of this, grub-install only supports cross-disk
installations when embedding in the "first" disk is possible.
Post by Chris Murphy
b.) Installing grub to ext partitions isn't recommended, hence I don't expect it's supported. The only way to get it there would be if core.img is already in /boot/grub on sdb1, and you use --force with grub-install to place the blocklist into the ext VBR.
I don't think that they were ever trying to install grub's boot sector
to anything but the MBR, and of course /boot/grub/ can be anywhere.
Post by Chris Murphy
In any case there isn't a way for grub-install to put the MBR jump code on one drive but install core.img somewhere else. The prescribed manner is they both go on the same disk, and core.img goes in the MBR gap.\
Completely correct.
Post by Chris Murphy
Post by David WE Roberts
I am still booting initially (first bits of grub) off MBR disc /dev/sda
with the expectation that grub will be able to see /dev/sdb2 on the GPT
disc and find /boot/grub with all the information it requires to complete
booting.
Expectations are flawed.
I think this expectation is completely reasonable, as explained above
(grub-install will just embed the core.img in sda's post-mbr gap and
the core.img will read the GPT label from sdb and find /boot/grub/).
Post by Chris Murphy
Post by David WE Roberts
I have assumed that this is what 'part_gpt' is supposed to do. i.e. it
should be able to recognise a GPT disc, recognise the partitions within
that disc, and then enable grub to access data from one of the partitions.
According to your ls, it's not even seeing the 2nd disk at all let alone its partitions. It's only seeing (hd0) and that indicates a BIOS limitation.
I agree that a BIOS bug is likely, though I'm still waiting on boot
info script output and the output of "mount" when grub-install was run
to confirm my understanding of the current configuration.
--
Jordan Uggla (Jordan_U on irc.freenode.net)
David WE Roberts
2013-03-26 21:55:40 UTC
Permalink
On Tue, 26 Mar 2013 14:01:35 -0700, Jordan Uggla wrote:
<snip>
Post by Chris Murphy
According to your ls, it's not even seeing the 2nd disk at all let
alone its partitions. It's only seeing (hd0) and that indicates a BIOS
limitation.
I agree that a BIOS bug is likely, though I'm still waiting on boot info
script output and the output of "mount" when grub-install was run to
confirm my understanding of the current configuration.
Noted that you think it may be BIOS (UEFI) related.

As a first stage, I'll update to the latest version.

After that I can no doubt get into the various complications of changing
from legacy (BIOS) mode to UEFI mode of booting.

Shows you how something which seemed simple just keeps on getting more
complicated.

Cheers

David
David
2013-03-26 21:11:47 UTC
Permalink
On Mar 26, 2013, at 1:46 PM, David WE Roberts
Post by David WE Roberts
However to me what I am doing is very simple.
I am booting grub from MBR on disc /dev/sda.
It is loading the main part of grub from /dev/sdb1 on MBR disc /dev/sdb.
I can't imagine this is workable at all ever.
a.) the jump code on sda's MBR I don't think can jump to another device
entirely, just to another LBA on that drive.
b.) Installing grub to ext partitions isn't recommended, hence I don't
expect it's supported. The only way to get it there would be if core.img
is already in /boot/grub on sdb1, and you use --force with grub-install
to place the blocklist into the ext VBR.
In any case there isn't a way for grub-install to put the MBR jump code
on one drive but install core.img somewhere else. The prescribed manner
is they both go on the same disk, and core.img goes in the MBR gap.
<snip>

Firstly ""It Just Works[TM]"

Secondly, your rebuttal seems over complicated.

The MBR on /dev/sda holds core.img.

No force options were used in this picture and no animals were harmed.

As far as I know the initial invocation of grub from the MBR is wise
enough to find /boot/grub on /dev/sdb1 and then get all the required
information from there to put up the boot menu.

Having just (due to finger trouble) set the prefix to /grub instead of /
boot/grub and dropped back into the shell prompt I can say that setting
the prefix correctly and invoking normal does get to the boot menu.

So you seem to be telling me that I can't do what I obviously can.

If I put another HDD into my PC with a version of Ubuntu on it, then
update-grub will find this, include it in the boot menu, and it will boot.

Been there with a PATA disc.

So I am somewhat bemused by you saying that it can't be done/ isn't
supported.

If you have several MBR discs in a PC you should be able to install Linux
(Ubuntu) onto any of those discs and still boot up from grub on your
chosen boot drive.

The Ubuntu install is quite happy to have a single partition for all the
data - /boot/grub is by definition found under / - and just asks which
disc should hold the initial boot code.

So with boring old MBR discs everything works.

My problem is that grub doesn't seem to be able to see GPT discs.

See my long post for the Boot Info.

I don't know if the fact I am on Grub2 (v1.99) has any bearing on all this.

Cheers

Dave R
Chris Murphy
2013-03-26 22:33:04 UTC
Permalink
Post by David
The MBR on /dev/sda holds core.img.
When you wrote: "It is loading the main part of grub from /dev/sdb1 on MBR disc /dev/sdb" to me that sounded like core.img on sdb1 using blocklists. The main part of grub is core.img.
Post by David
So you seem to be telling me that I can't do what I obviously can.
It's a terminology problem. If you'd read what I wrote, you'd by now have already realized I thought core.img was on sdb.
Post by David
So I am somewhat bemused by you saying that it can't be done/ isn't
supported.
Cute. You think my rebuttal was over complicated, meanwhile on paragraph 10 you're still repeating yourself.
Post by David
If you have several MBR discs in a PC you should be able to install Linux
(Ubuntu) onto any of those discs and still boot up from grub on your
chosen boot drive.
GRUB still depends on the BIOS.
Post by David
So with boring old MBR discs everything works.
My problem is that grub doesn't seem to be able to see GPT discs.
So when this GPT disk is MBR, grub rescue's ls command now returns two disks? Or is it still just one disk reported?
Post by David
See my long post for the Boot Info.
I don't know if the fact I am on Grub2 (v1.99) has any bearing on all this.
With hundreds of MBR and GPT installations, I've never known that to be the case with GRUB2.

Your version of GRUB is old, and probably still produces a device.map.
cat /boot/grub/device.map


Chris Murphy
David WE Roberts
2013-03-27 09:21:58 UTC
Permalink
On Tue, 26 Mar 2013 16:33:04 -0600, Chris Murphy wrote:

<snip>
Post by Chris Murphy
Post by David
So with boring old MBR discs everything works.
My problem is that grub doesn't seem to be able to see GPT discs.
So when this GPT disk is MBR, grub rescue's ls command now returns two
disks? Or is it still just one disk reported?
<snip>

As posted elsewhere, with all 3 discs connected and grub-install run
against a GPT partition, on reboot I can see the two MBR discs and not the
GPT disc.

Because core.img has been built with part_gpt I can't see the partitions
on either MBR disc.

However this does point to the main issue - that it isn't part_gpt causing
the problem but something that is preventing core.img seeing the GPT disc.

I will follow up on BIOS/UEFI issues this morning.

I note that the version (1.99) of grub2 is quite old - this is the version
that ships with the latest version (12.04) of Ubuntu.

Regards

David
Chris Murphy
2013-03-27 19:25:05 UTC
Permalink
Post by David WE Roberts
As posted elsewhere, with all 3 discs connected and grub-install run
against a GPT partition, on reboot I can see the two MBR discs and not the
GPT disc.
This is all very unclear terminology, as I mentioned elsewhere.

This GPT disk contains a BIOS Boot partition? And you used grub-install on that GPT disk? And when you reboot you're absolutely certain it's loading GRUB off the GPT disk?

It doesn't make sense that GRUB loads from a GPT disk, and then can't see that GPT disk. That's pretty inexplicable, don't you think?
Post by David WE Roberts
Because core.img has been built with part_gpt I can't see the partitions
on either MBR disc.
It sounds like os-prober isn't finding systems on those MBR partitioned disks, therefore it's not building MBR support into the core.img. This might have to do with an old version of os-prober, or maybe the partitions os-prober is searching are encrypted.
Post by David WE Roberts
I note that the version (1.99) of grub2 is quite old - this is the version
that ships with the latest version (12.04) of Ubuntu.
12.10 has 2.00-7 listed in the repos. I suspect you can still use it on 12.04. I don't know if os-prober is a separate package, but I'd make sure that too is as up to date as you can make it.


Chris Murphy
David WE Roberts
2013-03-27 20:01:36 UTC
Permalink
On Mar 27, 2013, at 3:21 AM, David WE Roberts
Post by David WE Roberts
As posted elsewhere, with all 3 discs connected and grub-install run
against a GPT partition, on reboot I can see the two MBR discs and not
the GPT disc.
This is all very unclear terminology, as I mentioned elsewhere.
This GPT disk contains a BIOS Boot partition? And you used grub-install
on that GPT disk? And when you reboot you're absolutely certain it's
loading GRUB off the GPT disk?
It doesn't make sense that GRUB loads from a GPT disk, and then can't
see that GPT disk. That's pretty inexplicable, don't you think?
Post by David WE Roberts
Because core.img has been built with part_gpt I can't see the
partitions on either MBR disc.
It sounds like os-prober isn't finding systems on those MBR partitioned
disks, therefore it's not building MBR support into the core.img. This
might have to do with an old version of os-prober, or maybe the
partitions os-prober is searching are encrypted.
Post by David WE Roberts
I note that the version (1.99) of grub2 is quite old - this is the
version that ships with the latest version (12.04) of Ubuntu.
12.10 has 2.00-7 listed in the repos. I suspect you can still use it on
12.04. I don't know if os-prober is a separate package, but I'd make
sure that too is as up to date as you can make it.
We seem doomed to exchange messages but completely fail to communicate.

Throughout all of this grub *always* boots from the MBR on /dev/sda.

The problem is that under certain circumstances it can't find /boot/grub.

As Jordan has said, if when you run 'grub-install' the location of /boot/
grub is on a GPT disc then "part_gpt" will be included in core.img.

If the location of /boot/grub is on an MBR disc then 'part_msdos' will be
included in core.img.

The initial job of 'core.img' is to get itself up and running and then
locate the partition where /boot/grub resides and it can then proceed to
load all the additional modules and set all the variables it needs to get
ready to boot a variety of OS, and then present the user with a menu.

The copy of 'core.img' stored in the MBR is a pared down version because
of the lack of available space and the restricted environment it starts in.

Once it has found /boot/grub it can then flesh itself out with all the
other modules it needs such as for example NTFS support.

Hopefully this makes things a little clearer :-)

Cheers

David
Chris Murphy
2013-03-27 21:40:27 UTC
Permalink
Post by David WE Roberts
We seem doomed to exchange messages but completely fail to communicate.
Well you're being stubborn too, you have to admit that. I've lost count of how many questions people have asked you that you don't answer.
Post by David WE Roberts
Throughout all of this grub *always* boots from the MBR on /dev/sda.
OK and that is a BIOS issue. The BIOS is responsible for determining what drive it looks to first, it blindly executes the first 446 bytes of code in LBA 0. In the case of GRUB that code usually just forwards loading to core.img found in the MBR gap, which contains a prefix for /boot/grub. Normally this is all on the same disk. That I know works whether MBR or GPT, without having to specify modules. It just works.
Post by David WE Roberts
As Jordan has said, if when you run 'grub-install' the location of /boot/
grub is on a GPT disc then "part_gpt" will be included in core.img.
If the location of /boot/grub is on an MBR disc then 'part_msdos' will be
included in core.img.
The initial job of 'core.img' is to get itself up and running and then
locate the partition where /boot/grub resides and it can then proceed to
load all the additional modules and set all the variables it needs to get
ready to boot a variety of OS, and then present the user with a menu.
The copy of 'core.img' stored in the MBR is a pared down version because
of the lack of available space and the restricted environment it starts in.
Once it has found /boot/grub it can then flesh itself out with all the
other modules it needs such as for example NTFS support.
OK the part you're missing? Is your CSM-BIOS is apparently the limiting factor. I haven't ever heard of a CSM that only sees one disk. But yours seems to be doing that, as the ls command at the rescue prompt shows only one disk. If that's always true, you will not be able to have a split GRUB bootloader setup. GRUB boot.img, core.img, and /boot/grub will have to be on one disk. And further, you'd have to put the /boot volumes on that disk also, for Windows, and whatever Linux volumes you have. Because GRUB isn't going to find a boot volume on a drive the BIOS isn't admitting exists. Once the kernel takes over, it will see the other drives, so you can have rootfs on other drives. Windows and Linux support such setups.

As an example of EFI CSM's not behaving like a full BIOS: Apple's EFI CSM can see and boot from multiple disks, but there's no UI. The CSM determines the boot order, looks at the first drive for boot code in the MBR - if it's there, it executes it. Period. User doesn't get a choice. To get GRUB, or any boot loader, to load itself from another disk, I first have to zero the first 440 bytes on LBA 0 on the first disk. In effect, only one disk can have code in the MBR bootstrap region. However, whether grub rescue or grub shells, the ls command displays all disks and all of their partitions, both MBR and GPT.

So I think you need to learn more about your CSM-BIOS, possibly blow away some MBR bootstrap code regions so you can figure out what disk the bootloader is coming from, and whether GRUB really only sees one disk at a time no matter what. Or you go down the UEFI rabbit/rat hole.

Chris Murphy

David WE Roberts
2013-03-26 20:00:39 UTC
Permalink
On Tue, Mar 26, 2013 at 6:50 AM, David WE Roberts
Post by David WE Roberts
Test #3
Installed Ubuntu 12.04 64 bit to the partition on the GPT drive where
it was previously installed.
Nominated MBR drive as boot drive.
Same failure as Test #2.
Now, of course, I can't boot anything because when I revert back to a
full MBR configuration core.img is set up for GPT partitions so can't
see the MBR partitions, although it can see both MBR discs.
About to rerun Test #2 on the MBR configuration to reset core.img (I hope).
I am very confused about what you're trying to accomplish, and even more
confused about what you've done up to this point. There is no reason
that you should need to get stuck at a grub rescue shell when
transitioning from an msdos label to a GPT label if you run grub-install
properly (meaning, passing the device whose boot sector your BIOS is
going to load, and if needed a proper --boot-directory argument, no
--modules argument should ever be necessary) after making any
partitioning changes. Please re-run grub-install (without --modules) and
note down the exact command you ran, as well as the output of "mount"
when you ran grub-install, and post both. If after that grub-install
command you're still not able to boot, please run boot info script
http://bootinfoscript.sourceforge.net/ from a LiveCD/USB or other
working GNU/Linux installation and post the RESULTS.txt that it
produces.
Please read back up thread (a few words added to hopefully clarify).

"Boot from Ubuntu 12.04 Live CD into the 'Try Ubuntu' option.

start up Terminal

within the terminal window:

sudo bash

mount /dev/sdb2/ /mnt/

[ls to confirm correct filestore mounted]

grub-install --boot-directory=/mnt/boot /dev/sda

[I believe this meets your requirements for running 'grub-install' without
a --modules argument.]

reboot, and get

error: no such device: 28ba1903-0731-40e2*8ce2-55e5597293c2

*Then at the grub rescue prompt *

$ set

prefix=(hd0,2)/boot/grub

root=hd0,2

$ ls

(hd0)
"

Please not that I have run grub-install on an ext2 partition on a GPT disc.

This (as you have already described) has built core.img with module
'part_gpt' instead of 'part_msdos'.

The result is that grub cannot see any partitions (although it does still
recognise the MBR disc ).
David
2013-03-26 20:49:50 UTC
Permalink
Quick test from another version of Pan
David
2013-03-26 20:54:44 UTC
Permalink
On Tue, 26 Mar 2013 12:07:59 -0700, Jordan Uggla wrote:


<snip>
Please re-run grub-install (without --modules) and
note down the exact command you ran, as well as the output of "mount"
when you ran grub-install, and post both. If after that grub-install
command you're still not able to boot, please run boot info script
http://bootinfoscript.sourceforge.net/ from a LiveCD/USB or other
working GNU/Linux installation and post the RESULTS.txt that it
produces.
Here is the RESULTS.txt

Beware - it is long!

Boot Info Script 0.61 [1 April 2012]


============================= Boot Info Summary:
===============================

=> Grub2 (v1.99) is installed in the MBR of /dev/sda and looks at sector
1 of
the same hard drive for core.img. core.img is at this location and
uses an
embedded config file:


---------------------------------------------------------------------------
search.fs_uuid 28ba1903-0731-40e2-8ce2-55e5597293c2 root
set prefix=($root)/grub

---------------------------------------------------------------------------
-----.
=> Grub2 (v1.99) is installed in the MBR of /dev/sdb and looks at sector
1 of
the same hard drive for core.img. core.img is at this location and
looks
for (,msdos6)/boot/grub on this drive.
=> No boot loader is installed in the MBR of /dev/sdc.

sda1:
__________________________________________________________________________

File system: ntfs
Boot sector type: Windows Vista/7: NTFS
Boot sector info: No errors found in the Boot Parameter Block.
Operating System:
Boot files: /bootmgr /Boot/BCD

sda2:
__________________________________________________________________________

File system: ntfs
Boot sector type: Windows Vista/7: NTFS
Boot sector info: No errors found in the Boot Parameter Block.
Operating System: Windows 7
Boot files: /Windows/System32/winload.exe

sdb1:
__________________________________________________________________________

File system: ext4
Boot sector type: -
Boot sector info:
Operating System: Ubuntu 12.04.2 LTS
Boot files: /boot/grub/grub.cfg /etc/fstab
/boot/extlinux/extlinux.conf /boot/grub/core.img

sdb2:
__________________________________________________________________________

File system: swap
Boot sector type: -
Boot sector info:

sdb3:
__________________________________________________________________________

File system: ntfs
Boot sector type: Windows Vista/7: NTFS
Boot sector info: No errors found in the Boot Parameter Block.
Operating System:
Boot files:

sdc1:
__________________________________________________________________________

File system:
Boot sector type: Unknown
Boot sector info:
Mounting failed: mount: unknown filesystem type ''

sdc2:
__________________________________________________________________________

File system: ext4
Boot sector type: -
Boot sector info:
Operating System: Ubuntu 12.04.1 LTS
Boot files: /boot/grub/grub.cfg /etc/fstab
/boot/extlinux/extlinux.conf /grub/core.img
/boot/grub/core.img

sdc3:
__________________________________________________________________________

File system: swap
Boot sector type: -
Boot sector info:

sdc4:
__________________________________________________________________________

File system: ntfs
Boot sector type: Windows Vista/7: NTFS
Boot sector info: According to the info in the boot sector, sdc4
starts
at sector 156555264. But according to the info from
fdisk, sdc4 starts at sector 157960192.
Operating System:
Boot files:

============================ Drive/Partition Info:
=============================

Drive: sda
_____________________________________________________________________

Disk /dev/sda: 64.0 GB, 64023257088 bytes
255 heads, 63 sectors/track, 7783 cylinders, total 125045424 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes

Partition Boot Start Sector End Sector # of Sectors Id System

/dev/sda1 2,048 206,847 204,800 7 NTFS /
exFAT / HPFS
/dev/sda2 * 206,848 125,040,639 124,833,792 7 NTFS /
exFAT / HPFS


Drive: sdb
_____________________________________________________________________

Disk /dev/sdb: 750.2 GB, 750156374016 bytes
255 heads, 63 sectors/track, 91201 cylinders, total 1465149168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes

Partition Boot Start Sector End Sector # of Sectors Id System

/dev/sdb1 2,048 125,304,831 125,302,784 83 Linux
/dev/sdb2 125,304,832 156,555,263 31,250,432 82 Linux swap /
Solaris
/dev/sdb3 156,555,264 1,465,143,295 1,308,588,032 7 NTFS /
exFAT / HPFS


Drive: sdc
_____________________________________________________________________

Disk /dev/sdc: 3000.6 GB, 3000592982016 bytes
255 heads, 63 sectors/track, 364801 cylinders, total 5860533168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes

Partition Boot Start Sector End Sector # of Sectors Id System

/dev/sdc1 1 4,294,967,295 4,294,967,295 ee GPT


GUID Partition Table detected.

Partition Start Sector End Sector # of Sectors System
/dev/sdc1 34 262,177 262,144 Microsoft Reserved
Partition (Windows)
/dev/sdc2 264,192 126,216,191 125,952,000 Data partition
(Windows/Linux)
/dev/sdc3 126,216,192 157,960,191 31,744,000 Swap partition
(Linux)
/dev/sdc4 157,960,192 1,530,120,191 1,372,160,000 Data partition
(Windows/Linux)

"blkid" output:
________________________________________________________________

Device UUID TYPE LABEL

/dev/loop0 squashfs
/dev/sda1 E4E8A488E8A45B16 ntfs System
Reserved
/dev/sda2 8AE0BD40E0BD3375 ntfs Windows
7
/dev/sdb1 28ba1903-0731-40e2-8ce2-55e5597293c2 ext4
/dev/sdb2 5a8f1ee7-b300-4b6e-9da3-c996132a5a20 swap
/dev/sdb3 EAF86ACEF86A9899 ntfs Shared
Storage
/dev/sdc2 28ba1903-0731-40e2-8ce2-55e5597293c2 ext4
/dev/sdc3 d133ebc0-14c9-49b2-8408-e55771115326 swap
/dev/sdc4 EAF86ACEF86A9899 ntfs Shared
Storage
/dev/sr0 iso9660 Ubuntu
12.04.1 LTS amd64

================================ Mount points:
=================================

Device Mount_Point Type Options

/dev/loop0 /rofs squashfs (ro,noatime)
/dev/sdb3 /mnt/dwer fuseblk
(rw,nosuid,nodev,allow_other,blksize=4096)
/dev/sdc2 /mnt/sdc2 ext4 (rw)
/dev/sr0 /cdrom iso9660 (ro,noatime)


=========================== sdb1/boot/grub/grub.cfg:
===========================

--------------------------------------------------------------------------------
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
set have_grubenv=true
load_env
fi
set default="0"
if [ "${prev_saved_entry}" ]; then
set saved_entry="${prev_saved_entry}"
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi

function savedefault {
if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
fi
}

function recordfail {
set recordfail=1
if [ -n "${have_grubenv}" ]; then if [ -z "${boot_once}" ]; then
save_env recordfail; fi; fi
}

function load_video {
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
}

insmod part_msdos
insmod ext2
set root='(hd1,msdos1)'
search --no-floppy --fs-uuid --set=root
28ba1903-0731-40e2-8ce2-55e5597293c2
if loadfont /usr/share/grub/unicode.pf2 ; then
set gfxmode=auto
load_video
insmod gfxterm
insmod part_msdos
insmod ext2
set root='(hd1,msdos1)'
search --no-floppy --fs-uuid --set=root
28ba1903-0731-40e2-8ce2-55e5597293c2
set locale_dir=($root)/boot/grub/locale
set lang=en_GB
insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ]; then
set timeout=-1
else
set timeout=10
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=white/black
set menu_color_highlight=black/light-gray
if background_color 44,0,30; then
clear
fi
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/08_os-prober ###
menuentry "Windows 7 (loader) (on /dev/sda1)" --class windows --class os {
insmod part_msdos
insmod ntfs
set root='(hd0,msdos1)'
search --no-floppy --fs-uuid --set=root E4E8A488E8A45B16
chainloader +1
}
### END /etc/grub.d/08_os-prober ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
if [ "${1}" = "keep" ]; then
set vt_handoff=vt.handoff=7
else
set vt_handoff=
fi
}
if [ "${recordfail}" != 1 ]; then
if [ -e ${prefix}/gfxblacklist.txt ]; then
if hwmatch ${prefix}/gfxblacklist.txt 3; then
if [ ${match} = 0 ]; then
set linux_gfx_mode=keep
else
set linux_gfx_mode=text
fi
else
set linux_gfx_mode=text
fi
else
set linux_gfx_mode=keep
fi
else
set linux_gfx_mode=text
fi
export linux_gfx_mode
if [ "${linux_gfx_mode}" != "text" ]; then load_video; fi
menuentry 'Ubuntu, with Linux 3.2.0-39-generic' --class ubuntu --class gnu-
linux --class gnu --class os {
recordfail
gfxmode $linux_gfx_mode
insmod gzio
insmod part_msdos
insmod ext2
set root='(hd1,msdos1)'
search --no-floppy --fs-uuid --set=root
28ba1903-0731-40e2-8ce2-55e5597293c2
linux /boot/vmlinuz-3.2.0-39-generic
root=UUID=28ba1903-0731-40e2-8ce2-55e5597293c2 ro quiet splash
$vt_handoff
initrd /boot/initrd.img-3.2.0-39-generic
}
menuentry 'Ubuntu, with Linux 3.2.0-39-generic (recovery mode)' --class
ubuntu --class gnu-linux --class gnu --class os {
recordfail
insmod gzio
insmod part_msdos
insmod ext2
set root='(hd1,msdos1)'
search --no-floppy --fs-uuid --set=root
28ba1903-0731-40e2-8ce2-55e5597293c2
echo 'Loading Linux 3.2.0-39-generic ...'
linux /boot/vmlinuz-3.2.0-39-generic
root=UUID=28ba1903-0731-40e2-8ce2-55e5597293c2 ro recovery nomodeset
echo 'Loading initial ramdisk ...'
initrd /boot/initrd.img-3.2.0-39-generic
}
submenu "Previous Linux versions" {
menuentry 'Ubuntu, with Linux 3.2.0-38-generic' --class ubuntu --class gnu-
linux --class gnu --class os {
recordfail
gfxmode $linux_gfx_mode
insmod gzio
insmod part_msdos
insmod ext2
set root='(hd1,msdos1)'
search --no-floppy --fs-uuid --set=root
28ba1903-0731-40e2-8ce2-55e5597293c2
linux /boot/vmlinuz-3.2.0-38-generic
root=UUID=28ba1903-0731-40e2-8ce2-55e5597293c2 ro quiet splash
$vt_handoff
initrd /boot/initrd.img-3.2.0-38-generic
}
menuentry 'Ubuntu, with Linux 3.2.0-38-generic (recovery mode)' --class
ubuntu --class gnu-linux --class gnu --class os {
recordfail
insmod gzio
insmod part_msdos
insmod ext2
set root='(hd1,msdos1)'
search --no-floppy --fs-uuid --set=root
28ba1903-0731-40e2-8ce2-55e5597293c2
echo 'Loading Linux 3.2.0-38-generic ...'
linux /boot/vmlinuz-3.2.0-38-generic
root=UUID=28ba1903-0731-40e2-8ce2-55e5597293c2 ro recovery nomodeset
echo 'Loading initial ramdisk ...'
initrd /boot/initrd.img-3.2.0-38-generic
}
menuentry 'Ubuntu, with Linux 3.2.0-37-generic' --class ubuntu --class gnu-
linux --class gnu --class os {
recordfail
gfxmode $linux_gfx_mode
insmod gzio
insmod part_msdos
insmod ext2
set root='(hd1,msdos1)'
search --no-floppy --fs-uuid --set=root
28ba1903-0731-40e2-8ce2-55e5597293c2
linux /boot/vmlinuz-3.2.0-37-generic
root=UUID=28ba1903-0731-40e2-8ce2-55e5597293c2 ro quiet splash
$vt_handoff
initrd /boot/initrd.img-3.2.0-37-generic
}
menuentry 'Ubuntu, with Linux 3.2.0-37-generic (recovery mode)' --class
ubuntu --class gnu-linux --class gnu --class os {
recordfail
insmod gzio
insmod part_msdos
insmod ext2
set root='(hd1,msdos1)'
search --no-floppy --fs-uuid --set=root
28ba1903-0731-40e2-8ce2-55e5597293c2
echo 'Loading Linux 3.2.0-37-generic ...'
linux /boot/vmlinuz-3.2.0-37-generic
root=UUID=28ba1903-0731-40e2-8ce2-55e5597293c2 ro recovery nomodeset
echo 'Loading initial ramdisk ...'
initrd /boot/initrd.img-3.2.0-37-generic
}
menuentry 'Ubuntu, with Linux 3.2.0-35-generic' --class ubuntu --class gnu-
linux --class gnu --class os {
recordfail
gfxmode $linux_gfx_mode
insmod gzio
insmod part_msdos
insmod ext2
set root='(hd1,msdos1)'
search --no-floppy --fs-uuid --set=root
28ba1903-0731-40e2-8ce2-55e5597293c2
linux /boot/vmlinuz-3.2.0-35-generic
root=UUID=28ba1903-0731-40e2-8ce2-55e5597293c2 ro quiet splash
$vt_handoff
initrd /boot/initrd.img-3.2.0-35-generic
}
menuentry 'Ubuntu, with Linux 3.2.0-35-generic (recovery mode)' --class
ubuntu --class gnu-linux --class gnu --class os {
recordfail
insmod gzio
insmod part_msdos
insmod ext2
set root='(hd1,msdos1)'
search --no-floppy --fs-uuid --set=root
28ba1903-0731-40e2-8ce2-55e5597293c2
echo 'Loading Linux 3.2.0-35-generic ...'
linux /boot/vmlinuz-3.2.0-35-generic
root=UUID=28ba1903-0731-40e2-8ce2-55e5597293c2 ro recovery nomodeset
echo 'Loading initial ramdisk ...'
initrd /boot/initrd.img-3.2.0-35-generic
}
menuentry 'Ubuntu, with Linux 3.2.0-29-generic' --class ubuntu --class gnu-
linux --class gnu --class os {
recordfail
gfxmode $linux_gfx_mode
insmod gzio
insmod part_msdos
insmod ext2
set root='(hd1,msdos1)'
search --no-floppy --fs-uuid --set=root
28ba1903-0731-40e2-8ce2-55e5597293c2
linux /boot/vmlinuz-3.2.0-29-generic
root=UUID=28ba1903-0731-40e2-8ce2-55e5597293c2 ro quiet splash
$vt_handoff
initrd /boot/initrd.img-3.2.0-29-generic
}
menuentry 'Ubuntu, with Linux 3.2.0-29-generic (recovery mode)' --class
ubuntu --class gnu-linux --class gnu --class os {
recordfail
insmod gzio
insmod part_msdos
insmod ext2
set root='(hd1,msdos1)'
search --no-floppy --fs-uuid --set=root
28ba1903-0731-40e2-8ce2-55e5597293c2
echo 'Loading Linux 3.2.0-29-generic ...'
linux /boot/vmlinuz-3.2.0-29-generic
root=UUID=28ba1903-0731-40e2-8ce2-55e5597293c2 ro recovery nomodeset
echo 'Loading initial ramdisk ...'
initrd /boot/initrd.img-3.2.0-29-generic
}
menuentry 'Ubuntu, with Linux 3.2.0-27-generic' --class ubuntu --class gnu-
linux --class gnu --class os {
recordfail
gfxmode $linux_gfx_mode
insmod gzio
insmod part_msdos
insmod ext2
set root='(hd1,msdos1)'
search --no-floppy --fs-uuid --set=root
28ba1903-0731-40e2-8ce2-55e5597293c2
linux /boot/vmlinuz-3.2.0-27-generic
root=UUID=28ba1903-0731-40e2-8ce2-55e5597293c2 ro quiet splash
$vt_handoff
initrd /boot/initrd.img-3.2.0-27-generic
}
menuentry 'Ubuntu, with Linux 3.2.0-27-generic (recovery mode)' --class
ubuntu --class gnu-linux --class gnu --class os {
recordfail
insmod gzio
insmod part_msdos
insmod ext2
set root='(hd1,msdos1)'
search --no-floppy --fs-uuid --set=root
28ba1903-0731-40e2-8ce2-55e5597293c2
echo 'Loading Linux 3.2.0-27-generic ...'
linux /boot/vmlinuz-3.2.0-27-generic
root=UUID=28ba1903-0731-40e2-8ce2-55e5597293c2 ro recovery nomodeset
echo 'Loading initial ramdisk ...'
initrd /boot/initrd.img-3.2.0-27-generic
}
menuentry 'Ubuntu, with Linux 3.2.0-24-generic' --class ubuntu --class gnu-
linux --class gnu --class os {
recordfail
gfxmode $linux_gfx_mode
insmod gzio
insmod part_msdos
insmod ext2
set root='(hd1,msdos1)'
search --no-floppy --fs-uuid --set=root
28ba1903-0731-40e2-8ce2-55e5597293c2
linux /boot/vmlinuz-3.2.0-24-generic
root=UUID=28ba1903-0731-40e2-8ce2-55e5597293c2 ro quiet splash
$vt_handoff
initrd /boot/initrd.img-3.2.0-24-generic
}
menuentry 'Ubuntu, with Linux 3.2.0-24-generic (recovery mode)' --class
ubuntu --class gnu-linux --class gnu --class os {
recordfail
insmod gzio
insmod part_msdos
insmod ext2
set root='(hd1,msdos1)'
search --no-floppy --fs-uuid --set=root
28ba1903-0731-40e2-8ce2-55e5597293c2
echo 'Loading Linux 3.2.0-24-generic ...'
linux /boot/vmlinuz-3.2.0-24-generic
root=UUID=28ba1903-0731-40e2-8ce2-55e5597293c2 ro recovery nomodeset
echo 'Loading initial ramdisk ...'
initrd /boot/initrd.img-3.2.0-24-generic
}
menuentry 'Ubuntu, with Linux 3.0.0-17-generic' --class ubuntu --class gnu-
linux --class gnu --class os {
recordfail
gfxmode $linux_gfx_mode
insmod gzio
insmod part_msdos
insmod ext2
set root='(hd1,msdos1)'
search --no-floppy --fs-uuid --set=root
28ba1903-0731-40e2-8ce2-55e5597293c2
linux /boot/vmlinuz-3.0.0-17-generic
root=UUID=28ba1903-0731-40e2-8ce2-55e5597293c2 ro quiet splash
$vt_handoff
initrd /boot/initrd.img-3.0.0-17-generic
}
menuentry 'Ubuntu, with Linux 3.0.0-17-generic (recovery mode)' --class
ubuntu --class gnu-linux --class gnu --class os {
recordfail
insmod gzio
insmod part_msdos
insmod ext2
set root='(hd1,msdos1)'
search --no-floppy --fs-uuid --set=root
28ba1903-0731-40e2-8ce2-55e5597293c2
echo 'Loading Linux 3.0.0-17-generic ...'
linux /boot/vmlinuz-3.0.0-17-generic
root=UUID=28ba1903-0731-40e2-8ce2-55e5597293c2 ro recovery nomodeset
echo 'Loading initial ramdisk ...'
initrd /boot/initrd.img-3.0.0-17-generic
}
menuentry 'Ubuntu, with Linux 3.0.0-16-generic' --class ubuntu --class gnu-
linux --class gnu --class os {
recordfail
gfxmode $linux_gfx_mode
insmod gzio
insmod part_msdos
insmod ext2
set root='(hd1,msdos1)'
search --no-floppy --fs-uuid --set=root
28ba1903-0731-40e2-8ce2-55e5597293c2
linux /boot/vmlinuz-3.0.0-16-generic
root=UUID=28ba1903-0731-40e2-8ce2-55e5597293c2 ro quiet splash
$vt_handoff
initrd /boot/initrd.img-3.0.0-16-generic
}
menuentry 'Ubuntu, with Linux 3.0.0-16-generic (recovery mode)' --class
ubuntu --class gnu-linux --class gnu --class os {
recordfail
insmod gzio
insmod part_msdos
insmod ext2
set root='(hd1,msdos1)'
search --no-floppy --fs-uuid --set=root
28ba1903-0731-40e2-8ce2-55e5597293c2
echo 'Loading Linux 3.0.0-16-generic ...'
linux /boot/vmlinuz-3.0.0-16-generic
root=UUID=28ba1903-0731-40e2-8ce2-55e5597293c2 ro recovery nomodeset
echo 'Loading initial ramdisk ...'
initrd /boot/initrd.img-3.0.0-16-generic
}
menuentry 'Ubuntu, with Linux 3.0.0-15-generic' --class ubuntu --class gnu-
linux --class gnu --class os {
recordfail
gfxmode $linux_gfx_mode
insmod gzio
insmod part_msdos
insmod ext2
set root='(hd1,msdos1)'
search --no-floppy --fs-uuid --set=root
28ba1903-0731-40e2-8ce2-55e5597293c2
linux /boot/vmlinuz-3.0.0-15-generic
root=UUID=28ba1903-0731-40e2-8ce2-55e5597293c2 ro quiet splash
$vt_handoff
initrd /boot/initrd.img-3.0.0-15-generic
}
menuentry 'Ubuntu, with Linux 3.0.0-15-generic (recovery mode)' --class
ubuntu --class gnu-linux --class gnu --class os {
recordfail
insmod gzio
insmod part_msdos
insmod ext2
set root='(hd1,msdos1)'
search --no-floppy --fs-uuid --set=root
28ba1903-0731-40e2-8ce2-55e5597293c2
echo 'Loading Linux 3.0.0-15-generic ...'
linux /boot/vmlinuz-3.0.0-15-generic
root=UUID=28ba1903-0731-40e2-8ce2-55e5597293c2 ro recovery nomodeset
echo 'Loading initial ramdisk ...'
initrd /boot/initrd.img-3.0.0-15-generic
}
menuentry 'Ubuntu, with Linux 3.0.0-14-generic' --class ubuntu --class gnu-
linux --class gnu --class os {
recordfail
gfxmode $linux_gfx_mode
insmod gzio
insmod part_msdos
insmod ext2
set root='(hd1,msdos1)'
search --no-floppy --fs-uuid --set=root
28ba1903-0731-40e2-8ce2-55e5597293c2
linux /boot/vmlinuz-3.0.0-14-generic
root=UUID=28ba1903-0731-40e2-8ce2-55e5597293c2 ro quiet splash
$vt_handoff
initrd /boot/initrd.img-3.0.0-14-generic
}
menuentry 'Ubuntu, with Linux 3.0.0-14-generic (recovery mode)' --class
ubuntu --class gnu-linux --class gnu --class os {
recordfail
insmod gzio
insmod part_msdos
insmod ext2
set root='(hd1,msdos1)'
search --no-floppy --fs-uuid --set=root
28ba1903-0731-40e2-8ce2-55e5597293c2
echo 'Loading Linux 3.0.0-14-generic ...'
linux /boot/vmlinuz-3.0.0-14-generic
root=UUID=28ba1903-0731-40e2-8ce2-55e5597293c2 ro recovery nomodeset
echo 'Loading initial ramdisk ...'
initrd /boot/initrd.img-3.0.0-14-generic
}
menuentry 'Ubuntu, with Linux 3.0.0-12-generic' --class ubuntu --class gnu-
linux --class gnu --class os {
recordfail
gfxmode $linux_gfx_mode
insmod gzio
insmod part_msdos
insmod ext2
set root='(hd1,msdos1)'
search --no-floppy --fs-uuid --set=root
28ba1903-0731-40e2-8ce2-55e5597293c2
linux /boot/vmlinuz-3.0.0-12-generic
root=UUID=28ba1903-0731-40e2-8ce2-55e5597293c2 ro quiet splash
$vt_handoff
initrd /boot/initrd.img-3.0.0-12-generic
}
menuentry 'Ubuntu, with Linux 3.0.0-12-generic (recovery mode)' --class
ubuntu --class gnu-linux --class gnu --class os {
recordfail
insmod gzio
insmod part_msdos
insmod ext2
set root='(hd1,msdos1)'
search --no-floppy --fs-uuid --set=root
28ba1903-0731-40e2-8ce2-55e5597293c2
echo 'Loading Linux 3.0.0-12-generic ...'
linux /boot/vmlinuz-3.0.0-12-generic
root=UUID=28ba1903-0731-40e2-8ce2-55e5597293c2 ro recovery nomodeset
echo 'Loading initial ramdisk ...'
initrd /boot/initrd.img-3.0.0-12-generic
}
}
### END /etc/grub.d/10_linux ###

### BEGIN /etc/grub.d/20_linux_xen ###
### END /etc/grub.d/20_linux_xen ###

### BEGIN /etc/grub.d/20_memtest86+ ###
menuentry "Memory test (memtest86+)" {
insmod part_msdos
insmod ext2
set root='(hd1,msdos1)'
search --no-floppy --fs-uuid --set=root
28ba1903-0731-40e2-8ce2-55e5597293c2
linux16 /boot/memtest86+.bin
}
menuentry "Memory test (memtest86+, serial console 115200)" {
insmod part_msdos
insmod ext2
set root='(hd1,msdos1)'
search --no-floppy --fs-uuid --set=root
28ba1903-0731-40e2-8ce2-55e5597293c2
linux16 /boot/memtest86+.bin console=ttyS0,115200n8
}
### END /etc/grub.d/20_memtest86+ ###

### BEGIN /etc/grub.d/30_uefi-firmware ###
### END /etc/grub.d/30_uefi-firmware ###

### BEGIN /etc/grub.d/40_custom ###
# This file provides an easy way to add custom menu entries. Simply type
the
# menu entries you want to add after this comment. Be careful not to
change
# the 'exec tail' line above.
### END /etc/grub.d/40_custom ###

### BEGIN /etc/grub.d/41_custom ###
if [ -f $prefix/custom.cfg ]; then
source $prefix/custom.cfg;
fi
### END /etc/grub.d/41_custom ###
--------------------------------------------------------------------------------

=============================== sdb1/etc/fstab:
================================

--------------------------------------------------------------------------------
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc nodev,noexec,nosuid 0 0
# / was on /dev/sdb1 during installation
UUID=28ba1903-0731-40e2-8ce2-55e5597293c2 / ext4
errors=remount-ro 0 1
# swap was on /dev/sdb2 during installation
UUID=5a8f1ee7-b300-4b6e-9da3-c996132a5a20 none swap
sw 0 0
--------------------------------------------------------------------------------

====================== sdb1/boot/extlinux/extlinux.conf:
=======================

--------------------------------------------------------------------------------
## /boot/extlinux/extlinux.conf
##
## IMPORTANT WARNING
##
## The configuration of this file is generated automatically.
## Do not edit this file manually, use: extlinux-update


default l0
prompt 1
timeout 50

include themes/debian/theme.cfg
--------------------------------------------------------------------------------

=================== sdb1: Location of files loaded by Grub:
====================

GiB - GB File
Fragment(s)

= boot/grub/
core.img 1
= boot/grub/
grub.cfg 1
= boot/initrd.img-3.0.0-12-
generic 2
= boot/initrd.img-3.0.0-14-
generic 10
= boot/initrd.img-3.0.0-15-
generic 2
= boot/initrd.img-3.0.0-16-
generic 2
= boot/initrd.img-3.0.0-17-
generic 9
= boot/initrd.img-3.2.0-24-
generic 2
= boot/initrd.img-3.2.0-27-
generic 2
= boot/initrd.img-3.2.0-29-
generic 2
= boot/initrd.img-3.2.0-35-
generic 2
= boot/initrd.img-3.2.0-37-
generic 2
= boot/initrd.img-3.2.0-38-
generic 2
= boot/initrd.img-3.2.0-39-
generic 2
= boot/vmlinuz-3.0.0-12-
generic 1
= boot/vmlinuz-3.0.0-14-
generic 1
= boot/vmlinuz-3.0.0-15-
generic 1
= boot/vmlinuz-3.0.0-16-
generic 1
= boot/vmlinuz-3.0.0-17-
generic 2
= boot/vmlinuz-3.2.0-24-
generic 1
= boot/vmlinuz-3.2.0-27-
generic 1
= boot/vmlinuz-3.2.0-29-
generic 1
= boot/vmlinuz-3.2.0-35-
generic 2
= boot/vmlinuz-3.2.0-37-
generic 2
= boot/vmlinuz-3.2.0-38-
generic 1
= boot/vmlinuz-3.2.0-39-
generic 1
=
vmlinuz 1
=
vmlinuz.old 1

================= sdb1: Location of files loaded by Syslinux:
==================

GiB - GB File
Fragment(s)

= boot/extlinux/
chain.c32 1
= boot/extlinux/
extlinux.conf 1

============== sdb1: Version of COM32(R) files used by Syslinux:
===============

boot/extlinux/chain.c32 : COM32R module (v4.xx)

=========================== sdc2/boot/grub/grub.cfg:
===========================

--------------------------------------------------------------------------------
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
set have_grubenv=true
load_env
fi
set default="0"
if [ "${prev_saved_entry}" ]; then
set saved_entry="${prev_saved_entry}"
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi

function savedefault {
if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
fi
}

function recordfail {
set recordfail=1
if [ -n "${have_grubenv}" ]; then if [ -z "${boot_once}" ]; then
save_env recordfail; fi; fi
}

function load_video {
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
}

insmod part_gpt
insmod ext2
set root='(hd1,gpt2)'
search --no-floppy --fs-uuid --set=root
28ba1903-0731-40e2-8ce2-55e5597293c2
if loadfont /usr/share/grub/unicode.pf2 ; then
set gfxmode=auto
load_video
insmod gfxterm
insmod part_gpt
insmod ext2
set root='(hd1,gpt2)'
search --no-floppy --fs-uuid --set=root
28ba1903-0731-40e2-8ce2-55e5597293c2
set locale_dir=($root)/boot/grub/locale
set lang=en_GB
insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ]; then
set timeout=-1
else
set timeout=10
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=white/black
set menu_color_highlight=black/light-gray
if background_color 44,0,30; then
clear
fi
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
if [ "${1}" = "keep" ]; then
set vt_handoff=vt.handoff=7
else
set vt_handoff=
fi
}
if [ "${recordfail}" != 1 ]; then
if [ -e ${prefix}/gfxblacklist.txt ]; then
if hwmatch ${prefix}/gfxblacklist.txt 3; then
if [ ${match} = 0 ]; then
set linux_gfx_mode=keep
else
set linux_gfx_mode=text
fi
else
set linux_gfx_mode=text
fi
else
set linux_gfx_mode=keep
fi
else
set linux_gfx_mode=text
fi
export linux_gfx_mode
if [ "${linux_gfx_mode}" != "text" ]; then load_video; fi
menuentry 'Ubuntu, with Linux 3.2.0-39-generic' --class ubuntu --class gnu-
linux --class gnu --class os {
recordfail
gfxmode $linux_gfx_mode
insmod gzio
insmod part_gpt
insmod ext2
set root='(hd1,gpt2)'
search --no-floppy --fs-uuid --set=root
28ba1903-0731-40e2-8ce2-55e5597293c2
linux /boot/vmlinuz-3.2.0-39-generic
root=UUID=28ba1903-0731-40e2-8ce2-55e5597293c2 ro quiet splash
$vt_handoff
initrd /boot/initrd.img-3.2.0-39-generic
}
menuentry 'Ubuntu, with Linux 3.2.0-39-generic (recovery mode)' --class
ubuntu --class gnu-linux --class gnu --class os {
recordfail
insmod gzio
insmod part_gpt
insmod ext2
set root='(hd1,gpt2)'
search --no-floppy --fs-uuid --set=root
28ba1903-0731-40e2-8ce2-55e5597293c2
echo 'Loading Linux 3.2.0-39-generic ...'
linux /boot/vmlinuz-3.2.0-39-generic
root=UUID=28ba1903-0731-40e2-8ce2-55e5597293c2 ro recovery nomodeset
echo 'Loading initial ramdisk ...'
initrd /boot/initrd.img-3.2.0-39-generic
}
submenu "Previous Linux versions" {
menuentry 'Ubuntu, with Linux 3.2.0-38-generic' --class ubuntu --class gnu-
linux --class gnu --class os {
recordfail
gfxmode $linux_gfx_mode
insmod gzio
insmod part_gpt
insmod ext2
set root='(hd1,gpt2)'
search --no-floppy --fs-uuid --set=root
28ba1903-0731-40e2-8ce2-55e5597293c2
linux /boot/vmlinuz-3.2.0-38-generic
root=UUID=28ba1903-0731-40e2-8ce2-55e5597293c2 ro quiet splash
$vt_handoff
initrd /boot/initrd.img-3.2.0-38-generic
}
menuentry 'Ubuntu, with Linux 3.2.0-38-generic (recovery mode)' --class
ubuntu --class gnu-linux --class gnu --class os {
recordfail
insmod gzio
insmod part_gpt
insmod ext2
set root='(hd1,gpt2)'
search --no-floppy --fs-uuid --set=root
28ba1903-0731-40e2-8ce2-55e5597293c2
echo 'Loading Linux 3.2.0-38-generic ...'
linux /boot/vmlinuz-3.2.0-38-generic
root=UUID=28ba1903-0731-40e2-8ce2-55e5597293c2 ro recovery nomodeset
echo 'Loading initial ramdisk ...'
initrd /boot/initrd.img-3.2.0-38-generic
}
menuentry 'Ubuntu, with Linux 3.2.0-37-generic' --class ubuntu --class gnu-
linux --class gnu --class os {
recordfail
gfxmode $linux_gfx_mode
insmod gzio
insmod part_gpt
insmod ext2
set root='(hd1,gpt2)'
search --no-floppy --fs-uuid --set=root
28ba1903-0731-40e2-8ce2-55e5597293c2
linux /boot/vmlinuz-3.2.0-37-generic
root=UUID=28ba1903-0731-40e2-8ce2-55e5597293c2 ro quiet splash
$vt_handoff
initrd /boot/initrd.img-3.2.0-37-generic
}
menuentry 'Ubuntu, with Linux 3.2.0-37-generic (recovery mode)' --class
ubuntu --class gnu-linux --class gnu --class os {
recordfail
insmod gzio
insmod part_gpt
insmod ext2
set root='(hd1,gpt2)'
search --no-floppy --fs-uuid --set=root
28ba1903-0731-40e2-8ce2-55e5597293c2
echo 'Loading Linux 3.2.0-37-generic ...'
linux /boot/vmlinuz-3.2.0-37-generic
root=UUID=28ba1903-0731-40e2-8ce2-55e5597293c2 ro recovery nomodeset
echo 'Loading initial ramdisk ...'
initrd /boot/initrd.img-3.2.0-37-generic
}
menuentry 'Ubuntu, with Linux 3.2.0-35-generic' --class ubuntu --class gnu-
linux --class gnu --class os {
recordfail
gfxmode $linux_gfx_mode
insmod gzio
insmod part_gpt
insmod ext2
set root='(hd1,gpt2)'
search --no-floppy --fs-uuid --set=root
28ba1903-0731-40e2-8ce2-55e5597293c2
linux /boot/vmlinuz-3.2.0-35-generic
root=UUID=28ba1903-0731-40e2-8ce2-55e5597293c2 ro quiet splash
$vt_handoff
initrd /boot/initrd.img-3.2.0-35-generic
}
menuentry 'Ubuntu, with Linux 3.2.0-35-generic (recovery mode)' --class
ubuntu --class gnu-linux --class gnu --class os {
recordfail
insmod gzio
insmod part_gpt
insmod ext2
set root='(hd1,gpt2)'
search --no-floppy --fs-uuid --set=root
28ba1903-0731-40e2-8ce2-55e5597293c2
echo 'Loading Linux 3.2.0-35-generic ...'
linux /boot/vmlinuz-3.2.0-35-generic
root=UUID=28ba1903-0731-40e2-8ce2-55e5597293c2 ro recovery nomodeset
echo 'Loading initial ramdisk ...'
initrd /boot/initrd.img-3.2.0-35-generic
}
menuentry 'Ubuntu, with Linux 3.2.0-29-generic' --class ubuntu --class gnu-
linux --class gnu --class os {
recordfail
gfxmode $linux_gfx_mode
insmod gzio
insmod part_gpt
insmod ext2
set root='(hd1,gpt2)'
search --no-floppy --fs-uuid --set=root
28ba1903-0731-40e2-8ce2-55e5597293c2
linux /boot/vmlinuz-3.2.0-29-generic
root=UUID=28ba1903-0731-40e2-8ce2-55e5597293c2 ro quiet splash
$vt_handoff
initrd /boot/initrd.img-3.2.0-29-generic
}
menuentry 'Ubuntu, with Linux 3.2.0-29-generic (recovery mode)' --class
ubuntu --class gnu-linux --class gnu --class os {
recordfail
insmod gzio
insmod part_gpt
insmod ext2
set root='(hd1,gpt2)'
search --no-floppy --fs-uuid --set=root
28ba1903-0731-40e2-8ce2-55e5597293c2
echo 'Loading Linux 3.2.0-29-generic ...'
linux /boot/vmlinuz-3.2.0-29-generic
root=UUID=28ba1903-0731-40e2-8ce2-55e5597293c2 ro recovery nomodeset
echo 'Loading initial ramdisk ...'
initrd /boot/initrd.img-3.2.0-29-generic
}
menuentry 'Ubuntu, with Linux 3.2.0-27-generic' --class ubuntu --class gnu-
linux --class gnu --class os {
recordfail
gfxmode $linux_gfx_mode
insmod gzio
insmod part_gpt
insmod ext2
set root='(hd1,gpt2)'
search --no-floppy --fs-uuid --set=root
28ba1903-0731-40e2-8ce2-55e5597293c2
linux /boot/vmlinuz-3.2.0-27-generic
root=UUID=28ba1903-0731-40e2-8ce2-55e5597293c2 ro quiet splash
$vt_handoff
initrd /boot/initrd.img-3.2.0-27-generic
}
menuentry 'Ubuntu, with Linux 3.2.0-27-generic (recovery mode)' --class
ubuntu --class gnu-linux --class gnu --class os {
recordfail
insmod gzio
insmod part_gpt
insmod ext2
set root='(hd1,gpt2)'
search --no-floppy --fs-uuid --set=root
28ba1903-0731-40e2-8ce2-55e5597293c2
echo 'Loading Linux 3.2.0-27-generic ...'
linux /boot/vmlinuz-3.2.0-27-generic
root=UUID=28ba1903-0731-40e2-8ce2-55e5597293c2 ro recovery nomodeset
echo 'Loading initial ramdisk ...'
initrd /boot/initrd.img-3.2.0-27-generic
}
menuentry 'Ubuntu, with Linux 3.2.0-24-generic' --class ubuntu --class gnu-
linux --class gnu --class os {
recordfail
gfxmode $linux_gfx_mode
insmod gzio
insmod part_gpt
insmod ext2
set root='(hd1,gpt2)'
search --no-floppy --fs-uuid --set=root
28ba1903-0731-40e2-8ce2-55e5597293c2
linux /boot/vmlinuz-3.2.0-24-generic
root=UUID=28ba1903-0731-40e2-8ce2-55e5597293c2 ro quiet splash
$vt_handoff
initrd /boot/initrd.img-3.2.0-24-generic
}
menuentry 'Ubuntu, with Linux 3.2.0-24-generic (recovery mode)' --class
ubuntu --class gnu-linux --class gnu --class os {
recordfail
insmod gzio
insmod part_gpt
insmod ext2
set root='(hd1,gpt2)'
search --no-floppy --fs-uuid --set=root
28ba1903-0731-40e2-8ce2-55e5597293c2
echo 'Loading Linux 3.2.0-24-generic ...'
linux /boot/vmlinuz-3.2.0-24-generic
root=UUID=28ba1903-0731-40e2-8ce2-55e5597293c2 ro recovery nomodeset
echo 'Loading initial ramdisk ...'
initrd /boot/initrd.img-3.2.0-24-generic
}
menuentry 'Ubuntu, with Linux 3.0.0-17-generic' --class ubuntu --class gnu-
linux --class gnu --class os {
recordfail
gfxmode $linux_gfx_mode
insmod gzio
insmod part_gpt
insmod ext2
set root='(hd1,gpt2)'
search --no-floppy --fs-uuid --set=root
28ba1903-0731-40e2-8ce2-55e5597293c2
linux /boot/vmlinuz-3.0.0-17-generic
root=UUID=28ba1903-0731-40e2-8ce2-55e5597293c2 ro quiet splash
$vt_handoff
initrd /boot/initrd.img-3.0.0-17-generic
}
menuentry 'Ubuntu, with Linux 3.0.0-17-generic (recovery mode)' --class
ubuntu --class gnu-linux --class gnu --class os {
recordfail
insmod gzio
insmod part_gpt
insmod ext2
set root='(hd1,gpt2)'
search --no-floppy --fs-uuid --set=root
28ba1903-0731-40e2-8ce2-55e5597293c2
echo 'Loading Linux 3.0.0-17-generic ...'
linux /boot/vmlinuz-3.0.0-17-generic
root=UUID=28ba1903-0731-40e2-8ce2-55e5597293c2 ro recovery nomodeset
echo 'Loading initial ramdisk ...'
initrd /boot/initrd.img-3.0.0-17-generic
}
menuentry 'Ubuntu, with Linux 3.0.0-16-generic' --class ubuntu --class gnu-
linux --class gnu --class os {
recordfail
gfxmode $linux_gfx_mode
insmod gzio
insmod part_gpt
insmod ext2
set root='(hd1,gpt2)'
search --no-floppy --fs-uuid --set=root
28ba1903-0731-40e2-8ce2-55e5597293c2
linux /boot/vmlinuz-3.0.0-16-generic
root=UUID=28ba1903-0731-40e2-8ce2-55e5597293c2 ro quiet splash
$vt_handoff
initrd /boot/initrd.img-3.0.0-16-generic
}
menuentry 'Ubuntu, with Linux 3.0.0-16-generic (recovery mode)' --class
ubuntu --class gnu-linux --class gnu --class os {
recordfail
insmod gzio
insmod part_gpt
insmod ext2
set root='(hd1,gpt2)'
search --no-floppy --fs-uuid --set=root
28ba1903-0731-40e2-8ce2-55e5597293c2
echo 'Loading Linux 3.0.0-16-generic ...'
linux /boot/vmlinuz-3.0.0-16-generic
root=UUID=28ba1903-0731-40e2-8ce2-55e5597293c2 ro recovery nomodeset
echo 'Loading initial ramdisk ...'
initrd /boot/initrd.img-3.0.0-16-generic
}
menuentry 'Ubuntu, with Linux 3.0.0-15-generic' --class ubuntu --class gnu-
linux --class gnu --class os {
recordfail
gfxmode $linux_gfx_mode
insmod gzio
insmod part_gpt
insmod ext2
set root='(hd1,gpt2)'
search --no-floppy --fs-uuid --set=root
28ba1903-0731-40e2-8ce2-55e5597293c2
linux /boot/vmlinuz-3.0.0-15-generic
root=UUID=28ba1903-0731-40e2-8ce2-55e5597293c2 ro quiet splash
$vt_handoff
initrd /boot/initrd.img-3.0.0-15-generic
}
menuentry 'Ubuntu, with Linux 3.0.0-15-generic (recovery mode)' --class
ubuntu --class gnu-linux --class gnu --class os {
recordfail
insmod gzio
insmod part_gpt
insmod ext2
set root='(hd1,gpt2)'
search --no-floppy --fs-uuid --set=root
28ba1903-0731-40e2-8ce2-55e5597293c2
echo 'Loading Linux 3.0.0-15-generic ...'
linux /boot/vmlinuz-3.0.0-15-generic
root=UUID=28ba1903-0731-40e2-8ce2-55e5597293c2 ro recovery nomodeset
echo 'Loading initial ramdisk ...'
initrd /boot/initrd.img-3.0.0-15-generic
}
menuentry 'Ubuntu, with Linux 3.0.0-14-generic' --class ubuntu --class gnu-
linux --class gnu --class os {
recordfail
gfxmode $linux_gfx_mode
insmod gzio
insmod part_gpt
insmod ext2
set root='(hd1,gpt2)'
search --no-floppy --fs-uuid --set=root
28ba1903-0731-40e2-8ce2-55e5597293c2
linux /boot/vmlinuz-3.0.0-14-generic
root=UUID=28ba1903-0731-40e2-8ce2-55e5597293c2 ro quiet splash
$vt_handoff
initrd /boot/initrd.img-3.0.0-14-generic
}
menuentry 'Ubuntu, with Linux 3.0.0-14-generic (recovery mode)' --class
ubuntu --class gnu-linux --class gnu --class os {
recordfail
insmod gzio
insmod part_gpt
insmod ext2
set root='(hd1,gpt2)'
search --no-floppy --fs-uuid --set=root
28ba1903-0731-40e2-8ce2-55e5597293c2
echo 'Loading Linux 3.0.0-14-generic ...'
linux /boot/vmlinuz-3.0.0-14-generic
root=UUID=28ba1903-0731-40e2-8ce2-55e5597293c2 ro recovery nomodeset
echo 'Loading initial ramdisk ...'
initrd /boot/initrd.img-3.0.0-14-generic
}
menuentry 'Ubuntu, with Linux 3.0.0-12-generic' --class ubuntu --class gnu-
linux --class gnu --class os {
recordfail
gfxmode $linux_gfx_mode
insmod gzio
insmod part_gpt
insmod ext2
set root='(hd1,gpt2)'
search --no-floppy --fs-uuid --set=root
28ba1903-0731-40e2-8ce2-55e5597293c2
linux /boot/vmlinuz-3.0.0-12-generic
root=UUID=28ba1903-0731-40e2-8ce2-55e5597293c2 ro quiet splash
$vt_handoff
initrd /boot/initrd.img-3.0.0-12-generic
}
menuentry 'Ubuntu, with Linux 3.0.0-12-generic (recovery mode)' --class
ubuntu --class gnu-linux --class gnu --class os {
recordfail
insmod gzio
insmod part_gpt
insmod ext2
set root='(hd1,gpt2)'
search --no-floppy --fs-uuid --set=root
28ba1903-0731-40e2-8ce2-55e5597293c2
echo 'Loading Linux 3.0.0-12-generic ...'
linux /boot/vmlinuz-3.0.0-12-generic
root=UUID=28ba1903-0731-40e2-8ce2-55e5597293c2 ro recovery nomodeset
echo 'Loading initial ramdisk ...'
initrd /boot/initrd.img-3.0.0-12-generic
}
}
### END /etc/grub.d/10_linux ###

### BEGIN /etc/grub.d/20_linux_xen ###
### END /etc/grub.d/20_linux_xen ###

### BEGIN /etc/grub.d/20_memtest86+ ###
menuentry "Memory test (memtest86+)" {
insmod part_gpt
insmod ext2
set root='(hd1,gpt2)'
search --no-floppy --fs-uuid --set=root
28ba1903-0731-40e2-8ce2-55e5597293c2
linux16 /boot/memtest86+.bin
}
menuentry "Memory test (memtest86+, serial console 115200)" {
insmod part_gpt
insmod ext2
set root='(hd1,gpt2)'
search --no-floppy --fs-uuid --set=root
28ba1903-0731-40e2-8ce2-55e5597293c2
linux16 /boot/memtest86+.bin console=ttyS0,115200n8
}
### END /etc/grub.d/20_memtest86+ ###

### BEGIN /etc/grub.d/30_os-prober ###
menuentry "Windows 7 (loader) (on /dev/sda1)" --class windows --class os {
insmod part_msdos
insmod ntfs
set root='(hd0,msdos1)'
search --no-floppy --fs-uuid --set=root E4E8A488E8A45B16
chainloader +1
}
### END /etc/grub.d/30_os-prober ###

### BEGIN /etc/grub.d/40_custom ###
# This file provides an easy way to add custom menu entries. Simply type
the
# menu entries you want to add after this comment. Be careful not to
change
# the 'exec tail' line above.
### END /etc/grub.d/40_custom ###

### BEGIN /etc/grub.d/41_custom ###
if [ -f $prefix/custom.cfg ]; then
source $prefix/custom.cfg;
fi
### END /etc/grub.d/41_custom ###
--------------------------------------------------------------------------------

=============================== sdc2/etc/fstab:
================================

--------------------------------------------------------------------------------
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc nodev,noexec,nosuid 0 0
# / was on /dev/sdb2 during installation
UUID=28ba1903-0731-40e2-8ce2-55e5597293c2 / ext4
errors=remount-ro 0 1
# swap was on /dev/sdb3 during installation
UUID=d133ebc0-14c9-49b2-8408-e55771115326 none swap
sw 0 0
--------------------------------------------------------------------------------

====================== sdc2/boot/extlinux/extlinux.conf:
=======================

--------------------------------------------------------------------------------
## /boot/extlinux/extlinux.conf
##
## IMPORTANT WARNING
##
## The configuration of this file is generated automatically.
## Do not edit this file manually, use: extlinux-update


default l0
prompt 1
timeout 50

include themes/debian/theme.cfg
--------------------------------------------------------------------------------

=================== sdc2: Location of files loaded by Grub:
====================

GiB - GB File
Fragment(s)

= boot/grub/
core.img 1
= boot/grub/
grub.cfg 1
= boot/initrd.img-3.0.0-12-
generic 2
= boot/initrd.img-3.0.0-14-
generic 10
= boot/initrd.img-3.0.0-15-
generic 2
= boot/initrd.img-3.0.0-16-
generic 2
= boot/initrd.img-3.0.0-17-
generic 9
= boot/initrd.img-3.2.0-24-
generic 2
= boot/initrd.img-3.2.0-27-
generic 2
= boot/initrd.img-3.2.0-29-
generic 2
= boot/initrd.img-3.2.0-35-
generic 2
= boot/initrd.img-3.2.0-37-
generic 2
= boot/initrd.img-3.2.0-38-
generic 2
= boot/initrd.img-3.2.0-39-
generic 2
= boot/vmlinuz-3.0.0-12-
generic 1
= boot/vmlinuz-3.0.0-14-
generic 1
= boot/vmlinuz-3.0.0-15-
generic 1
= boot/vmlinuz-3.0.0-16-
generic 1
= boot/vmlinuz-3.0.0-17-
generic 2
= boot/vmlinuz-3.2.0-24-
generic 1
= boot/vmlinuz-3.2.0-27-
generic 1
= boot/vmlinuz-3.2.0-29-
generic 1
= boot/vmlinuz-3.2.0-35-
generic 2
= boot/vmlinuz-3.2.0-37-
generic 2
= boot/vmlinuz-3.2.0-38-
generic 1
= boot/vmlinuz-3.2.0-39-
generic 1
= grub/
core.img 1
=
initrd.img 2
=
vmlinuz 1

================= sdc2: Location of files loaded by Syslinux:
==================

GiB - GB File
Fragment(s)

= boot/extlinux/
chain.c32 1
= boot/extlinux/
extlinux.conf 1

============== sdc2: Version of COM32(R) files used by Syslinux:
===============

boot/extlinux/chain.c32 : COM32R module (v4.xx)

======================== Unknown MBRs/Boot Sectors/etc:
========================

Unknown BootLoader on sdc1

00000000 5b 7d 16 6c 66 41 41 9b bc cc b5 21 ae 3d af be |
[}.lfAA....!.=..|
00000010 4a 5d 3a d4 ac fc 27 0e 9f cb f7 f7 f0 af 52 1c |
J]:...'.......R.|
00000020 65 5b 47 3a 43 c2 10 9d 0b 84 a5 61 f8 9e 8f da |e
[G:C......a....|
00000030 20 23 e8 70 02 ba 6f 6b e8 8f 09 14 e8 77 c7 41 |
#.p..ok.....w.A|
00000040 f2 46 7f cd 82 df ac d4 13 ab 40 f6 7c 77 7a 8a |***@.|
wz.|
00000050 20 c3 48 88 f0 c4 2b 49 f2 de 6a 54 bd 20 05 a7 | .H...
+I..jT. ..|
00000060 0c 04 4d fd 2d 3a fc 3f 4d 2f e3 24 5a 1f 97 cb |..M.-:.?M/.
$Z...|
00000070 9c 50 93 84 36 94 3e e5 b0 2a ce 51 6c e0 cb 03
|.P..6.>..*.Ql...|
00000080 6d 07 ab 32 43 41 b2 6c d1 b3 c5 6d f7 22 db 5a |
m..2CA.l...m.".Z|
00000090 44 9b 86 d0 72 b6 d4 b4 84 c6 39 a8 80 a2 03 08 |
D...r.....9.....|
000000a0 3f 57 cc 1a ff 2c 8c 70 f6 f1 cb 17 66 25 05 21 |?W...,.p....f
%.!|
000000b0 14 92 89 7a f7 06 af 4e a8 b3 67 d9 31 5f b1 2c
|...z...N..g.1_.,|
000000c0 ee 2b 11 08 1f 77 fd 70 1d 12 1e a2 e7 fa eb 22 |.
+...w.p......."|
000000d0 d9 ea 40 c6 43 9e 22 be c2 6a bf 91 7e db df bd
|***@.C."..j..~...|
000000e0 f3 80 33 51 94 65 e6 82 d2 37 c3 16 ef 0f 70 c0
|..3Q.e...7....p.|
000000f0 2e 17 47 6e 9a 1b 7d b0 5b 44 79 5f 50 dd 64 45 |..Gn..}.
[Dy_P.dE|
00000100 26 6e 6f 79 57 bc e3 2d 2e 7b 53 5f 90 77 26 d0 |&noyW..-.
{S_.w&.|
00000110 e3 e9 35 4a 3f ae 51 80 eb b2 18 f1 3a 85 bb 04
|..5J?.Q.....:...|
00000120 8f 16 85 a9 08 3e 24 a1 1d 7c 77 67 f3 96 57 1a |.....>$..|
wg..W.|
00000130 55 c9 9e b3 35 8b 6f 73 8d d8 fb f1 96 b7 5d cb |
U...5.os......].|
00000140 e7 29 a5 c3 35 cf 17 79 96 cd 57 da d8 64 b7 f4
|.)..5..y..W..d..|
00000150 23 0f 16 40 a0 c7 ae 79 34 6f a8 5b 88 14 a0 2f |#***@...y4o.
[.../|
00000160 fa 4f 45 da eb 84 77 de 56 9b bf d3 95 9e d6 74
|.OE...w.V......t|
00000170 ef b1 21 1e cc 0c a4 fa 50 57 e3 7e 5f 57 f9 d8
|..!.....PW.~_W..|
00000180 2d 64 48 77 60 ca 53 e8 ce 06 c6 2e e8 fd a7 2d |-
dHw`.S........-|
00000190 0e f8 d8 f9 ba 5c 04 7c 80 2e 37 24 17 0c 7c 65 |.....\.|..7
$..|e|
000001a0 59 8c b8 4a 13 e7 13 a8 36 72 87 75 03 27 93 25 |
Y..J....6r.u.'.%|
000001b0 9a c5 05 dd fb 18 73 32 f2 0d bb 9b 77 2f 47 3b |......s2....w/
G;|
000001c0 c0 3f 75 02 07 0d 6d d2 33 fa f6 7f 54 d4 4a 43 |.?
u...m.3...T.JC|
000001d0 49 f9 fb ec cc 2e bb b2 63 b5 b3 b6 4b 49 49 92 |
I.......c...KII.|
000001e0 40 81 e1 11 22 e8 6b 7b c3 09 aa 74 df 26 77 d1 |@...".k
{...t.&w.|
000001f0 60 e7 61 c9 43 d8 2c cc 34 c9 96 b3 cb 55 5a 12 |
`.a.C.,.4....UZ.|
00000200


=============================== StdErr Messages:
===============================

xz: (stdin): Compressed data is corrupt
xz: (stdin): Compressed data is corrupt
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
awk: cmd. line:36: Math support is not compiled in
David
2013-03-26 21:24:01 UTC
Permalink
On Tue, 26 Mar 2013 12:07:59 -0700, Jordan Uggla wrote:

<snip>
I am very confused about what you're trying to accomplish, and even more
confused about what you've done up to this point. There is no reason
that you should need to get stuck at a grub rescue shell when
transitioning from an msdos label to a GPT label if you run grub-install
properly (meaning, passing the device whose boot sector your BIOS is
going to load, and if needed a proper --boot-directory argument, no
--modules argument should ever be necessary) after making any
partitioning changes. Please re-run grub-install (without --modules) and
note down the exact command you ran, as well as the output of "mount"
when you ran grub-install, and post both. If after that grub-install
command you're still not able to boot, please run boot info script
http://bootinfoscript.sourceforge.net/ from a LiveCD/USB or other
working GNU/Linux installation and post the RESULTS.txt that it
produces.
Running from Ubuntu 12.04 64 bit Live CD.

Here is the output of the 'mount'

Please note that I've got lazy here and I have both the MBR and the GPT
disc connected at the same time, so the GPT disc is /dev/sdc.

I note that I as usual dyslexically incorrect as I was posting ext2 when I
meant ext4.

/cow on / type overlayfs (rw)

proc on /proc type proc (rw,noexec,nosuid,nodev)

sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)

udev on /dev type devtmpfs (rw,mode=0755)

devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)

tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)

/dev/sr0 on /cdrom type iso9660 (ro,noatime)

/dev/loop0 on /rofs type squashfs (ro,noatime)

none on /sys/fs/fuse/connections type fusectl (rw)

none on /sys/kernel/debug type debugfs (rw)

none on /sys/kernel/security type securityfs (rw)

tmpfs on /tmp type tmpfs (rw,nosuid,nodev)

none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)

none on /run/shm type tmpfs (rw,nosuid,nodev)

gvfs-fuse-daemon on /home/ubuntu/.gvfs type fuse.gvfs-fuse-daemon
(rw,nosuid,nodev,user=ubuntu)

/dev/sdb3 on /mnt/dwer type fuseblk
(rw,nosuid,nodev,allow_other,blksize=4096)

/dev/sdc2 on /mnt/sdc2 type ext4 (rw)


------------------------------------------------------

/dev/sdc2 is the target for grub-install.

"grub-install --boot-directory=/mnt/sdc2/boot /dev/sda"

Also please note that /mnt/dwer is the NTFS partition used for shared
storage between all OS and that is where the log files have been saved.

Cheers

Dave R
David WE Roberts
2013-03-27 20:29:54 UTC
Permalink
Post by David WE Roberts
Should grub rescue started from an MBR disc be able to see GPT
partitions?
The answer is "Yes, of course" or more accurately "It depends".

After updating the UEFI from 1.0 to 2.x (and having a few heart stopping
moments when the system just sighed and died before coming back to life) I
had to set about re-configuring everything because it had all been reset.

During this process I noted that I couldn't see the 3TiB (tibbles?) drive
in the boot menu.

Further checking showed (apart from the disc handling being set back to
IDE from AHCI) that the 3TiB drive was on the Marvell SATA 6GB/sec
controller not the Intel MoBo controller and this Marvell controller (as
strongly advised in the UEFI setup utility) was set to not bootable.

I set it to bootable and noted an extra flash screen when the PC booted -
and then the 3TiB drive was visible as a boot drive.

Once this was done, grub could also see the GPT drive and could find /boot/
grub.

So, in the end, a fine analysis from Andrey, Jordan and Chris in that it
was a BIOS/UEFI problem and really nothing to do with grub.

I didn't realise that although I was booting successfully off an MBR disc,
the GPT disc had also to be set as bootable in the UEFI for it to be
visible in the environment grub was searching.

So a five minute job at the start of a long series of disc swaps and OS
installs and upgrades seems to be finally nearing completion.

Thanks for all the help.

At least now I understand a bit more about grub.

Next comes Windows 8 :-(

Cheers

Dave R
Continue reading on narkive:
Loading...