Jump to content

Make a proper Dual Boot


Dogway

Recommended Posts

What I care to stress about is that NO such thing as an EISA partition exists (if not in the perverted mind of the good MS guys) since something like 25 years (and actually never existed as a "standard").

EISA is (was) an update/extension to the ISA bus:

http://en.wikipedia.org/wiki/Extended_Industry_Standard_Architecture

On some machines equipped with that bus, a "hidden" partition containing the configuration utilities was created.

This partition had a partition ID of 12 which has NEVER been tagged (if not by the good MS guys) as EISA, as a matter of fact everyone know (knew) it as the Compaq Diagnostics partition:

http://web.archive.org/web/20030411231940/www.powerquest.com/support/primus/id233.cfm

http://www.ctyme.com/intr/rb-2270.htm

(Compaq was one of the "Gang of nine") because it was the firm that at the time made the first machines and particularly the first "commonly used" machines based on this bus.

The bus soon faded into oblivion, and was replaced by faster buses, such as VESA and later PCI.

But there was a precedent of a "hidden" partiion with id 12 that has been later used extensively by Compaq itself and later by other manufacturers (including Intel and IBM to name a couple) for Recovery or Diagnostics use, see:

http://www.win.tue.nl/~aeb/partitions/partition_types-1.html

Microsoft NT based systems - trying possibly to be smart - tag in Disk Management the ID 12 partition as EISA instead of "unknown".

A partition ID that means "nothing" in the sense that it DOES NOT IDentify a particular filesystem as it can contain everything and the contrary of everything should not be tagged with something that actually does not exist (and possibly NEVER existed), IMNSHO.

Dell's Recovery partitions normally have a partition ID of DE, see:

http://www.goodells.net/dellrestore/

http://www.goodells.net/dellutility/

