Radified Community Forums
http://radified.com/cgi-bin/yabb2/YaBB.pl
Rad Community Technical Discussion Boards (Computer Hardware + PC Software) >> PC Hardware + Software (except Cloning programs) >> Sector use in the First Track
http://radified.com/cgi-bin/yabb2/YaBB.pl?num=1335993593

Message started by Brian on May 2nd, 2012 at 4:19pm

Title: Sector use in the First Track
Post by Brian on May 2nd, 2012 at 4:19pm
I saw this today. It seems we may need to restore more sectors than the 63 sectors of the First Track if we are using Grub2 with a 2048 sector aligned source partition.


Quote:
One thing to be aware is that the Grub2 version used in Ubuntu 11.10 occupies 62 sectors in the first track. That could be the issue if you are using an older version of IFL (not sure how far back this would apply), since I believe the older versions did not restore that many sectors when First Track Sectors (on the restore options screen) is set to the default of "AUTO". So if you are using an older version of IFL, setting that value to 63 (rather than to "AUTO") could resolve the problem.

Edit: Also, if the source drive is using 2048 sector alignment, Grub2 then occupies 101 sectors in the first track, and in that case you have to set First Track Sectors to 101 (or higher), or the target system will not boot.


http://www.terabyteunlimited.com/ucf/viewtopic.php?f=4&t=534

Title: Re: Sector use in the First Track
Post by NightOwl on May 3rd, 2012 at 11:19am
@ Brian


Quote:
It seems we may need to restore more sectors than the 63 sectors of the First Track if we are using Grub2 with a 2048 sector aligned source partition.

Oh, my head hurts--so many little glitchy details to keep *track* of (pun intended  ;) )!

But, this brings up several questions--perhaps *rhetorical*--but, none the less....

Looking at the thread you reference above--verket states:


Quote:
I have two new identical machines.

I'm assuming he means hardware--but of course, no two machines are truly *identical*--they're *similar* in configuration and installed devices!


Quote:
I install Ubuntu 11.10 on one of them and back it up (entire disk) with IFL.

Creates a *whole disk* image.


Quote:
I use IFL (to) restore on the second machine (entire disk again)

So, *cloning* the first machine's *image* to the second machine.  (Hmmmm...was that second machine's HDD a blank *new* HDD--not already formatted or partitioned?--see later discussion.)


Quote:
and the partition structure and Ubuntu contents are restored just fine.

Obviously, NOT...because.....


Quote:
The second machine won't boot


I think verket needs to do a trial of *restoring* his image of the first machine back to that first machine--it may not boot depending on what IFL does by *default* once a boot region already exists on a HDD.

Older Ghost imaging programs will not *touch* the boot region once it exists--that's why you *have to* zero a HDD's boot region in order to get a restore of the boot information from an image on an existing HDD.  If you do not zero the boot region, Ghost leaves it alone (it will update the partition table)!  If you have a boot region virus or rootkit--it's still there!  I don't know if newer Ghost versions have the ability to *zero* an existing boot region during a restore to an existing HDD.

Brian, does IFL alter the boot region after it already exists.  If the *AUTO* setting does not over-write the boot region, are there over-rides in the IFL interface that allow you to force a zeroing of the boot region and restoring the boot region from the image?  If so, verket will need to restore that 101 minimum sectors if he's restoring the boot region from his image to that first machine--or probably no boot again!  If IFL does not touch the boot region, then GRUB2 should be unchanged, and restores should go just fine.


Regarding TeraByte Support(TB)'s response:


Quote:
(not sure how far back this would apply), since I believe the older versions did not restore that many sectors when First Track Sectors (on the restore options screen) is set to the default of "AUTO". So if you are using an older version of IFL, setting that value to 63 (rather than to "AUTO") could resolve the problem.

Edit: Also, if the source drive is using 2048 sector alignment, Grub2 then occupies 101 sectors in the first track, and in that case you have to set First Track Sectors to 101 (or higher), or the target system will not boot. That is true for all IFL versions.

I can understand an *older* version not being aware of *newer* Grub2's 62 sectors behavior.  (But, how many sectors did older Grub use in the past?!)

But I guess I don't understand how the most recent IFL version(s) are not able to inspect and/or recognize what's in the boot region or MBR!  It apparently does not *know* that the GRUB loader has various different *standards* as to how many sectors are used in the boot region--so I guess not so *AUTO*matic!

