Re: newfs seems stuck in loop

[Johnny Billquist <bqt%softjar.se@localhost>]

Johnny Billquist wrote:
> Carl Lowenstein wrote:
> > On Sat, May 1, 2010 at 3:08 PM, Rhialto <rhialto%falu.nl@localhost> wrote:
> > > I am trying to install a recently updated tree (crosscompiled on amd64)
> > > and chose my "new" 2 GB scsi disk (a HP OEM disk from Seagate). My VAX
> > > is a headless VAXstation 3100 with 32 MB RAM.
> > >
> > > When sysinst got to newfs'ing the /home partition, it seemed to do its
> > > work, but then it got into an infinite loop, eating CPU user time.
> > >
> > > (all retyped by hand:)
> > >
> > > Command: /sbin/newfs -V2 -O 1 -b 16384 -f 2048 /dev/rsd0e
> > >
> > > /dev/rsd0e: 1306.6MB (2676004 sectors) block size 16384, fragment 
> > > size 2048
> > > using 7 cylinder groups of 186.67MB, 11947 blks, 23552 inodes.
> > > .............................................................................. 
> > >
> > > load: 1.08  cmd: newfs 22 [runnable] 2615.23u 3.61s 99% 876k
> > >
> > > The system time doesn't seem to increase.
> > >
> > > I interrupted it after the time shown. I hoped it had really done its
> > > work, but fsck could not find the superblock. When I retried the command
> > > from the shell, it printed the same, and 7 numbers followed by commas
> > > (those are the superblock numbers, right?) I didn't test if the comma
> > > after number #7 meant it wanted to print another one, which may explain
> > > the loop?
> >
> > This is a real hardware VAXstation, right.  Maybe it has a really old
> > SCSI controller that uses the 6-byte command set and can not address
> > beyond 1GB.   Or rather disk addresses wrap around so that after 1GB
> > they over-write the beginning of the disk.
>
> The 6-byte limitation of old VAXstations is not a limitation of the 
> controller, but of the firmware in the boot monitor. Which means it's 
> only a problem for the booting.
> Once the OS driver takes over, it can use 8-byte disk block numbers.
>
> So, in short. No, this can not be the problem.

And, fyi: If you can make sure that the boot monitor will only access 
data in the first 1G of a disk, you can actually have a disk of any size 
also as the boot disk. And since Unix partitions the disk, all you need 
to do is make sure that the root partition (partition a) is less than 
1G, and you are home free.

It's a bigger problem with VMS, since f you have a larger disk, the OS 
image might be anywhere on that disk, meaning you cannot savelt use a 
larger disk as the boot disk for VMS.

        Johnny

--
Johnny Billquist                  || "I'm on a bus
                                  ||  on a psychedelic trip
email: bqt%softjar.se@localhost             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol