[WBEL-devel] LVM version 1.0.8-5 broken

[Johan Broman]

Hi!

Just updated one of our WBEL machines yesterday night and ran into some problems
with the LVM update. It seems that all the files in the RPM-package has a .lvm1
suffix which of course throws off all the init-scripts, hence the machine is
now failing to vgchange -a y the volume groups. (and of course it is unable to
mount all my LVM filesystems)
I got around the problem y re-installing the original respin-1 RPM, but running
yum update would brake my machine again :(

Best Regards
johan

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

[Pavel Krebs]

Download SRPMS and build RPM yourself. Build it on WBEL with kernel 2.4
and RPM will be correct.

Pavel

Post by Johan Broman
Hi!
Just updated one of our WBEL machines yesterday night and ran into some problems
with the LVM update. It seems that all the files in the RPM-package has a .lvm1
suffix which of course throws off all the init-scripts, hence the machine is
now failing to vgchange -a y the volume groups. (and of course it is unable to
mount all my LVM filesystems)
I got around the problem y re-installing the original respin-1 RPM, but running
yum update would brake my machine again :(
Best Regards
johan
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
_______________________________________________
Whitebox-devel mailing list
http://beau.org/mailman/listinfo/whitebox-devel

[Raimo Koski]

Post by Pavel Krebs
Download SRPMS and build RPM yourself. Build it on WBEL with kernel 2.4
and RPM will be correct.

The real solution is to add more options to setarch.

[Johan Broman]

Hi Pavel!

I downloaded lvm-1.0.8-5.src.rpm, compiled it and installed it.

Works just fine!

Thanks!
johan

Post by Pavel Krebs
Download SRPMS and build RPM yourself. Build it on WBEL with kernel 2.4
and RPM will be correct.
Pavel

Post by Johan Broman
Hi!
Just updated one of our WBEL machines yesterday night and ran into some

problems

Post by Johan Broman
with the LVM update. It seems that all the files in the RPM-package has a

.lvm1

Post by Johan Broman
suffix which of course throws off all the init-scripts, hence the machine is
now failing to vgchange -a y the volume groups. (and of course it is unable

to

Post by Johan Broman
mount all my LVM filesystems)
I got around the problem y re-installing the original respin-1 RPM, but

running

Post by Johan Broman
yum update would brake my machine again :(
Best Regards
johan
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
_______________________________________________
Whitebox-devel mailing list
http://beau.org/mailman/listinfo/whitebox-devel

_______________________________________________
Whitebox-devel mailing list
http://beau.org/mailman/listinfo/whitebox-devel

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

[John Morris]

Post by Pavel Krebs
Download SRPMS and build RPM yourself. Build it on WBEL with kernel 2.4
and RPM will be correct.

The one I just built that way looks good, at least the names are right.
Added a .WB1 on the end of the package so it would overwrite the bad
version and up2date should have it as soon as the mirrors sync.

[John Morris]

Post by Raimo Koski
The real solution is to add more options to setarch.

Not really. The correct way to determine the kernel version to build for
would be to look at the kernel-headers package version if building
packages in a chrooted environment is the preferred way, and I think it
is. (The alternative being racks of seperate machines or user-mode linux
for sites trying to support diverse distributions, chroot is far easier.)

If somebody fixed setarch/uname for kernel version, next we would have
people looking down /proc or something for version info. Package
management should use it's own datastore whenever possible, nothing else
is really safe. I'd say it is a bug in the .spec so I opened #133309.

[Raimo Koski]

Post by John Morris

Post by Raimo Koski
The real solution is to add more options to setarch.

Not really. The correct way to determine the kernel version to build for
would be to look at the kernel-headers package version if building
packages in a chrooted environment is the preferred way, and I think it
is. (The alternative being racks of seperate machines or user-mode linux
for sites trying to support diverse distributions, chroot is far easier.)

Gfs does that (kernel-source, kernel-headers no longer exists), but I
think it is the only one from RH. Dag has several kernel module packages
and I think they are similar.
I agree on chroot, but you should do full install on a separate
partition, boot it to save at least env vars before copying it to subdir
on a larger partition. For example QTDIR=/usr/lib64/qt-3.1 on x86_64
will cause trouble when building KDE apps for x86. There might be other
gotchas and I intend to do some full builds and compare them before
relying on chrooted build environments. Dag has made about the same
mistakes as you and generally he and you may have good results, but
building a whole distribution should be on a more stable base.

[John Morris]

Post by Raimo Koski
Gfs does that (kernel-source, kernel-headers no longer exists), but I
think it is the only one from RH. Dag has several kernel module packages
and I think they are similar.

Eh? I thought they were eliminating kernel-source over at Fedora, since
it really doesn't have anything you can't get out of the srpm. Having to
install the kernel source to get the headers would be a big 'ol PITA.

Post by Raimo Koski
I agree on chroot, but you should do full install on a separate
partition, boot it to save at least env vars before copying it to subdir
on a larger partition. For example QTDIR=/usr/lib64/qt-3.1 on x86_64
will cause trouble when building KDE apps for x86. There might be other
gotchas and I intend to do some full builds and compare them before
relying on chrooted build environments.

You might want to nab the scripts I used and see what you can reuse from
them. I manage to get WBEL3 to cleanly install without needing to use
anaconda and a partition using just rpm and some bash tricks. Be advised
the script only works with the original 3.0, the respin needs a tweak or
two according to previous posts on this list. (add laus to the first
batch of packages, etc)

Post by Raimo Koski
Dag has made about the same mistakes as you and generally he and you may
have good results, but building a whole distribution should be on a more
stable base.

Guys like Dag are the ones who REALLY need packages building correctly in
a chroot. If I can ever get X working I'll probbaly start sticking to the
dogfood and running WBEL on my home machine, eliminating this particular
problem.... until I need to be supporting WBEL3 and WBEL4. But Dag is
supporting so many kernel versions he would need a pretty good stack of
buildhosts if he had to build everything on a real host.

[Raimo Koski]

Post by John Morris

Post by Raimo Koski
Gfs does that (kernel-source, kernel-headers no longer exists), but I
think it is the only one from RH. Dag has several kernel module packages
and I think they are similar.

Eh? I thought they were eliminating kernel-source over at Fedora, since
it really doesn't have anything you can't get out of the srpm. Having to
install the kernel source to get the headers would be a big 'ol PITA.

Gfs spec file copies the whole kernel source, adds gfs code and builds
all the modules for several archs. At least I believe so. It takes about
the half of the time of building kernel rpms, so I think I am right.
Kinda sledgehammer way of doing it, but it works and I am not going to
fix it. So headers is not enough for me and I really don't care what is
for others ;)

Post by John Morris
You might want to nab the scripts I used and see what you can reuse from
them. I manage to get WBEL3 to cleanly install without needing to use
anaconda and a partition using just rpm and some bash tricks. Be advised
the script only works with the original 3.0, the respin needs a tweak or
two according to previous posts on this list. (add laus to the first
batch of packages, etc)

Dag has similar install script in his dar package. Full install of LEL
is currently little over 5 GB and with the current cost of hard disks it
is about 2.5 $/EUR, so there is no sense in trying to save some space or
do tricks. That separate install partition can be used for testing and
comparing the results, so even that is not wasted.

It will take a while before I will start using chrooted builds. Lots of
interesting architectural problems. For example, concurrent builds needs
separate /usr/src for each chroot. Is local nfs or really big chroot
partition the best solution. I really don't want to redo it when I start.

[Milan Keršláger]

Post by Raimo Koski
Dag has similar install script in his dar package. Full install of LEL
is currently little over 5 GB and with the current cost of hard disks it
is about 2.5 $/EUR, so there is no sense in trying to save some space or
do tricks. That separate install partition can be used for testing and
comparing the results, so even that is not wasted.

You don't need separate partition since chroot works far better and it
is almost the same.

The only thing you need is to check your work for SPEC and configure
mistakes.

This is wrong to throw away chroot because somebody made a mistake only.

Post by Raimo Koski
It will take a while before I will start using chrooted builds. Lots of
interesting architectural problems. For example, concurrent builds needs
separate /usr/src for each chroot. Is local nfs or really big chroot
partition the best solution. I really don't want to redo it when I start.

I see no reason to have copy of /usr/src since you are able to block
concurent build of the same packages which is normal IMHO (you have to
have different chroots for different archs).

[Raimo Koski]

Post by Milan Keršláger

Post by Raimo Koski
Dag has similar install script in his dar package. Full install of LEL
is currently little over 5 GB and with the current cost of hard disks it
is about 2.5 $/EUR, so there is no sense in trying to save some space or
do tricks. That separate install partition can be used for testing and
comparing the results, so even that is not wasted.

You don't need separate partition since chroot works far better and it
is almost the same.

Well, it doesn't work better and it isn't the same. That install
partition should be used to install a distro, boot it, save env vars,
boot again to master, copy installed distro to chroot dir and repeat for
each distro desired. Later you can mkfs the install partition and copy
back the desired distro if you wish to boot it again. It is just 10GB
(could be less, but I am betting on the safe side) or about 5 $/EUR worth
of disk space. You get clean, original installs and can always boot to
original environment (well, booting is not as simple as I make it to be,
but doable, I am not running a class here). One of the best and most
cost efficient ways to solve problems is to throw more iron at them.
Disk space is really cheap.

Post by Milan Keršláger
The only thing you need is to check your work for SPEC and configure
mistakes.

Or rather fear for oddities and mistakes RH has made. J. Morris didn't
make a direct mistake with LVM, I would say he just wasn't defensive
enough against RH stupidities. And big thanks to him for making this
"mistake" and uncovering this problem.

Post by Milan Keršláger
This is wrong to throw away chroot because somebody made a mistake only.

Not my purpose. Just bringing problems to light.

Post by Milan Keršláger

Post by Raimo Koski
It will take a while before I will start using chrooted builds. Lots of
interesting architectural problems. For example, concurrent builds needs
separate /usr/src for each chroot. Is local nfs or really big chroot
partition the best solution. I really don't want to redo it when I start.

I see no reason to have copy of /usr/src since you are able to block
concurent build of the same packages which is normal IMHO (you have to
have different chroots for different archs).

/usr/src has linux source code which may differ. Some subdirs could be
shared, like /usr/src/redhat/RPMS for different archs, but if you have
different distro levels, you will have hard time separating packages for
those distro levels for distribution. Much easier to have the whole tree
separate for each chroot. Performance-wise you should have
/usr/src/redhat/BUILD on a different disk as well as /var/tmp to avoid
copying within one physical disk. Add RAID to that and it gets more
interesting..

[Milan Keršláger]

Post by Raimo Koski

Post by Milan Keršláger

Post by Raimo Koski
Dag has similar install script in his dar package. Full install of LEL
is currently little over 5 GB and with the current cost of hard disks it
is about 2.5 $/EUR, so there is no sense in trying to save some space or
do tricks. That separate install partition can be used for testing and
comparing the results, so even that is not wasted.

You don't need separate partition since chroot works far better and it
is almost the same.

Well, it doesn't work better and it isn't the same. That install
partition should be used to install a distro, boot it, save env vars,
boot again to master, copy installed distro to chroot dir and repeat for
each distro desired. Later you can mkfs the install partition and copy

As I said there is no reason for this and RH folks has chroot
environment for building too. Well maybe they are not building x86 stuff
on x86_64 (AMD64) box but this is not interesting part of the story.

If you would like, you can reboot to compile every one piece of a
package. But your binaries will be exactly the same as mine when
building in chroot (ok, only if somebody will not write SPEC file
dependent on running kernel - but I'm able to catch this sort of
troubles).

Post by Raimo Koski
/usr/src has linux source code which may differ. Some subdirs could be
shared, like /usr/src/redhat/RPMS for different archs, but if you have
different distro levels, you will have hard time separating packages for
those distro levels for distribution. Much easier to have the whole tree
separate for each chroot. Performance-wise you should have
/usr/src/redhat/BUILD on a different disk as well as /var/tmp to avoid
copying within one physical disk. Add RAID to that and it gets more
interesting..

This is all about I wrote here. Just use chroot to gain more power to
your hands.