Re: Instalacja XP - ntldr

Użytkownik "Rafal" <nie_podaje@costam.pl> napisał w wiadomości
news:c97ncp$dlc$1@news.onet.pl
> Użytkownik "Michal Kawecki" <kkwinto@o2.px> napisał w wiadomości
> news:ca4052b8a102ff5f06a36ca32c4140ec@kwinto.2com.pl...
>> Ja słyszałem o problemach w dystrybucji Mandrake 9.2 i 10, tudzież w
>> Fedorze.
>
> Ale w której Fedorze?? Core 1, czy 2??

Core2.

Znalazłem w końcu źródło problemów: jest nim nowy kernel 2.6, a
właściwie narzędzia partycjonujące nieprzystosowane do wprowadzonych
przez niego zmian w raportowaniu parametrów dysków. Skutki mogą być
opłakane, włącznie ze zniszczeniem tabeli partycji i danych. Obejściem
problemu jest NIE UŻYWANIE linuksowych narzędzi partycjonujących do
czasu ich aktualizacji, ewentualnie wymuszenie w BIOS-ie translacji LBA
dla wszystkich dysków twardych.

Jeśli dobrze zrozumiałem problem po pobieżnym przejrzeniu poniższych
linków - chodzi o użycie innego wywołania Int-13h, niż w Windows, celem
określenia parametrów dysków twardych, a następnie obliczenie na ich
podstawie i zapisanie w tabeli partycji wartości CHS, które są odmienne
od wartości raportowanych przez BIOS na podstawie już istniejącej na
dysku, założonej wcześniej np. spod Windows, tabeli partycji.

Dodam tylko, że to nie jest jedyny błąd w tych nielicznych dystrybucjach
Linuksa. Panowie postanowili pójść na całość ;-) i uznali, że nie trzeba
już zwracać uwagi na kolejność w łańcuszku zlinkowanych ze sobą dysków
logicznych; innymi słowy, wpis w EBR pierwszego dysku logicznego może
sobie wskazywać na piąty dysk logiczny, potem wracać do drugiego, and so
on... wyjaśnienie? "Bo w specyfikacji nie jest to zabronione". Żenada. .
. .
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=122413

=======================
At last someone here reproduced the bug which is now fully explored.

Part of the reason I could not understand the bug, is that I could not
believe windows XP was still using the error prone int13 function 2
(CHS based) instead of the (available everywhere for some time) int13
function 0x42. Under linux, grub and lilo only use function 2 when
function 0x42 fails (they don't even ask the BIOS if it manages 0x42
since some BIOS don't report correctly having this functionality, cf
FORCE_LBA in grub)

The other reason is that I thought BIOS faking heads number (the
so-called LBA mode) was a choice independant of the content of the
drive. This is wrong, the BIOS tries to adapt its mode based on the
partition table [1]

So here is what happened:
- kernel 2.6 doesn't try to give the logical geometry, and gives the
  physical geometry instead [2]
- diskdrake uses the physical geometry to generate the CHS information
  (which is a broken duplicate of the linear sector number)
- the BIOS sees the partition table uses a different CHS geometry, and
  adapt to it
- ... and Windows computes the CHS to read its stage1.5 based on the
  previous geometry that it keeps in its boot sector. Alas the CHS
  doesn't get the same sector and Windows's boot dies (with very bad
  error detection) [3]

Bug occurence: the pb only occurs when you modify the partition table,
  since otherwise diskdrake won't write it.

Code fix description: inspired by the way new fdisk and parted detects
  the logical geometry based on the partition table [4]. parted code
  is especially quite robust.
  The fix is now included in cooker (DrakX #1.912), so:

  I still would like to access the BIOS geometry, esp. for empty
  partition tables. But kernel 2.6 doesn't give us this
  (/sys/firmware/edd/int13_dev80/default_heads is plain wrong on a box
  here)

Known workaround: forcing LBA mode in the BIOS

Fixing partition table:
  with diskdrake from drakxtools-10-24mdk do
    % diskdrake --change-geometry=hda=255,63
  where
  - you replace hda with your drive device
  - if Windows still fails, try adapting 255,63 to your drive LBA
    emulation. For this, see what is the geometry your BIOS gives when
    forcing LBA emulation

[1] http://www.ussg.iu.edu/hypermail/linux/kernel/0311.3/1142.html
[2] http://www.ussg.iu.edu/hypermail/linux/kernel/0311.3/0898.html
[3] http://www.ussg.iu.edu/hypermail/linux/kernel/0311.3/1029.html
[4] http://www.ussg.iu.edu/hypermail/linux/kernel/0311.3/1164.html
================

Ponadto polecam te linki:
https://qa.mandrakesoft.com/show_bug.cgi?id=7959
http://mlf.linux.rulez.org/mlf/ezaz/ntfsresize.html
http://www.ussg.iu.edu/hypermail/linux/kernel/0311.3/1029.html
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=115980

-- 
M.           [MVP]                               "Use Google, stupid!"
/odpowiadając zmień px na pl/