[12:40] <zul> hey
[04:39] <Mithrandir> Keybuk: rewriting fstab for evms devices == not a good idea.
[04:40] <Keybuk> -v
[04:42] <Kamion> probably similar to bug 54002
[04:43] <Mithrandir> Keybuk: changing /dev/evms/* entries in fstab to UUID entries breaks stuff since the system then tries to access /dev/evms/.nodes/lvm/[...]  rather than /dev/evms/name
[04:44] <Keybuk> is that a mount bug?
[04:44] <Mithrandir> fsck + mount at least.
[04:45] <Keybuk> right, both use libblkid, no?
[04:45] <Mithrandir> looks like fsck.ext3 does at least.
[04:45] <Keybuk> so it could be a difference between libblkid and libvolume_id?
[04:46] <Mithrandir> or libvolume_id could have gotten the "cannot open" error and gone on its merry way.
[04:50] <Keybuk> hmm?
[04:53] <Mithrandir> : tfheen@golem ~ > LANG=C sudo fsck.ext3 UUID=e956b7b4-6ebf-4bd4-98ac-ffa52eb26028
[04:53] <Mithrandir> e2fsck 1.39 (29-May-2006)
[04:53] <Mithrandir> fsck.ext3: Device or resource busy while trying to open /dev/evms/.nodes/lvm/lvm0/home0
[04:54] <Mithrandir> Filesystem mounted or opened exclusively by another program?
[04:54] <Mithrandir> well, I gotta run now.
[05:02] <Keybuk> right, but why's it looking there?
[05:14] <Mithrandir> "it" being?
[05:15] <Keybuk> fsck.ext3, apparently
[05:15] <Keybuk> I suspect this is a libblkid problem
[05:15] <Mithrandir> because the block device is exposed there too.
[05:15] <Mithrandir> quite possibly.
[05:15] <Keybuk> it's not mapping UUID=* to evms volumes correctly
[05:16] <Keybuk> what does /dev/disk/by-uuid/e956b7b4-6ebf-4bd4-98ac-ffa52eb26028 point to?
[05:16] <Mithrandir> well, technically it's available with the .nodes/lvm name too, but that's just for internal consumption by evms, AIUI.
[05:16] <Mithrandir> unsure, the machine is on the other side of a firewall now.
[05:17] <Kamion> Keybuk: oh, speaking of, has anyone mentioned this problem yet?
[05:17] <Kamion> $ sudo blkid -t UUID=424fb11b-b062-4c5b-83bc-6ffd84c17ae7
[05:17] <Kamion> /dev/hda3: LABEL="debian" UUID="424fb11b-b062-4c5b-83bc-6ffd84c17ae7" SEC_TYPE="ext2" TYPE="ext3"
[05:17] <Kamion> /dev/evms/hda2: LABEL="debian" UUID="424fb11b-b062-4c5b-83bc-6ffd84c17ae7" SEC_TYPE="ext2" TYPE="ext3"
[05:19] <Keybuk> nope, what's the problem there?
[05:19] <Kamion> I have a feeling that that's deliberate on EVMS' part, although I'm not sure
[05:19] <Kamion> the problem is that I don't use EVMS
[05:19] <Kamion> (although I have it installed)
[05:19] <Kamion> and apparently (ogra says) fresh reboots cause the /dev/evms/* one to be picked and mounted
[05:20] <Keybuk> they appear to be the same block device?
[05:20] <Keybuk> what does /dev/disk/by-uuid/424fb11b-b062-4c5b-83bc-6ffd84c17ae7 point to?
[05:24] <Kamion> ../../hda3
[05:25] <Kamion> they're not actually the same block device (3,3 vs. 253,1) although the underlying contents are probably the same
[05:25] <Kamion> (note, I haven't upgraded to new udev yet or rebooted since the fstab transition or anything; if you need that, talk to ogra)
[05:31] <Keybuk> really, we need someone who understands EVMS, LVM, software RAID, etc.  and is actually co-operative and willing to fix it themselves instead of just bitch all the time
[05:34] <Mithrandir> I could conceivably do it, except I'm leaving for a couple of week of vacation from Friday.
[05:37] <Keybuk> *nods*
[05:37] <Keybuk> my general feeling with this stuff is that 95% of people haven't even noticed the conversion taking place
[05:37] <Keybuk> so we're good to move on to the other boot loaders, and play with kernel modules
[05:37] <Keybuk> and the silly exotic filesystems can be fixed after feature freeze :p
[05:37] <Mithrandir> yeah, in most cases it seems to have gone over fine.  I'm a bit worried about LVM + EVMS and other similar cases.
[05:37] <Mithrandir> evms isn't a filesystem. :-P
[05:38] <Keybuk> ntfs/fat/vfat is unhappy also
[05:38] <Keybuk> that's because vol_id supports uuid from those filesystems, so the conversion goes ahead
[05:38] <Keybuk> but blkid doesn't, so mount can't actually use them
[05:39] <Mithrandir> that should be a SMOP to fix, shouldn't it?
[05:39] <Keybuk> where P=Stealing the patch to make mount just use libvolume_id from SuSE
[05:40] <Mithrandir> why did udev NIH libblkid, really?
[05:41] <Keybuk> I suspect the original vol_id author didn't know about blkid
[05:41] <Keybuk> it's kinda hidden inside e2fsprogs
[05:41] <Keybuk> and then got more people involved, so vol_id is sufficiently better than blkid that it's got used by udev
[07:14] <fuoco> i use dapper, and i need some new things found in newer kernels like 2.6.17. what is the best way to get that? manually compile my kernel, or cam i find a kernel image for these versions somewhere ?
[07:14] <BenC> fuoco: easiest way is to use edgy
[07:15] <fuoco> BenC: but i lose stability...
[07:15] <BenC> fuoco: them's the breaks...you lose stability if you compile your own kernel too :)
[07:16] <BenC> you can always do a partial upgrade of just the kernel and its dependencies, which is pretty small
[07:16] <fuoco> BenC: true, but it's different if only my kernel is 'unstable' (2.6.17 not necessarily less stable than 2.6.15 + it fixes crashes for me)
[07:17] <fuoco> BenC: like take only the kernel from edgy ?
[07:17] <BenC> edit /etc/apt/sources.list, s/dapper/edgy/; sudo apt-get update; sudo apt-get install linux-386 (or 686, or whatever kernel you use)
[07:18] <fuoco> what if i just get a .deb from the kernels-daily url in the topic ?
[07:19] <fuoco> can it not cause problems to mix parts from edgy and dapper ?
[07:20] <BenC> the one in the url above wont installe
[07:20] <BenC> because it depends on things from edgy
[07:20] <BenC> and the small amount of things you have to upgrade for the kernel wont cause any instabilities that I know of
[07:21] <cjb> I'm doing the reverse, running edgy on a dapper kernel, and it's fine.
[07:21] <BenC> if you don't upgrade the things the kernel needs, you might not even boot
[07:21] <cjb> (The edgy kernel just kicks me to a blank screen, for some reason, and haven't had time to debug.)
[07:24] <jbailey> BenC: =)
[07:24] <jbailey> BenC: Practice, or is it tournament time already?
[09:15] <makx> hmm no output from usplash after init, hmm i guess i need better drugs from lsb
[09:33] <doko> BenC: http://librarian.launchpad.net/3573913/buildlog_ubuntu-edgy-sparc.xorg-server_1%3A1.1.1-0ubuntu1_FAILEDTOBUILD.txt.gz
[09:33] <doko> $ dpkg -S asm/kbio.h
[09:33] <doko> dpkg: *asm/kbio.h* not found.
[09:36] <rodarvus> hi there
[09:36] <rodarvus> any hints on why this build failure happened? -> http://librarian.launchpad.net/3573913/buildlog_ubuntu-edgy-sparc.xorg-server_1%3A1.1.1-0ubuntu1_FAILEDTOBUILD.txt.gz
[09:36] <rodarvus> (just for reference) asm/kbio.h is not found. This file is included on sparc only
[09:38] <zul> rodarvus: might want to talk to fabbione, otherwise it was probably missed in the lkh transition stuff
[09:38] <doko> rodarvus: I already did ask :)
[09:39] <crimsun> right, probably needs prodding from the linux-source side so it can be included in l-k-h
[09:39] <rodarvus> doko, heh, thanks :)
[09:41] <rodarvus> zul, crimsun: *nods*, thanks - I'll wait for fabbione to be online and ask him on the subject