HDDOSD Issues

i dont trust winhiip no more. it has messed up these games during install: mk shaolin monks, tony hawk 3/4 and gt 2002 tokyo geneva

 

Hello! This is a great thread. I recently got a 1TB SATA drive in addition to the SATA hardware upgrade kit for the NA. My personal preference is to avoid using disk images whenever possible unless restoring to an identical drive. Anyway, I was just thinking that a lot of all these different image files seem to be larger than necessary. I understand that the intent is to simplify the process for new users, but why not just keep images to only the __mbr partition? I was thinking that really all we need is an __mbr partition (which boots to some recent version of uLE) that enables users to create their own FMCB. Once that is done, then they can format their drive using uLE from FMCB and merely copy the app files to appropriate partitions they make themselves.

This is a much more involved process but I think it would encourage new users to learn more about the PS2, HDD, and setup process. Plus, the apps themselves tend to be very small, so that the total download would be considerably smaller than these compressed images I have seen on the internet. Then there is also the issue of failed image restores that lead to even more attempts to restore an image (or perhaps to use other images) adding wear to the drives. Plus, it is my personal opinion that the overall process would be faster since creating partitions and copying apps from USB to HDD is generally faster than waiting on a 40GB+ image to copy.

For the slightly more advanced user, creating packages in the form of only an __mbr image and zipped apps means they can taylor their setup to however they want without have to destroy partitions they don't necessarily want and recreating new ones (opening up the possibility of more scan/repairs that in my opinion quite avoidable).

To get back on topic, is my understanding that HDD OSD (patched from original versions, so presumably 28-bit) should still work properly in a 48-bit setup (up to 128GB) correct? Or does the HDD OSD software need further patching to handle 48-bit partitions?

 

Each partition has its purpose, so eliminating or changing partitions is not good:
__mbr contains the boot program and is not formatted.
__net contains stuff used by the PSBBN.
__sysconf contains common system settings and files (i.e. ATOK).
__system contains the browser.
__common is supposed to contain your saves.

__boot is unofficial and the code for generating it has been removed from the PS2SDK.

Your concern about the use of disk images was the reason why I wrote a port of the APA and PFS drivers, to be used in a tool that mounts and installs FHDB in the proper way.
Unfortunately, I got sidetracked and the project has been left derelict for a long time. The last version can be found here: http://psx-scene.com/forums/f153/un...e-package-obt-119562/index13.html#post1141776
Someday, I will finish it... just that I don't know when.

I haven't really decided how would be the best way to allow users to install their own programs, without making it too complicated. For now, I created an APPS partition (PP.FHDB.APPS), but it doesn't seem like people appreciate that... (and it is undeniably so!).
The right path is not really clear because we're not actually supposed to have access to the system partitions (other than __common and __sysconf), but yet taking up 2GB of space seems to be a bit too much for some users (I guess, users of the SONY 40GB disk).

The original HDD Browser (regardless of whether it was ATAD-patched to accept generic IDE disks or not) will support up to 137GB of space. Even if you used a 2TB disk, it will only "see" 137GB.
The problem is that you must not mix such old software with homebrew software that support 48-bit LBA (which is most of them) because the old software may crash/produce unpredictable results if it finds half a partition passing through the 137GB limit.
So you can either stick with using the old (28-bit LBA) software or go with 48-bit LBA software. Just don't mix and match.

 

Thank you for sharing this info. As for the partitions, I did not mean to say that we only need __mbr for a working system. What I had meant to write, but failed to express in my writing, was that when people release disk images for others to use, that they really only needed to provide an image of just the __mbr partition (with uLE). Right now, too many of these images write 40GB or even much larger sizes, most of which is empty space in a partition. On the other hand, simply providing an initial __mbr image that boots directly into uLE enables users to set up FMCB (in an easy manner w/out relying on disc swapping or mod chips). After users are able to get a working FMCB setup, then they can rebuild a proper system by formatting with uLE (which sets up all the necessary basic partitions). Then, any other applications can be easily copied to the appropriate partitions. That is, users would only need to re-image that single partition (and only temporarily until they can install FHDB).

