28 Mar
2014
28 Mar
'14
4:54 p.m.
I'm trying to figure out how to access an rx33 floppy disk on a pdp11/83 without going
through the disklabel process.
It would be nice if I could write a tar archive to a floppy with my Linux system, and
extract it on the 11/83. Unfortunately, since the rx33 looks like any other MSCP disk to
unix, it doesn't seem to want to access the floppy unless a disklabel (and file
system) is present.
I'm sure there must be some way to get actual raw access to the floppy drive under
2.11bsd, but I can't seem to figure it out, and I've spent some time looking
through the ra device driver source. Frustration levels are high -:)
Anyone have any suggestions?
Thanks in advance.
30 Mar
30 Mar
12:05 p.m.
On Fri, Mar 28, 2014 at 1:54 PM, Peterson, Roe (LAI)
<roe at liveblockauctions.com> wrote:
I'm trying to figure out how to access an rx33
floppy disk on a pdp11/83 without going through the disklabel process.
It would be nice if I could write a tar archive to a floppy with my Linux system, and
extract it on the 11/83. Unfortunately, since the rx33 looks like any other MSCP disk to
unix, it doesn't seem to want to access the floppy unless a disklabel (and file
system) is present.
I'm sure there must be some way to get actual raw access to the floppy drive under
2.11bsd, but I can't seem to figure it out, and I've spent some time looking
through the ra device driver source. Frustration levels are high -:)
Anyone have any suggestions?
Thanks in advance.
Does it work if you use the raw device /dev/rra1a instead of
/dev/ra1a, assuming ra0 is the boot device and ra1 is the rx33?
1 Apr
1 Apr
12:42 p.m.
On 03/30/2014 10:05 AM, Glen Slick wrote:
On Fri, Mar 28, 2014 at 1:54 PM, Peterson, Roe (LAI)
<roe at liveblockauctions.com> wrote:
In this case, it's /dev/rra8a. Here's what happens with a freshly
formatted floppy:
# dd if=/dev/zero of=/dev/rra8a bs=512
write error: read only file system
2+0 blocks in
2+0 blocks out
#
I'm trying to figure out how to access an
rx33 floppy disk on a pdp11/83 without going through the disklabel process.
It would be nice if I could write a tar archive to a floppy with my Linux system, and
extract it on the 11/83. Unfortunately, since the rx33 looks like any other MSCP disk to
unix, it doesn't seem to want to access the floppy unless a disklabel (and file
system) is present.
I'm sure there must be some way to get actual raw access to the floppy drive under
2.11bsd, but I can't seem to figure it out, and I've spent some time looking
through the ra device driver source. Frustration levels are high -:)
Anyone have any suggestions?
Thanks in advance.
Does it work if you use the raw device /dev/rra1a instead of
/dev/ra1a, assuming ra0 is the boot device and ra1 is the rx33?
2 Apr
2 Apr
11:24 a.m.
On Apr 2, 2014 12:37 AM, "Roe Peterson" <roe at liveblockauctions.com>
wrote:
In this case, it's /dev/rra8a. Here's what happens with a freshly
formatted floppy:
# dd if=/dev/zero of=/dev/rra8a bs=512
write error: read only file system
2+0 blocks in
2+0 blocks out
#
Does it work if you dd from the rx33 instead of to it? Can you read the
entire disk doing that?
I vaguely remember making a minor modification somewhere in the kernel
source and rebuilding it when I wanted to dd an image to an entire disk.
There is some code somewhere that appeared to want to prevent write access
to the disklabel area. I'll have to see if I can find the details of what I
did there.
-Glen
2:11 p.m.
On Wed, Apr 2, 2014 at 8:24 AM, Glen Slick <glen.slick at gmail.com> wrote:
On Apr 2, 2014 12:37 AM, "Roe Peterson"
<roe at liveblockauctions.com> wrote:
I think this is related to the routine partition_check() in the kernel
source file src/sys/sys/ufs_disksubr.c which is used, for example, by
the routine rastrategy() in the source file src/sys/pdpuba/ra.c
I'll have to see if I can find the copy of the source files where I
modified this to work around this issue when I needed to do this.
Possibly I just commented out this section of the partition_check()
routine:
/*
* Check for write to write-protected label area. This does not include
* sector 0 which is the boot block.
*/
if (bp->b_blkno + pi->p_offset <= LABELSECTOR &&
bp->b_blkno + pi->p_offset + sz > LABELSECTOR &&
!(bp->b_flags & B_READ) && !(dk->dk_flags &
DKF_WLABEL))
{
bp->b_error = EROFS;
goto bad;
}
In this case, it's /dev/rra8a. Here's what happens with a freshly
formatted floppy:
# dd if=/dev/zero of=/dev/rra8a bs=512
write error: read only file system
2+0 blocks in
2+0 blocks out
#
Does it work if you dd from the rx33 instead of to it? Can you read the
entire disk doing that?
I vaguely remember making a minor modification somewhere in the kernel
source and rebuilding it when I wanted to dd an image to an entire disk.
There is some code somewhere that appeared to want to prevent write access
to the disklabel area. I'll have to see if I can find the details of what I
did there. 
2:35 p.m.
On Apr 2, 2014, at 2:11 PM, Glen Slick <glen.slick at gmail.com> wrote:
...
I think this is related to the routine partition_check() in the kernel
source file src/sys/sys/ufs_disksubr.c which is used, for example, by
the routine rastrategy() in the source file src/sys/pdpuba/ra.c
I'll have to see if I can find the copy of the source files where I
modified this to work around this issue when I needed to do this.
Possibly I just commented out this section of the partition_check()
routine:
/*
* Check for write to write-protected label area. This does not include
* sector 0 which is the boot block.
*/
if (bp->b_blkno + pi->p_offset <= LABELSECTOR &&
bp->b_blkno + pi->p_offset + sz > LABELSECTOR &&
!(bp->b_flags & B_READ) && !(dk->dk_flags &
DKF_WLABEL))
{
bp->b_error = EROFS;
goto bad;
}
So how do you write a label? Some ioctl? It may be that this means that writing the
whole floppy requires some extra trickery: plain writes for all except the protected area,
and some magic writes for the protected area.
paul
3:41 p.m.
> if (bp->b_blkno + pi->p_offset
<= LABELSECTOR &&
> bp->b_blkno + pi->p_offset + sz > LABELSECTOR &&
> !(bp->b_flags & B_READ) && !(dk->dk_flags &
DKF_WLABEL))
So how do you write a label? Some ioctl?
Most likely. But for your purposes it is probably enough to just turn
on DKF_WLABEL, probably just another ioctl. At least, based on
BSD-derived code I have at ready hand (which uses DIOCSDINFO to write
the label and DIOCWLABEL to enable or disable what the above quote
calls DKF_WLABEL).
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
3:49 p.m.
On Apr 2, 2014 12:00 PM, "Paul Koning" <paulkoning at comcast.net> wrote:
writing
the whole floppy requires some extra trickery: plain writes for all
except the protected area, and some magic writes for the protected area.
Yes, I believe there is an ioctl for writing disk labels. Some bit of
kernel code which sets the DKF_WLABEL flag to allow the section of code
above to pass its check.
Possibly I just commented out this section of the
partition_check()
routine:
/*
* Check for write to write-protected label area. This does not include
* sector 0 which is the boot block.
*/
if (bp->b_blkno + pi->p_offset <= LABELSECTOR &&
bp->b_blkno + pi->p_offset + sz > LABELSECTOR &&
!(bp->b_flags & B_READ) && !(dk->dk_flags &
DKF_WLABEL))
{
bp->b_error = EROFS;
goto bad;
}
So how do you write a label? Some ioctl? It may be that this means that
9:49 p.m.
So how do you
write a label? Some ioctl? It may be that this means that
writing the whole floppy requires some extra trickery: plain writes for all
except the protected area, and some magic writes for the protected area.
Yes, I believe there is an ioctl for writing disk labels. Some bit of kernel
code which sets the DKF_WLABEL flag to allow the section of code above to
pass its check.
3 Apr
3 Apr
10:45 a.m.
On 04/02/2014 07:49 PM, Glen Slick wrote:
Yep, this works perfectly, and changing media does not reset the write
enable.
Sigh. You'd think after 35+ years working with *nix, I'd know enough to
RTFM.
Yes, I believe
there is an ioctl for writing disk labels. Some bit of kernel
code which sets the DKF_WLABEL flag to allow the section of code above to
pass its check.
It appears that the usage "disklabel -N disk" should
disable write
access to the disk label area and the usage "disklabel -W disk" should
enable write access to the disk label area, where I think disk should
be the device /dev/rra8a you were using
So maybe all you need to do is use disklabel -W before trying to dd to
the rx33 disk. I don't have a system running at the moment to give
that a try myself.
7:45 p.m.
Too bad I didn't spent a little more time investigating this issue
when I ran into it myself a while back. I just confirmed that after
using "disklabel -W" on the raw disk device then you can then dd to
the entire disk without encountering the "Read-only file system"
error.
# dd if=/dev/rra1a of=rx33.dsk bs=512
ra1: RX33 size=2400
2400+0 records in
2400+0 records out
# ls -l
total 1200
-rw-r----- 1 root 1228800 Jun 8 22:56 rx33.dsk
# dd if=rx33.dsk of=/dev/rra1a bs=512
write: Read-only file system
2+0 records in
2+0 records out
# disklabel -W /dev/rra1a
# dd if=rx33.dsk of=/dev/rra1a bs=512
2400+0 records in
2400+0 records out
2 Apr
2 Apr
3:30 p.m.
On 04/02/2014 09:24 AM, Glen Slick wrote:
# dd if=/dev/zero of=/dev/rra8a bs=512
write error: read only file system
2+0 blocks in
2+0 blocks out
#
Does it work if you dd from the rx33 instead of to it? Can you read the
entire disk doing that?
Yes, dd will read all 2400 blocks from /dev/rra8a.
I took a quick find/grep around in /usr/src/sys/.../*.c for EROFS, and
it wasn't immediately obvious where to patch; ufs_fio.c is definitely
not responsible...
| I vaguely remember making a minor modification somewhere in the kernel
source and rebuilding it when I wanted to dd an image to an entire disk.
There is some code
| somewhere that appeared to want to prevent write access to the
disklabel area. I'll have to see if I can find the details of what I did
there. -Glen
Thanks, I'll also look into it a bit further after work tonight.
3764
days inactive
3770
days old
11 comments
4 participants
participants (4)
-
glen.slick＠gmail.com -
mouse＠Rodents-Montreal.ORG -
paulkoning＠comcast.net -
roe＠liveblockauctions.com