I want to check that you can boot from a volume… Like the System Pref for Start Volume does.
Any ideas?
I looked in a lot of Tables, but nothing that indicates that is bootable.
On Linux you can use fdisk -l but that won't work on Mac OS.
diskutil info -plist (path)
With the -plist option the results include a boolean flag named Bootable.
Related
usually creating RAM disks works with the following commands
hdid -nomount ram://<blocksize>
Returns e.g. /dev/disk2
Then I would format the disk, with say
newfs_hfs /dev/disk2
followed by mounting it:
mount -t hfs /dev/disk2 /some/mount/target
This procedure doesn't seem to work with APFS. I'm on High Sierra beta 9. The mount command doesn't output any error, but the path is not mounted.
In my case, after the hdid command finished, newfs_apfs -i /dev/disk2 yields
nx_kernel_mount:1364: checkpoint search: largest xid 1, best xid 1 # 1
nx_kernel_mount:1422: sanity checking all nx state... please be patient.
spaceman_metazone_init:278: no metazone for device 0, of size 209715200 bytes, block_size 4096
apfs_newfs:18075: FS will NOT be encrypted.
When I then enter mount -t apfs /dev/disk2 /some/target/path then the mount commands seems to work for 2 seconds, doesn't give any output and the mount was NOT succesful.
Can anyone tell me how to actually make a APFS RAM disk s.t. it works? :p
PS: I've also tried something like diskutil partitionDisk /dev/disk2 GPT APFS myvolumename 0b which does mount the volume to /Volumes/myvolumename but creates yet another disk (disk3 in this case) which seems odd to me!
#Glyph provided the best answer in a comment to the accepted answer, but it deserves its own answer:
diskutil partitionDisk $(hdiutil attach -nomount ram://$((2048*sizeInMB))) 1 GPTFormat APFS 'Ramdisk' '100%'
Change sizeInMB to your desired size.
I've updated Glyph's answer to simplify the volume name a little.
Found a solution:
hdid -nomount ram://<blocksize>
diskutil erasedisk <format> <diskname> <output path of previous hdid command>
where <format> is taken from diskutil listFilesystems from the "Personality" column. Yes, it seems weird to me too that you may have to quote this parameter, e.g. when specifying case-sensitive variants, but oh well...
<blocksize> is 2048 * desired size in megabytes
The last command formats the RAM disk and mounts it to /Volumes/<diskname>
It seems to be the case that when now entering diskutil list that you will see two new disks, the one hdid created, and a synthesized one.
To destroy the RAM disk again, call diskutil eject <output path of previous hdid command>, e.g. diskutil eject /dev/disk2
This will do all the work for you, unmounting the /Volumes/<diskname> path and destroy the two disks, releasing your memory.
Keep in mind that the minimum/maximum values for <blocksize> depend on the chosen <format>. Also, <diskname> cannot always be chosen arbitrarily. Exemplary, FAT32 requires it to consist of upper-case letters!
Cheers!
Also, info to delete/destroy the RAM disk needs to be corrected. ramdisk will be created at path /Volumes/'ramdisk', so the command is:
diskutil eject /Volumes/'ramdisk'
Is there a command for the apple terminal to brute force a wipe of everything including all partitions, master boot records, and data on a usb flash drive?
Just a little information about the situation:
I just got a stick from a friend which seems to be damaged but it isnt a physical defect. I guess he just removed the stick while formatting or so.
I already tried to repartition, reformat and erase the stick with the Mac Disc Utility and I tried to format it on windows. Nothing of it worked, so I decided to use terminal for it (im just getting used to terminal/bash, so im a complete newbie at this) and tried the commands (all with sudo and diskutil in front of them ofc) repairDisk, reformat, partitionDisk, eraseDisk or zeroDisk, but nothing worked. Im getting this error message now: Error: -69759: Securely erasing data to prevent recovery failed
Underlying error: 5: POSIX reports: Input/output error
So my final thought is now that I have to clean everything from this drive as it seems there is something broken on a very low level and i would assume that completely wiping it will result in my diskutil to install a complete new partition scheme and everything on the drive so it will eventually start working again..
Thank you all in advance!
Screenshots:
Try this in Terminal if you are CERTAIN it is disk3:
sudo dd if=/dev/zero of=/dev/rdisk3 bs=65536 count=1000
If it says the disk is busy, make it un-busy!
sudo diskutil unmountDisk /dev/disk3
First, check what disk# your usb is (to be certain) in a terminal:
sudo diskUtil list
then
sudo dd if=/dev/urandom of=/dev/<your_usb_disk_here> bs=1m
If you get busy error and/or if the usb is in use elsewhere, stop what you are doing there and unmount it first as Mark Setchell said
sudo diskutil unmountDisk /dev/<your_usb_disk_here>
If you get a funky name from using bootcamp assistant or something, and you cannot get dd or even Disk Utility to wipe it for some reason, like "permission" problem, use:
diskutil eraseVolume HFS+ NAME <your_usb_disk_here>
Note that the last arg is not e.g. /dev/disk2 , but just the last part, disk2
Good evening everyone! I have been working on this for sometime, but can't figure it out. I am simply trying to get the working bootcode of a bootloader installed on an attached media, but can't figure this out!!! I have tried grub legacy, lilo, and grub2... The host system has it's drive listed as /dev/sda* and the target attached media is listed as /dev/sdb* and is mounted to /mnt/target.
With grub legacy, I was attempting to work with another media (/dev/sdc*, /mnt/source) that already had it installed and tried dirty hacks like:
dd if=/mnt/source/boot/grub/stage1 of=/dev/sdb bs=446 count=1
dd if=/mnt/source/boot/grub/stage2 of=/dev/sdb bs=512 seek=1
This will actually boot into a grub interface where you can enter things like:
root (hd0,0)
setup (hd0)
I get no error messages, but grub will boot to garbage on the screen and then stop.
With lilo, I actually had the package installed and tried to setup (after creating a lilo.conf):
default=Test1
timeout=10
compact
prompt
lba32
backup=/mnt/target/boot/lilo/MBR.hda.990428
map=/mnt/target/boot/lilo/map
install=/mnt/target/boot/lilo/boot.b
image=/mnt/target/boot/vmlinuz
label=Test1
append="quiet ... settime"
initrd=/mnt/target/boot/ramdisks/working.gz
And then from the prompt execute the following:
$ lilo -C /mnt/target/boot/lilo/lilo.conf -b /dev/sdb
Warning: /dev/sdb is not on the first disk
Fatal: Sorry, don't know how to handle device 0x0701
With grub2, I tried something like:
grub-mkconfig -o /mnt/target/boot/grub/grub.cfg
Generating grub.cfg ...
Found linux image: /boot/vmlinuz-3.11.0-12-generic
Found initrd image: /boot/initrd.img-3.11.0-12-generic
Found memtest86+ image: /boot/memtest86+.bin
No volume groups found
done
I couldn't even get the above to generate a grub.cfg correctly or in the right spot so I gave up on this one... The entries listed above are for the host system, not the target system.
I can provide any additional information that you guys need to help resolve this problem.
-UPDATE-
After working with the media a bit longer, I decided to run an 'fdisk -l' and was presented with the following info:
Partition 1 has different physical/logical beginnings (non-Linux?):
phys(0,32,33) logical(0,37,14)
Partition 1 has different physical/logical endings:
phys(62,53,55) logical(336,27,19)
I should also note that when I try to mount the partition I always get a message that states:
EXT4-fs (sdb1): couldn't mount as ext3 due to feature incompatibilities
Not sure if that is just specific to busybox, or if that is related to the fdisk output. Anyhow, I don't know if the fdisk info is indicating that there may be a problem with the disk geometry that could be causing all these bootloaders to not work.
First stage boot sector code for grub legacy is in "stage1", for grub(2) in "boot.img". Fist stage code contains the address of next stage to be loaded on same disk.
On some other disk the address of next stage to be loaded could be (and is maybe) different.
I think using chroot and grub-install would be a better way to go.
See Grub2/Installing.
As for disk/partition structure:
dd if=/mnt/source/boot/grub/stage2 of=/dev/sdb bs=512 seek=1
maybe has overwritten partition table in MBR of sdb.
I need to mount a VHD file at grub2 command prompt.
I tries using "loopback" command as shown below:
grub > insmod ntfs
grub > insmod ntldr
grub > loopback loop (hd0,1)/test.vhd
grub > ls (loop)/
error: unknown filesystem
I tried both "static" and "dynamic" vhd and both VHD file had ntfs partitioned data.
I guess VHD files have some header data which makes the filesystem not recognizable after "loopback" mount. I am able to mount and access "iso" files using same set of commands.
Is my guess correct? If so, is there a way to overcome this issue?
Well, your guess is half right:
Whilst VHD supports a linear "fixed" storage model, which actually is just the raw data as it would be stored on a "real" hard drive, followed by a VHD footer, this is most probably not usually the case; VHD supports dynamically resizing images, which of course aren't linear internally, so you can't simply boot into that.
I was finally able to get the data from the loop mounted data with following change in the above pasted grub command.
grub > insmod ntfs
grub > loopback loop (hd0,1)/test.vhd
grub > ls (loop,1)/
The file "test.vhd" was a single partitioned VHD file.
NOTE: Only "fixed" or "static" model VHDs work. I could not get it working with "dynamic" VHD (as suggested by #Marcus Müller )
Thanks for the help. Hope this helps somebody.
To use VHD disks on grub2 need:
insmod part_msdos
insmod ntfs
loopback loop /point/where/disk.vhd tdisk=VHD
ls (loop,msdos1)/
How to extract content of DMG without mounting it?
I want add autoupdate system to my application. It downloads DMG from website, then extract new version of application from it.
Some .dmg files can be extracted by using 7-zip.
$ 7z x your.dmg
$ ls
your.dmg
0.MBR
1.Primary GPT Header
2.Primary GPT Table
3.free
4.hfs
5.free
6.Backup GPT Table
7.Backup GPT Header
...and after extracted the 4.hfs file:
$ 7z x 4.hfs
...you'll get the content of the .dmg file.
You could also mount the .dmg in Mac OS X using hdiutil command (which is also used by Homebrew Cask).
Please refer to this Ask Ubuntu question for more use cases on Linux.
Dmg is just a format used for MacOS. It's a not compressed file format like zip or tar.gz
You have several choices to mount it. Here are some options.
Double click on it to mount it.
Use hdiutil attach your.dmg to mount the dmg file. After mounting on it,
operating your command line to extract the files you want out.
Doing that is working counter to the design of DMGs, so it's very painful. DMGs are designed to be mounted, that is their whole raison d'être. You would need to rely on experimental code if you wanted to do something like that. You are probably better served by using a non-DMG archive such as a zip file, or by making your automatic updating process download, mount, and unmount the DMG file you provide.