Re: [SLE] Problems with initrd after mkinitrd
- From: "Carlos E. R." <robin1.listas@xxxxxxxxxx>
- Date: Wed, 28 Dec 2005 13:27:21 +0100 (CET)
-----BEGIN PGP SIGNED MESSAGE-----
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
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
> 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.
> > 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
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
> Is the scope of his problem (and my comprehension of it) now clearer?
> > 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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Made with pgp4pine 1.76
-----END PGP SIGNATURE-----
Check the headers for your unsubscription address
For additional commands send e-mail to suse-linux-e-help@xxxxxxxx
Also check the archives at http://lists.suse.com
Please read the FAQs: suse-linux-e-faq@xxxxxxxx
- Prev by Date: RE: [SLE] Problems with initrd after mkinitrd
- Next by Date: Re: [SLE] RESOLVED Re: [SLE] dhcpd Doesn't Run
- Previous by thread: Re: [SLE] Problems with initrd after mkinitrd
- Next by thread: RE: [SLE] Problems with initrd after mkinitrd