Thanks to everyone who responded. My original problem was that after performing
the installupdate from 4.0B to 4.0D, the device names of most of the disks had
changed. The original post was:
>Upon reboot, I notice that it has completely screwed up where it thinks
>all of the disks are. It understands that the system disk is /dev/rz0,
>and it has these partitions correct. However, what used to be /dev/rz1 is
>now /dev/rz4, what used to be /dev/rz4 is not /dev/rz16, and so on and so
>on. Of course, many of these disks are partitioned differently, so it
>fails miserably on the filesystem check and won't reboot.
I realize now that in my haste (i.e. PANIC) to get the system back up, I was not
thinking clearly, and of course several of you noted that it is impossible to
have /dev/rz4 become /dev/rz16. I had just made these up as an example without
thinking first about what the possibilities were. Sorry about that.
Robert Mulley wrote:
>I'd be thinking along the lines of kernel bus renumbering. If somebody had
>changed the 4.0B kernel to recognise the scsi busses where different
>numbers (e.g. scsi1 remapped to scsi3 etc...). This wouldn't explain why
>rz1 is now rz4, so I don't know what could have caused that. If rz1 had
>actually become rz9 then my solution would apply. Just giving you my first
>thought on the matter.
This is exactly what happened. After the upgrade, scsi bus 1 was scsi bus 2,
and scsi bus 2 had become scsi bus 1. Fortunately, scsi bus 0 had remained
where it was, so at least the system disk (rz0) was in the same place. The
effect was that all of the rz8 through rz15 had become rz16 through rz23, and
all of the rz16 through rz23 had become rz8 through rz15. For the uninitiated,
like me, for example, I later read in the documentation that the device number
is given by (8 * bus number) + unit number.
Why did this happen?
Franc Carter explains why:
>You possible have a problem that I encountered a while ago related to
>the way the the generic kernel names the scsi controllers it finds. THe
>generic kernel numbers the scsi controller in linear order from pci slot 0
>to pci slot N. I had added a scsi controller into a vacant slot between
>other cards - using the default kernel reconfig (using sizer) this changes the
>scsi controller numbers of all the controllers 'above' the added one. Because
>I didn't want to re configure all the filesystems and mount points i.e
>hand hacked the config file to put the new controller at the next available
>number - this turned out to be a bad idea as the generic kernel numbers them
>differently, which is really annoying if /usr/var is on one the disks that
>changes name as was my case.
Fortunately, I did manage to fix the problem. Once I found out how to do it, it
was not that bad.
Tom Blinn explained how to do it:
>In any case, fix your /etc/fstab to correspond to where the disks have
>been found by the update procedure, and then reboot. You can edit the
>/etc/fstab file using the "ed" editor, but you may need to mount -u /
>or use some other method to get the root file system mounted so you can
>edit files in it.
I rebooted in single user mode. Then, I did a mount -u / as suggested to mount
the root file system so that it was writeable. Then, I used the "ed" editor (Oh
my God, what an experience this was !!) to change the fstab file. After this,
everything worked just fine.
Thanks again for the help, to all who responded.
Cheers,
Ed.
Received on Wed Jan 19 2000 - 16:34:56 NZDT