For example, the typical method for creating minimal FHDB noobie package is to set up a hard drive with all the apps etc installed and then creating a (possibly compressed) image of the entire drive. If the creator did not also zero his drive at the start, then even a compressed image of a 120GB drive comes out to several GB!. If I were to do it, I would probably just include Akuhack's image that boots into uLE (and only fills what is normally __mbr), and also include the FMCB installer. A user would simply write a tiny image to their HDD, plug it into their PS2 to boot automatically into uLE, and use this to install FMCB. Once FMCB is done, they would boot through their memory card and reformat their HDD. Upon completion, they could do whatever they wanted (create new partitions of sizes they prefer; copy over only the apps they want). There would be no more of this one-size-fits-all disk image. And, I believe this would be a much faster process overall. That's just my personal take on how to make the process go faster, and at the same time engage users into actually learning about the setup process.

Ah, ok that makes sense. But if I were diligent enough to ensure that no application is "split" at the 137GB limit, then in theory using 28-bit HDD OSD would be ok, yes (with the understanding only the first 137GB is visible, of course)?

 

I personally have no issues with the few GB taken by the system partitions (even on my 40GB drive). I think that those who have had experience with the original HDD are likely not to mind, either. I suspect that many of them would want to preserve their system and keep everything as close to original as possible (both for archival purposes, as well as for compatibility). And in general I would advocate for keeping those partitions. Any progress towards getting the elimination of (re)imaging drives using images from very-likely-not-identical disks would also be well received by me.

 

But as a matter of fact, installing FHDB this way doesn't complete the installation; HDD support is not enabled on the target console. Which is why I do recommend people who install FHDB this way to install FHDB again with the normal installer.
So if/when my tool is completed, I'll probably add a small program to fix this on the first boot.

So if you've installed FHDB for the first time on a new console (or simply a console that never had HDD support enabled on it before), you will get the syndromes that are related to HDD support being deactivated: When the console starts up, the HDD will spin up. The browser will find the HDD update, but the HDD unit will be switched off. After that, the HDD unit will be switched back on again.

I would simply write the files directly... no need to mess with images at all.
In the first place, when you image somebody else's disk image, some things like the next partition links may be severed. Which is why you're supposed to use WinHIIP to repair your disk's content after writing the image.

Unfortunately, it is hard to achieve that because you aren't meant to be able to control how the partitions are allocated. Even if you do somehow achieve that, there is a pretty good chance that it still wouldn't work once the disk is filled beyond 137GB because the last partition before the 137GB mark will still point to another partition after that; the browser may error out when it tries to list all installations.

Why not just simply use a 48-bit LBA-patched version? It's simpler and safer.

 

Unfortunately, APA (Aligned Partition Allocation) requires that marks for blank partitions be written to the harddisk at periodic intervals (128MB) until the end of the allocable space, thus creating what is called "APA chain".

If that is not done you have a broken HDD image. APA is not made for being "imaged" into drives. It's supposed to be created on the spot with parameters derived from the drive geometry. If they were doing what you're proposing they would be distributing broken HDD images.

 

If I understand you correctly (and I freely admit that there is a lot for me to learn here), _any_ HDD image is broken because the chance that someone's image matches up with another person's drive geometry is very slim. Hence the need to always repair all images with Winhiip. Having only an __mbr image that boots to uLE is arguably more broken, but it is only used (once) to run the FMCB installer. After that, the entire drive gets a proper format using uLE from the FMCB memory card rather than relying on the repair operations of a closed-source program. (From there they would presumably use the FMCB installer to install FHDB onto the drive.)

