linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Andreas Dilger <adilger@turbolabs.com>
To: Linux LVM mailing list <linux-lvm@msede.com>
Subject: Re: [linux-lvm] SuSE/LVM boot problem
Date: Wed, 3 May 2000 12:09:03 -0600 (MDT)	[thread overview]
Message-ID: <200005031809.e43I93R26551@webber.adilger.net> (raw)

David Gould writes:
> > Option 1 is way easier to implement, but has one big disadvantage: Whenever
> > you move physical extents, you have to re-run lilo.

> Yes. Would it be reasonable to have LVM tools check for this and warn
> the user?

You need to re-run LILO even if you move the kernel on a regular filesystem,
so I don't think it's that important if LVM doesn't warn you about this.
How often do you move LVs around anyways?  If you keep them in your /boot
LV and it's only a couple of PPs in size, it shouldn't be an issue.  Under
AIX, you are forced to have your boot LV contiguous (which I think LILO
doesn't need, as long as it is a single disk), and you are still required
to run "bosboot" if you move or mirror your BLV.

> If I have understood this, we need the following to make this
> work (some of this may already exist):
> 
>  - lvm needs to have a way of tracking/enforcing/satisfying the constraint
>    that specified lvs need to be in the bios bootable physical area

I think this can mostly be left up to the sysadmin for now.  I think if
LILO can handle LVs at all, it already complains if your kernel isn't
in a BIOS bootable area.

>  - lilo needs to understand about lvm and use the lvm provided ways to
>    get physical mappings.

How does LILO do this now?  It currently gets a filename for the kernel,
and that's it.  It must do some sort of internal calculation or IOCTL to
get the physical block numbers on the disk.  Is the problem that it does
its calculations w.r.t. the start of the partition?

>  - the kernel needs to be able to reconstruct enough of the lvm
>    descriptors to mount / at boot time.

You could always require that the / partition be contiguous, so it can
initially be mounted as ext2 directly.  If you want to resize your root
filesystem, you have to migrate the blocks after it to another location,
or move the whole LV to a contiguous region large enough for the new
size and re-run LILO.  I think it is already possible to specify an offset
into a block device for the / filesystem (think bootfloppy), so the kernel
could mount /dev/hda1 + X blocks read-only at boot, and when it goes to
mount read/write it remounts /dev/rootvg/lv00 as read-write.

I think I need to dig a bit more into the LILO code to see what's really
happening there.

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

             reply	other threads:[~2000-05-03 18:09 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-05-03 18:09 Andreas Dilger [this message]
2000-05-03 21:01 ` [linux-lvm] SuSE/LVM boot problem Eric M. Hopper
  -- strict thread matches above, loose matches on Subject: below --
2000-05-04 12:18 Shaw, Marco
2000-05-03 23:50 Andreas Dilger
2000-05-04  2:28 ` dgould
2000-05-04  5:21   ` Michael Loftis
2000-05-04  2:38 ` Eric M. Hopper
2000-05-03  7:38 Michael Marxmeier
2000-05-03 16:53 ` dgould
2000-05-31  9:01   ` Andi Kleen
2000-05-31 16:13     ` Christoph Hellwig
2000-05-31 16:18       ` Andi Kleen
2000-05-31 18:25         ` Michael Marxmeier
2000-06-01 12:15           ` Ulf Bartelt
2000-06-01  9:01     ` David Gould
2000-05-02  5:20 Marco Shaw
2020-11-27 16:17 ` Michael Marxmeier
2000-05-02 18:41   ` dgould
2000-05-02 21:22     ` Jan Niehusmann
2000-05-02 22:18       ` Heinz Mauelshagen
2000-05-03 10:05       ` Ulf Bartelt
2000-05-31  8:40       ` Andi Kleen
2000-05-03  0:15     ` Marco Shaw

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200005031809.e43I93R26551@webber.adilger.net \
    --to=adilger@turbolabs.com \
    --cc=linux-lvm@msede.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).