All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ulf Bartelt <ulf@twc.de>
To: linux-lvm@msede.com
Subject: Re: [linux-lvm] SuSE/LVM boot problem
Date: Thu, 01 Jun 2000 14:15:50 +0200	[thread overview]
Message-ID: <393653F6.2D1C57B9@twc.de> (raw)
In-Reply-To: 39355918.C2B6A94B@msede.com

Michael Marxmeier wrote:
> AFAIR someone already did something similar by hacking the partition
> table  and creating an overlapping partition which just happened to
> map to the root LV.

someone == me.

It�d work if the root were the only partition but I preferred to do this
hack on /boot and /.


What do I gain?

I just refer /boot and / by the "partition aliases" in fstab and
lilo.conf and my system boots strictly conventional.

And when turning off lvm functionality becomes a must, the init.d-script
can safely switch lvm off and I�m still able to access /boot and /.

When the system crashes by eventually using wrong lvm tools, I still can
get up the essential file systems and insert the right lvm tools from
e.g. a floppy (I needed this once since 11-1999).


What do I loose?

/ and /boot appear as conventional partitions in all locations e.g. df
output. I cannot switch from partition alias to lvm addressing after the
system comes up. While not modifying the boot setup, /boot could be
mounted using the lv device, but I see no reason why this would make
sense...

Both partitions are flagged to be contiguous and <strong>I</strong> have
to remember, not to move them arround. I�d like to have a nonmoveable
flag in lvm instead...

If I�d resize or move /boot or /, I�d have to recalculate the faked
partition entries.

I have to tell the geometry of the boot drive to the kernel on booting
("append=" in lilo.conf is enough) cause the kernel guesses arround and
shows strange geometries if I do not...

As long as lvm is not launched and brought down by some kernel code like
the raid stuff, I thing this way is my favourite one...


Bye!
	Ulf.

  reply	other threads:[~2000-06-01 12:15 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-05-03  7:38 [linux-lvm] SuSE/LVM boot problem 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 [this message]
2000-06-01  9:01     ` David Gould
  -- 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 18:09 Andreas Dilger
2000-05-03 21:01 ` Eric M. Hopper
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=393653F6.2D1C57B9@twc.de \
    --to=ulf@twc.de \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.