В Thu, 14 Mar 2013 20:18:46 -0600 Chris Murphy <li...@colorremedies.com> пишет:
> > On Mar 5, 2013, at 12:22 AM, Vladimir 'φ-coder/phcoder' Serbinenko > <phco...@gmail.com> wrote: > > > On 05.03.2013 00:16, Chris Murphy wrote: > > > >> > >> On Mar 4, 2013, at 12:43 PM, "Lennart Sorensen" > >> <lsore...@csclub.uwaterloo.ca> wrote: > >> > >>> On Mon, Mar 04, 2013 at 08:33:51PM +0100, Vladimir 'φ-coder/phcoder' > >>> Serbinenko wrote: > >>>> Not necessarily. 3T drives often use msdos, just with 4K sectors which > >>>> increases the range of msdos to 16T. > >>> > >>> Hmm, I suppose that would work. I have never seen one that did that yet, > >>> but I don't have that many 3TB drives either. > >> > >> I wonder what the BIOS does when it "asks" the drive for LBA 0, and > >> receives 4096 bytes instead of 512 bytes. > > > > It doesn't get that far. Most likely it bails out after reading SCSI > > descriptor. > > I have anecdotal evidence these drives are now in the wild. Mac user with a > new 3TB Seagate USB 3 external drive: > Device / Media Name: Seagate Backup+ Desk Media > > This is not very descriptive. But when I ask the user to display the GPT with > gdisk, there's normal output, except for this line: > Logical sector size: 4096 bytes > > Next, when I have him report the result from: > sudo dd if=/dev/disk3 count=2 2>/dev/null | hexdump -C > > The 1st 512 bytes reported is the PMBR, but the 2nd 512 bytes is garbage, not > the GPT header as expected. > It is possible that you need to read in physical sector size; what if you try bs=4k? > When this drive is connected to the computer and he tries to boot Windows, > the system hangs at a black screen. That's kinda interesting/concerning, if > even CSM-BIOS implementations on recent EFI firmware can have problems with > such drives. > > > Chris Murphy > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