I know Ghost 2003, in its default mode, only restores *absolute sector zero*--and not the first 63 sectors of the boot track.  You can *over-ride* that behavior--if you know you need to--but it seems like newer imaging programs should be able to detect what's going on and adjust the *default* behavior to cover these new *standards* as to how the boot region is set up!

And, what's with the GRUB loader--having different sector usage standards depending on *alignment*! 

How does the *average* user even begin to anticipate all these nuances?!

Title: Re: Sector use in the First Track
Post by Brian on May 3rd, 2012 at 9:06pm
@ NightOwl


NightOwl wrote on May 3rd, 2012 at 11:19am:
How does the *average* user even begin to anticipate all these nuances?!

Imaging apps are no longer simple to use and the Win7 SRP has created further difficulties.

If you zero LBA-1 to LBA-62 and then install BIBM you will find data in sectors LBA-0 to LBA-8. I created another 5 partitions but no data was written to other sectors in the First Track. I assume that the "AUTO First Track Sectors" when restoring just restores the EMBR sectors that BIBM needs to function. Instead of AUTO you can enter a number in the field such as 63, 120, etc. (If you enter 0 then 63 sectors will be restored). I didn't know that the definition of AUTO has been changed in recent versions of the apps.

With Ubuntu and Grub2 the restore of the first 101 sectors is only relevant if you are restoring the image to a new HD. When you are restoring an image to the same HD, Grub2 is already present.

The TeraByte apps have different defaults depending on whether you are restoring an Entire Drive image or a Partition image. With an Entire Drive image the default is AUTO First Track Sectors. With a partition image the default is no First Track sectors are restored.


Title: Re: Sector use in the First Track
Post by Brian on May 3rd, 2012 at 11:26pm
@ NightOwl

Some practical numbers.

I zeroed the first few thousand sectors of a HD and created two 2048 sector aligned partitions. Ubuntu 12.40 was installed into one partition and Grub2 was installed to the MBR. On checking with DE there was data in LBA-0 to LBA-102. ie 103 sectors. Ubuntu booted OK. Images were created of Ubuntu and the Swap partition with IFD 2.70.

The first few thousand sectors were zeroed again and both images were restored with the AUTO First Track Sectors option. Ubuntu wouldn't boot. There was just a flashing cursor alternating with a restart. On checking with DE there was data in LBA-0 to LBA-62. ie 63 sectors.

IFD was used to restore the images over the top but I selected Restore 105 sectors. Ubuntu booted. On checking with DE there was data in LBA-0 to LBA-102 ie 103 sectors.

When you are using BIBM as a boot manager you have to install Grub2 into the partition boot sector instead of into the MBR. Installing Grub2 into the MBR would remove BIBM. So users of BIBM wouldn't experience the above issue.


Title: Re: Sector use in the First Track
Post by Brian on May 4th, 2012 at 2:00am
@ NightOwl

I mentioned earlier about using 0 in the Restore First Track field. I understood it restored all the First Track Sectors. I repeated the above test with zeroing of the first few thousand sectors of the HD.  The two images were restored using the 0 option. Ubuntu booted normally. DE showed the first 103 sectors contained data.

It looks like 0 is a better option than AUTO in this situation.

Title: Re: Sector use in the First Track
Post by Brian on May 4th, 2012 at 2:08am
And finally (maybe), restoring the two images to the same HD (Ubuntu working) but not restoring any First Track sectors. Ubuntu boots normally. DE showed data in the first 103 sectors.

Title: Re: Sector use in the First Track
Post by Brian on May 4th, 2012 at 2:32am
Another test. The first few thousand sectors of the HD were zeroed. The two images were restored but no First Track sectors were restored. DE showed data in LBA-0, boot code, disk signature and partition table. The remainder of the First Track showed zeroes.

Title: Re: Sector use in the First Track
Post by NightOwl on May 4th, 2012 at 11:55am
@ Brian

Great reporting of testing!


Quote:
When you are using BIBM as a boot manager you have to install Grub2 into the partition boot sector instead of into the MBR.

Not sure of this information--*partition boot sector*--I've not seen that terminology before--references?

You reported two different outcomes for *0*:


Brian wrote on May 3rd, 2012 at 9:06pm:
(If you enter 0 then 63 sectors will be restored).


Brian wrote on May 4th, 2012 at 2:00am:
I mentioned earlier about using 0 in the Restore First Track field. I understood it restored all the First Track Sectors. I repeated the above test with zeroing of the first few thousand sectors of the HD.The two images were restored using the 0 option. Ubuntu booted normally. DE showed the first 103 sectors contained data.

