[comp.unix.i386] Another fdisk partition for 386/ix.

jonm@syma.sussex.ac.uk (Jonathan Meyer) (11/13/89)

I am sure that many of you have been in this situation at some time or
another:
    When I installed 386/ix, I made a 32MB DOS partition, and left the
    rest of the disk for unix (73MB). Now I find I need a little more
    space for UNIX (of course :-) and so I thought I would reduce the
    size of the DOS partition to 15MB, and use the other 17MB for unix.
    Easy, I thought: backup the DOS partiton, run 386/ix fdisk to create
    two new partitions where once there was only one DOS partiton, use
    DOS format to prepare the new 15MB partition, and use the unix equivelant
    to prepare the new 17MB partition, modify the relevant init files...
    bingo!

But what is the unix equivelant? I can find documentation relating to adding a
new disk, or to modifying the 386/ix partitions (0s1, 0s2 etc), but not to add
a new fdisk partition (0p1, 0p2, etc).

I don't want to have to reformat and repartition the whole disk. Does anyone a
better solution? (can I use mkfsys etc?)

jon

(replies to jonm@uk.ac.sussex.syma please).

jrh@mustang.dell.com (jrh) (11/15/89)

386/ix has a 'fdisk' program to do this.  Be careful though, some versions
of this have a bug when using the percentage option when specifying partition
size.  This will cause the UNIX file system to get trashed when the DOS partition fills up because of a rounding error when the convert % to physical
cylinder numbers.

-------------------------------------------------------------------------
James R. Howard
!s: cs.utexas.edu!dell!mustang!jrh	

johnl@esegue.segue.boston.ma.us (John R. Levine) (11/16/89)

The 386/ix HPDD really expects only to find one Unix partition per disk.
I expect it wouldn't be too hard to trick fdisk into making another one,
but I'd be astonished if you could mount it sucessfully.  This isn't really
ISC's fault, as they inherited the layout scheme from AT&T.

-- 
John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 864 9650
johnl@esegue.segue.boston.ma.us, {ima|lotus|spdcc}!esegue!johnl
"Now, we are all jelly doughnuts."

mark@zok.UUCP (Mark W. Snitily) (11/17/89)

In article <1989Nov15.175055.913@esegue.segue.boston.ma.us> johnl@esegue.segue.boston.ma.us (John R. Levine) writes:
>The 386/ix HPDD really expects only to find one Unix partition per disk.
>I expect it wouldn't be too hard to trick fdisk into making another one,
>but I'd be astonished if you could mount it sucessfully.  This isn't really
>ISC's fault, as they inherited the layout scheme from AT&T.

Yes, it can be done.  Zok has a Maxtor 4380E (~320MB) disk.  Originally
I created a 100MB partition for DOS (4.0) and gave the rest to 386/ix.
After installing VP/ix (DOS 3.3), it was obvious that VP/ix couldn't
access the DOS 4.0 partition so I went back and created a 32MB DOS
partition and a spare 68MB partition.  My goal was to use the 68MBs
for news -- which is exactly what I'm using it for.

I forget the details and my notes are sketchy, but here are some
pointers.  [Note: I'm not claiming that this is the "right" way to do
it, but it's worked for me...]

1)  When I split the 100MB partition, I believe that I manually edited
the partition table (using DOS's Norton Utilities) so that the 386/ix
partition was the third entry.  (Don't think this is mandatory, but
it kept things in a logical order.  It does affect the physical partition
device name though.  Since the spare 68MB partition was the 2nd entry
in the table, its device name was /dev/dsk/0p2.  If it was 3rd, it would
have been /dev/dsk/0p3.)

2)  You need to format the partition.  Don't have the exact command
in my notes, think it's simply "format <devicename>".  Believe you can
find an example by looking in the /usr/admin scripts for adding a second
disk.

3)  Make a file system.  [From this point on I kept notes.]  Since I
was going to use it for news, I wanted to use 512 byte blocks.  Couldn't
get it to work, (ended up using 1K blocks).  Believe it created the file
system okay, but couldn't mount it.  Anyone know what the -f name of a
512 byte file system is for the mount command?  Note: I was bitten by
the missing i-node bug in the past, so I specified the max number of
i-nodes (65535).  Here's the exact command I used, obviously your
parameters will differ:

         mkfs /dev/dsk/0p2 140400:65535 1 540 -b 1024

This is what the command printed out:

         Mkfs: /dev/dsk/0p2?
         (DEL if wrong)

         bytes per logical block = 1024
         total logical blocks = 70200
         total inodes = 65488
         gap (physical blocks) = 1
         cylinder size (physical blocks) = 540
         mkfs: Available blocks = 66104

4) At this point you can mount your file system.  Since I wanted my
news to be located in /usr/spool/news, I created that directory and then
did:
         mount -fS51K /dev/dsk/0p2 /usr/spool/news

5) There was some type of complaint (forget what the message was) about
the partition's label.  (Believe the label needs to match the name of
the directory.)  Regardless, this is how I got it to stop complaining.

   First, unmount it with:
         umount /dev/dsk/0p2

   Then label it with:
         labelit /dev/rdsk/0p2 news dpart2

   (The "dpart2" was arbitrary.  The "news" was important.)

