Изпечатай

[dejuren]

Крайно време е да се премине към нещо ново.

Да, ако това нещо ново не е заключено от една известна корпорация да работи само с нейните продукти. За домашно може да прочетеш какво колегата plamen_f е пуснал:
http://www.linux-bg.org/forum/index.php?topic=42900.msg245186#msg245186
И както говорим за заключени работи в светлината на горното не ти ли се струва и добра идея една нова телевизия 3Д ако щете, която да има едни предпазни колани, които да се затягат като тръгнат рекламите? Да не пропуснете нещо за новия шампоан. Лошо няма, нали така?

PS Ще го кажа и по друг начин: ако новата къща която ми дават е модерен затвор, предпочитам старата си дъсчена барака.

[go_fire]

Странно бая народ не могат да прежалят ISA и попържат кански PCI. По между другото примера изобщо не е добър. Все още се произвеждат и устройства и дънни платки с ISA и даже са доволно скъпи.

[Mitaka]

От кога има проблем с инсталиране на Линукс върху машини с UEFI?
Аз имам един IBM x3650M3 и на него RHEL си върви повече от прекрасно

[n00b]

Проблема който дискутирате е тривиален:

SecureBoot е параметър който може да бъде изключен от UEFI интерфейса. Друг е въпроса дали OEM производителя ще го е изнесъл - но това не е проблем на M$, UEFI, Linux и т.н.
За ARM архитектура обаче M$ ИЗИСКВАТ този параметър да не може да се пипа. Т.е. йок пингвини на таблетите които ще излязат...

[dejuren]

За ARM архитектура обаче M$ ИЗИСКВАТ този параметър да не може да се пипа. Т.е. йок пингвини на таблетите които ще излязат...

Което направо прави Морковсофт смешни... Та те горките имат 1.5% пазарен дял в таблетите, при 57% Ябълка и 39% Андроид. Очевадно който иска линух инсталиран на желязо на таблета ще си е взел андроидски. Тези с виндовс на таблет спокойно може да си дъвчат кактуса и по-нататък.
(http://techcrunch.com/2012/01/26/android-reaches-39-tablet-os-market-share-standing-on-amazons-shoulders/)

ПП виндозе на АРМ? Ще успеят ли за средата на века, или феновете ще трябва да се запасят с търпение и да чакат 2100г. ? (http://www.itpro.co.uk/640870/arm-based-windows-8-tablets-facing-delays)

[shoshon]

Не знам някои отговори ли на човека? В смисъл две страници клюки и никакъв смислен отговор.

Това може да помогне. Според този пост, Lenovo S205 очаква да намери Windows партиция като първа на машината. Прочети и ако помогне кажи да знаем.

Това е единиственото смислено нещо, което прочетох. Не знам дали сте забелязали ( нали все пак ще даваме Леново на съд ), но в спецификацията на UEFI пише:

3.4 Boot Mechanisms
EFI can boot from a device using the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL or the
EFI_LOAD_FILE_PROTOCOL. A device that supports the
EFI_SIMPLE_FILE_SYSTEM_PROTOCOL must materialize a file system protocol for that
device to be bootable. If a device does not wish to support a complete file system it may produce an
EFI_LOAD_FILE_PROTOCOL which allows it to materialize an image directly. The Boot
Manager will attempt to boot using the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL first. If that
fails, then the EFI_LOAD_FILE_PROTOCOL will be used.

(страница 71, весия 2.3.1, Errata B )

Понеже, не е написано на руски ще обясня с думи две... По спецификация UEFI се опитва да намери стартиращата програма, чрез EFI_SIMPLE_FILE_SYSTEM_PROTOCOL, а след това пробва с EFI_LOAD_FILE_PROTOCOL ( структура с виртуален метод  LoadFile() ).

Интересно е какво е EFI_SIMPLE_FILE_SYSTEM_PROTOCOL. Чичо Гошо казва:

The EFI_SIMPLE_FILE_SYSTEM_PROTOCOL provides a minimal interface for file-type access to a device. This protocol is only supported on some devices.

Devices that support the Simple File System protocol return an EFI_FILE_SYTEM_PROTOCOL. The only function of this interface is to open a handle to the root directory of the file system on the volume.

Once opened, all accesses to the volume are performed through the volume’s file handles, using the EFI_FILE_PROTOCOL protocol. The volume is closed by closing all the open file handles.

The firmware automatically creates handles for any block device that supports the following file system formats:

    FAT12
    FAT16
    FAT32

т.е опитват се да кажат, че UEFI може да разпознава FAT** файлови системи автоматично, БЕЗ да се налага зареждане на междинен код. Втория метод EFI_LOAD_FILE_PROTOCOL е отворена врата за допълнителна имплементация от страна на драйверите на дъното, т.е. може да съществува код, който по някакъв начин да интерпретира зададения път на файл. А този път на файл може изобщо да не е файл, а примерно PXE Boot image ( както е дадено в примера ).

След като хвърлихме бегъл поглед, вече може да си зададем въпроса, защо не е стартирала машната. За съжаление не мога да отговоря без поне снимка на конзолата от UEFI-то. Мога само да спекулирам и да кажа:
1) Човека е направил грешка при форматирането на диска, въответно Boot Loader-а не е успял да се инсталира успешно.
2) Грешна имплементация от страна на firmware или Grub когато се използва Legacy Master Boot Record.

И така, технологията е нова и нетествана. Би следвало човек да се замисли и в тази насока.