What's the difference?



Quote:
Another test. The first few thousand sectors of the HD were zeroed. The two images were restored but no First Track sectors were restored.

How do you select *no First Track sectors...restored* if *0* mentioned above restores all the boot region information?

Title: Re: Sector use in the First Track
Post by Brian on May 4th, 2012 at 4:09pm
@ NightOwl

The partition boot sector is the first sector in an OS partition.

http://www.ntfs.com/ntfs-partition-boot-sector.htm

I should have said install Grub to the Ubuntu root partition as I didn't realize Grub2 used so many sectors. You don't have to read much of the following...

http://www.terabyteunlimited.com/kb/article.php?id=279

When doing a partition restore, "Restore First Track" is not selected and AUTO is greyed out. In this default position no first track sectors are restored  but a new LBA-0 is created if LBA-0 had been zeroed. When "Restore First Track" is selected, AUTO becomes active and the first 63 sectors are restored. You can change AUTO to a number, 30, 50, 105, etc, and these sectors will be restored. I confused you with 0 (zero). 0 doesn't mean no sectors, it means "all sectors". Until yesterday I thought it meant all sectors in the First Track but I found it is smarter than that.

Tom Pfeiffer (the TeraByte thread I quoted) has made another comment about Grub2.

Title: Re: Sector use in the First Track
Post by Dan Goodell on May 4th, 2012 at 9:23pm
Very interesting information, Brian.  The inconsistent behavior of Grub2 sounds like a good argument for always installing it in linux root instead of the MBR.  Boy, the linux community isn't doing itself any favors by playing fast and loose like this.  They're never going to convince skeptics that linux is a stable alternative to Windows with shenanigans like this.

I wonder what the reason is for the inconsistent behavior between CHS-aligned and MB-aligned partition layouts.  Is there some compelling reason Grub2 needs all those extra sectors?  Or could this simply be a case of lazy programming by whomever wrote the new boot manager?

In Reply #3 you said, "On checking with DE there was data in LBA-0 to LBA-102 ie 103 sectors."  Are you saying that each and every one of the first 103 sectors had content in it?  Or are you saying there was content spread in an assortment of the first 103, but maybe not all of them?



Title: Re: Sector use in the First Track
Post by Brian on May 4th, 2012 at 9:51pm
Dan,


Dan Goodell wrote on May 4th, 2012 at 9:23pm:
Or are you saying there was content spread in an assortment of the first 103, but maybe not all of them?


There was content in every one of the 103 sectors. None were empty.

In Tom Pfeifer's last post he mentioned the number of sectors involved with Grub2 seems to differ with each Ubuntu release. I know the TeraByte apps can restore more than the first 63 sectors but which of the other imaging apps can do that?

Title: Re: Sector use in the First Track
Post by Brian on May 5th, 2012 at 2:28am
It's not just 2048 sector aligned partitions that are associated with Grub2 in the first 103 sectors. The same thing happens with a cylinder aligned partition if there is unallocated free space preceding the partition at the start of the HD.

Title: Re: Sector use in the First Track
Post by NightOwl on May 5th, 2012 at 9:19am
@ Brian


Quote:
I know the TeraByte apps can restore more than the first 63 sectors but which of the other imaging apps can do that?

Do the Linux folks have an imaging program like TeraByte's, Symantec's Ghost, etc.?

If so, does it have the flexibility to capture and restore all these various configurations?

Title: Re: Sector use in the First Track
Post by Dan Goodell on May 5th, 2012 at 2:32pm

Brian wrote on May 5th, 2012 at 2:28am:
It's not just 2048 sector aligned partitions that are associated with Grub2 in the first 103 sectors. The same thing happens with a cylinder aligned partition if there is unallocated free space preceding the partition at the start of the HD.


That's not what bothers me, though.  It stands to reason that a boot manager needs room for itself, so the first 63 sectors has always been the logical place for it.  And it's understood that one boot manager may use more of that space than another.

It's Grub2's apparent randomness that I find frustrating.  If Grub2 can work perfectly fine within 63 sectors on a CHS-aligned layout, why can't it do the same with a MB-aligned layout?  Why does it spread out just because it can?  That just feels like lazy programming.

That's the kind of inconsistency that hurts a product's reputation.  It reminds of Microsoft's Windows Backup.  Ever since Microsoft added a backup function to the OS back in the DOS days, it's been deemed unreliable because backups made with one version couldn't be restored with another version.  So if you thought you could backup your data, upgrade the OS and then restore your data, you'd be out of luck.  It seems like linux, or perhaps Ubuntu in particular, is falling into the same trap.



