I got some time this weekend to try to initialize a new Quantum Atlas 10K3 36GB SCSI disk so that I can copy all my files to it and use it as a larger main boot disk in a Pentium III machine that, at the moment, runs NEXTSTEP 3.3 on an 80 GB EIDE disk, which is limited to 8GB for NEXTSTEP. I created a disktab for my Quantum Atlas so that I could have 8 slices of 2GB each, just as I do on my IBM-Seagate ST973401LC 73 GB SCSI disks. The disk is attached to an Adaptec 2940UW controller.
I've run into a curious problem that I havn't been able to solve: I can run fdisk on the Quantum Atlas and create a NEXTSTEP partition that is bigger than 16GB in size (using the -useAllSectors flag) but then when I run /usr/etc/disk (with the -u -i flags) on /dev/rsd0h, it seems to work fine, but the partition information seems to be destroyed by creating the filesystem and though I can mount /dev/sd0b through /dev/sd0g, I cannot mount /dev/sd0a or /dev/sd0h. When I try to mount /dev/sd0a or /dev/sd0h, I get the error message:
# mount /dev/sd0a /Disk
mount: /dev/sd0a on /Disk: Invalid argument
mount: giving up on:
/Disk
I've tried using the /usr/etc/disk program from user patch 4 for OPENSTEP 4.2, I've tried turning off extended DOS translation for disks > 1GB in the Adaptec 2940UW BIOS, I've tried low-level formatting with the 2940UW BIOS, I've upgraded the 2940UW BIOS from version 2.57.2 to 3.10.0, I've tried low-level formatting from NEXTSTEP by using /usr/etc/sdform or by using the -F flag on /usr/etc/disk (both of which give a kernel panic) but nothing so far helps. My disktab seems to be correct. There seem to be very few levers left that I can pull. There aren't many low-level NEXTSTEP disk utilities or other tools to attack this problem. I do have a 3rd party tool /usr/etc/sdformat that I've forgotten where it came from that I haven't yet used, but I don't have any other ideas at the moment.
If anyone has seen this problem before and knows what to do about it, or even has an idea that I haven't considered, I'd appreciate the help!
I tried to find out a bit more about sdformat and ran across a post by its author Brian Willoughby,
https://ftp.nice.ch/peanuts/GeneralData/Usenet/news/1997/_Sys-08.html. It might be a lost cause as Brian says that he had heard that Quantum's SCSI drives over 500 MB have a proprietary way of responding to commands on the SCSI bus and don't like to share it with other drives. This proprietary drive electronics may mean that I'm just out of luck.
/dev/rsdxh /dev/rhdxh (where x = 0 or greater) is the full hard drive which is why you can't use it is a partition. Unfortunately I can't provide a reference. Is that what you were asking?
No, that's not primarily what I'm asking. The two things that are vexing me right now are (1) that creating an MBR partition with
/usr/etc/fdisk and then creating the filesystems with
/usr/etc/disk destroys the MBR partitioning (which shows up if I run
/usr/etc/fdisk again: the whole disk is shown as free space), and (2) I cannot mount
/dev/sd0a, but I can mount the other partitions (except for
/dev/sd0h, which
is a valid partition according to the
disk command when used interactively--running
disk and then printing the label shows all eight slices. NeXTanswer
1849 Adding Disks concurs, showing that various entries in
/etc/disktab can have 'partitions' (i.e., slices) a-h. Of course, there could be a bug in
/usr/etc/disk and the NeXTanswer could be wrong. (I tried to attach a PDF of my modified NeXTanswer 1849, but I got errors from the server when I tried, so I've put it at
https://people.hws.edu/tjallen/1849_Adding_Disks.pdf .)
I also had understood that
/dev/{,r}sd0h was the whole disk since it was the argument for the
fdisk and
disk commands, but using any of the slices with those commands seems to work just the same as a stand-in for the whole disk (edit: I checked again and
fdisk only takes
/dev/rsd0h and
disk does seem to take any slice as an argument, but will throw an error if you try to do anything interactively), while
/usr/etc/mkfs, which takes slices as arguments, seems perfectly happy to make a 2GB filesystem on /dev/rsd0h, so now I'm not so sure. I will try again with only seven slices to see what happens (edit: It makes no difference.). Unfortunately, there was little guidance from NeXT on this, probably because at the time even a 1GB SCSI disk was about $1000 (that's what I paid for my first disk in 1993) so no one could afford a disk bigger than 16 GB then, and now, some thirty years later, what little guidance there was is gone or very hard to find. (Remembering those prices now, I'm amazed that today I can get a 16 TB disk for around $400, when it would have been around $16,000,000 in 1993 if it were to have existed at all!)
Incidentally, I tried an unused one of the 2.5" IBM-ESXS ST973401LC 73 GB SCSI disks again as well as a disk not made by Quantum and all of them show this annoying behavior now, so it's got to be something with my hardware and not necessarily the Quantum Atlas disk. I'm going to have to try with a different NEXTSTEP x86 machine to see if that changes anything. (I have eight such machines, all the way from a 486, Pentium, Pentium Pro, and PII, to several PIII machines.)
An update: I changed the value of the front porch from 320 to 640 in my disktab for the 73 GB IBM-ESXS ST973401LC disk and now after initializing with /usr/etc/disk, I can mount /dev/sd0a, but still cannot mount /dev/sd0h and running /usr/etc/disk still wipes out the MBR partition. I've been playing with other undocumented parameters in the disktab, but so far no luck on either problem. It'd be nice to know how the disk is laid out physically as it might explain why the MBR partition table gets zeroed out.
I don't think this is going to help you but
Darwin 0.3 source code for:
EDIT: Probably means nothing but from:
https://github.com/evolver56k/Darwin-0.3/blob/745305afd074437bb660bcf02146a2754eeef5ae/diskdev_cmds-1/disk.tproj/disk.c#L988 The
int init() loop only goes from partitions
a to
g so maybe you can not use partition
h? I thought
@Apple2guy would post some hints and tips about
/etc/disktabfor (partition = 'a'; partition < 'h'; partition++) {
sprintf(buff, "%s/%s%c", fn, baseName + 1, partition);
if (MountPoint(buff)) {
bomb(S_NEVER, "The device is mounted as a filesystem and "
"can't be initialized.\n");
}
}
Thanks for that find, pTeK. It's certainly possible that /dev/sd0h is usable as a filesystem in BSD4.3, but in NEXTSTEP/Darwin it may not be, for some reason. If that's the case, I can't complain since 14 GB is still much more than 8 GB on a disk. What bothers me now is why /usr/etc/disk kills the MBR partitioning and why I need to change the front porch value to something other than what NeXTanswer 1849 states. I've just copied over the other OSs on my EIDE disk to a SCSI disk and now I need to test to see if running lilo has trashed my NEXTSTEP partition.
Yup, my NEXTSTEP MBR partition shows up when running fdisk on /dev/rsd0h, but none of the slices will mount. The NEXTSTEP filesystems must have been hosed by running lilo under Slackware. Nothing like this has ever happened with an EIDE disk, nor on any other SCSI disk. I'm starting to suspect a hardware issue.
It turns out that the disk label was trashed, not the filesystems. I ran /usr/etc/disk interactively and re-wrote the label. I was able to run fsck on /dev/sd0a and found no errors. It now mounts correctly. The MBR partitioning was also apparently not damaged by writing the disk label. I wish I understood where the disk label is on the disk. Very puzzling.
By the way, here's what disk says about my disk:
(this is a different SCSI disk from the Quantum Atlas)
island ROOT [18]# disk -u /dev/rsd0h
disk name: COMPAQ BD07265A22 3B003
disk type: fixed_rw_scsi
Disk utility
disk> la
label information: print, write? p
current label information on disk:
disk label version #3
disk label: Disk
disk name: BD07265A22
disk type: fixed_rw_scsi
ncyls 28004 ntrack 40 nsect 127 rpm 10000
sector_size 512 front_porch 640 back_porch 0
ngroups 0 ag_size 0 ag_alts 0 ag_off 0
boot blocks: #1 at 64 #2 at 192
bootfile: mach_kernel
host name: island
root partition: a
part base size bsize fsize cpg density minfree newfs optim automount type
a 0 4194304 8192 1024 4 4096 10% yes time yes 4.3BSD
b 4194304 4194304 8192 1024 4 4096 10% yes time yes 4.3BSD
c 8388608 4194304 8192 1024 4 4096 10% yes time yes 4.3BSD
d 12582912 4194304 8192 1024 4 4096 10% yes time yes 4.3BSD
e 16777216 4194304 8192 1024 4 4096 10% yes time yes 4.3BSD
f 20971520 4194304 8192 1024 4 4096 10% yes time yes 4.3BSD
g 25165824 4194304 8192 1024 4 4096 10% yes time yes 4.3BSD
h 29360128 4194304 8192 1024 4 4096 10% yes time yes 4.3BSD
disk>
Quote from: tjallen on January 14, 2025, 12:16:23 PMI wish I understood where the disk label is on the disk. Very puzzling.
I think the
disk label could be that the name that shows up when booting the system and when using the command
scsimodes and
idemodes (With OpenStep 4.2 only or you can compile the source for NS3.3) ??
We (
@Apple2guy and I) were talking about it in this thread
https://www.nextcomputers.org/forums/index.php?topic=5786Those commands in post #9 above were they done from NeXT or from Linux/*BSD ?
In post #9, I ran the command /usr/etc/disk from NEXTSTEP.
Sadly, Linux can only see the first slice of a NEXTSTEP partition, which makes it impossible to copy files from a home directory in /User on NEXTSTEP to Linux if /User is not on /dev/sd0a on NEXTSTEP.
I had read the thread with Apple2guy on IDE disks and disktabs for them, but I've never needed a disktab for an IDE/EIDE disk because /usr/etc/disk has always given me excellent slices: usually I get four slices with as many as possible being the maximum size of 2 GB. So for the last twenty years or so I've been using 80 GB EIDE disks and putting NEXTSTEP, some form of Windows (usually W2K)--I have a small number programs for some hardware devices, such as mechanical watch timers and flash utilities, that are Windows-only, and Slackware on the disks, and then using lilo from Slackware to write the MBR to boot all of them. I get four 2 GB slices for NEXTSTEP because the EIDE driver can't see more than 8GB of an EIDE disk, but I've been getting greedy and wanting to have more than four slices, which is why I'm playing with SCSI disks, but that means making a disktab and, now, battling strange fdisk & disk problems.
I suppose that I could try OPENSTEP 4.2 on these disks, but NEXTSTEP 3.3 works fine for me.
Openstep only supports 7 slices. The last slice h refers to the raw device, ie the whole disk. So when it formats sd0g you are wiping out sd0a. I learned this painfully.. wiped out several installs.
Well, apparently on NEXTSTEP I can format /dev/sd0a through /dev/sd0h and the worst that happens is that the MBR and the disklabel get messed up, but if I fix the disklabel, I can mount /dev/sd0a through /dev/sd0g. It seems that going to OPENSTEP would be worse than staying on NEXTSTEP.
Quote from: tjallen on January 15, 2025, 11:01:22 AMSadly, Linux can only see the first slice of a NEXTSTEP partition, which makes it impossible to copy files from a home directory in /User on NEXTSTEP to Linux if /User is not on /dev/sd0a on NEXTSTEP.
Oh wow so on a partition manager it shows 7x2GB partitions with the first one being valid or 1x2GB and 1x12GB unknown partition?
Quote from: tjallen on January 15, 2025, 11:01:22 AMI suppose that I could try OPENSTEP 4.2 on these disks, but NEXTSTEP 3.3 works fine for me.
NS3.3 gang here too
Under Linux, cfdisk shows the full sized partition, since it's defined in the MBR, but when you mount that partition, only the first slice is mounted. There doesn't seem to be any way to access or mount any of the other slices.
NEXTSTEP can be installed on Intel machines and will run fine even if you don't run fdisk in NEXTSTEP or even if you don't partition the disk at all. As the man page for fdisk under NEXTSTEP says about logical partitions, "fdisk knows nothing about logical partitions, which are sub-partitions of an extended partition. Nor perhaps should it, as these are gross kludges from the Evil OS Company of the North." I think that NeXT's view more generally is that they'll get along with MBR primary partitions to be a good citizen, but they also don't care if there is no MBR partition.
Quote from: tjallen on January 16, 2025, 01:33:43 PMUnder Linux, cfdisk shows the full sized partition, since it's defined in the MBR, but when you mount that partition, only the first slice is mounted. There doesn't seem to be any way to access or mount any of the other slices.
If you had a disk image, I think you could identify the place where one of the other slices begins and use the offset argument to the loopback mounting method to point to the beginning of the slice of choice.
For a real disk, I don't know if you can use the loopback device with a special file (a block device file in this case), but if you can, then you might be able to use the same offset trick?
Quote from: tjallen on January 15, 2025, 11:51:04 AMWell, apparently on NEXTSTEP I can format /dev/sd0a through /dev/sd0h and the worst that happens is that the MBR and the disklabel get messed up, but if I fix the disklabel, I can mount /dev/sd0a through /dev/sd0g. It seems that going to OPENSTEP would be worse than staying on NEXTSTEP.
I tried formatting a atlas10k 36gb drive with 8 4gb slices (a-h). I get no errors during the formatting but cannot mount any partitions because it clobbers the disk label. I re wrote the disk label without reformatting and it still refuses to mount slice a. Ran fsck on the partition and it is missing the superblock.. so in openstep it seems when disk formats slice h it also somehow clobbers the first slice as well as the disk label/mbr area. but imho 7 4gb slices beats 2 4gb slices or 4 2gb slices on IDE.
Apple2guy,
Wow, thanks for doing that experiment! Did you have a disktab with a non-standard front porch, as I did? Here's my NEXTSTEP entry:
# 3.5" Quantum Atlas 10K3 Disks OEM for HP
#
# scsimodes /dev/rsd0a
# SCSI information for /dev/rsd0a
# Drive type: HP 36.4G ATLAS10K3_36_S
# 512 bytes per sector
# 579 sectors per track
# 4 tracks per cylinder
# 31022 cylinder per volume (including spare cylinders)
# 168 spare sectors per cylinder
# 83 alternate tracks per volume
ATLAS10K3|ATLAS10K3_36_S|HP 36.4G ATLAS10K3_36_S:\
:ty=fixed_rw_scsi:nc#31022:nt#4:ns#579:ss#512:rm#10000:\
:fp#640:bp#0:ng#0:gs#0:ga#0:ao#0:\
:os=mach_kernel:z0#64:z1#192:hn=island:ro=a:\
:pa#0:sa#4194304:ba#8192:fa#1024:ca#2:da#2048:ra#10:oa=time:\
:ia:ta=4.3BSD:aa:\
:pb#4194304:sb#4194304:bb#8192:fb#1024:cb#2:db#2048:rb#10:ob=time:\
:ib:tb=4.3BSD:ab:\
:pc#8388608:sc#4194304:bc#8192:fc#1024:cc#2:dc#2048:rc#10:oc=time:\
:ic:tc=4.3BSD:ac:\
:pd#12582912:sd#4194304:bd#8192:fd#1024:cd#2:dd#2048:rd#10:od=time:\
:id:td=4.3BSD:ad:\
:pe#16777216:se#4194304:be#8192:fe#1024:ce#2:de#2048:re#10:oe=time:\
:ie:te=4.3BSD:ae:\
:pf#20971520:sf#4194304:bf#8192:ff#1024:cf#2:df#2048:rf#10:of=time:\
:if:tf=4.3BSD:af:\
:pg#25165824:sg#4194304:bg#8192:fg#1024:cg#2:dg#2048:rg#10:og=time:\
:ig:tg=4.3BSD:ag:\
:ph#29360128:sh#4194304:bh#8192:fh#1024:ch#2:dh#2048:rh#10:oh=time:\
:ih:th=4.3BSD:ah:
QuoteATLAS|ATLAS10K3|ATLAS10K3-512:\
:ty=fixed_rw_scsi:nc#31022:nt#4:ns#579:ss#512:rm#10000:
:fp#320:bp#0:ng#0:gs#0:ga#0:ao#0:\
:os=mach_kernel:z0#64:z1:192:hn=mordor:ro=a:\
:pa#63:sa#8388608:ba#8192:fa#1024:ca#4:da#4096:ra#10:oa=time:\
:ia:ta=4.3BSD:aa:\
:pb#8388671:sb#8388608:bb#8192:fb#1024:cb#4:db#4096:rb#10:ob=time:\
:ib:tb=4.3BSD:ab:\
:pc#16777279:sc#8388608:bc#8192:fc#1024:cc#4:dc#4096:rc#10:oc=time:\
:ic:tc=4.3BSD:ac:\
:pd#25165887:sd#8388608:bd#8192:fd#1024:cd#4:dd#4096:rd#10:od=time:\
:id:td=4.3BSD:ad:\
:pe#33554495:se#8388608:be#8192:fe#1024:ce#4:de#4096:re#10:oe=time:\
:ie:te=4.3BSD:ae:\
:pf#41943103:sf#8388608:bf#8192:ff#1024:cf#4:df#4096:rf#10:of=time:\
:if:tf=4.3BSD:af:\
:pg#50331711:sg#8388608:bg#8192:fg#1024:cg#4:dg#4096:rg#10:og=time:\
:ig:tg=4.3BSD:ag:\
:ph#58720319:sh#8388608:bh#8192:fh#1024:ch#4:dh#4096:rh#10:oh=time:\
:ih:th=4.3BSD:ah:
/quote]
So I tried using your ftontporch of 640.
ATLASNS|ATLAS10K3_36_S|HP 36.4G ATLAS10K3_36_S:\
:ty=fixed_rw_scsi:nc3128:nt#4:ns#512:ss#512:rm#10000:\
:fp#640:bp#0:ng#0:gs#0:ga#0:ao#0:\
:os=mach_kernel:z0#64:z1#192:hn=island:ro=a:\
:pa#0:sa#8388608:ba#8192:fa#1024:ca#2:da#2048:ra#10:oa=time:\
:ia:ta=4.3BSD:aa:\
:pb#8388608:sb#8388608:bb#8192:fb#1024:cb#2:db#2048:rb#10:ob=time:\
:ib:tb=4.3BSD:ab:\
:pc#16777216:sc#8388608:bc#8192:fc#1024:cc#2:dc#2048:rc#10:oc=time:\
:ic:tc=4.3BSD:ac:\
:pd#25165824:sd#8388608:bd#8192:fd#1024:cd#2:dd#2048:rd#10:od=time:\
:id:td=4.3BSD:ad:\
:pe#33554432:se#8388608:be#8192:fe#1024:ce#2:de#2048:re#10:oe=time:\
:ie:te=4.3BSD:ae:\
:pf#41943040:sf#8388608:bf#8192:ff#1024:cf#2:df#2048:rf#10:of=time:\
:if:tf=4.3BSD:af:\
:pg#50331648:sg#8388608:bg#8192:fg#1024:cg#2:dg#2048:rg#10:og=time:\
:ig:tg=4.3BSD:ag:\
:ph#58720256:sh#8388608:bh#8192:fh#1024:ch#2:dh#2048:rh#10:oh=time:\
:ih:th=4.3BSD:ah:
It formats with no errors.
disk> label
label information: print, write? p
current label information on disk:
disk label version #3
disk label: test
disk name: ATLASNS
disk type: fixed_rw_scsi
ncyls -1 ntrack 4 nsect 512 rpm 10000
sector_size 512 front_porch 640 back_porch 0
ngroups 0 ag_size 0 ag_alts 0 ag_off 0
boot blocks: #1 at 64 #2 at 192
bootfile: mach_kernel
host name: peethree
root partition: a
part base size bsize fsize cpg density minfree newfs optim automount type
a 0 8388608 8192 1024 2 2048 10% yes time yes 4.3BSD
b 8388608 8388608 8192 1024 2 2048 10% yes time yes 4.3BSD
c 16777216 8388608 8192 1024 2 2048 10% yes time yes 4.3BSD
d 25165824 8388608 8192 1024 2 2048 10% yes time yes 4.3BSD
e 33554432 8388608 8192 1024 2 2048 10% yes time yes 4.3BSD
f 41943040 8388608 8192 1024 2 2048 10% yes time yes 4.3BSD
g 50331648 8388608 8192 1024 2 2048 10% yes time yes 4.3BSD
h 58720256 8388608 8192 1024 2 2048 10% yes time yes 4.3BSD
disk> i
DESTROYS ALL EXISTING DISK DATA -- really initialize? y
enter host name: peethree
enter disk label: testicle
writing disk label
Boot block is "/usr/standalone/i386/boot", ok? y
Writing /usr/standalone/i386/boot
Writing /usr/standalone/i386/boot1
creating new filesystem on /dev/rsd2a
/usr/etc/newfs -n -v /dev/rsd2a
/etc/mkfs /dev/rsd2a 8388608 512 4 8192 1024 2 10 166 2048 t
/dev/rsd2a: 8388608 sectors in 4096 cylinders of 4 tracks, 512 sectors
4096.0Mb in 2048 cyl groups (2 c/g, 2.00Mb/g, 896 i/g)
super-block backups (for fsck -b#) at:
32, 4640, 9248, 13856, 16416, 21024, 25632, 30240, 32800, 37408,
... 8355872, 8360480, 8365088, 8369696, 8372256, 8376864, 8381472, 8386080,
creating new filesystem on /dev/rsd2b
/usr/etc/newfs -n -v /dev/rsd2b
/etc/mkfs /dev/rsd2b 8388608 512 4 8192 1024 2 10 166 2048 t
/dev/rsd2b: 8388608 sectors in 4096 cylinders of 4 tracks, 512 sectors
4096.0Mb in 2048 cyl groups (2 c/g, 2.00Mb/g, 896 i/g)
super-block backups (for fsck -b#) at:
32, 4640, 9248, 13856, 16416, 21024, 25632, 30240, 32800, 37408,
... 8355872, 8360480, 8365088, 8369696, 8372256, 8376864, 8381472, 8386080,
creating new filesystem on /dev/rsd2c
/usr/etc/newfs -n -v /dev/rsd2c
/etc/mkfs /dev/rsd2c 8388608 512 4 8192 1024 2 10 166 2048 t
/dev/rsd2c: 8388608 sectors in 4096 cylinders of 4 tracks, 512 sectors
4096.0Mb in 2048 cyl groups (2 c/g, 2.00Mb/g, 896 i/g)
super-block backups (for fsck -b#) at:
32, 4640, 9248, 13856, 16416, 21024, 25632, 30240, 32800, 37408,
... 8355872, 8360480, 8365088, 8369696, 8372256, 8376864, 8381472, 8386080,
creating new filesystem on /dev/rsd2d
/usr/etc/newfs -n -v /dev/rsd2d
/etc/mkfs /dev/rsd2d 8388608 512 4 8192 1024 2 10 166 2048 t
/dev/rsd2d: 8388608 sectors in 4096 cylinders of 4 tracks, 512 sectors
4096.0Mb in 2048 cyl groups (2 c/g, 2.00Mb/g, 896 i/g)
super-block backups (for fsck -b#) at:
32, 4640, 9248, 13856, 16416, 21024, 25632, 30240, 32800, 37408,
... 8355872, 8360480, 8365088, 8369696, 8372256, 8376864, 8381472, 8386080,
creating new filesystem on /dev/rsd2e
/usr/etc/newfs -n -v /dev/rsd2e
/etc/mkfs /dev/rsd2e 8388608 512 4 8192 1024 2 10 166 2048 t
/dev/rsd2e: 8388608 sectors in 4096 cylinders of 4 tracks, 512 sectors
4096.0Mb in 2048 cyl groups (2 c/g, 2.00Mb/g, 896 i/g)
super-block backups (for fsck -b#) at:
32, 4640, 9248, 13856, 16416, 21024, 25632, 30240, 32800, 37408,
... 8355872, 8360480, 8365088, 8369696, 8372256, 8376864, 8381472, 8386080,
creating new filesystem on /dev/rsd2f
/usr/etc/newfs -n -v /dev/rsd2f
/etc/mkfs /dev/rsd2f 8388608 512 4 8192 1024 2 10 166 2048 t
/dev/rsd2f: 8388608 sectors in 4096 cylinders of 4 tracks, 512 sectors
4096.0Mb in 2048 cyl groups (2 c/g, 2.00Mb/g, 896 i/g)
super-block backups (for fsck -b#) at:
32, 4640, 9248, 13856, 16416, 21024, 25632, 30240, 32800, 37408,
... 8355872, 8360480, 8365088, 8369696, 8372256, 8376864, 8381472, 8386080,
creating new filesystem on /dev/rsd2g
/usr/etc/newfs -n -v /dev/rsd2g
/etc/mkfs /dev/rsd2g 8388608 512 4 8192 1024 2 10 166 2048 t
/dev/rsd2g: 8388608 sectors in 4096 cylinders of 4 tracks, 512 sectors
4096.0Mb in 2048 cyl groups (2 c/g, 2.00Mb/g, 896 i/g)
super-block backups (for fsck -b#) at:
32, 4640, 9248, 13856, 16416, 21024, 25632, 30240, 32800, 37408,
... 8355872, 8360480, 8365088, 8369696, 8372256, 8376864, 8381472, 8386080,
creating new filesystem on /dev/rsd2h
/usr/etc/newfs -n -v /dev/rsd2h
/etc/mkfs /dev/rsd2h 8388608 512 4 8192 1024 2 10 166 2048 t
/dev/rsd2h: 8388608 sectors in 4096 cylinders of 4 tracks, 512 sectors
4096.0Mb in 2048 cyl groups (2 c/g, 2.00Mb/g, 896 i/g)
super-block backups (for fsck -b#) at:
32, 4640, 9248, 13856, 16416, 21024, 25632, 30240, 32800, 37408,
... 8355872, 8360480, 8365088, 8369696, 8372256, 8376864, 8381472, 8386080,
initialization complete
But if you quit disk and then try to mount it fails because the disktab was overwritten.
But re-creating the disktab will let you mount slices a thru g.
but mounting slice h fails.
-bash-2.05b# mount /dev/sd2h /Why_Knot
mount: /dev/sd2h on /Why_Knot: No such device or address
mount: giving up on:
/Why_Knot
Also you're using 8 2gb slices? I get 7 4gb slices with my disktab and it is bootable off of the 4gb slice.
Quote from: Apple2guy on January 25, 2025, 08:42:13 AMAlso you're using 8 2gb slices? I get 7 4gb slices with my disktab and it is bootable off of the 4gb slice.
Apple2guy, the behavior you see is exactly what I see (assuming you meant that the MBR partition table was overwritten instead of the disktab being overwritten) though you're using 4GB slices since you're on 4.2, while I'm using 8 2GB slices since I'm on 3.3. All of my slices /dev/sd0a through /dev/sd0g are mountable but /dev/sd0h is not, even though disk reports that it exists. I haven't tried to boot my /dev/sd0a yet since work has become busier lately. Maybe I should try deleting the last slice from my disktab and re-checking. Thanks much for checking this!
I think what happens is when newfs formats slice h it is actually reformatting slice a and in the process overwrites mbr and the disktab?