6)  All done.  If you want to have it automatically mounted when you boot
add an entry in /etc/fstab.  Here's my fstab:

         /dev/dsk/0s3 /usr
         /dev/dsk/0s4 /usr2
         /dev/dsk/0p1 /dos DOS
         /dev/dsk/0p2 /usr/spool/news

Note: The above fstab worked fine under 2.0.1, but after upgrading to
2.0.2 ISC decided not to allow DOS partitions to be mounted from fstab.
(Asked them about, yes it was intentional, but I still don't understand
their reasoning.)  Had to make a trivial change in my 2.0.2 version of
/etc/mountall to allow DOS entries.

The only item that still has me puzzled is the lost+found directory, it
was not created.  Anyone know how/when this directory is normally created?

Hope this helps...

Mark W. Snitily                 Consulting Services:
894 Brookgrove Lane             Graphics, Operating Systems, Compilers
Cupertino, CA 95014             (408) 252-0456
mark@zok.uucp
...!{amdcad,ardent,athertn,claris,daisy,limbo,mips,sgi,sjsca4,voder}!zok!mark

swatt@cup.portal.com (Steven Edward Watt) (11/18/89)

Mark@zok.UUCP writes:
>[lotsa stuff deleted!]
>The only item that still has me puzzled is the lost+found directory, it
>was not created.  Anyone know how/when this directory is normally created?
>
>Hope this helps...
>
>Mark W. Snitily                 Consulting Services:
>894 Brookgrove Lane             Graphics, Operating Systems, Compilers
>Cupertino, CA 95014             (408) 252-0456
>mark@zok.uucp
>...!{amdcad,ardent,athertn,claris,daisy,limbo,mips,sgi,sjsca4,voder}!zok!mark
  In the SCO implementation, the lost+found directory is created in the mkdev
script for file systems.  It uses a nested for loop to generate some large
number of files, and then deletes them.  I probably shouldn't post the source..
.
they might get mad.  :-)

Steve Watt
swatt@cup.portal.com  ...!ucbvax!sun!portal!cup.portal.com!swatt

lee@sq.sq.com (Liam R. E. Quin) (11/19/89)

In article <4244@dell.dell.com> jrh@mustang.dell.com (jrh) writes:
>386/ix has a 'fdisk' program to do this.

It seems worth pointing out that you have to arrange for Unix to do
something with the new partition.
Remember the "fdisk" partition number, so that you can refer to the
partition from Unix.  You can then use mkfs and mount, and can arrange
for the new partition to be mounted automatically.

Again, remember to specify the end cylinder (not a percentage), and
to ensure that the end cylinder is one less thatn the start of the
next partition!  (fdisk shouldn't let you create overlapping partitions,
but it does...).

Lee
-- 
Liam R. Quin, Unixsys (UK) Ltd [note: not an employee of "sq" - a visitor!]
lee@sq.com (Whilst visiting Canada from England)
lee@anduk.co.uk (Upon my return to England at Christmas)

jrh@mustang.dell.com (jrh) (11/20/89)

The /lost+found directory is probably there when you originally install, the
problem is the shell script /etc/cleanup has a nasty bug in it.  They have
a line which reads:

find /lost+found -mtime 14 -exec rm -rf {} \; > /dev/null 2>&1

This is loaded in crontab to be executed every Sunday morning by default.
The problem is, if /lost+found has not had it's modification time changed 
in 14 days, the entire subdirectory is removed.

to fix the problem, just do the following:

# mkdir /lost+found
# cd /lost+found
# cp /usr/bin/* /lost+found
# rm *
# cd /
# ls -al

The /lost+found directory should be there, with room for a relatively large
number of files.  The script that creates the file makes it about 1360, 
anything there or above should be fine.

Next, modify /etc/cleanup to fix the problem permanently.  The easiest is
to insert a line with:

touch /lost+found

before the 'find' command above, should clear it up...




-------------------------------------------------------------------------
James R. Howard
!s: cs.utexas.edu!dell!mustang!jrh	

cpcahil@virtech.uucp (Conor P. Cahill) (11/20/89)

In article <4339@dell.dell.com>, jrh@mustang.dell.com (jrh) writes:
> to fix the problem, just do the following:
> 
> # mkdir /lost+found
> # cd /lost+found
> # cp /usr/bin/* /lost+found
> # rm *
> # cd /
> # ls -al

I wouldn't recommend doing this (especially because of the use of the "rm *" 
by root).  Copying all files from /usr/bin to any lost+found will take
a long time and can run the file system out of space.  A faster mechanism
would be to put the following into a shell file:

	mkdir lost+found
	cd lost+found
	for i in 1 2 3 4 5 6 7 8 9 0
	do
		for j in 1 2 3 4 5 6 7 8 9 0
		do
			for k in 1 2 3 4 5
			do
				> $i$j$k
			done
		done
	done
	rm [0-9]*

NOTE-> I just typed that in off the top of my head, so there may be a typo.

This will always creat 500 slots in the directory and not use up any real
file system space while creating the slots.  The use of "for i in 1 2..." is
just to preclude the use of something like

	i=1;
	while [ i -lt 500 ]
	do
		> $i
		i=`expr $i + 1`
	done

which is much, much slower.



-- 
+-----------------------------------------------------------------------+
| Conor P. Cahill     uunet!virtech!cpcahil      	703-430-9247	!
| Virtual Technologies Inc.,    P. O. Box 876,   Sterling, VA 22170     |
+-----------------------------------------------------------------------+