Dmitri.
Thanks much for taking the time to try to get me through this problem.
See below for individual responses.
Norm
----- Original Message -----
From: Dmitri A. Sergatskov <[EMAIL PROTECTED]>
To: Dresner, Norman A. <[EMAIL PROTECTED]>
Cc: 'RTLinux' <[EMAIL PROTECTED]>
Sent: Friday, March 23, 2001 3:24 PM
Subject: RE: [rtl] Problems Dual Booting (RT)Linux
> On Fri, 23 Mar 2001, Dresner, Norman A. wrote:
>
> > 1. I tried to create a common swap partition. But the new system
> > (RH 6.2/2.2.18) put a signature into the swap partition that's not
> > recognized by the old (RH5.2/2.0.26) system and consequently it has no
swap
> > space. That's not fatal but ... Of course I could repartition the new
HD
> > and create separate swap partitions for the two systems.
> >
>
> I believe that -- there is new type of swap partitions that would
> make available more than 128MB swaps. You still should be able to
> use old swap partitions with a new system. And if you really
> want you may force new swap partition be of the old type as well
> (which is probably OK if each of them < 128MB).
That slipped by me in the initial configuration. I should be able to
change the (64 MB) swap partition with fdisk back to the old type.
>
> > 2. The new system's root partition [the only partition on that HD]
> > isn't recognized by the old system and I can't mount the new root drive
onto
> > the old system at any mount point. That's not fatal either, but ...
The
> > old system's fdisk shows that the partition on the new disk is "Linux
> > Native" but mount simply complains:
> > wrong fs type, bad option, bad superblock ...
> > The problem is probably 'bad superblock."
> >
>
> This is very strange, I do not have problems mounting old (like RH4.2)
> linux ext2 partitions on recent systems (like RH7.0).
> It appears to me that mount misreads the filesystem type on that partition
> (or you make a mistake in fstab and specified say "vfat" instead of
> "ext2").
> Do you get the same error if you mount with all explicit options, i.e.:
>
> mount /old /dev/hdb1 -text2
>
> ?
>
Whoops, I obviously created a communications problem. I have no problem
mounting the old HD in the new system. It's the new HD that I can't mount
in the old system. The old system's fdisk indicates that the new partition
is ext2 but I can't mount it that way. And the new system's fdisk also
indicates ext2. I don't know what's wrong there, but it's more important to
mount the old disk in the new system than the opposite anyway so that's not
a major problem.
>
> > Also, it seems that when I run lilo in the new system its module-info
and
> > System.map files are used to create the "boot record" (?in the mbr?)
which
> > are wrong for the old system. It's impossible to modprobe or insmod
certain
> > modules in the old system because that. [There is NO per-image option
in
> > lilo.conf for either System.map or module-info.] Since one of the
modules
> > that I can't us is for the NIC, it cripples the old system.
> >
>
> I used to think that System.map should be in the same directory as a
> kernel image, but now I am in doubt...
Each system, in it's own /boot, has a System.map and module-info. But
from the behavior I've seen there has to be something else somewhere. I'm
going to have to read the lilo and boot documentation very carefully to see
what's going on.
>
> > Here's (the relevant portions of) my lilo.conf from the new system
which --
> > I think -- has exactly what you've suggested:
>
> ......
>
> >
> > image=/boot/RTzImage
> > label=rtlinux
> > initrd=/boot/initrd-2.2.14-5.0.img
> > read-only
> > root=/dev/hdc1
> > image=/boot/vmlinuz-2.0.36-0.7
>
> I suggested to keep old image with its relevant files (like System.map)
> in its own directory: /old/boot/vmlinuz-2.0.36-0.7
>
There's a /boot on each of the two hard disks. I also copied the system
image from the old system into the new /boot, but I have maintained them
separately.
> .......
>
> >
> > It's beginning to look like setting both systems up as /dev/hdb and
> > physically swapping HD's is going to be the only way to make this work.
> > Since I still have to support programs that use the old system, I'm open
to
> > all suggestions.
> >
>
> Well, if your "duty cycle" is large (i.e. you have to reboot every once in
> while) then re-linking System.map and re-running the lilo is an option
> (that is what I do). Otherwise you may want to ask in linux newsgroup
> for suggestions (comp.os.linux.development.kernel and comp.os.linux.setup
> seems to be the most relevant).
>
What's going to happen (for the foreseeable future) is that all new
programs will be written in the new system (with as much code reuse as
possible which is why I'm satisfied being able to mount the old disk in the
new system) and there are two categories of support activities for old
projects: (1) simple questions for which read access to the directories is
sufficient and (2, very rarely I hope) minor modifications to existing code.
When I get some time I'm going to get onto one of the setup newsgroups
and get a final answer but for now I think I can handle it with what I have.
> > Norm
>
> Sincerely,
>
> Dmitri.
>
> -- [rtl] ---
> To unsubscribe:
> echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
> echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
> --
> For more information on Real-Time Linux see:
> http://www.rtlinux.org/rtlinux/
>
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
--
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
