Sat 06 Feb 2016 06:55:03 AM UTC, comment #22:
Well, there is apparently some bug (or at least incorrect assumption) on GRUB side. Pity, it is the first known case of BIOS supporting 4Kn disks.
If you can ever get hold of such system again, feel free to reopen.
|
Mon 01 Feb 2016 01:06:28 PM UTC, comment #21:
Sorry, I no longer have time for this and machine in question is already in production. Let's close this as "works as expected".
Thanks for help.
|
Mon 11 Jan 2016 05:59:29 PM UTC, comment #20:
Could you please test attached patch on top of previous one; any changes?
(file #35993)
|
Mon 11 Jan 2016 09:39:09 AM UTC, comment #19:
I can't scroll up, so providing only this.
Thanks.
(file #35986, file #35987)
|
Tue 29 Dec 2015 05:13:28 PM UTC, comment #18:
Did you try filetree.diff ? What is the result you get with it?
|
Fri 25 Dec 2015 05:29:03 PM UTC, comment #17:
So it appears that BIOS returns correct information in "Get drive parameters" but then fails in "Extended read". Could you please replace previous patch with next one and try once more; it should log actual read calls.
(file #35856)
|
Wed 23 Dec 2015 01:50:05 PM UTC, comment #16:
here you go.
(file #35847, file #35848)
|
Mon 21 Dec 2015 06:35:50 PM UTC, comment #15:
See attached patch. It is on top of GIT master, so would be better to use it.
git clone git://git.savannah.gnu.org/grub.git
cd grub
git am /tmp/biosdisk.patch
./autogen.sh
./configure
make
pkgdatadir=$PWD ./grub-mkrescue -d grub-core -o grub.iso
Or use other commands you normally used to create grub image. All modules and other images are under grub-core directory.
Boot from this image and do
set debug=biosdisk
ls (hd0)
where hd0 is your 4Kn disk. Attach picture of result.
(file #35827)
|
Mon 21 Dec 2015 10:26:56 AM UTC, comment #14:
Yes, let's do that if that's necessary. Tell me what's needed.
|
Sun 20 Dec 2015 09:47:03 AM UTC, comment #13:
Well, we still may support this but we need more details about what BIOS reports. Are you willing to run test version that displays more debugging information?
|
Sun 20 Dec 2015 09:19:03 AM UTC, comment #12:
Okay guys, so next time someone comes around with a question about 4KN drives and BIOS and GRUB, tell him the following:
Booting from 4Kn drives is and will NEVER be supported by BIOS (AKA legacy BIOS AKA LEGACY). The ONLY solution for 4Kn AF drives is to boot via UEFI.
It's indeed the BIOS' fault and GRUB has nothing to do with it.
More than that, I propose printing a warning message immediately someone is trying to boot from such a drive under non-UEFI environment or maybe even if someone is `ls (hd0)` such a drive.
And, btw, sadly, I didn't consult supermicro KB initially as they have hell lot of questions about 4Kn and legacy BIOS.
Thanks.
|
Fri 18 Dec 2015 09:23:12 AM UTC, comment #11:
> I have a theory
Yes, this is probably the only explanation. But then total_sectors needs adjustment.
I wonder if there is any BIOS that natively supports 4k logical sector. EDD always talks about "physical" size.
|
Fri 18 Dec 2015 06:44:18 AM UTC, comment #10:
> I no longer have time to troubleshoot this, sorry.
As you wish. I cannot reproduce it using available environment so assuming this is GRUB bug, it depends on someone having access to the affected system to debug and fix.
But it can just as well be BIOS bug.
|
Fri 18 Dec 2015 03:10:51 AM UTC, comment #9:
Try attached patch. I have a theory
(file #35787)
|
Thu 17 Dec 2015 09:54:42 PM UTC, comment #8:
This is the version of grub I've used from my gentoo machine: 2.02_beta2-r7.
I no longer have time to troubleshoot this, sorry.
|
Thu 17 Dec 2015 06:53:32 PM UTC, comment #7:
What version do you use? You selected beta1 - please test current GIT master.
|
Thu 17 Dec 2015 06:51:10 PM UTC, comment #6:
here's the grub image I'm using (pxelinux -> lnxboot.img -> grub.img)
(file #35785)
|
Thu 17 Dec 2015 06:46:49 PM UTC, comment #5:
Now I'm wondering what module should be loaded in order to make grub understand VFAT.
Also, I was able to boot via EFI centos 6' grub.efi (v0.97), which found the partition and found the files and booted the system properly.
Now in regards to grub2, here's the screenshot. The sizes there are totally wrong. I also don't get why they differ between ls -l invokations.
(file #35784)
|
Thu 17 Dec 2015 05:53:38 PM UTC, comment #4:
Please show "ls -l" output in GRUB to verify sector size.
|
Thu 17 Dec 2015 04:09:44 PM UTC, comment #3:
Purely cosmetic? Are you kidding me? The FS is full of files.
The machine can't boot.
# fdisk -l /dev/sda
WARNING: GPT (GUID Partition Table) detected on '/dev/sda'! The util fdisk doesn't support GPT. Use GNU Parted.
Note: sector size is 4096 (not 512)
Disk /dev/sda: 1800.4 GB, 1800360124416 bytes
255 heads, 63 sectors/track, 27360 cylinders
Units = cylinders of 16065 * 4096 = 65802240 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000
Device Boot Start End Blocks Id System
/dev/sda1 1 27361 1758164180 ee GPT
# gdisk -l /dev/sda
GPT fdisk (gdisk) version 0.8.10
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 439541046 sectors, 1.6 TiB
Logical sector size: 4096 bytes
Disk identifier (GUID): 1FFC3352-7D1B-4C8A-B2DC-044530D005EB
Partition table holds up to 128 entries
First usable sector is 6, last usable sector is 439541040
Partitions will be aligned on 256-sector boundaries
Total free space is 1530 sectors (6.0 MiB)
Number Start (sector) End (sector) Size Code Name
1 1536 76799 294.0 MiB EF00 primary
2 76800 439541040 1.6 TiB FD00 Linux RAID
#
I have now trashed ext2 FS and made it a VFAT to go with UEFI bootloader. Still, grub is clueless about partition size and FS.
GPT was created with parted and gdisk, I don't remember the steps.
At this point it would be easier to just ship your the drive I guess.
(file #35780, file #35781, file #35782, file #35783)
|
Thu 17 Dec 2015 08:49:52 AM UTC, comment #2:
Do you see any problems that are not purely cosmetic? Ls that you pasted suggest that it mostly worked fine: fs is detected.
|
Thu 17 Dec 2015 05:37:43 AM UTC, comment #1:
Please attach
- first and last 32K of disk
- output of "fdisk -l /dev/sdX" for this disk
- 1K at offsets 6 and 48 MiB
And describe how exactly you created this partition table (which program/version, which steps).
|
Wed 16 Dec 2015 10:13:32 PM UTC, original submission:
So basically they're not supported under latest grub.
I'm talking about real 4096 drives, where physical and logical sector sizes are 4096.
See attached screenshot. Partition start and total sizes are plain wrong unless you divide them by 8.
4096 / 512 = 8
Real FS begins at 6MiB and is 294 MiB in size.
So, let's get this fixed promptly. Such drives are now starting to flood the market.
|