Contribute
Register

Chimera and 4k HDD boot issues

Status
Not open for further replies.
Joined
Jan 17, 2012
Messages
23
Motherboard
GA-H61N-USB3-B3-HDMI-F8
CPU
i3 2125
Graphics
HD3000
Mac
  1. Mac mini
Classic Mac
  1. 0
Mobile Phone
  1. iOS
Hi all. I'm not 100% sure that I understand these issues but I am having extreme difficulty booting from my HDD after a successfull 10.7.3 and Win7 install on the same drive.

I trawled this forum and tried every solution on offer - well apart from getting into complex coding and commands.

I get Boot0 errors on boot and it appears that this might have something to do with the HDD being 4k. (?) in my case a Seagate 1tb drive formatted from new as per TonyMac's UniBeast install guide. The post suggests that the system removes the bootloader after it installs it for some reason. I have seen a post that offers very complicated Ubuntu solutions but that is a bit beyond me...

Can anyone help? My build is typical H61N, i3, 4gig XMS 3, Seagate 1tb 7200 HDD, plenty power etc.

Surely I with this build I can't be experiencing unique HDD issues. Or have I done a basic mistake when formatting/partitioning the drive?

Thanks
 
The issue is with the drive and the dd command in OS X.

Right now the cure is to manually write boot1h in the terminal. You will find boot1h in /usr/standalone/i386.

The command would be:

sudo dd if=/usr/standalone/i386/boot1h of="the raw device name" bs=4K
 
MacMan, I have read in numerous places that writing the boot1h file to an 'Advanced Format' 4k sector drive can only be done reliably if the drive being written to is unmounted... is that incorrect? Frankly, I've read so many different explanations for how to fix this problem with, with reports of varying degrees of success, that I don't know what the truth is about this problem. Also, I don't know where on the drive boot1h is written to, so how can I look to see if it was in fact written? Can I see it in the root on the OS X partition with finder if I use ShowAllFiles? I have looked, but I did not find it.

I have read that while Chameleon writes it's files to the EFI partition, that Chimera differs because it writes to the partition where OS X is installed... is this correct, and is how MultiBeast implements Chimera?

I assume in your above example that "the raw device name" for disk number 0 and partition 2 would be: /dev/rdisk0s2 is that correct? The bs=4k is to force a write of a complete 4k sector??? Sorry, my terminal skills are lacking...
 
Thanks, kudos MacMan thanks for all your help.

Yes, on this post: http://forge.voodooprojects.org/p/chameleon/issues/129/ (worth a read) one of the authors seems to suggest that the drive needs to be unmounted first and, the boot1h file should come from the extracted package, not the one on the OSX HD. "The boot1h file can be downloaded in the main zip file of the Chameleon package."
And "The boot1h file is in the chimera boot folder of the zip file you download to install chimera."

"Don't try to copy it off the Hard drive in mac using dd. the dd
doesn't work properly with the 4k sectors. if you copy the boot1h
file to your mackintosh using mac's dd as in the instructions
chances are your hard drive will remove it (this causes the boot0
GPT error). to resolve use the same boot1h file in the zip folder
and copy using the dd command using the Linux dd command (not mac's
dd) the linux dd can handle 4k sectors and will align the file
correctly so it is not removed by the system and then will allow you
to triple boot."

Then there is this:

