Text 6308, 141 rader
Skriven 2006-06-12 19:01:16 av Maurice Kinal (1:140/13.1)
   Kommentar till text 6304 av Paul Rogers (1:105/360.0)
Ärende: follow up
=================
Hey Paul!

Jun 12 11:20 06, Paul Rogers wrote to Maurice Kinal:

 PR> geometry by asking the kernel.  For a single IDE system, it
 PR> certainly didn't seem to me that disk= is necessary.

Right.  However if you attach another drive temporarily to mirror a system for
another machine then the disk= will be needed.  That is usually how I install
these days, especially if I want to make CD/DVD drives disappear here, which I
do.  Waste of money methinks.

 PR> In a system
 PR> like yours, where geometries aren't so definitely fixed and there
 PR> are a couple levels of drivers getting involved, I'd certainly
 PR> expect it is.

Right again.  I like doing weird stuff with drives.  I find it more satisfying
and useful then following the pack.

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

It is always 0x80 for any drive on an x86 machine from my understanding of the
situation.  Again, it has never failed to work here no matter what /dev/xxx,
ide or scsi.

 PR> It would be unless I'm chrooted to the target system, I think.

Yes but suppose the target system is on a drive connected to the host system
where it's /dev/xxx is different then what will happen when it is actually
connected to the target system?  For instance if I hook up a ide drive to my
host system via a usb adapter and the host sees it as /dev/sda and I know
beforehand that it'll be hooked up as master on ide0 (/dev/hda) then to make it
bootable from the host then 'disk=/dev/sda bios=0x80', 'boot=/dev/sda' and
'root=/dev/hda1' in the special lilo.conf (assuming I installed to the first
partition).  Then 'lilo -C /mnt/wherever/etc/lilo.conf' will write to the mbr
of /dev/sda which will become /dev/hda on the target and it'll boot right off
the bat when wired into the target machine.  Right?  ;-)

It works.  However in my case I am doing it with flashdisks and loading it into
ramspace so it doesn't matter what the target sees it as since it only relies
on the bios recognizing it as a bootable device.  This is the REAL bonus but I
still like installing to regular HDs using the same method.  Saves a bunch of
grief.

 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).

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

Right, and if you actually set the drive up that way originally.  Most of mine
aren't since they've never had to worry about it.  I already abandoned 16-bit
before it became a REAL issue with me so it never was a problem here.  I recall
it being a major issue with dos and os/2 around the time I switched over to
linux.  Oh well, I don't miss either of them.

 PR> That's what the LFS base I'm using builds.

Ah!  That makes sense then.

 PR> My enhancements push
 PR> it up to 2.4.31.  If I get the clone script working, I may just
 PR> pause with 2.4.20, patch it to 2.4.21, get the modules I need for
 PR> Trinux, then wipe it all and start over.

Sounds like a plan.  One step at a time.

 PR> I'm not sure what's strange.

Neither am I.  :-/

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

Okay.  Still don't really understand but we obviously have a different approach
and goal.

 PR> Right.  You were still in the host's environment.

Yes.

 PR> I'm trying to
 PR> avoid making two lilo.conf's for the host & target environments,
 PR> because they might disagree.

Mine always disagree but the host is already booting so I never have to run
lilo there and DEFINETLY don't want it to overwrite the mbr of it's booted
drive.

 PR> But it sure looks like something's
 PR> wierd about running lilo in the chroot/target environment.

You have to mount /proc in the chrooted enviroment (2.4 kernels) else the root
file system there cannot see any drives, not even the one it is residing on.

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

That shouldn't be.

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

An older knoppix?  Seems to me knoppix is using 2.6 kernels lately and is even
more bloated (DVD).  They lost me on CD's nevermind DVD's.

 PR> Yeah, but I think you're in something of the same pickle I'm in,
 PR> except in reverse.  As long as it works, you just go on.

Something like that.  However I always have an issue with scripting in
something that isn't static.  I've gone from flashdisks that are ide, usb, and
pcmcia mounted so they are seldom the same from install to install.  I have a
generic lilo.conf for the occasion that I hand edit to suit the target as well
as the host.  In the case of the 64-bit machine the host and the target are the
same machine BUT the targetted disk on the host is apt to change on the next
boot so the initrd method is preferrable.

 PR> should, though I can get a bootable disk out of it.  I'm just NOT
 PR> going forward until I get the script working.

And then you'll upgrade and start the process all over again.  ;-)

I know.

Life is good,
Maurice

--- Msged/LNX 6.2.0
 * Origin: The Pointy Stick Society XVIII - Don't know what I want (1:140/13.1)