I am looking to overwrite an existing NeXTStep formatted SD disk using MacOS 10.14 Mojave. I want to copy an updated NeXTStep image to the disk, overwriting the existing.
When I run dd as root, I encounter an error. The command is: dd if=openstep4.sd of=/dev/disk5 bs=512b
dd: /dev/disk5: Permission denied
If I try to unlock it in diskutil, I get diskutil enableOwnership /dev/disk5
Error enountered enabling user/group ownership: A disk with a mount point is required (-69854)
Note: The physical lock is switched to unlocked. I have replicated this on several SD disks, this is not an anomaly. EDIT: The issue is the same on Linux, so it's unrelated to OS.
Any suggestions? I can't reformat, can't change ownership, and can't copy an image as root.
Thanks!
Run the 'dd' command as a user with root privileges, by using sudo:
sudo dd if=openstep4.sd of=/dev/disk5 bs=512b
It will prompt you for your password. Assuming your account is an admin account, it should succeed at that point. You're probably better off using a much larger block size for the 'dd' copy, it will go much faster (try 1024k or even larger).
Quote from: g_c_p on December 07, 2021, 09:47:29 PMRun the 'dd' command as a user with root privileges, by using sudo:
I was running the command as root and it fails. I have bolded that text for future readers, it's easy to miss.
Are you sure you are logged in as root there? What does 'whomi' return? Are you sure the device you are writing to is correct? What is the output of 'sudo diskUtil list'? You can also try the /dev/rdisk5 device under OSX. I would suggest to verify that Terminal.app has all of the permissions that it needs, but I think that shouldn't be relevant in Mojave? I forget which update substantially changed the permissions model.
Thank you for your responses, g_c_p
I can confirm that whoami is root
/dev/rdisk or /dev/disk does not change the issue
Replicated the issue with Linux machine
Replicated the issue with other NeXTStep formatted SD cards
The issue appears to be with the cards that I have used to back up my working NextStep SD cards.
Sorry it's still not working, BillAnderson. Puzzling... I feel like I must be overlooking something obvious!
Assuming you've verified the right device number, the only other thing I can think to try is to ensure the disk is in an unmounted, non-ejected state... 'sudo diskutil unmountDisk /dev/disk5', then run the dd command
What card reader device are you using? Do you have a different card reader to test with?
I did unmountDisk too. I've tried 4 different SD cards in 3 different machines (2 macs and a Linux box). I checked the physical switch on each. I taped over the little hole on the SD opposite side of the switch. I tried erasing and reformatting using several tools and commands.
I think when I write to the disk, there must be some obsolete formatting in the NeXTStep image that doesn't use current mountpoints and sets the drive as write-only. Other cards work just fine, it's the NeXT disks.
I ordered a 10pack of 8gb SD cards to experiment with, but I would love to solve this.
What is the output of diskutil list for that device? Anything thing else on the device mounted?
Also look for a synthesized disk using the same drive. Its not obvious from the drive numbering..
I am still running Mojave here, and I vaguely remember a bit extra effort here on this item. I'll check my notes..
Jerry
Here's the readout. Disk5 is a working NeXTStep SD. It is a backup I created, but cannot overwrite:
diskutil list
/dev/disk0 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *251.0 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_APFS Container disk1 250.8 GB disk0s2
/dev/disk1 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +250.8 GB disk1
Physical Store disk0s2
1: APFS Volume Studio 192.7 GB disk1s1
2: APFS Volume Preboot 23.1 MB disk1s2
3: APFS Volume Recovery 510.6 MB disk1s3
4: APFS Volume VM 2.1 GB disk1s4
/dev/disk2 (external, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *14.0 TB disk2
1: EFI EFI 209.7 MB disk2s1
2: Apple_APFS Container disk4 12.0 TB disk2s2
3: Apple_HFS Studio Time Machine 2.0 TB disk2s3
/dev/disk3 (external, physical):
#: TYPE NAME SIZE IDENTIFIER
0: FDisk_partition_scheme *2.0 TB disk3
1: Apple_HFS Storage 2.0 TB disk3s1
/dev/disk4 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +12.0 TB disk4
Physical Store disk2s2
1: APFS Volume SlushBucket 2.0 TB disk4s1
/dev/disk5 (external, physical):
#: TYPE NAME SIZE IDENTIFIER
0: *15.8 GB disk5
Here's some of the things I've tried
studio:Desktop root# dd if=openstep4.sd of=/dev/rdisk5 bs=512b
dd: /dev/rdisk5: Permission denied
studio:Desktop root# dd if=openstep4.sd of=/dev/disk5 bs=512b
dd: /dev/disk5: Permission denied
studio:Desktop root# whoami
root
# diskutil enableOwnership /dev/disk5
Error enountered enabling user/group ownership: A disk with a mount point is required (-69854)
# diskutil mountDisk /dev/disk5
Volume(s) mounted successfully
# dd if=openstep4.sd of=/dev/rdisk5 bs=512b
dd: /dev/rdisk5: Permission denied
# diskutil enableOwnership /dev/disk5
Error enountered enabling user/group ownership: A disk with a mount point is required (-69854)
...
# diskutil unmount /dev/disk5
disk5 was already unmounted or it has a partitioning scheme so use "diskutil unmountDisk" instead
# diskutil unmountDisk /dev/disk5
Unmount of all volumes on disk5 was successful
# newfs_msdos -F 16 /dev/disk5
newfs_msdos: /dev/disk5: Permission denied
...
# diskutil eraseDisk FAT32 DISK MBRFormat /dev/disk5
Started erase on disk5
Unmounting disk
Creating the partition map
Error: -69877: Couldn't open device
I should note that the same thing happens on a 2015 MBAir with no external HDs, and on a Lenovo Linux machine with built in SD card reader. Multiple platforms, multiple SD disks.
If this happens on both Mac and Linux systems, different card readers and multiple SD disks, then i would start to look at the media itself. Are all the cards from the same vendor?
Try to switch to locked and see if anything changes, just for grins.
I tried switching to lock too! No luck.
I will try a new card when the 10pack comes in.
I wonder if it's because of the unique disk geometry, or a Next-flavored UFS filetype. I did find a hint that Linux has a ufstype=nextstep option. Might be worth pursuing.
QuoteI tried switching to lock too! No luck.
I will try a new card when the 10pack comes in.
I wonder if it's because of the unique disk geometry, or a Next-flavored UFS filetype. I did find a hint that Linux has a ufstype=nextstep option. Might be worth pursuing.
Try this command first. I think the trailing "b" is making the block size 512x512. Maybe the SD card cannot support this.
dd if=openstep4.sd of=/dev/disk5 bs=512 Geometry doesn't play a role yet in what you are trying to do. To a Mac or Linux system, you first want to use dd command to access it as a set of logical blocks. So you are stuck until we get past this.
If you are planning to use this SD card with a SCSI2SD adapter and once the NeXTstep disk image (openstep4.sd file) is on the SD card, you need to configure the SCSI2SD to present the correct geometry to a Next computer. See
http://www.nextcomputers.org/forums/index.php?topic=3866.msg22334#msg22334 for more information.
Yes, you can use utilities on Linux and Mac to access NeXTstep disk image (as a file). Example from Linux
$ sudo losetup /dev/loop0 Disk_Next_NS3.1.img
$ sudo mount -t ufs -r -o ufstype=openstep /dev/loop0 /media/NSdisk
$ ls /media/NSdisk
Apps NextAdmin
NextApps NextDeveloper
NextLibrary ...