On Sat, 04 Mar 2000, Stefan Bellon wrote:
> > > > It should be '0' or 'number of tracks - 1' (524). But with 128
> > > > heads showing, each 'track' in the bios is 8 tracks on the normal
> > > > format (i.e.16 heads), and as your disk really only has 2 heads,
> > >
> > > No, it has 16! The geometry that is printed onto the hard disc is
> > > (c/h/s): 4200/16/63. And the one recognised by Linux is (c/h/s):
> > > 525/128/63........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.
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?
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. 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. 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.
> > If certain information is not on the correct part of the hd, you
> > cannot boot from it. I speak from years of frustration in
> > Dos/windoze. I'm not sure about linux - yet, but I presume it's the
> > same.
>
> 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. 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. '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!
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 :-)
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?
> > > make again "sys a: c:"? Well ... :-/
Lovely Smiley ;-)
> > My idea (I was assuming the linux and M$ read the disk geometry
> > differently, and presuming LILO places the boot sector or presumes
> > the lzone in the wrong place) was to make EVERY sector a boot sector.
> > That would make sure that whatever the boot sector was, it would
> > point at a kernel. If the system then worked - great. Otherwise your
> > offset would be wrong, and you'd hang on lilo.
>
> So, MBR != MBR? If I understand you right, the lzone setting can change
> the absolute place of the MBR on the disc? And if LILO uses another
> lzone for its calculations than the BIOS when starting, then you'll get
> my problems?
As I think (REPEAT - THINK) it works, lzone is where the disk looks for the
boot record. There are tracks which aren't used on each disk.
.........snip.........
> Well, I've worked with _working_ Linux systems and didn't think about
> problems that could arise. So I'm more familar with Linux itself, than
> with how it starts and how the BIOS works. A deficiency I have to pay
> now. :-}
I've spent a portion of my life fixing crappy computers, but don't know linux
too well. We're making a good team! I looked on my own pc and found up to 255
heads on disks, but the 'real' number of tracks was 4962, and lzone was always
4961. I suppose they have it in there but don't show it.
>
> > 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. 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. 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.
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.
--
Regards,
Declan Moriarty.
