Mailinglist Archive: opensuse (3336 mails)

< Previous Next >
Re: [SLE] Problems with initrd after mkinitrd
  • From: "Carlos E. R." <robin1.listas@xxxxxxxxxx>
  • Date: Wed, 28 Dec 2005 02:31:04 +0100 (CET)
  • Message-id: <Pine.LNX.4.61.0512280217590.18941@xxxxxxxxxxxxxxxx>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


The Tuesday 2005-12-27 at 19:18 -0500, Carl Hartung wrote:

> More fodder to keep you up at nights ;-)
>
> On Tuesday 27 December 2005 13:16, Patrick Freeman wrote:
> <snip>
> > (BTW, thanks for the input, Terry) Well, interestingly, all of the
> > machines were booting at cylinder 2082 prior to the mkinitrd problem --
>
> Each cloned drive should theoretically have /boot and initrd "land" in the
> same physical location when the image is written, correct? Yet, sometimes and
> for unknown reasons, the clone doesn't completely "take" and you have to
> reinstall Grub to make the system bootable. Hmm... interesting clue...
>
> Please tell me you meant "sector" as in LBA and *not* "cylinder" as in CHS
> addressing? <shiver!><Ugh!> (Pardon my flashbacks...!)

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.

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.

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.

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 ;-)

Let's wait and see! I'm curious :-)

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

iD8DBQFDseratTMYHG2NR9URAgFEAJ0Sfkiq3BWjKZS2lvekpZ2KV1l7EgCgg+s5
cWwWDPGpe5p7JuiPyeGShzg=
=5X4x
-----END PGP SIGNATURE-----


< Previous Next >
Follow Ups