#$%#@## True Image
in [Computers]
|
From: Colin on 27 Oct 2006 02:11 "The Old Bloke" <le0pard32(a)gmail.com> wrote in message news:YWg0h.53939$rP1.20036(a)news-server.bigpond.net.au... > Then I shutdown the PC, changed drives to the cloned Samsung and booted. > Initially in the early parts of the boot, it said that TI was examining > the partitions, and then proceeded to complete a successful boot. > > I am writing this message from the new Samsung-booted OS. > > For my PC it seems that I have to start with an unpartitioned HD. This > may also be the case with Ghost 10, but I have not tried it. Good stuff That message is normal - I presume it is doing secret TI things to the drive and/or XP. Interesting about the partioned drive failing - I may have got into trouble if I had not let it destroy the partitions. Not gunna try tho. Colin
From: Rod Speed on 27 Oct 2006 02:47 Cerberus <styx.sentinel.PAY(a)FERRYMAN.gmail.com> wrote > Rod Speed <rod.speed.aaa(a)gmail.com> wrote >> Cerberus <styx.sentinel.PAY(a)FERRYMAN.gmail.com> wrote >>> Rod Speed <rod.speed.aaa(a)gmail.com> wrote >>>> The Old Bloke <le0pard32(a)gmail.com> wrote >>>>> I have always had a problem with TI in the clone mode. The >>>>> clone always seems to run OK but the cloned HD will not boot. >>>>> So yesterday I tried it again. All the C: files transferred. >>>>> The boot.ini looks OK but when I try to boot from the cloned >>>>> HD I get the message "Error loading operating system" >>>> The boot.ini is only a very minor component of the rather complex >>>> NT/2K/XP boot process, essentially just some config data that >>>> ntldr uses to decide what to offer the user menu wise etc. >>> boot.ini is far from a minor component Rod, >> Wrong. > Your admission is noted. Any 2 year old could leave that for dead. >>> and it does far more than provide basic data for a boot menu. >> Wrong. > Your admission is noted. Any 2 year old could leave that for dead. >>> boot.ini contains the ARC pathnames that >>> identify the location of the boot partition(s). >> In theory, yes. In practice when there is only one copy of >> the OS to boot from, the detail in the boot.ini is essentially >> irrelevant with a clone which did work fine in the original. > Bollocks. Have fun explaining how come you can have a working XP boot with the drive as one of the IDE drives, change that drive by jumpers etc to another location on that controller and change it to another ribbon cable, select that drive in the bios and have it still boot fine. > I suggest you read up on the ARC pathname definitions and the > restrictions of "multi" when relying on an int13 boot environment. I know what the parameters mean thanks, and actually have enough of a clue to have realised that you can move the drive around on the IDE controller AND STILL HAVE IT BOOT FINE WITHOUT NEEDING TO EDIT THE BOOT.INI >>> These pathnames identify the type of controller, the controller >>> number, the disk number and the partition number for any given >>> installation in the boot menu. They are crucial in identifying the >>> target partition to boot. >> Not with a clone where the original boots fine. > Irrelevant. Nope. > It all comes down to system geometry and > has nothing to do with the image source. Have fun explaining how come you can have a working XP boot with the drive as one of the IDE drives, change that drive by jumpers etc to another location on that controller and change it to another ribbon cable, select that drive in the bios and have it still boot fine. >>> The OP's problem is quite possibly related to the ARC >>> pathnames in his boot.ini not marrying up to the logical location >>> of the partition he is trying to boot. This is not at all uncommon >>> in cloning operations especially when cloning SCSI to IDE. >> Pity he isnt doing that. > It was only an example Rodney, try not to get too excited. Never ever could bullshit its way out of a wet paper bag. >>> The OP should ensure that his cloned disk is mounted in >>> the same position on the same adapter as the original disk. >> That isnt necessary. In fact XP will still boot fine if you move the >> drive on the controller. So it isnt as black and white as you claim. > I suggest you do some reading on the magic of int13 and the limitations > of boot.ini in an int13 environment before making further sweeping statements. Dont need to, I have enough of a clue to have realised that you can move the drive around on the IDE controller AND STILL HAVE IT BOOT FINE WITHOUT NEEDING TO EDIT THE BOOT.INI That evidence blows your pig ignorant claim completely out of the water, as always.
From: Rod Speed on 27 Oct 2006 02:51 Cerberus <styx.sentinel.PAY(a)FERRYMAN.gmail.com> wrote > Rod Speed <rod.speed.aaa(a)gmail.com> wrote >> Cerberus <styx.sentinel.PAY(a)FERRYMAN.gmail.com> wrote >>> lynx <none(a)nothere.com> wrote >>>> Rod Speed wrote >>>>> Thats an entirely different issue that is specific to Ghost. >>>>> Ghost plays silly buggers with the bootable partition, >>>>> basically so it can be initiated in Win and can reboot >>>>> into DOS and do its work at the DOS level. >>>>> When its work is finished, it cleans up that special bootable >>>>> partition it creates so it can boot into DOS to do the work. >>>>> When what Ghost attempts to do at the DOS level fails, >>>>> it never gets a chance to clean up that special bootable >>>>> DOS partition and restore the original bootable partition. >>>>> GhReboot.exe just does that cleanup manually. >>>> So any idea why it won't run when initiated from >>>> windoze but works fine from a DOS floppy boot? >>> HAL is the root cause of most of these limitations and workarounds. >> Nope, it just uses a special boot partition for the boot to dos. > Precisely because it is unable to access the disk > directly under an NT based operating system. Wrong, Ghost has precisely the same problem with Win9x too. Because the real problem is that it sets up a special dos boot partition when the Ghost job is initiated at the Win level. > Ghost has always had this limitation and this "special > boot partition" is nothing more than a workaround to > give the illusion that the software works under 2k etc. Wrong again, you get exactly the same effect under Win9x too.
From: Rod Speed on 27 Oct 2006 04:50 Cerberus <styx.sentinel.PAY(a)FERRYMAN.gmail.com> wrote > Rod Speed <rod.speed.aaa(a)gmail.com> wrote >> Cerberus <styx.sentinel.PAY(a)FERRYMAN.gmail.com> wrote >>> Rod Speed <rod.speed.aaa(a)gmail.com> wrote >>>> Cerberus <styx.sentinel.PAY(a)FERRYMAN.gmail.com> wrote >>>>> Rod Speed <rod.speed.aaa(a)gmail.com> wrote >>>>>> The Old Bloke <le0pard32(a)gmail.com> wrote >>>>>>> I have always had a problem with TI in the clone mode. The >>>>>>> clone always seems to run OK but the cloned HD will not boot. >>>>>>> So yesterday I tried it again. All the C: files transferred. >>>>>>> The boot.ini looks OK but when I try to boot from the cloned >>>>>>> HD I get the message "Error loading operating system" >>>>>> The boot.ini is only a very minor component of the rather >>>>>> complex NT/2K/XP boot process, essentially just some config data >>>>>> that ntldr uses to decide what to offer the user menu wise etc. >>>>> boot.ini is far from a minor component Rod, >>>> Wrong. >>> Your admission is noted. >> Any 2 year old could leave that for dead. > Yet quite obviously you can't. >>>>> and it does far more than provide basic data for a boot menu. >>>> Wrong. >>> Your admission is noted. >> Any 2 year old could leave that for dead. > Yet quite obviously you can't. >>>>> boot.ini contains the ARC pathnames that >>>>> identify the location of the boot partition(s). >>>> In theory, yes. In practice when there is only one copy of >>>> the OS to boot from, the detail in the boot.ini is essentially >>>> irrelevant with a clone which did work fine in the original. >>> Bollocks. >> Have fun explaining how come you can have a working XP boot with >> the drive as one of the IDE drives, change that drive by jumpers etc >> to another location on that controller and change it to another >> ribbon cable, select that drive in the bios and have it still boot fine. > because it hands the boot location off to the BIOS via int13. So much for your stupid pig ignorant claim about how crucial it is for the boot.ini entry to be correct IN HIS SITUATION. >>> I suggest you read up on the ARC pathname definitions and the >>> restrictions of "multi" when relying on an int13 boot environment. >> I know what the parameters mean thanks, and actually have >> enough of a clue to have realised that you can move the drive >> around on the IDE controller AND STILL HAVE IT BOOT FINE >> WITHOUT NEEDING TO EDIT THE BOOT.INI > because it hands the boot location off to the BIOS via int13. So much for your stupid pig ignorant claim about how crucial it is for the boot.ini entry to be correct IN HIS SITUATION. >>>>> These pathnames identify the type of controller, the controller >>>>> number, the disk number and the partition number for any given >>>>> installation in the boot menu. They are crucial in identifying >>>>> the target partition to boot. >>>> Not with a clone where the original boots fine. >>> Irrelevant. >> Nope. > Yep. >>> It all comes down to system geometry and has nothing to do with the >>> image source. >> Have fun explaining how come you can have a working XP boot with >> the drive as one of the IDE drives, change that drive by jumpers etc >> to another location on that controller and change it to another >> ribbon cable, select that drive in the bios and have it still boot fine. > because it hands the boot location off to the BIOS via int13. So much for your stupid pig ignorant claim about how crucial it is for the boot.ini entry to be correct IN HIS SITUATION. >>>>> The OP's problem is quite possibly related to the ARC >>>>> pathnames in his boot.ini not marrying up to the logical location >>>>> of the partition he is trying to boot. This is not at all uncommon >>>>> in cloning operations especially when cloning SCSI to IDE. >>>> Pity he isnt doing that. >>> It was only an example Rodney, try not to get too excited. >> Never ever could bullshit its way out of a wet paper bag. > Even a doddering old fool like you can come up with better than that. Never ever could bullshit its way out of a wet paper bag. >>>>> The OP should ensure that his cloned disk is mounted in >>>>> the same position on the same adapter as the original disk. >>>> That isnt necessary. In fact XP will still boot fine if you move the >>>> drive on the controller. So it isnt as black and white as you claim. >>> I suggest you do some reading on the magic of int13 and the >>> limitations of boot.ini in an int13 environment before making >>> further sweeping statements. >> Dont need to, I have enough of a clue to have realised that you >> can move the drive around on the IDE controller AND STILL HAVE >> IT BOOT FINE WITHOUT NEEDING TO EDIT THE BOOT.INI > because it hands the boot location off to the BIOS via int13 So much for your stupid pig ignorant claim about how crucial it is for the boot.ini entry to be correct IN HIS SITUATION. >> That evidence blows your pig ignorant claim >> completely out of the water, as always. > Even a doddering old fool like you can come up with better than that. Never ever could bullshit its way out of a wet paper bag. > Once again I suggest you read up on the > limitations of boot.ini in an int13 environment. So much for your stupid pig ignorant claim about how crucial it is for the boot.ini entry to be correct IN HIS SITUATION.
From: Rod Speed on 27 Oct 2006 04:52
Cerberus <styx.sentinel.PAY(a)FERRYMAN.gmail.com> wrote > Rod Speed <rod.speed.aaa(a)gmail.com> wrote >> Cerberus <styx.sentinel.PAY(a)FERRYMAN.gmail.com> wrote >>> Rod Speed <rod.speed.aaa(a)gmail.com> wrote >>>> The Old Bloke <le0pard32(a)gmail.com> wrote >>>>> I have always had a problem with TI in the clone mode. The >>>>> clone always seems to run OK but the cloned HD will not boot. >>>>> So yesterday I tried it again. All the C: files transferred. >>>>> The boot.ini looks OK but when I try to boot from the cloned >>>>> HD I get the message "Error loading operating system" >>>> The boot.ini is only a very minor component of the rather complex >>>> NT/2K/XP boot process, essentially just some config data that >>>> ntldr uses to decide what to offer the user menu wise etc. > Pig ignorant drivel from a doddering old fool who should know better. So much for your stupid pig ignorant claim about how crucial it is for the boot.ini entry to be correct IN HIS SITUATION. >>> boot.ini is far from a minor component Rod, >> Wrong. >>> and it does far more than provide basic data for a boot menu. >> Wrong. >>> boot.ini contains the ARC pathnames that >>> identify the location of the boot partition(s). >> In theory, yes. In practice when there is only one copy of >> the OS to boot from, the detail in the boot.ini is essentially >> irrelevant with a clone which did work fine in the original. > Pig ignorant drivel from a doddering old fool who should know better. So much for your stupid pig ignorant claim about how crucial it is for the boot.ini entry to be correct IN HIS SITUATION. > Here's a bone for you Rodney. > http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/prork/prbd_std_ccef.mspx > Check the int13 boot limitations and then review your pig ignorant > sweeping statements that reveal your underlying lack of understanding. So much for your stupid pig ignorant claim about how crucial it is for the boot.ini entry to be correct IN HIS SITUATION. |