D. Allen [CGL]" <idallen@watcgl.waterloo.edu> (12/13/90)
I have two RA90 disks, one on each KDA50 controller in my 5400. The ROOT file system's kernel only finds the first controller, so the advanced installation never asks me to put anything on my second disk. Just to make sure it wasn't hardware, I copied the Ultrix 3.1C kernel over and booted it; yes, it found both controllers and both disks. Does this have something to do with the "floating" address space? Why did it work under Ultrix 3.1C? So unless someone has a clever thought, it looks as though I'll have to try to install the system on a single disk, make a 4.1 kernel that sees both disks, then redo the whole thing from scratch again using my own kernel in place of the installation one from the ROOT file. -- -IAN! (Ian! D. Allen) idallen@watcgl.uwaterloo.ca idallen@watcgl.waterloo.edu [129.97.128.64] Computer Graphics Lab/University of Waterloo/Ontario/Canada
alan@shodha.enet.dec.com ( Alan's Home for Wayward Notes File.) (12/13/90)
In article <1990Dec13.102115.12468@watcgl.waterloo.edu>, idallen@watcgl.waterloo.edu (Ian! D. Allen [CGL]) writes: > I have two RA90 disks, one on each KDA50 controller in my 5400. > The ROOT file system's kernel only finds the first controller, so the > advanced installation never asks me to put anything on my second disk. This is the expected behaviour and actually documented in the release novel. The installation kernel will only find the first Q-BUS/UNIBUS MSCP disk controller. > > Just to make sure it wasn't hardware, I copied the Ultrix 3.1C kernel > over and booted it; yes, it found both controllers and both disks. The kernel that gets built as the last step in the installation has everything found on it's behalf. > > Does this have something to do with the "floating" address space? Yes. > Why did it work under Ultrix 3.1C? Sitting here thinking about I'm not sure how it works. The 2nd phase of the installation uses the "generic" kernel. Somehow a program called sizer (that is probably undocumented) uses it to find every supported device ont he bus. How the generic kernel manages not to find I don't know, unless sizer does some serious magick. > > So unless someone has a clever thought, it looks as though I'll have to > try to install the system on a single disk, make a 4.1 kernel that sees > both disks, then redo the whole thing from scratch again using my own > kernel in place of the installation one from the ROOT file. Simple. Put the 2nd disk on the first controller. Then move it back when you're done. > -- > -IAN! (Ian! D. Allen) idallen@watcgl.uwaterloo.ca idallen@watcgl.waterloo.edu > [129.97.128.64] Computer Graphics Lab/University of Waterloo/Ontario/Canada -- Alan Rollow alan@nabeth.enet.dec.com
D. Allen [CGL]) (12/18/90)
> This is the expected behaviour and actually documented > in the release novel. The installation kernel will only > find the first Q-BUS/UNIBUS MSCP disk controller. I can't find the relevant section in the 4.1 release novel. Where? This is a step backwards. The 3.1C genvmunix could find everything; the 4.1 genvmunix cannot. Someone suggested that the section dealing with sizer no longer assigning disks to the second controller in the floating address space was relevant, but I think not. The 4.1 genvmunix doesn't find the second controller *at all*; this has nothing to do with sizer or bulding the config file later. The 4.1 genvmunix only finds one controller and disk when it boots, and the advanced installation asks you all those questions about where you want to put things without knowing about the second disk. > Simple. Put the 2nd disk on the first controller. Then move > it back when you're done. Not quite so simple. The first controller is the built-in one on the 5400. To get at it, you have to do some serious disassembly of the front panel. No fun at all. I elected to do the single-disk minimal installation, built a proper kernel, moved stuff to where I really wanted it, then did the rest of the setld subsets. What I'm really proud of is that I did the over-the-net install from an Ultrix 3.1C machine. I figured out what had to be done to make the new 4.1 RIS stuff coexist with the old 3.x RIS stuff, so I can boot either version of Ultrix from the same RIS server (running Ultrix 3.1C). Any time I read something that says "this can't be done", I just get that urge to prove them wrong... -- -IAN! (Ian! D. Allen) idallen@watcgl.uwaterloo.ca idallen@watcgl.waterloo.edu [129.97.128.64] Computer Graphics Lab/University of Waterloo/Ontario/Canada
alan@shodha.enet.dec.com ( Alan's Home for Wayward Notes File.) (12/19/90)
In article <1990Dec17.211102.5978@watcgl.waterloo.edu}, idallen@watcgl.waterloo.edu (Ian! D. Allen [CGL]) writes: } > This is the expected behaviour and actually documented } > in the release novel. The installation kernel will only } > find the first Q-BUS/UNIBUS MSCP disk controller. } } I can't find the relevant section in the 4.1 release novel. Where? Section 1.4.4 "System Configuration When Disk Controllers Are in Floating Address Space", page 1-20. } } This is a step backwards. The 3.1C genvmunix could find everything; } the 4.1 genvmunix cannot. } } Someone suggested that the section dealing with sizer no longer assigning } disks to the second controller in the floating address space was } relevant, but I think not. The 4.1 genvmunix doesn't find the second } controller *at all*; this has nothing to do with sizer or bulding the } config file later. The 4.1 genvmunix only finds one controller and disk } when it boots, and the advanced installation asks you all those questions } about where you want to put things without knowing about the second disk. Not finding disks on the second controller is what we seem to call a restriction. Not finding the 2nd controller may be a bug. } -- } -IAN! (Ian! D. Allen) idallen@watcgl.uwaterloo.ca idallen@watcgl.waterloo.edu } [129.97.128.64] Computer Graphics Lab/University of Waterloo/Ontario/Canada -- Alan Rollow alan@nabeth.enet.dec.com