In article <00030511261100.00238@laptop>,
Declan Moriarty <[EMAIL PROTECTED]> wrote:
> On Sat, 04 Mar 2000, Stefan Bellon wrote:
[snip]
> > Well, what does that mean? Is there a way out of the dilemma?
> You check for disk software on the website of the hd manufacturer. I
> have disk master from Maxtor, for instance.
Well, Toshiba has hundreds of BIOS updates and Win drivers for their
notebooks on their web site, but nothing concerning their hard discs.
Congrats! :-/
Is the Maxtor disk master limited to Maxtor discs in some way, or does
it work with all discs?
> A Little bit of clear thnking might enable calculation or
> detection of the correct location for the hd. I really liked the idea
> of letting Dos place the kernel for you - even if it never worked, it
> was a top class idea, as ideas go. Have you a disk editor in Linux?
> Can you get one?
Well, under Linux you have access to the hard disc via the device files
/dev/hda, /dev/hda1, ... and so on. Then you can load these (access
rights permitting) into any editor supporting virtual memory editing.
But anyway, I've just installed ncurses-hexedit which seems very fine
for these things.
Problem is: You get it always relative to the start of /dev/hda,
/dev/hda1, ... whatever you're looking at. I don't know whether there's
a way to really look at _absolute_ sectors. And /if/ /dev/hda was
already placed at an offset, then I won't notice it this way (but later
on when looking at it in the DOS sector editor).
> You could solve your problem with a linux disk editor, as you would
> format for DOS, boot from a dos floppy, execute sys a: c: and then
> boot linux and examine the disk for the actual location of the dos
> system files.
Alright, did it just now with a floppy disc, and the offsets are both
the same. But - who wonders - booting into Linux from floppy *does*
work.
> My guess is that you will find them at an offset from the original,
> and that, in fact, Linux is able to access more tracks of the disk
> than the BIOS are, because Linux disk access is independent of the
> BIOS. It just may be the other way around, i.e. that the BIOS tracks
> lower on the disk.
Alright, I'll try that later on.
> If you need a DOS based disk editor, I'll e-mail you my one if you
> can get no other. This could get very messy, as the disk is only 3
> 'tracks' long.
Yes, please email me one, as I'm not sure whether I'll find one that
suits this special need.
[snip]
> > Alright, but I assumed that when booting, the contents of the MBR
> > (sector 0 of the hard disc, if I understand things right) is loaded
> > and executed by the BIOS. There's a JMP at the start to some
> > further init code which calls the kernel at the specified position
> > which was calculated and written into the boot sector by LILO. So
> > there's a problem when LILO and the BIOS calculate in a different
> > way. That's where a problem could be. But why doesn't the boot
> > sector get executed at all? At least the "LI" string from "LILO"
> > should appear on the screen. But it doesn't. So the boot sector
> > isn't executed at all. And why is this? Surely not, because it
> > doesn't get found? The only solution - that springs to my mind now
> > - is, that the BIOS checks what it thinks to be a valid boot
> > sector. And it decides that the LILO one is no valid one. When
> > copying to the floppy disc it works. So the BIOS doesn't check the
> > boot sector of floppy discs. Does this make sense? %-/
> For me, this adds the missing pieces. You obviously read more of the
> manuals than I have had time to.
Well, time is another problem (besides the notebook that doesn't want
to boot!). But there are priorities ... ;-)
> The boot sector doesn't get executed at all, because it isn't where
> the BIOS looks for it. The BIOS reads SOME sector, fails it as a boot
> sector (not valid) and reasons that there is not a system disk.
Yup. Although I'm still not sure whether the position is wrong, or
whether the BIOS really expects a _certain_ boot sector to be there and
this isn't there. We'll find out after I have done my tests, I assume.
> 'LI' never appears, because the sector where lilo lies never gets
> read. If lzone were the problem, you would hang on the 'li' - I
> think. If there's a real disk expert following this thread, now's the
> time to pipe up!
That would be nice, indeed!
I have no idea what the boot sector is laid out. What I think is the
following:
* 448 Bytes of real boot sector data
* 64 Bytes of partition data
Bytes 447 and 448 are:
* for LILO boot sectors 0x80 0x01
* for DOS boot sectors 0x80 0x00
What are these vaues?
> You can figure it out by formatting for UMSDOS, which should be read
> by Linux and DOS disk editors. Then install dos, and check for it's
> location with the linux disk editor. Format for linux, and check for
> it's location with the DOS disk editor. You'll add grey hairs, but
> contribute to the knowledge base :-)
Yes, that's true. Pity is that I should learn for exams as well. Why
does a day only have 24 hours? Grrrr.
> It should then be possible to correct the offset in Lilo - get the
> mantainer to give you a patch, or ask him to calculate it. I have
> been given more than one patch without asking. That's the great thing
> about Linux. When would ever M$ write a patch for one customer?
Yes, too true!
[snip]
> > > Have you tried /boot as an UMSDOS partition?
> >
> > No, but the 512 bytes of the MBR on a floppy disc work nice (as a
> > temporary solution)!
> I think if you're going to solve it, you need an UMSDOS partition, at
> least for an hour.
Sigh.
> That way, you can read it with DOS (the BIOS) and Linux (Directly).
> When you find where the bios places the system files, and boot
> sector, somebody who eats & sleeps this stuff will be able to write a
> patch for that lousy bios.
Well, I'll try to contact the new BIOS manufacturers as well
(SystemSoft don't maintain it anymore).
> Every time something like this comes up and I'm asking questions, I'm
> reccomended to ide.txt in the kernel docs. I never read it - yet :-(
> . You might think it a good idea.
I've hda a look at ide.txt, but didn't find anything which rang a bell.
:-/
> Another approach is to check out dos based programs such as lread
> (for reading linux disks), and see if they use the bios. If they do,
> you might be able to duplicate the /boot partition sector by sector,
> as it is seen from a BIOS reading in one big file, by piping the
> output to dd or something. Don't ask me how - it's an idea only. DD
> will read it as it is seen from Linux. You can then compare the two
> files, (The bios version and the linux look at it) spot the
> differences, and perhaps exchange them (i.e. write the linux read
> back onto disk with the bios). That's only a 10 MB partition. Then
> any hex editor will allow you to scan the image. You might be able to
> track what's going on here, and get some real fix.
Where do I get this lread from? This sounds the easiest way to start
with. :-}
BTW: From the LILO author I got another idea I'll try first of all. He
suggested setting the partition type of the boot partition to a DOS
type and not to an ext2 type. Perhaps the BIOS checks this? I'll try.
Greetings,
Stefan.
--
Stefan Bellon * <mailto:[EMAIL PROTECTED]> * <http://www.sbellon.de/>
Hard work has a future payoff. Laziness pays off now.
