Description of problem: After breating my head against the wal for about three days, I have come to the conclusion that it is not my problem but that pungi/loran is seriously broken. It cannot create an iso with working btrfs. When you boot the iso and there is a previously created good btrfs volume, here is what you get when you issue the command "btrfs fi show" -- btrfs: error while loading shared libraries: liblzo2.so.2: cannot open shared object file: No such file or directory Version-Release number of selected component (if applicable): Discovered on Fedora 19 but I see no reason that it does not exist also ojn Fedora 20 How reproducible: every damn time ... as you can tell, I am a little upset Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
OK, what is different about how livecd-creator uses lorax and pungi uses lorax to build the boot system. With livecd-creator, the result as a working btrfs whereas with pungi the result is as described above.
Progress. I was able to successfully create (with a working btrfs) a Fedora 19 ISO by using ONLY the Fedora 19 Everything repo ... no updates or anything else. Next will be to add in the updates repo.
This is pretty typical, and one reason why we don't respin install images. Packages we depend on make changes through the lifetime of a release so your best bet is to use the Everything repo with no updates when creating images.
The whole idea of the respin was to test some changes. I sure would like to understand just what causes btrfs to go tango-uniform. However, for the purposes of my test which involved two packages, I just ran a test with replaced anaconda-* and pykickstart and btrfs still works. However, it would be nice if punji/lorax could work in a general updates situation and ai just may keep plugging along trying to figure out just what is screwing things up. Then, the question is whether this condition could be detected and prevented. Looking at the packages that got brought in when I specified Fedora-Everything plus updates, there were some duplicates so there must be some screwed up dependencies in the updates repository. Close this but I may add more info here just to document things for other folks.
Turkey! This absolutely was a lorax bug!. See https://bugzilla.redhat.com/show_bug.cgi?id=997643 If you folks had published lorax-19.8.1 rather than sitting on it I would not have wasted all this time with this problem!. And then to clan that it was not a bug. I gyuess you a=have no idea what is going on in the product you have at least some responsibility for. Not that I had all my brain cells engaged either. I should have realized at once that when it said it could not find the library, then the problem was that it was not there. The reason that the old btrfs-progs worked is that it did not use lzo. I CONSIDER THAT PROBLEM OPEN UNTIL THE FIX IS PUBLISHED. For those who cannot wait, attataced is the patch.
Created attachment 818688 [details] fix for lzo
Gene, I'm going to ask you once to calm down and keep your Bugzilla conversations civil. Refer to the Fedora Code of Conduct: https://fedoraproject.org/code-of-conduct Bugzilla is open to Fedora users so users can communicate with developers about problems they run in to. This is not a customer service line and not an area where you can rant endlessly about a particular problem you are having. We work bugs with the users and contriburos, but remember that the developers are human too and can and do make mistakes (just like users). Please keep your Bugzilla comments considerate and respectful. *** This bug has been marked as a duplicate of bug 997643 ***
*contributors
I definitely apologize to one and all!!! I have myself to blame for all of this mostly! I must have take a handful of stupid pills when this first occurred because the message plainly said that liblzo.so.2 just was not there.