"Steps.
1. Download Ubuntu-
http://www.ubuntu.com/start-download?di ... &bits=32&r
elease=lts
2. burn .iso file to cd or dvd.
(http://hints.macworld.com/article.php?s ... 9181010389)
3. reboot computer
4. at boot chime press del or whatever to get to bios (could be f2
or f8 or f12 etc)
5. set cdrom as first boot drive
6. put cd in drive, reboot and load ubuntu live environment
7. identify your disk. look in system> administration> disk
drives. find your partition number for OS X. remember it i'll use
example '/dev/sdxy' replace this with your partition number (probably
something like /dev/sda2)
8. download the boot1h file and put in the home folder
9. open terminal (applications > accessories > terminal)
10. type "sudo dd if=boot1h of=/dev/sdxy bs=4096" replacing sdxy with the partition you noted down in step 7.
11. reboot and you're done."

This seems to be the latest conventional wisdom on the subject though there is a method using Coreutils.

I shall try this method today...

Cheers
 
Timeslice said:
Thanks, kudos MacMan thanks for all your help.

Yes, on this post: http://forge.voodooprojects.org/p/chameleon/issues/129/ (worth a read) one of the authors seems to suggest that the drive needs to be unmounted first and, the boot1h file should come from the extracted package, not the one on the OSX HD. "The boot1h file can be downloaded in the main zip file of the Chameleon package."
And "The boot1h file is in the chimera boot folder of the zip file you download to install chimera."

"Don't try to copy it off the Hard drive in mac using dd. the dd
doesn't work properly with the 4k sectors. if you copy the boot1h
file to your mackintosh using mac's dd as in the instructions
chances are your hard drive will remove it (this causes the boot0
GPT error). to resolve use the same boot1h file in the zip folder
and copy using the dd command using the Linux dd command (not mac's
dd) the linux dd can handle 4k sectors and will align the file
correctly so it is not removed by the system and then will allow you
to triple boot."

Then there is this:

"Steps.
1. Download Ubuntu-
http://www.ubuntu.com/start-download?di ... &bits=32&r
elease=lts
2. burn .iso file to cd or dvd.
(http://hints.macworld.com/article.php?s ... 9181010389)
3. reboot computer
4. at boot chime press del or whatever to get to bios (could be f2
or f8 or f12 etc)
5. set cdrom as first boot drive
6. put cd in drive, reboot and load ubuntu live environment
7. identify your disk. look in system> administration> disk
drives. find your partition number for OS X. remember it i'll use
example '/dev/sdxy' replace this with your partition number (probably
something like /dev/sda2)
8. download the boot1h file and put in the home folder
9. open terminal (applications > accessories > terminal)
10. type "sudo dd if=boot1h of=/dev/sdxy bs=4096" replacing sdxy with the partition you noted down in step 7.
11. reboot and you're done."

This seems to be the latest conventional wisdom on the subject though there is a method using Coreutils.

I shall try this method today...

Cheers

Timeslice,

that article you quoted from voodoo projects.org is one of the multi-dozens of articles that I've read regarding this problem. It seems like people have found a number of different ways to overcome the problems of 'Advanced Format' drives (4k sector drives), and from reports in the threads on line many of them work. One theory is that the problem occurs because the drive has 4k clusters, it's firmware's internal processes interfere with low-level commands trying to write smaller files. In many cases, users have reported seeing the file they are trying to write appear to be written to the drive, only to have it disappear moments later, and that if they write the same file multiple times it seems to finally 'stick'. All of the solutions that sound like they are successful seem to be 'workarounds' for the original reason this is happening, and I wouldn't say that the ones that work are wrong, but many seem to be unnecessarily convoluted or difficult. And many of the the solutions include steps which appear to be unnecessary, like marking the partition as active, as in most of what I've read, the real problem is getting the boot1h file actually written to the drive.

A large portion of solutions involve writing to an 'unmounted' drive, and to date they seem to have the largest percentage of success rate. I'm interested in MacMan's solution above, because as I understand it, it involves a parameter that instructs a complete 4k cluster to be written, even though the boot1h file is much smaller. That's why I posted in the thread, to get some clarification from MacMan about what the command is actually doing.

I'm not a fan of using Disk Utility to write ISO files to CDs and DVDs, especially for something like a system disc like your link above gives instructions for. When you use Disk Utility to write a DMG in a similar fashion to the method described in the link it creates a checksum first and then after the burn process is finished, it compares the burned copy to the original file. As far as I can tell, this does not happen when you burn an ISO file in the same way, so you are burning it blindly and there is no verification that the image has been burned correctly, something that I feel is mandatory when burning an operating system or system installation disc.

The method you describe above seems to be a combination of 2 different methods that work, the first being writing to an unmounted disk, and the second being specifying the write to be a complete 4k cluster (as I think the command specifies). Each, by themselves probably work.

After doing a ton of reading on the subject I came up with the following solution which uses nothing more than the Lion Installer USB drive (not the commercial one from Apple, but the one that created from the Apple store download as described elsewhere here on tonymacx86 that includes Chimera on it. If you used this to build your system, everything you need is already on it. The procedure involves starting the installer as your operating system and using the Utilities on it to unmount and write to your 4k sector drive. So far it has worked for me, although I'm still interested in understanding other people's solutions and why they work. The post below gives instructions for what worked for me.
 
Fixing the boot0: error (4k sector boot problem) on WD 'Advanced Format' Drives after installing Lion w Lion Installer USB drive

These instructions you have already installed Lion from a USB installer created as described on the tonymacx86 website: http://tonymacx86.blogspot.com/2011/10/ ... using.html

1) Reboot computer with Lion installer USB drive in USB port and go to boot menu (F12 key) - When boot menu appears, choose USB-HDD, and when the Lion Boot Screen appears, choose the Lion installer USB drive and boot to it.


2) Choose your Language and [return]. The Menu bar appears at the top of the screen.


3) From the Utilities menu choose Disk Utility. Highlight the drive you have just installed Lion on and Unmount it (either right-click on it and click 'Unmount' from the context menu, or click on the Unmount button at the top of Disk Utility.


4) From the Disk Utility menu, choose Quit Disk Utility.


5) From the Utilities menu, choose Terminal. Type diskutil list [return] and verify the Apple_HFS disk number and partition that you installed Lion on by identifying it's Volume Name (in my case the disk number is 0 and the partition is 2 = 0s2). This may be different in your installation and it is important that you get this correct.


