sys-fs/udev git tree (will lead to udev-142) has vol_id removed and now requires blkid from util-linux. As blkid was recently moved there from e2fsprogs and patched for udev we are still installing blkid via sys-fs/e2fsprogs (version 1.41.4 for now). So this requires a new util-linux ebuild with changed configure parameters, that blocks (maybe eapi2-soft-blocker) older e2fsprogs. sys-fs/udev then will depend on new util-linux. Without udev this still will not guarantee to keep blkid on the system, if user only updates e2fsprogs.
It seems this will create a dependency-cycle: * e2fsprogs-libs provides libuuid and needs libblkid from util-linux * util-linux provides libblkid and needs libuuid from e2fsprogs-libs
OK, udev 142 is out. Why exactly do e2fsprogs-libs need libblkid ? It did provide it, but just lib/headers, not a program that linked with it. There is a program in sys-fs/e2fsprogs - blkid, of course, but e2fsprogs 1.41.5 have been released on 24.04.2009. In the release notes: Add support for disabling the built-in blkid library in favor of a system-installed blkid implementation via the configure option --disable-libblkid. So, we only need to bump the dep.
Main problem, I see here, is the check for installed libblkid in e2fsprogs' configure.in. Lets start with manual upgrade: - unmerge e2fsprogs (to prevent file collision) - add '--disable-libblkid' to e2fsprobs-libs ebuild and emerge it - change --with-fsprobe value to builtin in util-linux ebuild, make necessary changes (see below) and emerge it - add '--disable-libblkid' to e2fsprobs ebuild,make necessary changes (see below) and emerge it Upgrade complete. Necessary changes: - in e2fsprogs: don't sed any vars related to BLKID - in util-linux: libblkid gets installed in /lib with static lib and la file - portage dies in postinstall; my idea - remove la file, move static to /usr, add gen_usr_ldscript (bit similar to what was done in e2fsprogs-libs) However, I fear that doing that with portage will be a horror compared to e2fsprogs-libs introduction. At very least, a lot more patching will be involved. On a semi-related note: e2fsprogs seems to suffer from a parallel make heisenbug during src_install.
I think that for e2fsprogs-libs, that check for installed libblkid should simply be removed and this change should be sent upstream - that check is OK for e2fsprogs, but seems unnecessary for e2fsprogs-libs.
Created attachment 191210 [details, diff] updated Makefile patch I'd almost forgot - one of e2fsprogs patches needs to be updated.
(In reply to comment #5) > Created an attachment (id=191210) [edit] > updated Makefile patch > > I'd almost forgot - one of e2fsprogs patches needs > to be updated. SpanKY posted a patch in bug #267402 as well...
(In reply to comment #6) > SpanKY posted a patch in bug #267402 as well... > Technically, correct. But: 1. I missed that bug. 2. This bug suggests, that that it should be a tied version bump, just like baselayout/udev/sysvinit/openrc once were (at baselayout 2 migration). On a related note: what exactly is keeping baselayout 2 from stable ? There seem to be some open bugs, but it seems there's no activity there. Then again, unstable has been on v2 for about a year now.
Created attachment 191217 [details, diff] e2fsprogs ebuild I used As I started attaching files, I may as well attach the diff of the ebuild I used for e2fsprogs. It's probably not 100% correct, but it did work for me.
Created attachment 191219 [details, diff] diff of util-linux ebuild ...and to make things complete, diff of util-linux ebuild. This one should be simplified.
Alright, I'm currently running e2fsprogs{,-libs}-1.41.5, util-linux-2.15 with builtin blkid and udev-142 and it seems to work. If you want me doing any tests, don't hesitate to ask. (In reply to comment #9) > Created an attachment (id=191219) [edit] > diff of util-linux ebuild > > ...and to make things complete, diff of util-linux ebuild. > This one should be simplified. Rafał this patch from you makde /sbin/blkid from util-linux non-funtional as libblkid.so.1.0.0 becomes an ASCII text file and /sbin/blkid moans about it not being a valid ELF-file. When I remove your changes you did in src_install() everything works as expected.
> (In reply to comment #9) > > Created an attachment (id=191219) [edit] > > diff of util-linux ebuild > > > > ...and to make things complete, diff of util-linux ebuild. > > This one should be simplified. > > Rafał this patch from you makde /sbin/blkid from util-linux non-funtional as > libblkid.so.1.0.0 becomes an ASCII text file and /sbin/blkid moans about it not > being a valid ELF-file. When I remove your changes you did in src_install() > everything works as expected. > Then either you're removing the static lib, or we're using different versions of portage, cause for me, portage moaned if I moved static lib to /usr/lib (as portage wanted), but did not create linker script there. And of course it's an ASCII file, all the linker scripts are. And this is what 'ldd -r /sbin/blkid' prints for me: linux-gate.so.1 => (0xb8038000) libblkid.so.1 => /lib/libblkid.so.1 (0xb8000000) libc.so.6 => /lib/libc.so.6 (0xb7eba000) libuuid.so.1 => /lib/libuuid.so.1 (0xb7eb5000) /lib/ld-linux.so.2 (0xb8039000) But thanks for making me move to 142, I was leaving that as the last step and didn't do it till today. This made me notice, that my upgrade process has actually removed /sbin/blkid (probably unmerge-orphans problem during one of the later upgrades). I've reemerged util-linux and it's OK now.
On second thought, the upgrade process I documented is correct, incorrect was the way I've actually done it (instead of unmerging progs right at the start I waited till later, so when I finally unmerged them, they took blkid with them).
And on another semi-related note: hal 0.5.12 was released - this version uses util-linux blkid, instead of (removed) udev libvolume_id.
Following previous comment: Things link properly (with link script): ldd -r /usr/libexec/hald-probe-storage linux-gate.so.1 => (0xb7f1f000) libblkid.so.1 => /lib/libblkid.so.1 (0xb7ee7000) libhal.so.1 => /usr/lib/libhal.so.1 (0xb7ed5000) libdbus-1.so.3 => /usr/lib/libdbus-1.so.3 (0xb7e9c000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb7dcd000) libparted-1.8.so.8 => /usr/lib/libparted-1.8.so.8 (0xb7d7e000) libc.so.6 => /lib/libc.so.6 (0xb7c38000) libuuid.so.1 => /lib/libuuid.so.1 (0xb7c32000) libdl.so.2 => /lib/libdl.so.2 (0xb7c2e000) libdevmapper.so.1.02 => /lib/libdevmapper.so.1.02 (0xb7c16000) /lib/ld-linux.so.2 (0xb7f20000) But 0001-Add-Gentoo-specific-policies.patch needs to be updated - most of the non-Gentoo specific part (so, not the plugdev group) seems to got upstreamed, just VideoAdapterPM block seems missing.
As we discussed it, off the bug, the difference in our experiences is caused by different arches. I'm on x86. Defaults work there. On amd64, however, it seems that explicit '--libdir=/$(get_libdir)' needs to be passed, otherwise libblkid gets installed in an incorrect location (econf passes a different value on that arch).
Looking at the git, upstream is doing much. They're moving libuuid and uuidgen into util-linux and changing configure options - it looks like in the next release, the correct option will be called '--enable-libblkid'. I wonder, if e2fsprogs' upstream will add an option to disable that build in time, though util-linux will have an option to disable that build, so till they change the lib, it should not be a big problem.
Oh, and one more minor detail from the git: I don't have a reiserfs partition, so I can't tell how important that is, but libblkid got a typo fix that changes partition type name from 'reiser' to reiserfs'. If that was really a typo, that change should probably be included when this libblkid goes into the tree.
(In reply to comment #16) > I wonder, if e2fsprogs' upstream > will add an option to disable that build in time, > though util-linux will have an option to disable that build, > so till they change the lib, it should not be a big problem. > e2fsprogs-1.41.5 configure script already has an option --disable-libblkid.
In the context of comment 17, that particular 'it' meant libuuid.
So, is this going to happen in the near future? I have a set of unrelated hal fixes queued up for hal 0.5.12, but if this is going to take a while, I'll do another bump of rc1.
So my opinion is: This will be hold until util-linux-2.16, as that will also contain libuuid and so no circular depends will appear. According to Karel Zak it will be released in the next 3 weeks.
I'm using paludis with an ~amd64 system. After nothing that should effect blkid, just standard paludis -i world upgrades, I have a small problem. blkid doesn't exist on my system. I've recompiling e2fstools and util-linux and -neither- provides blkid at the moment. paludis -i1 sys-fs/e2fsprogs sys-libs/e2fsprogs-libs util-linux eix e2fsprog [D] sys-fs/e2fsprogs Available versions: 1.40.9 ~1.40.11 1.41.3 1.41.3-r1 ~1.41.4 ~1.41.5 ~1.41.6 {elibc_FreeBSD nls static} Installed versions: 1.41.6(08:09:51 06/03/09)(nls -elibc_FreeBSD) Homepage: http://e2fsprogs.sourceforge.net/ Description: Standard EXT2 and EXT3 filesystem utilities [D] sys-libs/e2fsprogs-libs Available versions: 1.41.3-r1 ~1.41.4 ~1.41.5 ~1.41.6 {nls} Installed versions: 1.41.6(08:08:44 06/03/09)(nls) Homepage: http://e2fsprogs.sourceforge.net/ Description: e2fsprogs libraries (common error, subsystem, uuid, block id) [D] sys-apps/util-linux Available versions: 2.13.1.1 2.14.2 ~2.15 ~2.15-r1 **9999 {crypt loop-aes nls old-linux selinux slang uclibc unicode} Installed versions: 2.15-r1(08:05:23 06/03/09)(crypt nls unicode -loop-aes -old-linux -selinux -slang -uclibc) Homepage: http://www.kernel.org/pub/linux/utils/util-linux-ng/ Description: Various useful Linux utilities
completely unrelated to this bug
util-linux-2.15.1 was released and contains libblkid and libuuid. As libuuid can be stripped of e2fsprogs-libs now this bug can progress. But there are unrelated changes: should util-linux or e2fsprogs install the /sbin/fsck wrapper. And: Where should uuidgen and uuidd be installed? e2fsprogs now does: /sbin/uuidd /bin/uuidgen util-linux-2.15.1 does: /usr/sbin/uuidd /usr/bin/uuidgen
Look incorrect to me: 2.15.1 still doesn't ship with libuuid, that's delayed to 2.16.
(In reply to comment #25) > Look incorrect to me: > 2.15.1 still doesn't ship with libuuid, > that's delayed to 2.16. > Ouch, yes you are right, I was still using util-linux-9999.ebuild in my tests.
would make more sense to me for util-linux to install the fsck wrapper. other people (like the BSDs) would certainly prefer this as well. the uuid stuff was a mistake and will be fixed in next e2fsprogs ebuild: econf \ - --bindir=/bin \ - --sbindir=/sbin \ + --with-root-prefix=/ \ but otherwise, their exact location is irrelevant -- nothing should be hardcoding paths to binaries. if a package isnt using $PATH, it is broken, end of story.
I ran in to an issue today where I needed to chroot in to my gentoo system to recover grub. /sbin/blkid still didn't exist in a default upgrades ~amd64 system. I had to copy a binary from an ~amd64 ubuntu box and hope it linked properly (it happened to work). Should I open another bug about this specifically, or is a proper set of dependencies going to be added so that -some- version of -something- provides blkid to make mounting by UUID work?
mjevans1983: you're still offtopic for this bug. But anyway, I fixed e2fsprogs to install the blkid/findfs binaries (but not the libs), in .6-r1. If util-linux starts installing the blkid/findfs binaries in a released version, then we can take them out of e2fsprogs again. vapier: the accidental removal of them broke various things, including genkernel under some cases, making systems unbootable :-(.
Created attachment 196047 [details, diff] change e2fsprogs-libs ebuild to not install libuuid and libblkid
Created attachment 196054 [details, diff] change util-linux ebuild to install libblkid, libuuid, fsck and blkid This patch updates util-linux to now released util-linux-2.16_rc1. This includes libblkid, libuuid and the apps fsck and blkid. The ebuild was lifted to eapi-2 for its soft blockers. Else one could not update e2fsprogs and util-linux. It no longer depends on e2fsprogs-libs, as it has libuuid and libblkid itself now. It blocks older e2fsprogs-libs for the libs and e2fsprogs for fsck and blkid binaries. Without the patches it does not need eautoreconf and libtool. Installation of the static libs should be checked by someone having insight into toolchain.
Created attachment 196056 [details, diff] update e2fsprogs ebuild to use extern libblkid and not install fsck, blkid and uuid Update e2fsprogs ebuild to not install fsck and uuidd binary. Add a blocker against newer util-linux for these.
(In reply to comment #30) > Created an attachment (id=196047) [edit] > change e2fsprogs-libs ebuild to not install libuuid and libblkid > With new version e2fsprogs-libs-1.41.7 there is the configure option --disable-libuuid.
ive added e2fsprogs 1.41.8 and util-linux 2.16 which moves the libs, but no KEYWORDS. give it a spin to see if things work for you before i unmask.
(In reply to comment #34) > ive added e2fsprogs 1.41.8 and util-linux 2.16 which moves the libs, but no > KEYWORDS. give it a spin to see if things work for you before i unmask. > For me it works fine. system with udev-145 boots up normal. But udev-145 will stay masked until I checked some other things to be done before. Like submitting bugs for all users of old vol_id. The only critic point about new ebuilds is: The fsck binary from util-linux is a bit cryptic for end-users. Calling old fsck without parameters printed "fsck 1.41.3 (12-Oct-2008)" and ended. New one guesses I want to fsck my root partition: fsck fsck from util-linux-ng 2.16 reiserfsck 3.6.21 (2009 www.namesys.com) ************************************************************* ** If you are using the latest reiserfsprogs and it fails ** ** please email bug reports to reiserfs-list@namesys.com, ** ** providing as much information as possible -- your ** ** hardware, kernel, patches, settings, all reiserfsck ** ** messages (including version), the reiserfsck logfile, ** ** check the syslog file for any related information. ** ** If you would like advice on using this program, support ** ** is available for $25 at www.namesys.com/support.html. ** ************************************************************* Will read-only check consistency of the filesystem on /dev/mapper/vg2-slash Will put log info to 'stdout' Do you want to run this program?[N/Yes] These experiments continue if one trys to add --help or ---help. But I guess we should open a new bug.
are you sure ? $ qfile -v /sbin/fsck sys-fs/e2fsprogs-1.41.3-r1 (/sbin/fsck) $ fsck fsck 1.41.3 (12-Oct-2008) e2fsck 1.41.3 (12-Oct-2008) /dev/sda3 is mounted. WARNING!!! Running e2fsck on a mounted filesystem may cause SEVERE filesystem damage. Do you really want to continue (y/n)?
(In reply to comment #36) > are you sure ? > > $ qfile -v /sbin/fsck > sys-fs/e2fsprogs-1.41.3-r1 (/sbin/fsck) > > $ fsck > fsck 1.41.3 (12-Oct-2008) > e2fsck 1.41.3 (12-Oct-2008) > /dev/sda3 is mounted. > > WARNING!!! Running e2fsck on a mounted filesystem may cause > SEVERE filesystem damage. > > Do you really want to continue (y/n)? > Strange. Maybe my chroot did confuse fsck. Then I have no more bugs about the new ebuilds. :)
i agree it's a stupid default, but it isnt a regression, so i'll move to ~arch thanks for testing
This is not yet in ~arch.
(In reply to comment #39) > This is not yet in ~arch. > Now it is.
