Very Computer

Hi

I'm thinking of getting a bigger hard disk, although its not urgent yet.
I'll explain my setup first:

hda:
-------------
MBR: LILO (I know it could be in the extended partition, but it works
here)
-------------
hda1: C: drive (windoze 95) (active)
-------------
hda2: extended partition
 |
 +- hda5: D: drive (windoze 95)

hdc:
-------------
hdc1: extended partition
 |
 +- hdc5: root filesystem (ext2)
 +- hdc6-8: swap
 +- hdc9: ext2

hdd: CD-ROM

Now for the actual change, I assume I could temporarily take out the
stiffy drive, mount the new hard drive there as hdb, then copy the
entire filesystem across using cp -ar (I think that takes care of
symlinks, fifos, devices etc; please tell me if I'm wrong!).

To recreate the LILO map I'd just rerun /sbin/lilo, but with a chroot to
the mount point of the new filesystem (I think lilo has an option for
that). This part I'm a bit worried about, because lilo.conf specifies
hdc5, but the images on hdb which will only become hdc on the next boot.
Will it take the offset of the image in hdb and then look for it on hdc
on the next boot?

Then I'd take out the old hdc and put the new one in. Oh yes, I'd have
to modify fstab a bit, because I might move stuff like swaps around a
bit, maybe give a bit of the drive to DOS.

If anybody can confirm that this procedure will work, or won't work, I'd
appreciate an email.

I have one other concern: The disk is likely to have more than 1024
cylinders, which the LILO docs say can be a problem. I don't really
understand them, but it seems to me that there are 3 potential problem
areas:

the BIOS
LILO
FDISK

The BIOS I will check on with a dealer, but I need to know about LILO
and FDISK. If it helps, I am using LILO ver 19 and fdisk ver 2.1

Thanks a lot
Bruce

Use tar rather than cp. cp won't copy a symbolic link, it copies the
thing linked to instead.
tar to the standard output and pipe this into another tar to untar
everything. Or look at cpio.

Quote:

> To recreate the LILO map I'd just rerun /sbin/lilo, but with a chroot to
> the mount point of the new filesystem (I think lilo has an option for
> that). This part I'm a bit worried about, because lilo.conf specifies
> hdc5, but the images on hdb which will only become hdc on the next boot.
> Will it take the offset of the image in hdb and then look for it on hdc
> on the next boot?

Quote:> Then I'd take out the old hdc and put the new one in. Oh yes, I'd have
> to modify fstab a bit, because I might move stuff like swaps around a
> bit, maybe give a bit of the drive to DOS.

> If anybody can confirm that this procedure will work, or won't work, I'd
> appreciate an email.

> I have one other concern: The disk is likely to have more than 1024
> cylinders, which the LILO docs say can be a problem. I don't really
> understand them, but it seems to me that there are 3 potential problem
> areas:

The BIOS and also disk filesystems based on ms-dos (e.g. win 95's
vfat16) can only count cylinders up to 1023. So you can only boot from
or create dos/w95 partitions in that range.

Linux can count to larger numbers. You can create linux partitions
beyond the 1023rd cylinder. You can do any of these things:

Create a small (<504MB)  dos/w95 partition on the new disk first,
preferably a primary partition so that dos/w95 doesn't even have to
think beyond 10 bits (note this will become D: automatically). Create
your linux partitions afterwards beyond this.

Enable "Large mode" remaping in your bios. This halves the number of
cylinders and doubles the number of heads (on my machine anyway). Now
you can create a reasonable dos/w95 partition of up to 1000MB and use
the rest of the disk (still cylinders > 1023) for linux. Again make the
dos partition primary and it will magically be D: Again do the dos/w95
partition first so it can grab the low numbered cylinders.

Enable LBA remapping in your bios - this rempas all of the disk into
cylinders numbered less than 1023 by having a ridiculous number of
heads, e.g. 255. Avoid doing this as it is wasteful for two reasons: 1)
The size of the disk will be rounded down to achieve the remapping. 2)
Dos compatibility requires that each partition start with a few k of
info written in an otherwise empty cylinder - each cylinder is now
several MB of storage.

A few other things I found:

The partition table keeps the chs info. Linux and OS/2 fdisk will not
change it. So if you try one mapping and then select another, these two
fdisks will always complain that the partition table is wrong. dos 6.2
and dos5 (and presumably earlier) fdisk will write the mapped chs into
the table if necessary and this fdisk can be used to rewrite the table
by creating a small partition and deleting it again.

Before changing the mapping, remove all existing partitions.

Dos fdisk cannot remove non dos partitions.

Unfixed OS/2 warp 3.0 fdisk cannot cope with a mapping containing 255
heads.

Some versions of linux fdisk are more reliable than cfdisk.

The new big disk soon fills up :-)
Andrew

: I have one other concern: The disk is likely to have more than 1024
: cylinders, which the LILO docs say can be a problem. I don't really
: understand them, but it seems to me that there are 3 potential problem
: areas:

I've not found this to be a problem if I use LBA mode (makes the drive
look like it has fewer than 1024 cylinders), or if I locate the root
partition entirely below 1024, and load LILO on the MBR.

Surely there are other issues as well, but I've never had any problems
with large disks using either of these methods.

=================== http://www.iquest.net/~jbuchana ======================
I've been higher than stardust, I've been seen upon the sun.
I used to count in millions then, now I only count in ones.
 -Ronnie James Dio
==================== http://hybiss.delcoelect.com ========================