Even if there are no hiccups from Winhiiip, who's to say that the image itself isn't error-free (e.g. what if the original image copied from bad sectors)? If the ultimate goal is to get a clean setup with FHDB installed onto the drive, I still would prefer the method I proposed rather than using someone else's image and repairing with Winhiiip. It's not ideal, but it's faster and cleaner (at least in the end). My hopes still rest with sp193's installer (even if it is on indefinite hold

 

I wouldn't mind running a 48-bit version. However, I cannot seem to find any of the tools to patch my HDD OSD files to make it 48-bit. All my searches lead to images several GB large, and I prefer to avoid disk images. Even a text file with directions on what bytes to patch would be sufficient for me but I cannot even find that much.

 

rs1n imo you are making it more difficult then it is. there are no problems using a raw fhdb/hddosd img. i myself made a 3gb hddosd img that ive used on three different size hdds on three different ps2 models. also there is a 48 bit img made by krHACKen if you look for it

 

I probably am... however my HDD is already set. I did it exactly the way I described. The only thing that it is "missing" is a 48-bit HDD OSD which would be nice to have but not absolutely required. I do appreciate the ease of images as being a close-to-one-step method of getting started. But personally I avoid it because (perhaps I may be OCD) I prefer knowing exactly how my system is set up. Thank you for the tip on krHACKen's image. If I have another spare drive, I might check it out and then just copy the folders in __system. (And therein lies another annoyance -- downloading an image file even though only two tiny elfs are what I really need. And then even if the image is small, who's to say that after using dd, winhiiip won't mess something up even if I only image the first 1GB. I admit that in practice and in all likelyhood, nothing bad would happen.)

 

If you write a 40GB drive APA image into a bigger drive you will have all chain links, therefore the APA chain will be complete and it will work properly. But you will only be able to use 40GB regardless of the drive having 120GB or 1TB. If you cut the image, the resulting image will be missing links and the APA driver will refuse accessing the drive. You will need to run something to create the missing links (winhiip or hdldump salvage).

Was just commenting why images aren't clipped in the way you suggested.

 

those shared images are krHACKens experimental 48bit image just with the apps set up so no worries. hes the master at hddosd hacks. plus i believe hdd raw copy tool was used to create the images so bad sectors are skipped. the "cleanest" 48bit hddosd image you will find is krHACKens

 

In fact, my so-called LBA48 patched HDDOSD 1.10U is not completely patched for use with large HDDs. Only the main HDDOSD executable was patched. The other executables (MBR boot program and the filesystem checker) weren't haxed. It means that if for some reason the fsck kelf is run, it may damage the journal trying to access stuff >137GB.
The HDD image of this modified HDDOSD was built for proving the concept, years ago...

The properly patched files (by sp193) of the HDDOSD 1.00J are floating around.

As for the HDDOSD installation, the most reliable way to set it up, is to install it from a hacked HDD Utility Disc to a CLEAN HDD (not hex-edited or cloned with raw images), then replace its files manually.
To save you the hassle, I've extracted the osd100 folder from my HDDOSD 1.10U image. It's in PASTIE 10960369
Don't forget to delete/rename the fsck folder in your __system partition ... And prepare a bootable MC just in case...


The small __mbr images (like the __mbr.raw of uLE WIP 7) are only useful to set up a bootable PS2HDD from scratch. It's done by :
1) Wiping the HDD entirely
2) Writing __mbr.raw to the HDD
3) Booting the PS2 with the HDD so it goes to uLE
4) FORMAT the HDD from the HddManager, then run the FMCB Installer or the hacked HDD Utility Disc from the FileBrowser.

Can be useful to install FMCB to a MC too, since the point of writing the MBR this way is to run a MG DISK-signed (no MG CARD binding required) application in an unmodified system, then let the said application run an unsigned ELF...

Like @l_oliveira explained, overwriting a HDD with a dumped image breaks the APA scheme. This requires the user to "fix" the HDD contents with some other tools, although it's STILL hackish. Odd issues may appear later, like unable to create a new partition, or WinHIIP wasting the HDD contents trying to install a game...
That's why bundling homebrews with a MBR image for the purpose of running/installing them is moot point.

 

I guess this is what I have been trying to say (perhaps quite unsuccessfully):

After that, they can install apps. At any rate, I feel as though I have derailed OP's thread (sorry about that), but thank you all for your informative posts.

 

Pardon my ignorance but what is PASTIE?

 

pastie.org

 

@sp193 could you share your 48bit HDDOSD 1.00J please

 

@krHACKen is the fsck folder that comes from FMCB (installed onto HDD) safe to use? If so, can I simply copy fsck to fsck100 ?

 

@psydefx PMed

I don't know how the FHDBs fsck works, how it's launched and if it's compatible with $ONY's MBR.