Малко допълнителна тривиа:
Повечето от вас сигурно са се сблъсквали с Itanium-базирани машни. Те използват подобен протокол за стартиране на машината (iEFI, 2.1) като задължително първия диск е fat (не знам дали е 16 или 32 ) форматиран. Върху него седи програмата, която зарежда опрационната система. И да корените на EFI-то са в Intel ( не в MS ), като допълнителната разработа е точно унифицирането на Firmware-а м-у x86, ARM и другите бъдещи архитектури.

Q:    How does UEFI differ from BIOS?
A:    The Basic Input/Output System (BIOS) served as the OS-firmware interface for the original PC-XT and PC-AT computers. This interface has been expanded over the years as the "PC clone" market has grown, but was never fully modernized as the market grew. UEFI defines a similar OS-firmware interface, known as "boot services" and "runtime services", but is not specific to any processor architecture. BIOS is specific to the Intel x86 processor architecture, as it relies on the 16-bit "real mode" interface supported by x86 processors.

   
Q:    Does UEFI completely replace a PC BIOS?
A:    No. While UEFI uses a different interface for "boot services" and "runtime services", some platform firmware must perform the functions BIOS uses for system configuration (a.k.a. "Power On Self Test" or "POST") and Setup. UEFI does not specify how POST & Setup are implemented

Както виждате, разликата м-у BIOS и UEFI e съществена, и двете влизат в категорията Firmware, но UEFI не е BIOS, защото започваме да приличаме на лелките по книжарниците, които наричат копирната машина ксерокс. Всъщност UEFI е от голяма полза точно на GNU/Linux защото големите компании имат ресурс да пишат различен код за различен firmware, но OSS проектите нямат.

Ето малко допълнителна информация:

http://william.shallum.net/random-notes/windows-7-linux-uefi-dual-boot

Много хубава статия на Intel, отностно оптимизация на процеса на зареждане на OS-a. Разликите с BIOS просто не могат да се обянят във форум...
http://www.intel.com/technology/itj/2011/v15i1/Booting-in-an-Instant.htm

[Gogo_SZ]

Добре, де ето и сериозният отговор:

EFI/UEFI работи с нов вид partitition схема GUID:
http://en.wikipedia.org/wiki/GUID_Partition_Table

Демек диска трябва да се преформатира изцяло.
Резултат:
Работят само новите операционни системи...

Ако искате да четете много и подробно вижте в Гугъл за "uefi partition table"

[Mitaka]

Е не е ли нормално да работят само новите OS
Тъй де - въвежда се нещо ново => гледаме напред, а не назад, нали така?

[trosho]

Добре, де ето и сериозният отговор:

EFI/UEFI работи с нов вид partitition схема GUID:
http://en.wikipedia.org/wiki/GUID_Partition_Table

Демек диска трябва да се преформатира изцяло.
Резултат:
Работят само новите операционни системи...

Ако искате да четете много и подробно вижте в Гугъл за "uefi partition table"

Всъщност, UEFI не налага такова изискване. За дисковите устройства пише (цък), че освен с MBR дискове, ще работи и с новата схема на разделяне - GPT:

In addition to the standard PC disk partition scheme, which uses a master boot record (MBR), EFI works with a new partitioning scheme: GUID Partition Table (GPT).

Обаче, различните ОС-и могат да имат свои изисквания. За да се инсталира Windows на машина с EFI firmware, той трябва да е 64-битов, Vista SP1 или по-нов (за сървърните версии не знам), както и схемата на разделяне на диска да е GPT (цък):

Although EFI specifies booting from either the GPT or MBR, 64-bit Windows does not support booting EFI from MBR disks or 0xEF partitions.
(0xEF е идентификатора на EFI system partition при MBR диск)

Трябва доста да се задълбае, за да се разбере кой, какво и какви версиии на EFI/UEFI поддържа.

[dejuren]

Хоп - и аз намерих нещичко: https://help.ubuntu.com/community/UEFIBooting

[Gogo_SZ]

Обещанията и пожеланията са направо прелестни.....
Истината обаче е както винаки "сурава и курава" = GUID/GPT Only.

Тоя цирк MacOS потребителите го играят от повече от 10 години. И к'во - да не би да сте видяли Mac да стартира от MBR диск?
С останалите OS е (или ще е) същото.
Край на илюзиите!

Все пак GUID никак не е лош де, не се разстройвайте.

[n00b]

Обещанията и пожеланията са направо прелестни.....
Истината обаче е както винаки "сурава и курава" = GUID/GPT Only.

Тоя цирк MacOS потребителите го играят от повече от 10 години. И к'во - да не би да сте видяли Mac да стартира от MBR диск?
С останалите OS е (или ще е) същото.
Край на илюзиите!

Все пак GUID никак не е лош де, не се разстройвайте.

МОЖЕ да се стартира от MBR с известни хакове. Win2k3 ако не се лъжа също поддържа GPT (или беше Win2k?)

По-интересното е, че Ubuntu имат някакъв план...
http://www.phoronix.com/scan.php?page=news_item&px=MTEyNDY

With the GPLv3-licensed GRUB2 not being an option, Canonical then explored using the GRUB Legacy release with EFI patches on top, but they didn't want to touch that aging code-base. Canonical has decided to use Intel's efilinux loader that is more liberally licensed and they're able to make some modifications to provide a simple menu interface.

Also shared is that Canonical only plans to enforce requiring the authentication of boot-loader binaries but not signed kernel images or kernel modules. This will make Ubuntu Linux still capable of loading binary blobs like the NVIDIA and AMD Catalyst drivers and for users to easily spin their own kernels.

Future OEM PCs to have Ubuntu pre-installed and certified will require that the Ubuntu key be part of the device's UEFI signature database. They also hope to provide an alternative to Microsoft's signing infrastructure while requiring the standard Microsoft key be present in the Ubuntu certification process.