Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
Hi, i have modified EVMS alocal.m4 to get rid of glib version 1. So i could free some more place on my box :) EVMS text gui uses now glib version 2. Sorry i don't have gtk+ 1.2 installed on any of my computers. It depends on the glib-1 library so i couldn't check if it is still working with the modification i made. The new available EVMS patches can be found at http://evms.sourceforge.net/patches/2.5.5/engine/. They need to be installed in the files/2.5.5/ directory. I didn't develop a gtk interface (lack of skills), so i prefer not to integrate Alexey Maximov's patches (amax@fantoo.org) that he developed for the EVMS version 2.5.4 I hope this helps Jj
Created an attachment (id=100164) [edit] evms-2.5.5-r3.ebuild
Created an attachment (id=100165) [edit] aclocal.patch
Created an attachment (id=100166) [edit] cli_query_segfault.patch http://evms.sourceforge.net/patches/2.5.5/engine/
Created an attachment (id=100167) [edit] cli_reload_options.patch http://evms.sourceforge.net/patches/2.5.5/engine/
Created an attachment (id=100168) [edit] ntfs_unmkfs.patch http://evms.sourceforge.net/patches/2.5.5/engine/
Created an attachment (id=100169) [edit] raid5_algorithm.patch http://evms.sourceforge.net/patches/2.5.5/engine/
Created an attachment (id=100253) [edit] new version with static glib for the gui Hi, i added a static-glib flag. Now evmsn works even when /usr isn't mounted (i hope it will :). You need also a new glib ebuild that include a static option. See glib ebuild attachment below.
Created an attachment (id=100255) [edit] glib with static option Possibility to get a static glib with the dynamic one.
(In reply to comment #1) > Created an attachment (id=100164) [edit] > evms-2.5.5-r3.ebuild > May I suggest you apply the patches in chronological order? I don't know if this is the canonical order, but it makes sense that it would be the safest one. Here is the time-ordered listing of the current release patch set at http://evms.sourceforge.net/patches/2.5.5/engine/ : 2618 2006-04-20 09:16:56 -0700 md_super_fix.patch 1605 2006-05-04 15:00:13 -0700 ntfs_unmkfs.patch 1672 2006-05-05 10:55:33 -0700 raid5_degrade_fix.patch 1055 2006-05-10 14:50:32 -0700 raid5_remove_spare_fix.patch 1215 2006-05-10 14:51:27 -0700 raid5_remove_spare_fix_2.patch 562 2006-06-08 12:03:06 -0700 raid5_algorithm.patch 542 2006-09-01 09:58:26 -0700 cli_reload_options.patch 1255 2006-09-14 07:49:39 -0700 cli_query_segfault.patch 1230 2006-11-01 07:13:21 -0800 get_geometry.patch 1109 2006-11-01 15:16:09 -0800 BaseName.patch Also, the last two, get_geometry.patch and BaseName.patch, both bug fixes (the first a workaround for a Linux kernel change starting in 2.6.17, and the second an important bug fix) are not in your evms-2.5.5-r3. So, I am going to build an updated evms-2.5.5-r3 with those in it and attach it here. I didn't study the other issue, but it is true that when I'm installing EVMS, I have to manually make it runnable from a non-/usr mounted system by moving and/or copying all of the relevent files to the root filesystem and doing appropriate ldconfigs, and such. Of course this is vitally important, since whenever I use EVMS to resize /usr filesystem to something smaller, I have to first unmount /usr, then run EVMS (such as evmsn). Is that solved in your ebuild? That would sure be great.
First, additional comments: * The changes I made are important nonexperimental changes. * The current portage tree has another method of doing static glib than the one mentioned in the above attached glib ebuild. * The get_geometry.patch is necessary for my systems to boot, so it's not just some random bug fix that no one needs. Because of that, I am not sure wihch version of ebuild to work with. So, I just essoterically grabbed the most recent ebuild above and then updated it, then also updated a pure ebuild (starting from evms-2.5.5-r2.ebuild) with the same name (evms-2.5.5-r3.ebuild) with only my changes in it. I'll attach them both now. I did test that the chronological ordering of patches I put in works.
Created an attachment (id=101581) [edit] Most recent -r3 proposed above updated with EVMS release patches
Created an attachment (id=101582) [edit] evms-2.5.5-r3.ebuild only -r2 with latest release patches
Created an attachment (id=101583) [edit] get_geometry.patch http://evms.sourceforge.net/patches/2.5.5/engine/get_geometry.patch
Created an attachment (id=101584) [edit] BaseName.patch http://evms.sourceforge.net/patches/2.5.5/engine/BaseName.patch
(In reply to comment #12) > Created an attachment (id=101582) [edit] > evms-2.5.5-r3.ebuild only -r2 with latest release patches Ok, after some thought about how to tame these multiple kinds of changes, since evms-2.5.5-r2 isn't yet unkeyworded in release portage (i.e., it's still KEYWORDS ~x86), I suggest you just take my last "evms-2.5.5-r3.ebuild built from -r2" version above and make it the new evms-2.5.5-r2.ebuild in the current tree, since it's a very conservative change to include release patches. Then, the enhancement request above regarding glib and static and stuff can be reestablished in reference to the new evms-2.5.5-r2 version. Right now, this bug is marked as an Enhancement P2; I tried setting it at Critical P2 until the release patches make it in, but I don't have permission. (It is actually a BLOCKER for me with Linux kernel versions starting at 2.6.17.) Then, after the EVMS release patches are in the ebuild portage tree, then someone can set the severity back down. Perhaps someone can set it up for now? If this doesn't get traction soon, I'll just file a new bug (but I've been yelled at about entering "duplicate" bugs in bugzilla so I'll wait a very short bit before doing that). If you want a fresh copy of the release patches to load, here they are (they go into $PORTDIR/sys-fs/evms/files/2.5.5/): http://evms.sourceforge.net/patches/2.5.5/engine/md_super_fix.patch http://evms.sourceforge.net/patches/2.5.5/engine/ntfs_unmkfs.patch http://evms.sourceforge.net/patches/2.5.5/engine/raid5_degrade_fix.patch http://evms.sourceforge.net/patches/2.5.5/engine/raid5_remove_spare_fix.patch http://evms.sourceforge.net/patches/2.5.5/engine/raid5_remove_spare_fix_2.patch http://evms.sourceforge.net/patches/2.5.5/engine/raid5_algorithm.patch http://evms.sourceforge.net/patches/2.5.5/engine/cli_reload_options.patch http://evms.sourceforge.net/patches/2.5.5/engine/cli_query_segfault.patch http://evms.sourceforge.net/patches/2.5.5/engine/get_geometry.patch http://evms.sourceforge.net/patches/2.5.5/engine/BaseName.patch P.S., this does not include the DM INPUT patch I describe in http://gentoo-wiki.com/SECURITY_LVM_and_EVMS_over_cryptsetup-LUKS, and I won't update that wiki until you've updated the evms ebuild to include the evms 2.5.5 release patches (or if 2.5.6 comes out sooner, that).
(In reply to comment #9) > (In reply to comment #1) > > Created an attachment (id=100164) [edit] > > evms-2.5.5-r3.ebuild > > > > May I suggest you apply the patches in chronological order? I don't know if > this is the canonical order, but it makes sense that it would be the safest > one. Here is the time-ordered listing of the current release patch set at > http://evms.sourceforge.net/patches/2.5.5/engine/ : > > 2618 2006-04-20 09:16:56 -0700 md_super_fix.patch > 1605 2006-05-04 15:00:13 -0700 ntfs_unmkfs.patch > 1672 2006-05-05 10:55:33 -0700 raid5_degrade_fix.patch > 1055 2006-05-10 14:50:32 -0700 raid5_remove_spare_fix.patch > 1215 2006-05-10 14:51:27 -0700 raid5_remove_spare_fix_2.patch > 562 2006-06-08 12:03:06 -0700 raid5_algorithm.patch > 542 2006-09-01 09:58:26 -0700 cli_reload_options.patch > 1255 2006-09-14 07:49:39 -0700 cli_query_segfault.patch > 1230 2006-11-01 07:13:21 -0800 get_geometry.patch > 1109 2006-11-01 15:16:09 -0800 BaseName.patch > > Also, the last two, get_geometry.patch and BaseName.patch, both bug fixes (the > first a workaround for a Linux kernel change starting in 2.6.17, and the second > an important bug fix) are not in your evms-2.5.5-r3. > > So, I am going to build an updated evms-2.5.5-r3 with those in it and attach it > here. > > I didn't study the other issue, but it is true that when I'm installing EVMS, I > have to manually make it runnable from a non-/usr mounted system by moving > and/or copying all of the relevent files to the root filesystem and doing > appropriate ldconfigs, and such. Of course this is vitally important, since > whenever I use EVMS to resize /usr filesystem to something smaller, I have to > first unmount /usr, then run EVMS (such as evmsn). Is that solved in your > ebuild? That would sure be great. > Hi, thanks to help us gentoo-users to improve evms integration. I hope that some gentoo evms maintainers will soon integrate these patches :). Actually, i was focused on the fact that evms ui needs to be usable during earlier boot process before /usr is even mounted and definitely to get rid of glib version 1 in favor of the new release 2. So i didn't pay much attention to patches and their orders as long as epatch won't complain. I'm glad to see you make quite a good work to gather all the last release patches and include them in your r3 build. What bothers me about your build is why didn't you integrate the aclocal.patch patch in your release. Is there anything wrong? Because, without it, you won't be able to migrate evms to glib release 2 because it will continuously link with the old one. So, you will still need the old glib release for evms even when glib 2 is already installed. If you look at the dependencies (equery d glib) you can see there are a few packages depending on the old version like evms and unable to migrate to release 2 (build aborts). Please do try glib 2 with evms without the presence of glib 1. It works flawlessly. I don't use gtk+ version 1.2 so i'm unable to tell you if the exclusive use of glib 2 will interfere with it. Feel free to tell me about it. Anyway, it would be great that maintainers could have a look after their source codes and definitely migrate them to gtk+ 2. That seems not too much time eater and too difficult to integrate. Other people even managed to patch evms to support gtk+2 but still with some few bugs :). I concede the job needs to be improved but it was made and well working (thanks to amax@fantoo.org). As we try to improve evms, i found an other issue during the boot time process that was evms-activate related. When the root partition is under evms control, evms-activate try to write/access a temporary file on the filesystem (certainly located in /var) still unmounted or read only. That's only a warning, but you get the following messages in your kernel log about a recursive locking detection (dmesg): md: raid0 personality registered for level 0 md: raid1 personality registered for level 1 md: bind<dm-0> md: bind<dm-1> raid1: raid set md0 active with 2 out of 2 mirrors md: bind<dm-3> md: bind<dm-4> raid1: raid set md1 active with 2 out of 2 mirrors ============================================= [ INFO: possible recursive locking detected ] --------------------------------------------- evms_activate/1971 is trying to acquire lock: (&md->io_lock){----}, at: [<ffffffff812c5172>] dm_request+0x25/0x162 but task is already holding lock: (&md->io_lock){----}, at: [<ffffffff812c5172>] dm_request+0x25/0x162 other info that might help us debug this: 1 lock held by evms_activate/1971: #0: (&md->io_lock){----}, at: [<ffffffff812c5172>] dm_request+0x25/0x162 stack backtrace: Call Trace: [<ffffffff810a4705>] __lock_acquire+0x12e/0x9f4 [<ffffffff8100a7f2>] kmem_cache_alloc+0xb2/0xc4 [<ffffffff810a4289>] trace_hardirqs_on+0x100/0x124 [<ffffffff810a552f>] lock_acquire+0x4b/0x69 [<ffffffff812c5172>] dm_request+0x25/0x162 [<ffffffff8109aa24>] down_read+0x28/0x34 [<ffffffff812c5172>] dm_request+0x25/0x162 [<ffffffff8101c332>] generic_make_request+0x165/0x17c [<ffffffff810c9a10>] __bio_clone+0x76/0x8f [<ffffffff880177b3>] :raid1:make_request+0x1bf/0x613 [<ffffffff8101c332>] generic_make_request+0x165/0x17c [<ffffffff812c3fbe>] __map_bio+0x56/0x8c [<ffffffff812c49ca>] __split_bio+0x19d/0x394 [<ffffffff810698fe>] _spin_unlock_irq+0x36/0x53 [<ffffffff81068c9b>] __down_read+0x3d/0xaa [<ffffffff812c529d>] dm_request+0x150/0x162 [<ffffffff8101c332>] generic_make_request+0x165/0x17c [<ffffffff81035653>] submit_bio+0xf6/0x101 [<ffffffff8101aa4d>] submit_bh+0x103/0x126 [<ffffffff810c91e6>] block_read_full_page+0x264/0x282 [<ffffffff810ccac0>] blkdev_get_block+0x0/0x4c [<ffffffff81069239>] _write_unlock_irq+0x36/0x52 [<ffffffff810cbab0>] blkdev_readpage+0x13/0x15 [<ffffffff81012d35>] __do_page_cache_readahead+0x1e7/0x26c [<ffffffff810345a4>] blockable_page_cache_readahead+0x5f/0xc1 [<ffffffff81013f37>] page_cache_readahead+0x144/0x1b9 [<ffffffff8100bcea>] do_generic_mapping_read+0x158/0x496 [<ffffffff8100cc8b>] file_read_actor+0x0/0x15b [<ffffffff8100c17b>] __generic_file_aio_read+0x153/0x1a4 [<ffffffff810b6c2f>] generic_file_read+0xc6/0xe0 [<ffffffff81067f5e>] __mutex_lock_slowpath+0x241/0x272 [<ffffffff810987fd>] autoremove_wake_function+0x0/0x38 [<ffffffff810a4289>] trace_hardirqs_on+0x100/0x124 [<ffffffff8100b23b>] vfs_read+0xcc/0x172 [<ffffffff8101177e>] sys_read+0x47/0x6f [<ffffffff81062402>] system_call+0x7e/0x83 I don't know what to think about it since i'm using kernel 2.6.18. Earlier evms build wrote only a simple warning on the screen about the fact that evms-activate is unable to access some sort of filesystem and to check the presence of an other process in memory (certainly to avoid some collisions). It would be nice that some more geeks could have a look at the problem too. I was unable to locate the portion of the code that generates that lock :( I won't be able to answer your question about the ability to shrink /usr with ncurses evmsn ui. In fact i didn't try it by lack of time and motivation. I will rely on some other well proofed testers ;) I hope glib static library is the only one needed to make evmsn work without /usr. Again feel free to test it and prepare a boot livecd just in case ;) Thank you for your support. bye Jj
> What bothers me about your build is why didn't you integrate the aclocal.patch > patch in your release. Is there anything wrong? I actually want to push through the release level patches first so that we have a stable working environment reference point, and then we can do yours if Gentoo developers agree. I like your approaches. I put bug #154924 as a blocker to this one so that it goes through first so the devs have an easier time seeing the sequence of stability. That's the problem with mixing release level bug fixes with enhancement bug fixes. I understand that it wasn't upmost on your mind, and I don't blame you for it at all. I just need the release level bug fixes more, and they're more likely to be put into Portage sooner than the enhancement stuff. > ============================================= > [ INFO: possible recursive locking detected ] > --------------------------------------------- Right now I don't have time to diagnose, but is this possible if you have LVM/LVM2 "active" objects? You'd have to deactivate the LVM objects in order to use the same objects with EVMS, I think; you should only refer to each object via one device node in /dev (so e.g., /dev/evms/root, /dev/evms/tmp, etc.)). If I ran into this, I'm sure I was careful to have the data put someplace safe so that it would work correctly, but I don't remember running into it. I initrd via RAM disk and then pivot_root to EVMS mounts (which themselves are on dm-crypt devices).
(In reply to comment #17) I totally agree with you. After all the "enhancement" i suggest is not important for someone who doesn't mind to install both glib versions. I'm exclusively using /dev/evms trees when adressing the devices. One of my computer (that doesn't need raid devices) i just installes evms (not lvm2 and co) and i get also the same message. Actually evms is the only tool that activate objects. If your are using evms with raid/lvm2 and your root partition is on a lvm device (pivot_root), i'm quite sure your system is affected too. Indeed, the message is most hidden because most people don't activate the hacking capabilites of the kernel. I just set the following definition in my .config and build another kernel: CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_MAGIC_SYSRQ=y CONFIG_DEBUG_KERNEL=y CONFIG_LOG_BUF_SHIFT=15 CONFIG_DETECT_SOFTLOCKUP=y CONFIG_DEBUG_RT_MUTEXES=y CONFIG_DEBUG_PI_LIST=y CONFIG_RT_MUTEX_TESTER=y CONFIG_DEBUG_SPINLOCK=y CONFIG_DEBUG_MUTEXES=y CONFIG_DEBUG_RWSEMS=y CONFIG_DEBUG_LOCK_ALLOC=y CONFIG_PROVE_LOCKING=y CONFIG_LOCKDEP=y CONFIG_TRACE_IRQFLAGS=y CONFIG_DEBUG_LOCKING_API_SELFTESTS=y CONFIG_STACKTRACE=y CONFIG_DEBUG_BUGVERBOSE=y CONFIG_DEBUG_FS=y CONFIG_FRAME_POINTER=y CONFIG_UNWIND_INFO=y CONFIG_STACK_UNWIND=y CONFIG_RCU_TORTURE_TEST=m CONFIG_EARLY_PRINTK=y CONFIG_DEBUG_STACKOVERFLOW=y CONFIG_DEBUG_STACK_USAGE=y The problem affects both x86 and x86_64 kernel (at least on my computers). Anyway, it seems quite harmless. Yes, my computers live a dangerous life because i don't have enough room to save all the stuff in it. Mainly i just save /home, /var, /etc and world. But not so dangerous as loosing one single bit that will corrupt the whole partition because it is encrypted ;) Jj
Jimmy Jazz, thanks a lot for your work. From the latest revision bump on (-r4), evms will always use the static glib to link the ncurses ui with. This is because evmsn resides in /sbin and as you said: it sucks when you want to resize /usr. I've also included the debug USE-flag.