6) In Terminal, change to the directory on your Lion installer where the boot1h file is ( /usr/standalone/i386/ ):

The name of my Lion Installer USB drive is: Lion 10.7.3 UniBeast 1.1.0 - because of this, the name in the path has an extra \ followed by a space where ever there is a space in the Lion Installer USB drive name when it is typed in the path:

Type the path** to boot1h into Terminal (No need to type in SUDO first- when you boot from the Lion installer USB drive you automatically have those rights.
Type: cd /Volumes/Lion\ 10.7.3\ UniBeast\ 1.1.0/usr/standalone/i386/ [return] Terminal will not echo the directory i386 that you've changed to on the command line like it normally would in a fully completed OS X installation).

** Note: In the above path, there is a space between cd and /Volumes, a space between /Lion\ and 10.7.3\, a space between 10.7.3\ and UniBeast\ and a space between UniBeast\ and 1.1.0/


7) Verify you are in the correct directory where boot1 is located by typing ls [return] into Terminal- this lists the files in the directory- you should see: EfiLoginUI, boot, boot.efi, boot0, boot0md, boot1h and tmbootpicker.efi. The only one you're interested in is boot1h. If you see this file, proceed to the next step.


8) Once you've verified that you're in the directory where boot1h is located, in Terminal type: dd if=boot1h of=/dev/rdisk0s2 [return]
The response in Terminal to this command will include something similar to this:

2+0 records in
2+0 records out
1024 bytes transferred in 0.088021 secs (11634 bytes/sec)
_bash_3.2#



9) In Terminal, type: exit [return] to logout of Terminal. From the Terminal menu, choose Quit Terminal.


10) From the Apple menu select Shut Down - After power is off, remove the Lion installer USB drive from the USB port.


11) When powering the computer back up, enter the BIOS Setup (DELETE key) at the BIOS splash screen and make sure boot device settings are correct to boot from your hard drive.


NOTE: These instructions are what has worked for me, and have not been endorsed by anyone officially at tonymacx86.com
 
The above sounds a lot more complicated that it really is- I included every little detail that I could think of for noobs like me, and to the more experienced, a lot of the steps are things that are probably obvious to you.

I hope MacMan will read all my instructions above and make any corrections necessary, and explain some of the details of how the commands he used work, such as what the bs=4K parameter does- as I understand it, the bs=4k parameter specifies a block size of 4096 bytes to be written instead of the default size of 512 bytes- he doesn't mention unmounting the disk before writing, so does specifying a block size that equals the sector size of the 'Advanced Format' disks make it unnecessary to unmount the drive being written to??? How how does bs=4k differ from the bs=4096 parameter that Timeslice's citation uses??? ... is that just a difference between Linux & Mac OS X??? Or will either work in OS X???

Also, from another thread I read (which actually came from the same voodoo projects that Timeslice cited above), the author suggests writing directly to /dev/disk0s2 instead of /dev/rdisk0s2 so that you dd straight to the disk instead of going through the ramdisk ... any thoughts on that???
 
Thank you jwk - I bow to your superior knowledge...

I shall try your method right away as I installed Lion in the same manner as you. Two diffs though:
1) I ended up with a MacPro3,1 - It's stable and works. (Any advantage of MacMini?)
2) I prepped the HD for dual boot with OSX and Win7 - Will this effect your instructions?

Thanks again

(BTW, a hackintosh is a work-around! ;-)
 
Whenever you install Chimera either thru the standalone installer of thru MultiBeast ALL of the boot files are written to /usr/standalone/i386/ and fdisk440 and bdmesg to /usr/sbin. There is no need to ever extract these files after an install.
 
Timeslice said:
Thank you jwk - I bow to your superior knowledge...

I shall try your method right away as I installed Lion in the same manner as you. Two diffs though:
1) I ended up with a MacPro3,1 - It's stable and works. (Any advantage of MacMini?)
2) I prepped the HD for dual boot with OSX and Win7 - Will this effect your instructions?

Thanks again

(BTW, a hackintosh is a work-around! ;-)


My superior intelligence? Ha! that's a hoot!!! I'm a noob too... I just have this problem where I need to understand how things work so I did a lot of searching and reading trying to understand, and I'm still not sure about everything! I have used this method on two builds so far and it worked for me. Still, if MacMan's method will work without unmounting the drive, that would make it even easier- hope he weighs in on this, he's the one with superior intelligence!!

As for MacPro 3,1 vs MacMini definitions, my mini still has the MacPro 3,1 def... you can change that with MultiBeast whenever... I haven't worked out all the nuances yet, too busy researching 4k drives, video artifacts, and add in video cards. I think for our purposes the significant differences between MacPro 3,1 vs MacMini are the audio connector layout defs and also possibly the CPU power management... but like I said, I'm still a noob...

Good luck, and let me know if you have success...

and now that you put it that way, I guess a hackintosh is a 'workaround'...
 
Status
Not open for further replies.
Back
Top