Изпечатай

[remotex]

http://en.wikipedia.org/wiki/BIOS_Boot_Partition_%28GPT%29
http://en.wikipedia.org/wiki/GUID_Partition_Table

Основните предимства са
1. Макс. размер на дял: limitations of MBR partition tables restrict a disk partition's size to a maximum of 2.2 TB.  GPT allows for a maximum disk and partition size of 9.4 ZB.
2. EFI
На интелски дъна (сървъри) можеш да влезеш от БИОС в EFI Boot и оттам можеш да разглеждаш (от БИОС/ЕФИ) дялове, файлове, да копираш от/на тапа без да си заредил ОС - вярно досега съм го ползвал само за обновяване на БИОС-а
http://en.wikipedia.org/wiki/Extensible_Firmware_Interface

..това е от моя скромен личен опит в борбата с един много голям диск (всъщност РАЙД) който Уинодус не виждаше целия преди Upgrade to GPT а пък СЛЕД това се оказа че го вижда но не може да се инсталира на него т.е. може да ползва > 2.2 ТБ  но не може да зареди от такъв дял а само като 2-ти (-3и) диск за данни. С Grub(2) обаче заспа и нямаше никакви проблеми, но.. покрай борбата с подкарване под Уиндоус и обновяване на БИОС и пр. човек научава полезни неща 

[neter]

Пробвай пак с "ufstype= 44bsd,sun,sunx86,hp и всички останали"

Момент, тук вече отиваме в опасната част на експерименталния модул - грешно зададен тип на ufs може да повреди файловата система на дяла. Все пак, налага се да се пробва, но нека преди това се направи резервно копие на данните на дяла, ако има важни такива на него.

mystical, каза, че си успял да монтираш дяла в read-only режим. А успя ли да прочетеш данните от него или само успя да го монтираш? Ако си успял да ги прочетеш, направи резервно копие, ако имаш нещо важно на дяла. Ако не си успял, то значи наистина може да има slice-ове в този дял, и да е нужно да монтираш правилния slice, а не /dev/sdb1. Ако има slice-ове, то би трябвало да присъстват в /dev, нищо че не се виждат с fdisk. Нека видим какво ще покаже командата

Код

GeSHi (Bash):
ls -l /dev/sdb*

Не знам какво е това "магическо число" което не отговаря на ufs2 .. и то вероятно минава на default = old , което май също не отговаря. Според fdisk ID=a5 е някое *BSD ама за по сигурно пробвай всички останали (като хвърляш по едно око на dmesg).

Магическото число на дяла е 0xA5, което съответства на ID-то на файловата система, което се вижда с fdisk. 0xa5 отговаря на файлова система UFS. Отнася се до основния тип на файловата система. С параметъра ufstype се указва подтипа на UFS файловата система, един от които е ufs2. Магическото число не се отнася към подтиповете, и всички те попадат под магическото число 0xA5. Има вероятност от изкарване точно на тази грешка:

ufs_read_super: bad magic number

когато системата знае, че файловата система на дяла е от някакъв тип (в случая ufs с магическо число 0xA5), но не успява да го монтира, поради грешен подтип, така че има вероятност от успех с проба на всички подтипове, и при уцелване на точния, дялът да се монтира. Лошото е, че тази грешка не е никаква гаранция, че това е проблемът, така че накрая може да се наложи да вадим боба да помага

P.S.0: Сигурно ли е, че дялът е коректно демонтиран от телевизора? За сефте казвам такова изречение, колко лесно беше с телевизорите Велико Търново

P.S.1: Ааа, между другото, ако се окаже, че не е от FreeBSD подтиповете, а от Solaris, имаш нужда от задаване на тези модули в ядрото - CONFIG_SOLARIS_X86_PARTITION и CONFIG_SUN_PARTITION. Може и да ги имаш, но провери за всеки случай. Метни едно око и какво е положението с CONFIG_MAC_PARTITION, CONFIG_EFI_PARTITION и CONFIG_BSD_DISKLABEL.

[mystical]

Пробвай пак с "ufstype= 44bsd,sun,sunx86,hp и всички останали"
Не знам какво е това "магическо число" което не отговаря на ufs2 .. и то вероятно минава на default = old , което май също не отговаря. Според fdisk ID=a5 е някое *BSD ама за по сигурно пробвай всички останали (като хвърляш по едно око на dmesg).

Освен fdisk можеш да ползваш за иденфитициране на дял от диска и др. програмки като parted, blkid .

А, за малко да забравя че *BSD може би има и slices

Задънена улица.

mount -t ufs -o ufstype=sun|sunx86|44bsd|ufs2|5xbsd|old|hp|nextstep|nextstep-cd|openstep ...
Нито едното не става. Няма и slices

root@debian:/# cat /proc/partitions
major minor  #blocks  name

   8        0  312571224 sda
   8        1   16095232 sda1
   8        2          1 sda2
   8        5  265506222 sda5
   8       16  244198584 sdb
   8       17  244196001 sdb1

root@debian:/# blkid
/dev/sda1: UUID="da4e2fd8-48f5-41bd-a562-7097a9380434" TYPE="ext4"
/dev/sda5: UUID="9038A57738A55D4A" LABEL="multimedia" TYPE="ntfs"
/dev/sdb1: LABEL="" TYPE="ufs"

Когато монтирам дяла, мога да чета от него. Няма никаква информация на хард диска. Всички видове PARTITION и BSD_DISKLABEL са включени в ядрото.

[neter]

Как разбра, че можеш да четеш от него, след като няма данни на този дял? Сложи някакви данни и виж дали ги достъпваш след монтиране в read-only режим.
За slice-овете, покажи изхода от командата, която ти казах в по-горния пост. Казах ти, че slice-овете най-често не се виждат от fdisk, което беше намек, че имат навика да се крият под Linux, в това число и да не им се задава UUID (и да не ги виждаш с blkid) и т.н.

[mystical]

root@debian:/# ls -l /dev/sdb*
brw-rw---- 1 root floppy 8, 16 Jun 18 23:30 /dev/sdb
brw-rw---- 1 root floppy 8, 17 Jun 18 23:30 /dev/sdb1
root@debian:/# mount -t ufs -o ufstype=ufs2 /dev/sdb1 /mnt/
root@debian:/# ls -al /mnt/
total 4122
drwxr-xr-x  3 root root    1024 Jun 15 16:50 .
drwxr-xr-x 22 root root    4096 Jun 18 00:02 ..
-rw-r--r--  1 root root      32 Jun 15 16:50 bind.id
drwxrwxr-x  2 root root     512 Jun 15 16:50 .snap
-r--------  1 root root 4194304 Jan  1  1970 .sujournal