Mailinglist Archive: opensuse (3336 mails)

["Carlos E. R." <robin1.listas@xxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


The Wednesday 2005-12-28 at 02:24 -0500, Carl Hartung wrote:

> On Tuesday 27 December 2005 20:31, Carlos E. R. wrote:
> > No, it is track, ie, cylinder. That doesn't imply that the disk are using
> > CHS addressing, but only that he is partitioning using track numbers, as
> > is usual in fdisk.
> 
> Hi Carlos,
> 
> As I'm sure you're aware ;-) roughly a minute after you posted this, Patrick 
> wrote that he meant "sector 2082" and not "cylinder." (I'm not convinced, 
> however, that /he's/ convinced, so I'm afraid we'll both have to stay 
> tuned...)

Yes, I saw it when I was going off. I connect by modem, I would have to 
reconect again to have answered that - and anyway, later he said cylinders 
again ;-)

> Also, did you know that fdisk can be used in units of 'cylinders' *or* 
> 'sectors'... your choice!  man fdisk ;-)

Yeah, I know... I'm old fashioned in this. Cylinder numbers are easier to 
handle, smaller, and some software still complains if the partitions end 
at the middle of a track, even if "track" no longer has a true physical 
meaning. A disk can have three real heads and report a dozen or a hundred!

It justs makes life easier ;-)

> 
> I don't know that Patrick was actually /using/ fdisk, only that sectors are a 
> natural metric for partitioning drives that use LBA.

True.


> > Also, I gather he is talking of mkinitrd images, ie, ramdisk images, not
> > the disk cloning images. It is something different. The systems crash
> > sometimes after changing the initrd image.
> 
> In retrospect, I can see how my choice of words might have confused you. Let 
> me clarify my understanding:

Yes, it clarifies the situation a lot, I hadn't noticed the first type of 
failure you mention.

> Patrick says he is experiencing two 'flavors' of boot failure:
> 
> - One, less frequent, is the failure of some of the cloned drives to boot 
> immediately after they've been created and installed. He is presently 
> overcoming this 'flavor' of boot failure by reinstalling Grub.
> 
> - The second 'flavor,' which is occurring more frequently, is a failure to 
> boot after modifying the normally running system and creating a new initrd 
> (with mkinitrd.) IOW, these cloned drives have /not/ failed to boot, 
> initially, and the systems have been running normally for some time. Then, 
> after installing updates, he's run mkinitrd and the systems suddenly fail to 
> boot. He is presently overcoming this 'flavor' by tarring up the drive 
> contents, repartitioning the drive and restoring the contents.
> 
> In both cases, the boot failures are occurring *only* on the drives that have 
> been cloned. He is not experiencing either type of boot failure in those 
> systems where the drives have been installed raw and the systems have been 
> built and upgraded from scratch.


I think he said later that this was not completely true.

However, the word "clone" gives me ideas for the first type of problem. 
How were they cloned?

The thing is, moderm HD are not "born equal", even if they are of the same 
model. The number of sectors vary - so says Seagate, I read it. It is due 
to the fact that some sectors fail after manufacture, and are just mapped 
out, or moved to the reserved space for bad block, so the user never 
knows.

Now, how does that affect cloning?

If the cloning software attemps to create an identical image in the same 
positions, couldn't some sectors fall where they shouldn't?

Just a wild idea.

Some imaging software, like ghost, that allow resizing the cloned image, 
would overcome this problem: it doesn't create an exact image. Other 
methods, like dd done on the device, would perhaps not - then I might be 
wrong.


> 
> Is the scope of his problem (and my comprehension of it) now clearer?

Yeap :-)

> 
> > I suggested that there could be a problem, in his case, when the image was
> > placed above some track number, perhaps 1024, and he is testing if that
> > hypothesis is correct by creating separate /boot partitions at low track
> > numbers.
> 
> But he is building new systems using contemporary components that support 
> Logical Block Addressing. As I understand it, these systems should have no 
> difficulty booting from any location on a 40GB disk.

Correct. That's the theory. ;-)

For example, in this system of 2000 vintage I installed a new 160 GB HD. I 
can boot old msdos 6.0 from it. But grub has problems with it! Even more, 
if I place the swap partition on it, suspend/awake is not reliable. I know 
the bios is old, but then, msdos does boot, and it shouldn't.


> > The base for my idea is that grub and lilo have to use bios calls at first
> > to read the disk, and the bios might have problems with those disks. Its a
> > wild, educated guess ;-)
> 
> I agree that the BIOS limitation you're alluding to is still a common problem, 
> but I think it only concerns older hardware than what Patrick is dealing 
> with. I am increasingly confident that the error lies somewhere in the realm 
> of drive address calculations and/or translations.

Yes, that should be the case, however... I wonder.


> That is /my/ educated guess. I am still thinking about ways to test the drives 
> for proof, though. Any ideas?

Mmmm... no...

- -- 
Cheers,
       Carlos Robinson
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Made with pgp4pine 1.76

iD8DBQFDsoSztTMYHG2NR9URAqpzAJ4o1XLDnUptx5JFn3cVviBZtL8YHACfZHzt
SEmSA3jwJ755+LgKKFc4uQk=
=S3qF
-----END PGP SIGNATURE-----