Hello all, my son tried to install fresh Ubuntu to old Win7 machine (Gigabyte EP45-DS3 with 1TB WDC (systtem) and 4TB HGST(data) drives) to the second 4TB drive. System failed to boot and I said “Well, son, you deserve the best, just sit and see your dad will install OpenSuse and it will resolve all your pain”. I removed Ubuntu-created partitions from 4TB disk and installed OpenSuse there. Oops, it failed to boot as well. Booting from the second 4TB drive gives GRUB GRUB GRUB (1 to 3 times) output and it’s all. Booting from the first 1TB drive gives “unknown filesystem” and grub-rescue prompt. Ls in grub-rescue (after booting from first 1TB drive) gives a bunch of useless (hdX, gptY) entries, ls on all of them gives “unknown filesystem” again. I tried to boot from installation stick to the rescue mode, mount the partition with OpenSuse installed, chroot there, grub-install and Yast (in different tries), but it didn’t help. Now I have no more ideas. Yes, booting from GPT disk on BIOS machine is not a best solution, but it should work in given partitions setup, as far as I understood from Rod Smith’s explanation.
fdisk -l
...loop output skipped
Disk /dev/sda: 931.52 GiB, 1000203804160 bytes, 1953523055 sectors Disk model: WDC WD1001FALS-0 Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x3dbc3dbc
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 63 1433592404 1433592342 683.6G 7 HPFS/NTFS/exFAT
/dev/sda2 1433592405 1953503999 519911595 247.9G f W95 Ext'd (LBA)
/dev/sda5 1433592468 1953503999 519911532 247.9G 7 HPFS/NTFS/exFAT
Disk /dev/sdb: 3.65 TiB, 4000787030016 bytes, 7814037168 sectors
Disk model: HGST HMS5C4040BL
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 8A7574A1-29FA-4760-9268-907DA2267005
Device Start End Sectors Size Type
/dev/sdb1 34 262177 262144 128M Microsoft reserved
/dev/sdb2 264192 6144264191 6144000000 2.9T Microsoft basic data
/dev/sdb3 6144264192 6144266239 2048 1M BIOS boot
/dev/sdb4 6144266240 6145316863 1050624 513M Microsoft basic data
/dev/sdb5 6145316864 6146367487 1050624 513M Microsoft basic data
/dev/sdb6 6146367488 6146383871 16384 8M BIOS boot
/dev/sdb7 6146383872 6686889983 540506112 257.8G Linux filesystem
/dev/sdb8 6686889984 7809841151 1122951168 535.5G Linux filesystem
/dev/sdb9 7809841152 7814037134 4195983 2G Linux swap
...USB stick device skipped
It is hard to know what went wrong without more information.
The chances are that an old BIOS machine cannot cope with a 4T disk.
The original reason for using a “/boot” partition, is that the BIOS in early computers could not see all of the disk. So you would position “/boot” near the beginning of the disk, with kernel and boot menu there. That would allow the kernel to be loaded. And usually, the kernel could see all of the disk and carry on from there.
You seem to have two BIOS boot partitions. But both of them are probably beyond what the BIOS can access.
Is there anything important in “/dev/sdb1” (listed as Microsoft reserved)?
Writing a question often makes brain to work, so I understood I was too carefull and not removed all of Ubuntu-created partitions (sdb3 - sdb5), so I removed all partitions but the sbd2 from the sdb (and sdb1 gone too, no idea what it was) and reinstalled OpenSuse with suggested sdb partitioning. Now picture became to be more consistent: booting from both sdb and sda gives grub-rescue with useless entries I wrote above. But grub-rescue is running, so I think BIOS is able to reach and load it. But why grub can’t read filesystems - it’s a question. Another big question is sda. I don’t understand why it contains almost identical overlapping sda2 and sda5 and where the index “5” in sda5 came from, as long as MBR can contain only 4 partition records, AFAIK. Whether it’s Ubuntu’ work or it was so before and then why, no idea. OpenSuse installator suggested to remove sda5, but I feared to loose valuable data and rejected.
What “more information” can I supply?
The MBR can have only 4 partitions. You have only two – sda1 and sda2. However, sda2 is an extended partition. That means that it can be subdivided into logical partitions. And sda5 is one of those logical partitions that sits inside sda2 – that’s the reason for the overlap.
As for what grub can do – it uses the BIOS to read the disk. So it cannot read beyond what the BIOS can see. And 4T is larger than the BIOS can access.
GRUB is printed by first stage code (which normally resides in the very first sector of disk and is loaded by BIOS). Several GRUB would imply BIOS attempts booting several times, may be there are several boot entries.
No BIOS can access more than 2TB unless BIOS supports 4K sectors (unlikely and I do not think GRUB works in this case, I think there was bug report quite some time ago) and disk runs in 4Kn format. In this case both BIOS Boot partitions are beyond 2TB.
Yes, it’s true. I realized and already fixed it. Results have not become a much better, sigh. Booting from sda gives a delay ~10s and grub-rescue, booting from sdb gives grub-rescue immediately, but the last is explainable (you already did it, thank you)
Sorry for long delay. Done, results are here. sdg and sdh there are usb sticks and can be ignored, I left them there just to keep results untouched. I noticed strange thing there: config script (for sda’ grub presumably) referencing non-existing uuid and hdX,gpt7, which not exist as well. I have not idea where this script came from and why it survived multiple OpenSuse installations, supposing it’s a result of first Ubuntu installation. Can it be a reason of the problem? How to fix it then?
sda MBR has GRUB stage1 code that looks for filesystem with UUID 738157d3-ddee-470e-8f2b-da35cdc36e44 which does not exist. Probably it is left from some previous installation of some Linux. As this drive contains only Windows partitions, the simplest way to fix it would be to use Windows boot recovery to replace MBR.
booting from sdb gives grub-rescue immediately, but the last is explainable
Well, theoretically INT 13H extension is using 64 bit sector number, in practice there are a lot of reports that it does not work reliably.
While waiting Win recover disk to be delivered (Win7 installation disk is a rare thing these days), I tried to fix obvious inconsistencies (and to learn new tricks along with it), so I created new core.img with correct script and wrote it to sda. Still no luck. Hmm. Results are here. Where to dig to further?
Well, sdb3 is the partition the / installed to. I expected grub to find everything required for further booting there. Am I wrong? To be honest, I’ve read the grub manual not very carefully, but picked the most fascinating parts.
This partition is beyond 2TB boundary and you yourself said that exactly the same grub installed on sdb failed to access it. Why do you expect that starting the same grub binary from another disk will make a difference?
The problem is that grub has no way of reading the disk, except via the BIOS. So any BIOS limitation also affects grub.
I’ll illustrate with my own example. I have an external drive that is 1T. I have both openSUSE and Solus installed there. And I have a large partition for backups near the end of the disk.
On one of my computers, I can only boot openSUSE. I cannot boot Solus. If I select Solus from the boot menu, nothing useful happens. But if I boot openSUSE, then I have no difficulty seeing the Solus partitions or the backup partition. The linux kernel can read those. But the BIOS cannot read them and grub cannot read them.
If I plug that external drive into a different computer, everything works. It’s just a difference of whether the BIOS can see all of the disk.
Your problem is that 4T is outside the capability of any BIOS. And therefore it is outside the capability of grub unless you are using UEFI booting.
You need to have the partition containing “/boot” to be within the part of the disk that the BIOS can see.
Yes, I somehow missed the point the grub uses BIOS functions to read the disk, so massaging grub settings in either sda or sdb was useless without moving boot partition somewhere below 2TB, so even Win7 recover would not solve dual-boot task. Finally the problem was resolved, as usually, with more money (as karlmistelberger suggested): I bought cheap ssd disk and installed / there. Thank you all