From: Marcin Dalecki <dalecki@evision.ag>
To: Petr Vandrovec <VANDROVE@vc.cvut.cz>
Cc: martin@dalecki.de, linux-kernel@vger.kernel.org,
alan@lxorguk.ukuu.org.uk
Subject: Re: [PATCH] 2.5.29 IDE 110
Date: Thu, 01 Aug 2002 23:57:11 +0200 [thread overview]
Message-ID: <3D49AEB7.9060900@evision.ag> (raw)
In-Reply-To: CDEF453FCB@vcnet.vc.cvut.cz
Uz.ytkownik Petr Vandrovec napisa?:
> On 1 Aug 02 at 23:16, Marcin Dalecki wrote:
>
>>Lets not forgett that the code removed would allow to read behind the
>>partion in question and was broken therefore. However the real world
>>example from Petr worries me and makes me thinking that the partition
>>scanning time solution could turn out to be most adequate -> we have the
>>FAT partition ID there at hand and could adjust the partition
>>parameters in question properly with ease. Both of them: offset *and* size.
>>
>>Petr would you mind dumping the dd=/dev/hdx count=10 of the
>>disk in question at me? Or do you preferr to go after this blotch
>>yourself?
>
>
> First sector contains valid partition table, but all partitions are
> set to type 0x55, EZDrive. AFAIK EZDrive synchronizes this inivisble
> partition with one from sector 2 on each reboot. Second sector contains
> 'real' partition table, with types set to Linux, Linux swap, VFAT and
> so on. I do not have extended partition on the drive, so I do not know
> whether this record will have 0x55 or correct type in the sector 1.
>
> Problem only occurs when you'll run LILO (if you have installed it
> in /dev/hdx instead of in /dev/hdx#), or install-mbr - it will overwrite
> ezdrive, and you have to find diskette and reinstall EZDrive to make
> disk bootable in this obsolete system (btw, it is PentiumII).
>
> So only problem is that we do not have special /dev/hdx-mbr device
> for accessing MBR, all code expects that it is in first sector of the
> /dev/hdx, while with 0_to_1 remap it is in second one.
> Petr Vandrovec
Thank you for saving me a bit of time. I was right now scanning Phoenix
site for the precise docu. Now I don'thave too. Well all the above
sounds like a defficiency in:
1. LILO.
2. fdisk.
3. Partition scanning code which should look at both sectors.
Hmm...
2. Isn't that critical becouse it only affects disk creation time.
3. Can be fixed easy at the proper place. Namely parition/xxx.cc
1. Is actually interresting for installing a new kernel
and the most mind boggling offender.
next prev parent reply other threads:[~2002-08-01 21:58 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-08-01 21:45 [PATCH] 2.5.29 IDE 110 Petr Vandrovec
2002-08-01 21:57 ` Marcin Dalecki [this message]
-- strict thread matches above, loose matches on Subject: below --
2002-08-01 17:37 Adam J. Richter
2002-08-01 16:54 Petr Vandrovec
2002-08-01 20:21 ` Marcin Dalecki
2002-08-01 21:47 ` Alan Cox
2002-08-01 21:16 ` Marcin Dalecki
2002-08-01 0:40 Marcin Dalecki
2002-08-01 18:51 ` Albert D. Cahalan
2002-08-01 20:13 ` Marcin Dalecki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3D49AEB7.9060900@evision.ag \
--to=dalecki@evision.ag \
--cc=VANDROVE@vc.cvut.cz \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=martin@dalecki.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox