Text 6304, 117 rader
Skriven 2006-06-12 11:20:02 av Paul Rogers (1:105/360.0)
     Kommentar till en text av Maurice Kinal
Ärende: follow up
=================
I spent an hour or so last night reading in /usr/share/doc/lilo.
What I came away with is disk= isn't needed except in cases like
yours where there are multiple drives and lilo can't get the
geometry by asking the kernel.  For a single IDE system, it
certainly didn't seem to me that disk= is necessary.  In a system
like yours, where geometries aren't so definitely fixed and there
are a couple levels of drivers getting involved, I'd certainly
expect it is.

 MK> The bios=0x80 part works.  If the bios can detect the
 MK> target as a legitimate device then 0x80 will tell the bios
 MK> it is bootable.  I believe that is how it works.  So far it
 MK> has.

Perhaps, but for my clone script I can't really be sure how the
system has been cobbled together.  For example, I could be told
BOOTDEV=/dev/hdd1.  0x83?  0x91?  This was just a test.

 PR> install=/boot/boot.b
 MK> This might be wrong if the target is different then the
 MK> host.  I decided to drop it and it still works.

It would be unless I'm chrooted to the target system, I think.
Then /boot is on the target FS.  After my reading last night, and
after the EBDA failure, I mounted just /dev/hda6, chrooted to the
mount point & bash, and typed lilo.  (Note: /boot is now on /,
from which the copies on /dev/hda1 were made.)  It added pod, and
^D, reboot gave me a running target.  Since I was chrooted, the
(Knoppix CD) host's /boot was back in the host system.

I get different behavior if I've got a terminal in the chroot
environment than if I'm running a script there.  I know login
shells will get profiles and such, but I don't understand how that
relates here.

 PR> lba32
 MK> Not needed if no other targets other then linux.  I think
 MK> Bill needs it but I discovered I don't, especially for
 MK> small drives, but also for large ones (tested up to 300G so
 MK> far).

It's one of the recommendations for situations when you get a
"LI".

 PR> image=/boot/vmlinuz-2.4.20
 MK> Do you like that one?  I thought 2.4.19 was better but only
 MK> because of framebuffers.

That's what the LFS base I'm using builds.  My enhancements push
it up to 2.4.31.  If I get the clone script working, I may just
pause with 2.4.20, patch it to 2.4.21, get the modules I need for
Trinux, then wipe it all and start over.

 PR>   # Make drive bootable with lilo
 PR>   (cat >usr/local/sbin/runlilo <<EOF
 PR> mount $BOOTDEV /boot &&
 PR> lilo -C /etc/lilo.conf -A $mbr $part
 PR> EOF

 MK> That looks strange to me.  In the case of the example I

I'm not sure what's strange.  chroot runs A command, not two.
When you seemed to imply that lilo needed some mounted access to
the target drive, I made this so /dev/hda1 ($BOOTDEV, put in the
chroot environment by running env) got mounted, just like it would
be when the target system was running.  I make sure it finds the
target's regular lilo.conf, the same one it finds when I run lilo
by hand in the chroot, and I make sure /dev/hda is marked active.
(In case it wasn't when the drive was partitioned.)

 MK> posted earlier for the first 64-bit ttylinux on the M-
 MK> Systems iDOC, BOOTDEV=/dev/hda and /dev/hda1 was mounted on
 MK> /mnt/flashdisk.  Thus 'lilo -C
 MK> /mnt/flashdisk/etc/lilo.conf' was what was required.  I

Right.  You were still in the host's environment.  I'm trying to
avoid making two lilo.conf's for the host & target environments,
because they might disagree.  But it sure looks like something's
wierd about running lilo in the chroot/target environment.

 PR> Loading podEBDA too big
 MK> Yeah I seem to recall seeing that years ago.  I think you need an
 MK> upgrade.

I don't think so.  I think lilo is just being confused.  It works
if I run it by hand, several times.

 PR> I didn't get that when I didn't have the disk= in lilo.conf
 PR> and changed the chroot to just drop me in a shell and ran
 PR> lilo by hand.

 MK> Yeah.  The chrooted can be dangerous.

There's something different about it.  One thing is, I'm running
under the host's kernel, with a lilo (statically?) compiled for
the target.  Knoppix runs 2.4.17, IIANM.

 MK> already had it's own lilo in it's mbr.  I still like the
 MK> $TARGET idea best.  I'll write an example up later once I
 MK> finish testing the new development stuff out.  I just

Yeah, but I think you're in something of the same pickle I'm in,
except in reverse.  As long as it works, you just go on.  When
something works, who ever stops to make sure they know WHY it
works.  My script doesn't quite seem to work the way I think it
should, though I can get a bootable disk out of it.  I'm just NOT
going forward until I get the script working.

Paul Rogers, paulgrogers@yahoo.com                       -o)
http://www.angelfire.com/or/paulrogers                   /\\
Rogers' Second Law: Everything you do communicates.     _\_V

... Canadian DOS: Yer sure, eh? [oui/non]
___ MultiMail/MS-DOS v0.35

---
 * Origin: The Bare Bones BBS (1:105/360)