[SOLVED] udisks without lvm crypto and assoicated crap
Linux From ScratchThis Forum is for the discussion of LFS.
LFS is a project that provides you with the steps necessary to build your own custom Linux system.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Distribution: LFS 9.0 Custom, Merged Usr, Linux 4.19.x
Posts: 616
Rep:
udisks without lvm crypto and assoicated crap
First, there's a little bit of ranting there. I HATE the whole udisks ecosystem. I just want a simple desktop automounter and since this scatter-brianed project started using libbblockdev, it's become a dependency hell.
Has anyone built this bloatware without lvm, cryptsetup, volume key and all that stuff? I have tried, I've opened GitHub tickets and the result is always the same: can't build a simple udisks2 without libblockdev pulling in lvm2 through some indirect dependency.
--without-crypto --without-lvm --without-lvm_dbus doesn't work. It still wants devmapper.
I hate this project... I hate it. I'm close to saying f-it and finding a way to script around it on the desktop. Most of them want udisks2 in one way or another though.
Distribution: LFS 9.0 Custom, Merged Usr, Linux 4.19.x
Posts: 616
Original Poster
Rep:
So I did manage to get libblockdev to build without that stuff. Then udisks killed it. Udisks wants libblockdev dmraid and libblockdev crypto. Crypto requires volumekey and... you guessed it LVM!
I'm going to see if there are alternatives to this windows 98 like dependency hell that udisks has become. It really is absolutely out of control. I miss the days when Linux was simple.
Distribution: LFS 9.0 Custom, Merged Usr, Linux 4.19.x
Posts: 616
Original Poster
Rep:
Okay, there is a temporary solution. In late 2018 the maintainers updated the 2.6.5 udisks2 package to 2.6.6 to patch a CVE. The only package this version needs is libatasmart. It doesn't 100% support LVM, encrypted volumes, software raid and many of the other plugins that are there to support enterprise stuff like Red Hat's VDO SAN products. But it will work for normal desktop stuff. volume_key, libbytesize, cryptsetup, LVM2, libaio and argon2 are all eliminated by using this version. It probably won't support encrypted usb sticks either, but I don't use those anyway, I just hard encrypt 7z/xz files when I have a need for that.
I may try and fork this and create a udisks-lite package, removing the LVM2/crypt support and focusing on basic mounting that is dbus compatible with udisks2. This would probably help them too, because they could eliminate all those --without flags in the full featured package.
I'm using udisks2 version 2.1.8 with current kde5 desktop. It has no stupid dependencies and does everything i want it to do. I build it just like the blfs book options except i add 'enable-fhs-media' to mount stuff on /media/<volume> instead of /run/media/user/<volume> ( i put a symlink in /media for my user: cd /media && ln -s . <user> ).
Distribution: LFS 9.0 Custom, Merged Usr, Linux 4.19.x
Posts: 616
Original Poster
Rep:
Quote:
Originally Posted by bryan_S
I'm using udisks2 version 2.1.8 with current kde5 desktop. It has no stupid dependencies and does everything i want it to do. I build it just like the blfs book options except i add 'enable-fhs-media' to mount stuff on /media/<volume> instead of /run/media/user/<volume> ( i put a symlink in /media for my user: cd /media && ln -s . <user> ).
That's what I was going for with the 2.6.6 version. Though, I chose that one because it has the patched CVE.
Finally got around to installing and testing usdiks 2.6.6 (upgrade from my 2.1.8). Compiles with the same options as the book and works fine - thanks for finding that. Now the only other old versions i'm using are librsvg, gdk-pixbuf, and firefox. This due to dependencies on rust which i will probably never build (Firefox is about to be replaced with "something" probably palemoon).
Distribution: LFS 9.0 Custom, Merged Usr, Linux 4.19.x
Posts: 616
Original Poster
Rep:
Quote:
Originally Posted by bryan_S
Finally got around to installing and testing usdiks 2.6.6 (upgrade from my 2.1.8). Compiles with the same options as the book and works fine - thanks for finding that. Now the only other old versions i'm using are librsvg, gdk-pixbuf, and firefox. This due to dependencies on rust which i will probably never build (Firefox is about to be replaced with "something" probably palemoon).
I download the community compiled rust that is a complete package, it's faster anyway. The curl installer gets everything piecemeal and building it yourself still requires you to download a pre-compiled rust binary. Since all current builds of rustc are self-hosted now, you can never really build rust "from scratch". That is, unless you go all the way back to the initial versions that were built on scheme (I think) and build forward to a recent version from there.
I guess you mean the standalone installer package from: https://forge.rust-lang.org/other-in...n-methods.html. That looks like it would be a possible option for me (download via public wifi, install offline). I will see how building palemoon goes first - that's what I'm using right now and I am pretty well satisfied with it (using the pre-built PM binary).
That will give you the standard build tools without hundreds of megabytes of docs and other utilities you don't want unless you're developing rust programs.
Distribution: LFS 9.0 Custom, Merged Usr, Linux 4.19.x
Posts: 616
Original Poster
Rep:
Building Palemoon:
You'll need GConf if you want to save settings, otherwise it has the same requirements as Seamonkey. Don't try to add system libs with commands from Seamonkey because the Palemoon developers maintain their own internally patched versions of those things. Things may break if you try to add system-libs they didn't make available in their config file. Finally, you don't need to add an ld.so.conf setting if you're installing in /opt because the dependencies are either statically linked or use rlib embedded paths during the build. Personally, I don't add a PATH statement either and simply create a symlink to /usr/bin.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.