if XP tags a DE partition as "EISA" it is twice wrong :w00t: (and no, that doesn't make it a right :no: ).

jaclaz

Edited by jaclaz
Link to comment
Share on other sites


It's a fairly well known fact, that if one OS can see another OS, it will try to "fix". I don't remember the details now, but XP and Windows 7 seemed to mess with one another.

There is no mention of a Windows 7 here, and there are simple workaround for your well known fact, that's what the OP is asking about . Saying "I don't believe in dual boot because it scares me" is not helping much, is it ? :unsure:

There are lots of ways of dual booting two XP on a same HDD, the basic is to understand what you do at first. Maybe try on an other blank HDD with OS you can mistakenly loose. Then you'll see how you can get them back up. Not much is lost until you format the wrong partition.

What I do is install both OSs, setting there own partition as active during install, then install Ranish Partition/Boot Manager that lets me choose at boot what partition becomes active and so what OS (always on C:) is booted. One C: becomes E: in the alternative scenario. My data partition (logical) remains D: in both cases. I never had a problem that I couldn't fix in 2 minutes.

Now Ranish is an old horse and I'm not sure how big a HDD it would support.

Link to comment
Share on other sites

@Ponch

Here we have a "third" factor which is the Recovery partition.

Until the exact nature (and booting/accessing mechanism) of it is ascertained, changing the MBR CODE is NOT a suitable solution :ph34r: , hence the suggestion to use a selection mechanism outside and beyond the MBR.

Risks connected to overwriting the MBR code (in the case it uses a proprietary solution like the mentioned "Softthinks") are detailed here:

JFYI, among the "self contained in the MBR only" bootmanagers, the current state of the art is (and it is since years) MBLDR:

@androemda43

Only to counterbalance your report, I have run for several years a multiboot PC with:

  • DOS (6.22)
  • Windows 98 SE
  • Windows 2000 (actually TWO installs of it)
  • Windows XP

without a single itch/issue/problem whatever (and each OS - within it's filesystem/addressing limits - could "see" the other installs).

Certainly the multi-boot setup was accurately planned, and it is very possible that Windows 7 may have issues with XP, but I do have a couple system where there is Windows 7 installed as "main" system AND there is an XP "service" partition (and each can see the other) where I have had not (yet) any issue whatsoever, time will tell.

I have run for years double boot XP+XP and never had a single issue, so unless you know for sure that there is some issues for XP32+XP64, your recommendation of preventing them to "see the other" seems overcautious (and in any case Dogway is going to have them NOT "see the other").

jaclaz

Link to comment
Share on other sites

Ok, I got some time. It's a bit hard to grasp, but let's see.

First, thank for explanation on the "EISA" partition, guess it shouldn't be called like that, but still, it applies as a partition right? so I assume partition orders don't change.

-Since I will be booting grub4dos from CD I guess I can skip the first code block (hd maps).

-So to start, I delete everything on my x64 partition, that is T:, and put inside a "tag file" (what file?).

-make x64 partition (third partition, right?) the root partition with:

root(hd0,2)

ls

-make the partition active (as in C:), while hiding current C: (my second partition after Dell diagnostic tools partition)

makeactive (hd0,2)

hide (hd0,1)

-reboot, and install XP x64 (I guess that at this stage on the Windows Install blue console x86 partition will be now hidden, true?), let it do the unattended, etc. reboot and load again grub4dos from CD to unhide XP x86 partition, make it active (default OS) by typing:

unhide (hd0,1)

makeactive (hd0,1)

-reboot again, it will boot into the only available OS at the moment that is XP x86. Change boot.ini to allow XP x64 to be accessed through default XP boot manager. Hide T: partition (C: on the XP x64 install) from Disk Management. Hide x86 partition from x64 OS as well.

FINISH

Well, correct my process if something is wrong. Also I have many questions:

1. what tag file do I place onto the empty third (x64) partition?

2. Can't I hide each other partitions by using the hide commands? or is it because

3. in the end we are not installing grub4dos right?, but only using them as an indirect way of managing the migrate file from the command line. And the reason for that is due to -> an unusual "recovery partition", which I called EISA, and contains the "Dell Diagnostic Tools" (this is actually a Precision 690 Workstation), so not recommended to rewrite MBR with grub4dos.

4. I would ask you then, how to hide them with disk management?, but I don't think that's too critical to know by now (probably well documented around?), more importantly, how to backup MBR? This should be the very first thing to do, true?

You are a master, have all the variables covered. Let me know if you need any info on my system.

edit: I access the Diagnostic Tools by pressing F12 at the very start of the boot process, in the same panel I am to press F2 to enter BIOS. Later it takes me to a similar panel to that of F8 with certain entries (Boot from each disk, load from CD, Reboot, Recovery, Diagnostics, etc) Youtube link

partitionsb.th.png

Edited by Dogway
Link to comment
Share on other sites

Carefully re-read jaclaz's instructions, taking notes if it will help you.

As to the tag file, he said:

[...] making on it a file like "thisis_64_bit_part.txt" is just a way to make sure that partition is the "right" one.

So make a txt file "thisis_64_bit_part.txt" with anything in it that you want. The purpose of it, as I understand it, is so that you can easily do a "ls" command, the grub4dos version of "dir" I believe, to confirm that you are in the right partition so you don't overwrite something you didn't mean to.

As to how to hide partitions using Disk Manager, he said:

So, the idea is not to "hide" the partition(s) but simply to NOT mount the "other" volume on each of the two installs.

The easiest is to use migrate.inf during setup to have it mount to a "different from C:" drive letter, let's say U:, and later, once install is complete, de-assign the drive letter from the volume.

meaning that in Disk Manager that you simply "de-assign the drive letter from the volume" and it will then be hidden, if I understood correctly.

Cheers and Regards

Link to comment
Share on other sites

-Since I will be booting grub4dos from CD I guess I can skip the first code block (hd maps).

Yes :thumbup , this is needed only if you boot form a hd-like device, such as a USB stick or external hard disk.

To the numbered points:

1. *any* file, the idea is just to have a file that you can see with the ls command (in order to make sure that you are on the "right partition". I suggested a (can be an empty file or a text file containing something like "Hello peeps! :)") named "thisis_64_bit_part.txt" but you can use any.

I guess an explanation needs to be made.

You are used to see partitions on the disk through Disk Management which shows them as a graphical map of the hard disk, i.e. representing them as a "stripe" with the beginning of the disk on the left and the end on the disk on the right, and with the various partitions represented in the order they occupy on the hard disk.

I will try to be more clear, the "first" partition in disk manager is the partition the occupies the first part of the disk (leftmost), "second" is the one to the right of it, etc, etc.

BUT a number of other addressing methods for partitions use NOT their position on disk but INSTEAD the position of the corresponding entry in the partition table.

The partition table has 4 "slots" or "entries" for writing partition address data (let's for the moment set aside Extended partition and Volumes inside it).

These entries are numbered, in grub4dos:

#0 is first partition entry

#1 is second partition entry

#2 is third partition entry

#3 is fourth partition entry

it is perfectly possible (and happens more often than not, and especially when a "Recovery" partition is involved in the setup) that a partition entry does NOT correspond to the order in which it is placed on disk.

Example, your "Recovery partition" may well be written to partition entry #0 BUT being placed at the END of the disk, OR, in one of the changes made in the past on the disk partitioning, entry #1 could be empty.

So a sensible thing to do (better be safe than sorry) is to check which partition corresponds to a given partition entry.

In grub4dos making a given partition (in the sense of the partition whose address data is written to a given partiion entry) root and then check which files are on it with ls is a quick way to make sure that you are dealing with the "intended" partition.

2. I am not sure to get the "meaning" of the question, right now, from what you report you have three partitions:

  • the Recovery partition (which is already hidden, otherwise your first - 32 bit - XP install would have NOT gotten the C: drive letter)
  • the partition (non hidden) where you have already the XP 32 bit installed (that you need to hide when installing the XP 64 bit)
  • the partition (non hidden) where you are going to install the XP 64 bit (that needs to remain non hidden in order to install to it)

3. Yes and no.

NO, as a matter of fact we are going to use grub4dos simply as a MBR partitiion table editing tool, you can do the same booting from a DOS floppy with (say) MBRwizard, or from a PE and using MBRFIX or *any* disk editor. grub4dos is simply more handy as it is easily bootable (from CD/DVD in your case), has NTFS read access, has direct (and IMHO simple/linear syntax) MBR partition table access.

YES, the idea is to NOT touch the MBR (i.e. NOT writing the grldr.mbr to the MBR AND following few sectors) because this may cause the impossibility to boot again the Recovery partition.

The "enhancement" (let's call it "difference" ;)) with the solution proposed by submix8c :thumbup is that in his solution grub4dos (still NOT installed, but called/invoked through the renaming of the files approach) the grub4dos becomes a "permanent" part of the booting sequence, whilst in the one I proposed grub4dos is just a tool to manage the MBR partition entries at install time.

If something is not really-really needed I find it better to NOT make it a key step of booting "forever", though nothing prevents from (as an eaxample) haveing grub4dos as a "third option" in the BOOT.INI.

I am FIERCELY against the concept of the RENAMING of the files (still better be safe than sorry) before or later it could happen that because of you, or a stupid windows update or anyway *somehow* the NTLDR file (which is a grldr under false name) is overwritten (or that some stupid software checks that NTLDR is actually the real NTLDR or whatever) creates an unbootable system or some other "damage" (additionally the renaming of the grldr may cause issues in more recent grub4dos builds)

The original idea of renaming was by spacesurfer:

http://www.911cd.net/forums//index.php?showtopic=18031

but later it was (hopefully) "bettered" by this:

i.e. by changing the filename invoked by the bootsector, so that files kept their original names.

4. There is NO provision in Disk Management to hide/unhide partitions AFAIK. Why do you think there are so many "third party" tools to manage the MBR? :unsure:

You will find tens of (wrong :ph34r: ) references about Diskpart being capable of hiding partitions, while most the connected commands are about assigning or removing the assignment of a drive letter to a volume, example:

http://forum.thewindowsclub.com/windows-tips-tutorials-articles/31678-how-hide-show-your-hard-drive-partitions-using-diskpart.html

There is however a way is to set a given ID to a partition, this is a RIGHT example:

http://defaultreasoning.com/2009/05/29/unhide-the-recovery-partition-on-a-basic-disk-with-diskpart/

Basically (at least for MS "recognized" parition ID's) any partition ID that begins with 1 means that it is a hidden partition of the type ID-10, like:

16 is a hidden partition ID 06

17 is a hidden partition ID 07

etc.

About backing up the MBR, we are before a doubt.

To backup ONLY the MBR the easiest would be a GUI tool, such as HDhacker:

http://dimio.altervista.org/eng/

the MBR is the first sector of the \\.\PhysicalDriven (n is the same as DISK #-1 in disk management or diskpart, i.e. first disk is \\.\Physicaldrive0, second disk is \\.\PhysicalDrive1, etc)

BUT in your case we don't know whether the "Recovery partition booting mechanism" relies on:

  1. the MBR only
  2. the MBR and *some* hidden sectors
  3. the MBR and all (normally 62) hidden sectors, i.e. first 63 sectors
  4. none of the above and the code is in the BIOS

To be on the safe side I would backup:

  1. only the MBR
  2. the whole first head (63 sectors)
  3. the whole set of hidden sectors (if not 63)

using a command line tool like dsfo (part ot the dsfok toolkit):

http://members.ozemail.com.au/~nulifetv/freezip/freeware/

the corresponding commands would be (choose the "right" n, for the first two :

dsfo \\.\PhysicalDriven 0 512 C:\mymbr.bin

dsfo \\.\PhysicalDriven 0 32256 C:\myhid.bin

for the third one you need to check how many hidden sectors you have (normally in a disk partitioned under XP is 63, but if it has been partitioned in Vista :ph34r: or later this number maybe different, normally 2048)

To check them quickly you can use the partition editor here (dtidata partition repair tool):

http://www.dtidata.com/ntfs_partition_repair.htm

http://www.dtidata.com/free_data_recovery_software/dtidata_partition_repair_tool.exe

99.99% you will have a partition with "Rel Sectors" (i.e. "hidden sectors" or "sectors before" or LBA offset of partition) of 63, in the 0.01% in which this does not happen, you will need to multiply it by 512, example for 2048 sectors 2048*512=1048576 and thus:

dsfo \\.\PhysicalDriven 0 1048576 C:\myhidall.bin

Take your time digesting the info, maybe I pushed too much in a single post....

jaclaz

Link to comment
Share on other sites

I HAVE to chime in! ( sorry - :blushing: )

Please bear in mind the difference between "Utility Partition" and "Recovery Partition". They may or may not be the same partition. It has yet to be ascertained if the second truly exists in order to (e.g.) "Restore To Factor" (from some sort of Images) -AND- are one and the same.

AFAICR, just the Partition Type is necessary for the BIOS (the F-whatever key) to boot to it, with or without the MBR code. I'll be glad to prove that "theory" with my Dell if you wish, but I DO believe I did that with my Brother's Dimension 4600 using it as a LiveXP/Recovery Solution (from the BBS Selection). How ODD that it was a Clean Install/Setup and used the Standard XP MBR, only having Type=DE in the first Partition (the Second as the "Standard" Type=07 Bootable) and WORKED.

Don't confuse the two or the ABSOLUTE necessity of the MBR code to access it. It may ONLY be needed IF Recovery is possible. :unsure: Easy enough for the OP to prove by backing up the Sector(s), using the MBRfix to "replace" it, then attempting to Boot to it via the BIOS Selection. IF it works, then the MBR has absolutely nothing to do with anything and IF there is absolutely NO Recover To Factory available then it becomes a moot point, not so? ;) (You can ALWAYS put the Original MBR back.)

I shall now again bow out...

Link to comment
Share on other sites

I was referencing a line of this post

"Later you can remove the drive letter from the "other" partition from each of the two XP's from Disk Management."

What is this for, "hide" my partition, unmount it?

What should I do then, the above Disk Management procedure, or the Disk Part one by setting a +10 new ID? I remember having issues with DiskPart on XP before, being unable to format a drive with custom block size.

I will backup the recovery partition right away in those explained 3 ways, but to clear things up yesterday I made a video of my system booting that you might have missed.

edit: I access the Diagnostic Tools by pressing F12 at the very start of the boot process, in the same panel I am to press F2 to enter BIOS. Later it takes me to a similar panel to that of F8 with certain entries (Boot from each disk, load from CD, Reboot, Recovery, Diagnostics, etc) Youtube link

partitionsb.th.png

I made it so you could tell me exactly if what I have is a recovery partition or a Utilities partition (I read that Utilities normally go first, and recovery last in partition order).

And in case that's not enough to know, ask you how can I know it (what exactly to backup, if any). FYI my system came installed with XP x64, if that helps.

Either way, I'm gonna backup those three meanwhile, so rather than "what to backup", "what to delete" (or replace, when a fix is called)

edit: backed up the MBR, and whole first head. Rel sectors showed 63, so only backed up those two.

submixc8: Is it risky to test that what you say? I already have the backups, anyway I will follow jaclaz guidelines in case there's a better way to know what kind of partition/booting mechanism I have.

Edited by Dogway
Link to comment
Share on other sites

Please bear in mind the difference between "Utility Partition" and "Recovery Partition". They may or may not be the same partition. It has yet to be ascertained if the second truly exists in order to (e.g.) "Restore To Factor" (from some sort of Images) -AND- are one and the same.

AFAICR, just the Partition Type is necessary for the BIOS (the F-whatever key) to boot to it, with or without the MBR code. I'll be glad to prove that "theory" with my Dell if you wish, but I DO believe I did that with my Brother's Dimension 4600 using it as a LiveXP/Recovery Solution (from the BBS Selection). How ODD that it was a Clean Install/Setup and used the Standard XP MBR, only having Type=DE in the first Partition (the Second as the "Standard" Type=07 Bootable) and WORKED.

I'm pretty sure I moved a Dell Diagnostic partition to the end of a disk two years ago and it was still working. Also keep in mind that Dell keeps changing the way they arrange their stuffs.That PC had 4 primary partitions out of the box. Thank you Dell.

Link to comment
Share on other sites

There were TWO points I was trying to make:

  1. there may be n different ways the "recovery" or "service" partition is booted
  2. there are (at least) THREE different ways to avoid automatic drive lettering

#1:

Ponch just confirmed what was hinted before and partially documented on mentioned Dan Goodel's pages, DELL (which BTW has historically and gerically a "quirk" for introducing changes in almost *anything* from BIOSes to XP install disks, and generally adopting NON-standard solutions) the "DE" partition can contain everything and the contrary of everything.

As well the video does not in any way provide means to know (for sure) the exact mechanism that is used to boot to the "DE" partition, the F2 may cause a jump to a routine fully embedded in the BIOS, chainload a "special" DELL MBR passing to it a "switch" parameter, chainload directly another sector on the hard disk, there are many possibilities.

Not knowing exactly the specific way the specific machine uses, backing up everything is logical, since it costs nothing (in terms of money) and very little (in terms of time).

#2:

The generic problem is the following:

How is it possible to avoid that a partition or volume is auto-mounted and/or that drive letters are automatically assigned to it?

Normaly an XP will autoassign drive letters along an algorithm that is detailed here:

but for what is needed here is VERY simple:

First Primary partition on first hard disk drive gets letter C:

There are at least THREE different ways to avoid that:

  1. (ONLY valid at Setup) use a migrate.inf to force the assignment of another letter to that partition (and force the C: to the other partition)
  2. (valid BOTH at setup and during "normal" operation) hide the First Primary partition in the MBR partition table, this way NO letter will be assigned to it.
  3. (ONLY valid during "normal" operation) force the unmount of the partition and/or assign to it NO drive letter

#1 is the most complex and thus more prone to error

#2 is the most simple BUT in the case of a dual boot needs a third party boot manager capable of hiding/unhiding partitions

#3 is simple and needs NOT the use of a third party boiotmanager BUT cannot be used at setup (actually during setup this aproach is the same as #1 and needs a migrate.inf)

The idea is to use the #2 (simpler) during setup and #3 (simple and needing not third party tools) during "normal operation".

One of the possible ways to do #2, i.e. hide the partition (in the MBR) through the use of grub4dos has been given, you can use any other tool to do the same.

Once the XP is installed, you unhide the partition (again any suitable tool can be used) and implement #3 by using Disk Management or Diskpart (or a direct Registry editing, whatever suits you).

jaclaz

Link to comment
Share on other sites

Hint - if the "Utility Partition" is within "Megabytes" then it's obvious it does not contain any "Restore/Recovery" Images and had to have been on a separate partition.

It's possible to "create" a "DellUtility" from downloaded (from Dell) Programs that don't contain Restore functionality. I've already tested this and will gladly provide the file names - no special MBR, just the DR-DOS(?) PBR and associated "testing" software. It works with the special "Fx" key AFAICR.

The OP has never said if this Server was purchased NEW or not. As I had previously stated in other threads, the "Restore DVD" and "Driver DVD" Dell supplies does not require any "special" partitions or MBR any more than the "Utility Parition", which can be created before the OS Install.

The question remains - Can the OP Fully Restore to Factory from the HDD? If not, then you have ONE of your answers.

Link to comment
Share on other sites

The question remains - Can the OP Fully Restore to Factory from the HDD? If not, then you have ONE of your answers.

But the answer is to a non-asked (or irrelevant) question. :whistle:

Is it advisable to backup the MBR (as is) if it is involved in the Fn thingy? YES. :yes:

Is it advisable to backup the MBR (as is) if it is NOT involved in the Fn thingy? YES. :yes:

No matter WHAT they contain is it advisable to backup also hidden sectors? YES. :yes:

Is there ANY cost or issue in doing the above? NO. :no:

Just §@ç#ing make a backup of them - NO MATTER WHAT - and move on to next step.

jaclaz

Link to comment
Share on other sites

"by using Disk Management or Diskpart (or a direct Registry editing, whatever suits you)."

Ok, so indeed I can use anything. Actually I was using a simple tool called "NoDrives Manager", I believe it just edits registry, but is handy so I was a bit worried when you mentioned "complex" stuff as dealing with Diskpart or Disk Management, because I was wondering if removing the letter in Disk Management wouldn't compromise partition data, guess not, right?

I already did the MBR backup as I said in my previous post, now I only need an application that allows me to restore it when necessary (MBRwizard?), will look on the same page I found the backup utility.

I also made the grub4iso following this page, and burned onto a CDRW (edit: actually it didn't work, I finally made the iso using the matching call of this page and worked):

http://www.rmprepusb.com/tutorials/makegrub4dosiso

I will anyway test it on a VM to play it safe and assure it works.

It really annoys me to deal with things I don't know as you described is common among Dell environments. I guess I should live with it, and restore MBR given the moment. That's precisely why I was so scared to touch this computer that I had a bit abandoned, now at last I could get into my hands most if not all the updated hardware controllers (Dell Support refused at the moment to even give me a component list of the system, to search drivers by myself), managed to reinstall windows and integrate the **** RAID controllers, and now backup the important stuff and know a little more about this heavily customised system by Dell. Now I know what I have and what to do with it, and in extension, take the most of it. I am greatly annoyed I can't run SeaTools DOS because my HDD's are under RAID, and I care a lot about HDD's integrity, when the time comes that the hard drive dies, I will need to replace it with another, I guess then I will know for real if I need the backed up MBR or not, right?

I hope to do the multiboot thing tomorrow and let you know how it went.

Edited by Dogway
Link to comment
Share on other sites

I sometimes don't get you. :ph34r:

After I spent so much time to try and explain you the matter, what do you come out with?

"NoDrives Manager" :ph34r:

It is this one I presume:

http://nodrvman.sourceforge.net/

that makes NO sense whatsoever, 15 Mb of bloat (smartly UPXed to a mere 5 Mb :whistle: ) that does a COMPLETELY DIFFERENT THING from what we have talked till now! :realmad: .

JFYI, that tools make a drive not visible in Explorer (this has NOTHING to do with hiding a partition in the MBR or remove drive letter assignment) :

http://www.ghacks.net/2007/12/16/hide-drives-in-windows-explorer/

http://www.pctools.com/guides/registry/detail/148/

You can use *anything* that does the SAME thing, not *anything* that does ANOTHER thing!

About the MBR, you asked for suitable tools which (obviously) allow BOTH the saving AND the restoring, and then you used another tool to do the backup AND don't know how to restore it if needed?

Hdhacker (as well as dsfi) can.

Same goes for grub4dos, you can ask instead of going on "random" sites, this one:

http://ptspts.blogspot.com.es/2009/07/how-to-create-bootable-cd-running.html

points to an obsolete version of grub4dos (which you were already told to avoid)

This other site:

http://www.rmprepusb.com/tutorials/makegrub4dosiso

uses a version of mkisofs and a command line for it that is overly complex and completely UNneeded for the scope at hand, the "simple" way, enough for your scope is detailed in the guide:

http://diddy.boot-land.net/grub4dos/files/install_cd.htm

jaclaz

Link to comment
Share on other sites

"...(or a direct Registry editing, whatever suits you)."

sorry, I thought "NoDrives Manager" was an indirect way of editing the registry you commented as an available option. I could do it myself, but I need to know exactly what entries to edit, especially after knowing that the NoDrives key is not the one you refer to.

I used your linked 0.4.5 version in google code and linked version of mkisofs from your posts from the very begginning, the only thing I borrowed from that randome page was the command call for the ISO creation, which happens to be the correct one described in the diddy.boot page. I already tested the CD and boots fine on grub.

I will do the thing later on, after I finish an ongoing encode.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...