Title: Re: Sector use in the First Track
Post by NightOwl on May 6th, 2012 at 10:38am
@ Brian


Brian wrote on May 5th, 2012 at 2:28am:
It's not just 2048 sector aligned partitions that are associated with Grub2 in the first 103 sectors. The same thing happens with a cylinder aligned partition if there is unallocated free space preceding the partition at the start of the HD.

Do the installation instructions for GRUB2 inform you of this behavior?  Do they recommend placing the GRUB2 program wholly on the Linux partition rather than on the beginning boot track?

If you have a 63 sector boot track on a cylinder aligned partition--and GRUB2 goes past that 63rd sector--does the Linux installer *know* that the beginning of the partition has been used by GRUB2, and *knows* where to start the OS installation so as to not over-write the GRUB2 program file?

And, if you inadvertently use a tool that somehow damages the boot track in that first 63 sectors, and you re-install GRUB2 (now, there technically is no unallocated free space at the beginning of the OS partition), does GRUB2 now use only the first 63 sectors?

And, if you have GRUB2 taking up 103 sectors on a cylinder aligned HDD where it had the option to go past the initial 63 sector boot track, is there a way to tell TeraByte's imaging programs how many sectors to back up to capture that 103 sectors?  And, then use the above mentioned settings to restore those 103 sectors?  But, will the imaging program be able to restore the OS partition without somehow damaging the sectors after the first 63--will it know that GRUB2 is installed in sectors 64 through 103?

So many variables to control--can we control them?!


Title: Re: Sector use in the First Track
Post by Brian on May 6th, 2012 at 4:59pm
@ NightOwl

When I install Ubuntu I follow this tutorial and Grub2 is installed into the Ubuntu partition. You can't install Grub2 into the MBR and still have a functioning BIBM.

http://www.terabyteunlimited.com/kb/article.php?id=279

In the TeraByte forum thread I quoted, Tom Pfeifer said he'd check other Linux distros for the same issue. I used to think the TeraByte apps imaged the first 63 sectors whenever an image was created but they must image more sectors than 63 as you are able to restore 103 sectors. (By the way, there is no option about backing up sectors, only restoring them) In the above situation, restoring an Ubuntu image to a new HD, you would put 0 in the First Track Sectors  field and the appropriate number of sectors will be restored.

I can't answer your technical questions about Grub2.


Title: Re: Sector use in the First Track
Post by NightOwl on May 7th, 2012 at 9:43am
@ Brian


Quote:
(By the way, there is no option about backing up sectors, only restoring them)

Interesting--I guess we have to *know* what we're doing  ;) !


Quote:
I can't answer your technical questions about Grub2.

Not to worry.  My questions are often rhetorical to stimulate thinking about various topics--and to see if there are others out there with expertise that might contribute.

So, does Image for Linux represent an imaging technique similar to Image for DOS--you can only boot it from an optical disc or perhaps from a bootable partition?  Or, can it be *installed* to a Linux OS and used like Image for Windows from within the installed Linux OS?


Title: Re: Sector use in the First Track
Post by Brian on May 7th, 2012 at 3:29pm
@ NightOwl

You can run IFL from a CD, USB flash drive and a "bootfile". In addition it can be installed in a Linux OS but unlike IFW, it can only image non-OS partitions.

One advantage of IFL over IFD is it accesses the HD directly without using the BIOS. Depending on your BIOS, IFD sometimes doesn't see a USB external HD. IFL will see a USB external HD. IFD doesn't have networking. IFL does. If you get a chance have a look at the latest IFL GUI disk. It is very impressive with extra tools such as the OSDTool to assist with restoring to "different" hardware. I had fun restoring laptop images to desktops and getting the OS to load.

Title: Re: Sector use in the First Track
Post by Brian on May 29th, 2012 at 3:34pm
@ NightOwl

Restore First Track 0 restores the first 128 sectors.

Restore First Track AUTO restores the first 63 sectors but only if they have meaningful content. For example, you wipe the HD with random data, restore an OS image (without using Restore First Track) and then create a new OS partition image. Now wipe the HD with zeroes. Restore the newly created image with Restore First Track AUTO. The random content in LBA-1 to LBA-62 won't be restored. But if Restore First Track 0 is used the 127 sectors of random content following LBA-0 will be restored.


Radified Community Forums » Powered by YaBB 2.4!
YaBB © 2000-2009. All Rights Reserved.