* Re: [linux-lvm] Another strange setup by a newbie, but strange oops resulted while trying vgextend/vgmerge!
2001-01-03 13:13 ` [linux-lvm] Another strange setup by a newbie, but strange oops resulted while trying vgextend/vgmerge! Daniel Mitzlaff
@ 2001-01-03 13:55 ` Joe Thornber
2001-01-03 18:24 ` lewis
2001-01-08 16:05 ` Michael J. Declerck
2 siblings, 0 replies; 8+ messages in thread
From: Joe Thornber @ 2001-01-03 13:55 UTC (permalink / raw)
To: linux-lvm
> First, i ran into the same problems as reported before here on the list,
> vgmerge and vgextend give me OOPS while extending the LE counter for the
> VG.
Grab the latest code from the LVM_0-9-patches branch of cvs. You will
need to repatch/build the kernel module as well as the userland tools.
> other patches? (CVS snapshots are no choice!)
Then wait for the next release which shouldn't be too long.
> Ok, next ->
> What the heck are you guy's doing? I use a native RH6.2 installation w/o
> any updates/fixes (except for network security), using 2.2.17 and 2.2.18
> kernel-tarballs (the ..17 patches works well on ..18, only a few rejects
> which can easily inserted by hand;). But you CAN'T release a version that
> does not work w/o telling users if they had to look at some dependencies!
> (if there are some, remember i use a really clear RH6.2!)
???
The lvm-2.2.17 and 2.2.18 patches apply cleanly to the vanilla
kernel + rawio. The redhat kernel is almost certainly not a vanilla
kernel.
> reports and patches adressing this, but there's no help. And don't think
> all your users, who want to use LVM, are able to use CVS snapshots (i
> never use cvs snapshots on my server � release is release � features
> against bugs;).
I don't think 0.9 is quite ready for production systems. Maybe you
should play with 0.8.
- Joe
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [linux-lvm] Another strange setup by a newbie, but strange oops resulted while trying vgextend/vgmerge!
2001-01-03 13:13 ` [linux-lvm] Another strange setup by a newbie, but strange oops resulted while trying vgextend/vgmerge! Daniel Mitzlaff
2001-01-03 13:55 ` Joe Thornber
@ 2001-01-03 18:24 ` lewis
2001-01-08 16:05 ` Michael J. Declerck
2 siblings, 0 replies; 8+ messages in thread
From: lewis @ 2001-01-03 18:24 UTC (permalink / raw)
To: linux-lvm
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 5688 bytes --]
On Wed, Jan 03, 2001 at 01:13:14PM +0000, Daniel Mitzlaff wrote:
> First, i ran into the same problems as reported before here on the list,
> vgmerge and vgextend give me OOPS while extending the LE counter for the
> VG.
Joe has responded about this already.
> BUT, all my drives are filled up with data, there's NO BACKUP(!), and no
> way to take more than a single drive free for reformatting.
If this is a production system, you should really should have some backup.
There are plenty of things that can go wrong without even putting layers like
LVM into the picture. I agree that upgrading LVM should not mess up you're
data, but if you have no backup, you are taking a lot of risks no
matter what. I do understand that for home systems backup is a difficult issue,
but bad things do happen even with the most finely tuned systems. CD burners
are a cheap and effective way to backup user data, and hard drives are cheap
enough now that you could buy a cheap external drive with large capacity to do
backups to. That said, it is very unlikely that you will loose data to LVM.
Even the issues that have come up on the list don't cause data corruption.
> So, i tried the patches sent by Heinz not really knowing where to patch
> it in the lvm-userland, recompiled no change at all. Please, tell me
> if it is correct to use the patch at the userland-tools instead of
> patching the kernel-parts. And, can you tell me (and others) in which
> order we have to see the patch?, plain patch for native LVM0.9, are there
> other patches? (CVS snapshots are no choice!)
Which patches are you talking about here?
> Ok, next ->
> What the heck are you guy's doing? I use a native RH6.2 installation w/o
> any updates/fixes (except for network security), using 2.2.17 and 2.2.18
> kernel-tarballs (the ..17 patches works well on ..18, only a few rejects
> which can easily inserted by hand;). But you CAN'T release a version that
> does not work w/o telling users if they had to look at some dependencies!
> (if there are some, remember i use a really clear RH6.2!)
First of all, if you are using the stock redhat packages, and they don't work
with the new LVM stuff, please complain to RedHat. They are the ones that
should deal with that.
Secondly, what are you talking about? --> "version that does not work"
What is this? Are you using the RPMs off the sistina site? Did you compile
the packages yourself? If you used the sistina packages, make sure the liblvm*
files are removed from /lib. My initial packages installed into /usr/ instead
of root. I will get new packages out shortly that correct this problem. I
was hoping the transition issue would be resolved before I did this, but it
looks like I need to get new packages out first and then deal with that.
You can also look at
http://distro.conectiva.com.br/experimental/lvm/
for a version of the LVM packages that supports both the old (0.8.x) and the
new (0.9.x) interfaces.
> Ok, so please tell me where i can get a release that works on my server,
> it isn't uncool to me if i had to use an old but STABLE version but
> tell the users in all your released files WHICH version IS definitively
> STABLE.
Define stable. I don't know of any software package that is 100% stable.
There are always issues to track down. Point releases, such as LVM 0.9 are
especially prone to that. You should know that. If you are concerned about
it, don't upgrade immediately. Monitor the linux-lvm and lvm-devel mailing
lists and see what problems people have. That's why we archive the mailing
lists.
> Yes, as you can see, i read the complete ML about this problem, i found
> reports and patches adressing this, but there's no help. And don't think
> all your users, who want to use LVM, are able to use CVS snapshots (i
> never use cvs snapshots on my server release is release features
> against bugs;).
Good, I'm glad you are reading the ML. We are working on the issues. Heinz
has been out of contact for a few weeks due to a move and other issues, which
is delaying feedback. Sorry about that. :(
> Grmpf, ok all my frustration is left out, what can we do? ;)
> greetings, hackbyte -> hackbyte@gmx.de, IRCNet hackbyte @ #linux.de,
> +linux.de
I understand your frustration, but know that we are working on this. As I
said earlier, most point releases have issues that need to be worked out,
and LVM 0.9 is no exception. If you want a "stable" release, you
should probably use LVM 0.8.1 for now. LVM 0.9.1 should be out soon, which
should have all the *known* bugs fixed.
Regards,
--
AJ Lewis
Sistina Software Inc. Voice: 612-379-3951
1313 5th St SE, Suite 111 Fax: 612-379-3952
Minneapolis, MN 55414 E-Mail: lewis@sistina.com
http://www.sistina.com
Current GPG fingerprint = 3B5F 6011 5216 76A5 2F6B 52A0 941E 1261 0029 2648
Get my key at: http://www.sistina.com/~lewis/gpgkey
(Unfortunately, the PKS-type keyservers do not work with multiple sub-keys)
-----Begin Obligatory Humorous Quote----------------------------------------
THE LESSER-KNOWN PROGRAMMING LANGUAGES #16:
C- This language was named for the grade received by its creator when he
submitted it as a class project in a graduate programming class. C- is
best described as a "low-level" programming language. In fact, the
language generally requires more C- statements than machine-code statements
to execute a given task. In this respect, it is very similar to COBOL.
-----End Obligatory Humorous Quote------------------------------------------
[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [linux-lvm] Another strange setup by a newbie, but strange oops resulted while trying vgextend/vgmerge!
2001-01-03 13:13 ` [linux-lvm] Another strange setup by a newbie, but strange oops resulted while trying vgextend/vgmerge! Daniel Mitzlaff
2001-01-03 13:55 ` Joe Thornber
2001-01-03 18:24 ` lewis
@ 2001-01-08 16:05 ` Michael J. Declerck
2001-01-08 17:43 ` Daniel Mitzlaff
2 siblings, 1 reply; 8+ messages in thread
From: Michael J. Declerck @ 2001-01-08 16:05 UTC (permalink / raw)
To: linux-lvm
A short parable seems to be in order here.
There once was a large penguin rookery located on an island that was
designated as K-2.2.18. The penguin population that lived there was large
and plentiful due to the fact that it provided suitable protection and
sustenance. Due to this the population had grown large and was starting
to look for new territory to occupy. Lo and behold they discovered
a substantially larger island known as K-2.4.0 which had a wealth of
untapped resources that would allow the colony to expand in the future.
Unfortunately, the distance between K-2.2.18 and K-2.4.0 was large and
full of many unknown dangers (not the least of which were large killer
whales looking for tasty penguins to snack on).
Despite this, many of the penguin population decided that the risk and
effort necessary to reach K-2.4.0 was acceptable because of the
opportunities it provided. This divided the penguins into a number of
groups:
o Group #1 was composed of some of the elder penguins, who had made
successful ocean crossings in the past. They traveled together in a flock
so
as to mitigate their danger. They arrived successfully with only minor
injuries.
o Group #2 was formed from mature and adolescent penguins. When they
ventured forth they either swam in groups for protection or as individuals
who counted on their own strengths (speed and cunning) to insure a
successful journey. Despite this they still encountered dangerous schools
of jellyfish that inflicted damage upon some of them. These penguins
required some time to recuperate after completing their journey
Group #3 was made up of fledging penguins, who having seen others make the
journey, decided they could do so as well. They launched from shore with
a plan that consisted of nothing more than a dream of Island K-2.4.0 for
they were unexperienced in such endeavors. Many of them became lost
during the journey or were eaten by killer whales hunting for the
inexperienced. Of the remaining penguins, the majority turned back to
K-2.2.18. A few of the original group did make it K-2.4.0 and spent much
time recuperating from the exhausting swim and the mental trauma from having
seen their friends eaten.
Group #4 was all the other penguins left on K-2.2.18. These penguins waited
a number of months till the ocean calmed down and the killer whales migrated
to warmer waters. A this point the majority of them departed from K-2.2.18
for K-2.4.0 with friendly schools of dolphins to guide them (designated
Pod-RedHat, Pod-SuSe, Pod-Sistina, etc...). They arrived without incident
on K-2.4.0. Those left on K-2.2.18 maintained the rookery and lived happy
ever after.
The moral of the story -- If you are a Group #3 penguin don't expect
much sympathy from your wiser or more cautious
brethren when you get eaten.
---
Michael Declerck, declerck@sistina.com +1.510.823.7991
^ permalink raw reply [flat|nested] 8+ messages in thread