Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts.
On Fri, 16 Mar 2012 06:39:44 +0100, Joost Roeleveld wrote: Technically, we are all using an initramfs as all 2.6/3 kernels mount an initramfs when they load. If does not contain an init script, they fall back to the legacy behaviour. See /usr/src/linux/Documentation/filesystems/ramfs-rootfs-initramfs.txt Even when the init-options are not set? Yes, read the readme. admin@hera ~ $ zcat /proc/config.gz | grep -i init # CONFIG_BLK_DEV_INITRD is not set That's for an old style initrd, I don't have that set either. -- Neil Bothwick Oxymoron: Clearly Misunderstood. signature.asc Description: PGP signature
Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts.
Mike Edenfield wrote: From: Dale [mailto:rdalek1...@gmail.com] This has been one of my points too. I could go out and buy me a bluetooth mouse/keyboard but I don't because it to complicates matters. I had a long reply to Walt that I (probably wisely) decided not to send, but the basic point of it is also relevant here. My response to his (IMO needlessly aggressive) email was basically this: Why *shouldn't I* be able to go but a Bluetooth keyboard and mouse if I wanted to? Those things *work perfectly fine with udev*. And why wouldn't I want to use the *same* solution for all of my various machines, even if that solution is overkill for half of them? Just because my laptop doesn't need bluetoothd support in udev doesn't mean using udev there *is bad*. (I don't need 80% of what's in the Linux kernel but I still install one...) I am not in any way denigrating the work he's doing. I think it's awesome and I've tried to help where I can. But I'm pretty fed up with people like him acting as if the current udev solution is the end of the world. I've heard it called everything from design mistake to out of control truck full of manure. I have three PCs in my home running Gentoo. Two of them would boot correctly using Walt's new solution (mdev and no /usr mounted at boot) and one would not. *All three of them* boot correctly using udev. 100% success 66% success, so clearly the udev solution is a perfectly legitimate solution to a real world problem. At work, those numbers are likely different, and Walt's solution might be a working approach -- if udev didn't already work fine in 100% of those cases, too. Instead of asking why everyone else should be forced to use the udev solution *that already works*, you should be focusing on explaining to everyone else the reasons why it is worth the time and effort to configure *something different* for those same machines. There was a reason why people stopped using static /dev, and devfs; maybe there is a reason why people should stop using udev, but thus far that reason seems to be initramfs makes us cranky. There's no need to get mean-spirited just because you choose a different audience that freedesktop.org as the target for your solution. It just makes you look petty and childish. Produce an alternative to udev/initramfs/single root that works, provide (accurate) details on the differences, and let users pick which one they want. --Mike I have a question or two. If udev was going to *break* your bluetooth keyboard, what would you say then? To me, having a bluetooth keyboard is a bit out there. If udev was going to break a PS/2 keyboard, what would you say then? I suspect PS/2 keyboards outnumber bluetooth and most likely by a wide margin. Right now, udev is going to ruin my system while yours works. What if it was going to make my system work while breaking yours? Would you make the same argument? One other question, does your BIOS allow you to use your bluetooth keyboard? Just a thought. I'm going to take my meds. Ya'll argue for a while. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts.
On Wed, 14 Mar 2012 21:47:16 -0500, Dale wrote: I may end up with a init thingy, which I am currently using. Thing is, the first time it breaks and I can't fix it, I'll install something else. That's why I build the initramfs into the kernel and not as a separate file. If I do something to break the initramfs I just boot the previous kernel knowing it will still work. -- Neil Bothwick Use Colgate toothpaste or end up with teeth like a Ferengi. signature.asc Description: PGP signature
Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts.
Neil Bothwick wrote: On Wed, 14 Mar 2012 21:47:16 -0500, Dale wrote: I may end up with a init thingy, which I am currently using. Thing is, the first time it breaks and I can't fix it, I'll install something else. That's why I build the initramfs into the kernel and not as a separate file. If I do something to break the initramfs I just boot the previous kernel knowing it will still work. I tried that. It broke. It didn't boot not even once. Google was no help either tho I found others with the same issues but no fix. Right now I am using the dracut thingy. If it breaks, I have no idea how to fix it. That's one reason why I left Mandrake, the init thingy kept breaking every few months. Then after one upgrade, I was just fed up. I moved on. Keep in mind, this is Dale, the one that has issues with things. lol Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts.
On Thu, 15 Mar 2012 05:10:55 -0500, Dale wrote: That's why I build the initramfs into the kernel and not as a separate file. If I do something to break the initramfs I just boot the previous kernel knowing it will still work. I tried that. It broke. It didn't boot not even once. Google was no help either tho I found others with the same issues but no fix. Right now I am using the dracut thingy. If it breaks, I have no idea how to fix it. That's one reason why I left Mandrake, the init thingy kept breaking every few months. Then after one upgrade, I was just fed up. I moved on. If you're writing your own init, it's bound to fail at first. Just fill it full of echo statements and keep trying. It probably takes longer than dracut, but you end up with something that not only does what you want, but in a way you understand. -- Neil Bothwick Facts are stubborn, but statistics are more pliable signature.asc Description: PGP signature
Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts.
On 2012-03-14 9:03 PM, Walter Dnes waltd...@waltdnes.org wrote: *YOUR WIFE'S LAPTOP* won't boot properly without /usr on /, or an initramfs. OK, put /usr on /, or an initramfs*ON YOUR WIFE'S LAPTOP*. I don't have a problem with that. What gets people really upset is the dog-in-the-manger attitude of if my complex/corner-case machine won't boot up without /usr on /, or an initramfs, then by golly*NOBODY'S* machine will be allowed to boot up without /usr on /, or an initramfs. My machine does not use bluetooth/other-weird-stuff. udev doesn't need to find bluetooth drivers on /usr on my machine. Why is udev being deliberately broken to not work on*EVERYBODY'S* machine if they don't have /usr on /, or an initramfs? Why can't this argument simply be satisfied with one or more new profiles?
Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts.
On 2012-03-15 5:13 AM, Neil Bothwick n...@digimed.co.uk wrote: That's why I build the initramfs into the kernel and not as a separate file. If I do something to break the initramfs I just boot the previous kernel knowing it will still work. Ok, time to show my ignorance... How would I know if I am using an initramfs, and if I was, whether it was built into the kernel or not?
Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts.
On Thu, 15 Mar 2012 08:41:38 -0400, Tanstaafl wrote: That's why I build the initramfs into the kernel and not as a separate file. If I do something to break the initramfs I just boot the previous kernel knowing it will still work. Ok, time to show my ignorance... How would I know if I am using an initramfs, and if I was, whether it was built into the kernel or not? Well, you built the kernel, so you should know. Technically, we are all using an initramfs as all 2.6/3 kernels mount an initramfs when they load. If does not contain an init script, they fall back to the legacy behaviour. See /usr/src/linux/Documentation/filesystems/ramfs-rootfs-initramfs.txt -- Neil Bothwick It may be that your sole purpose in life is simply to serve as a warning to others. signature.asc Description: PGP signature
Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts.
On 2012-03-15 9:05 AM, Neil Bothwick n...@digimed.co.uk wrote: On Thu, 15 Mar 2012 08:41:38 -0400, Tanstaafl wrote: That's why I build the initramfs into the kernel and not as a separate file. If I do something to break the initramfs I just boot the previous kernel knowing it will still work. Ok, time to show my ignorance... How would I know if I am using an initramfs, and if I was, whether it was built into the kernel or not? Well, you built the kernel, so you should know. Well, since I basically just used a kernel .config that someone else originally set up, copying .config over and running make oldconfig when upgrading over the years, stumbling through any changes that broke anything (like when some changes to iptables broke my firewall back around 2.6.2x), I really didn't know - but I just confirmed that it is indeed built into my kernels, so, now, how do I know if I am *using* it or not? Technically, we are all using an initramfs as all 2.6/3 kernels mount an initramfs when they load. If does not contain an init script, they fall back to the legacy behaviour. So, how do I know whether or not 'it contains an init script'? I know, my ignorance is confounding... See /usr/src/linux/Documentation/filesystems/ramfs-rootfs-initramfs.txt Read it, thanks, but it didn't help me answer the above...
RE: [gentoo-user] Re: LVM, /usr and really really bad thoughts.
From: Dale [mailto:rdalek1...@gmail.com] This has been one of my points too. I could go out and buy me a bluetooth mouse/keyboard but I don't because it to complicates matters. I had a long reply to Walt that I (probably wisely) decided not to send, but the basic point of it is also relevant here. My response to his (IMO needlessly aggressive) email was basically this: Why *shouldn't I* be able to go but a Bluetooth keyboard and mouse if I wanted to? Those things *work perfectly fine with udev*. And why wouldn't I want to use the *same* solution for all of my various machines, even if that solution is overkill for half of them? Just because my laptop doesn't need bluetoothd support in udev doesn't mean using udev there *is bad*. (I don't need 80% of what's in the Linux kernel but I still install one...) I am not in any way denigrating the work he's doing. I think it's awesome and I've tried to help where I can. But I'm pretty fed up with people like him acting as if the current udev solution is the end of the world. I've heard it called everything from design mistake to out of control truck full of manure. I have three PCs in my home running Gentoo. Two of them would boot correctly using Walt's new solution (mdev and no /usr mounted at boot) and one would not. *All three of them* boot correctly using udev. 100% success 66% success, so clearly the udev solution is a perfectly legitimate solution to a real world problem. At work, those numbers are likely different, and Walt's solution might be a working approach -- if udev didn't already work fine in 100% of those cases, too. Instead of asking why everyone else should be forced to use the udev solution *that already works*, you should be focusing on explaining to everyone else the reasons why it is worth the time and effort to configure *something different* for those same machines. There was a reason why people stopped using static /dev, and devfs; maybe there is a reason why people should stop using udev, but thus far that reason seems to be initramfs makes us cranky. There's no need to get mean-spirited just because you choose a different audience that freedesktop.org as the target for your solution. It just makes you look petty and childish. Produce an alternative to udev/initramfs/single root that works, provide (accurate) details on the differences, and let users pick which one they want. --Mike
Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts.
On Thu, 15 Mar 2012 09:56:12 -0400, Tanstaafl wrote: Well, you built the kernel, so you should know. Well, since I basically just used a kernel .config that someone else originally set up, copying .config over and running make oldconfig when upgrading over the years, stumbling through any changes that broke anything (like when some changes to iptables broke my firewall back around 2.6.2x), I really didn't know - but I just confirmed that it is indeed built into my kernels, so, now, how do I know if I am *using* it or not? If CONFIG_INITRAMFS_SOURCE contains a path, that is the initramfs you are using. If it is empty and there is no initrd set in GRUB, you are not using one. -- Neil Bothwick New Intel opcode #007 PUKE: Put unmeaningful keywords everywhere signature.asc Description: PGP signature
Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts.
On Thu, Mar 15, 2012 at 6:56 AM, Tanstaafl tansta...@libertytrek.org wrote: On 2012-03-15 9:05 AM, Neil Bothwick n...@digimed.co.uk wrote: On Thu, 15 Mar 2012 08:41:38 -0400, Tanstaafl wrote: That's why I build the initramfs into the kernel and not as a separate file. If I do something to break the initramfs I just boot the previous kernel knowing it will still work. Ok, time to show my ignorance... How would I know if I am using an initramfs, and if I was, whether it was built into the kernel or not? Well, you built the kernel, so you should know. Well, since I basically just used a kernel .config that someone else originally set up, copying .config over and running make oldconfig when upgrading over the years, stumbling through any changes that broke anything (like when some changes to iptables broke my firewall back around 2.6.2x), I really didn't know - but I just confirmed that it is indeed built into my kernels, so, now, how do I know if I am *using* it or not? Technically, we are all using an initramfs as all 2.6/3 kernels mount an initramfs when they load. If does not contain an init script, they fall back to the legacy behaviour. So, how do I know whether or not 'it contains an init script'? I know, my ignorance is confounding... See /usr/src/linux/Documentation/filesystems/ramfs-rootfs-initramfs.txt Read it, thanks, but it didn't help me answer the above... I've only used an initramfs/initrd once so I can relate to the confusion. Assuming you have the config in /proc run: c2stable ~ # zcat /proc/config.gz | grep INITRAMFS CONFIG_INITRAMFS_SOURCE= c2stable ~ # Also, if you didn't actually create the initramfs hierarchy and zip it up to be used by your kernel then you're not using one, other than what Neil said that we all use one that does nothing. HTH, Mark
Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts.
On Thu, Mar 15, 2012 at 10:09 AM, Mike Edenfield kut...@kutulu.org wrote: From: Dale [mailto:rdalek1...@gmail.com] This has been one of my points too. I could go out and buy me a bluetooth mouse/keyboard but I don't because it to complicates matters. I had a long reply to Walt that I (probably wisely) decided not to send, but the basic point of it is also relevant here. My response to his (IMO needlessly aggressive) email was basically this: Why *shouldn't I* be able to go but a Bluetooth keyboard and mouse if I wanted to? Those things *work perfectly fine with udev*. And why wouldn't I want to use the *same* solution for all of my various machines, even if that solution is overkill for half of them? Just because my laptop doesn't need bluetoothd support in udev doesn't mean using udev there *is bad*. (I don't need 80% of what's in the Linux kernel but I still install one...) I wouldn't say you shouldn't be able to. (Outside that I think Bluetooth is a pile of smelly carp, people shouldn't have to bend over backwards to support, but that's a different issue...) I am not in any way denigrating the work he's doing. I think it's awesome and I've tried to help where I can. But I'm pretty fed up with people like him acting as if the current udev solution is the end of the world. I've heard it called everything from design mistake to out of control truck full of manure. design mistake is a perfectly reasonable description, and I'd agree with that. It's also not pejorative, but I'd say the two vocal sides of the issue are far too polarized to notice that. truck full of manure is probably a bit far, but that description only holds if important things which shouldn't need a dependency on udev gain or keep them. Rather like how installing a console Qt app on a Debian server pulls in X. I have three PCs in my home running Gentoo. Two of them would boot correctly using Walt's new solution (mdev and no /usr mounted at boot) and one would not. *All three of them* boot correctly using udev. 100% success 66% success, so clearly the udev solution is a perfectly legitimate solution to a real world problem. At work, those numbers are likely different, and Walt's solution might be a working approach -- if udev didn't already work fine in 100% of those cases, too. Sure. Instead of asking why everyone else should be forced to use the udev solution *that already works*, you should be focusing on explaining to everyone else the reasons why it is worth the time and effort to configure *something different* for those same machines. There's little use in explaining to someone why they should use something apart from what they're comfortable with. Moving out of a comfort zone requires personal motivation, not external. If udev works for someone, they should use it. If they discover udev is getting in their way, then they should look for alternatives. I use apache2+squid3 on my server, despite hordes of people telling me I should use nginx. Apache+squid works appropriately well for my circumstance. There was a reason why people stopped using static /dev, and devfs; maybe there is a reason why people should stop using udev, but thus far that reason seems to be initramfs makes us cranky. *That* is a matter of systemic complexity and maintenance difficulty; the increased complexity tickles the spider senses of anyone who's had to design, develop or maintain very complex systems with few leave-alone black boxes. It's very difficult to increase the complexity of a system without adding bugs or mistakes anywhere from code to testing procedures to package management to end-user maintenance. So when a system starts becoming more complex, and I'm told that I'm going to have to go along for the ride, I get concerned. Before Walt started pulling mdev from being a busybox-only component, that was exactly the scenario. (Thank you, Walt!) The only cases I've ever conceivably needed to use an initramfs have been where I needed a kernel module available early. Rather than build that as a module and build an initramfs, I simply build it into the kernel. Certainly, there are portions of the kernel (particularly some sound cards) where that doesn't work, and if someone needs those portions available early, then an initramfs is going to be the tool for them. There's no need to get mean-spirited just because you choose a different audience that freedesktop.org as the target for your solution. That's really not the reason for it. I mean, sure, I think the initial reactions were mostly grumpiness and misinformed outrage, but I don't think the contrariness really *baked* in until people got a twofer of you're going to use udev unless you write the code to get around it and oh, you're writing the code? You're wasting your time and you're going to fail. That, I think, is when the real malaise set in. It just makes you look petty and childish. Produce an alternative to udev/initramfs/single root that
Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts.
On Mar 15, 2012 9:50 PM, Michael Mol mike...@gmail.com wrote: 8 snip That's really not the reason for it. I mean, sure, I think the initial reactions were mostly grumpiness and misinformed outrage, but I don't think the contrariness really *baked* in until people got a twofer of you're going to use udev unless you write the code to get around it and oh, you're writing the code? You're wasting your time and you're going to fail. That, I think, is when the real malaise set in. This. On hindsight, I do admit that after I woke up this morning, my emails are perhaps too vitriolic. Blame it on a late night posting *just* before I go to bed ;-) But still, my emails indeed captured my emotions at the moment. It's 23:38 here, and I'll quickly bow out if this thread, for now :-) Rgds,
Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts.
On Thursday, March 15, 2012 01:05:12 PM Neil Bothwick wrote: On Thu, 15 Mar 2012 08:41:38 -0400, Tanstaafl wrote: That's why I build the initramfs into the kernel and not as a separate file. If I do something to break the initramfs I just boot the previous kernel knowing it will still work. Ok, time to show my ignorance... How would I know if I am using an initramfs, and if I was, whether it was built into the kernel or not? Well, you built the kernel, so you should know. Technically, we are all using an initramfs as all 2.6/3 kernels mount an initramfs when they load. If does not contain an init script, they fall back to the legacy behaviour. See /usr/src/linux/Documentation/filesystems/ramfs-rootfs-initramfs.txt Even when the init-options are not set? *** admin@hera ~ $ uname -a Linux hera 2.6.34-xen-r4_dom0 #1 SMP Wed Dec 8 15:52:31 CET 2010 x86_64 AMD Phenom(tm) II X4 955 Processor AuthenticAMD GNU/Linux admin@hera ~ $ zcat /proc/config.gz | grep -i init CONFIG_INIT_ENV_ARG_LIMIT=32 # CONFIG_BLK_DEV_INITRD is not set # CONFIG_SCSI_OSD_INITIATOR is not set CONFIG_DEBUG_MEMORY_INIT=y # CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set *** -- Joost
Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts.
Walter Dnes wrote: On Mon, Mar 12, 2012 at 06:22:39PM -0500, Dale wrote I think mdev has shown it can be fixed. Given time, it just may replace udev then the udev dev can screw up his own stuff on not bother other distros. I'm giving mdev some thought here. I want /usr on LVM which means it has to be separate. Sorry, in lste-breaking news, it looks like udev is a mandatory dependancy for lvm2. No udev == No lvm2 Can you run a test for me? What happens when you... 1) insert the line sys-fs/udev into /etc/portage/package.mask 2) execute emerge -pv system 3) execute emerge -pv world 4) Remember to remove the sys-fs/udev line from package.maskG I expect that you should get an error message about not being able to emerge lvm2 due to udev being masked. This is something I intend to add to the instructions, so people can check ahead of time whether their particular setup is able to run without udev. OK. I took my meds a bit ago so I hope I got this right. I used copy and paste. lol I added udev to the mask file and here is the results. It's a doozy. root@fireball / # emerge -pv system These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R] app-arch/xz-utils-5.0.3 USE=nls threads -static-libs 0 kB [ebuild R] sys-devel/gnuconfig-20110814 0 kB [ebuild R] sys-devel/patch-2.6.1 USE=-static -test 0 kB [ebuild R] app-arch/bzip2-1.0.6-r3 USE=-static -static-libs 0 kB [ebuild R] sys-apps/which-2.20 0 kB [ebuild R] sys-apps/texinfo-4.13 USE=nls -static 0 kB [ebuild R] virtual/os-headers-0 0 kB [ebuild R] virtual/man-0 0 kB [ebuild R] sys-apps/sed-4.2.1 USE=nls -acl (-selinux) -static 0 kB [ebuild R] sys-apps/less-444 USE=unicode 0 kB [ebuild R] sys-apps/grep-2.9 USE=nls pcre 0 kB [ebuild R] sys-apps/kbd-1.15.3 USE=nls 0 kB [ebuild R] sys-apps/busybox-1.19.3-r1 USE=ipv6 pam -make-symlinks -mdev -savedconfig (-selinux) -static 0 kB [ebuild R] app-shells/bash-4.1_p9 USE=net nls -afs -bashlogger -examples -mem-scramble -plugins -vanilla 0 kB [ebuild R] sys-apps/net-tools-1.60_p20110409135728 USE=nls -static 0 kB [ebuild R] virtual/modutils-0 0 kB [ebuild R] sys-apps/gawk-3.1.8 USE=nls 0 kB [ebuild R] sys-process/psmisc-22.14 USE=X ipv6 nls (-selinux) 0 kB [ebuild R] sys-apps/file-5.09 USE=zlib -python -static-libs 0 kB [ebuild R] app-arch/tar-1.26 USE=nls -static 0 kB [ebuild R] virtual/package-manager-0 0 kB [ebuild R] net-misc/rsync-3.0.9 USE=iconv ipv6 -acl -static -xattr 0 kB [ebuild R] virtual/editor-0 0 kB [ebuild R] sys-apps/coreutils-8.14 USE=nls unicode -acl -caps -gmp (-selinux) -static -vanilla -xattr 0 kB [ebuild R] sys-devel/make-3.82-r1 USE=nls -static 0 kB [ebuild R] sys-process/procps-3.2.8_p11 USE=unicode 0 kB [ebuild R] virtual/ssh-0 USE=-minimal 0 kB [ebuild R] virtual/dev-manager-0 0 kB [ebuild R] sys-apps/findutils-4.4.2-r1 USE=nls (-selinux) -static 0 kB [ebuild R] app-arch/gzip-1.4 USE=nls -pic -static 0 kB [ebuild R] net-misc/wget-1.12-r3 USE=ipv6 nls ssl -debug -idn -ntlm -static 0 kB [ebuild R] sys-apps/diffutils-3.0 USE=nls -static 0 kB [ebuild R] sys-apps/baselayout-2.0.3 USE=-build 0 kB [ebuild R] virtual/libc-0 0 kB [ebuild R] sys-apps/util-linux-2.20.1-r1 USE=cramfs loop-aes ncurses nls unicode -crypt -ddate -old-linux -perl (-selinux) -slang -static-libs (-uclibc) 0 kB [ebuild R] sys-devel/binutils-2.21.1-r1 USE=nls zlib -multislot -multitarget -static-libs -test -vanilla 0 kB [ebuild R] sys-apps/man-pages-3.35 USE=nls LINGUAS=-da -de -fr -it -ja -nl -pl -ro -ru -zh_CN 0 kB [ebuild R] net-misc/iputils-20101006-r2 USE=ipv6 ssl -SECURITY_HAZARD -doc -idn -static 0 kB [ebuild R] virtual/pager-0 0 kB [ebuild R] sys-apps/shadow-4.1.4.3 USE=cracklib nls pam -audit (-selinux) -skey 0 kB [ebuild R] sys-fs/e2fsprogs-1.42 USE=nls -static-libs 0 kB [ebuild R] sys-devel/gcc-4.5.3-r2 USE=cxx fortran gtk mudflap (multilib) nls nptl openmp (-altivec) -bootstrap -build -doc (-fixed-point) -gcj -graphite (-hardened) (-libssp) -lto -multislot -nocxx -nopie -nossp -objc -objc++ -objc-gc -test -vanilla 0 kB Total: 42 packages (42 reinstalls), Size of downloads: 0 kB !!! The following installed packages are masked: - sys-fs/udev-171-r5::gentoo (masked by: package.mask) For more information, see the MASKED PACKAGES section in the emerge man page or refer to the Gentoo Handbook. root@fireball / # emerge -pv world These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R] app-arch/xz-utils-5.0.3 USE=nls threads -static-libs 0 kB [ebuild R] sys-devel/gnuconfig-20110814 0 kB [ebuild R] app-arch/bzip2-1.0.6-r3 USE=-static -static-libs 0 kB [ebuild R]
Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts.
Hi, Walter. On Tue, Mar 13, 2012 at 04:09:46AM -0400, Walter Dnes wrote: On Mon, Mar 12, 2012 at 06:22:39PM -0500, Dale wrote I think mdev has shown it can be fixed. Given time, it just may replace udev then the udev dev can screw up his own stuff on not bother other distros. I'm giving mdev some thought here. I want /usr on LVM which means it has to be separate. Sorry, in lste-breaking news, it looks like udev is a mandatory dependancy for lvm2. No udev == No lvm2 I can mount and use my lvm2 partitions under mdev. As I said, I don't yet know whether lvm2's full functionality is available. I suspect there'll be quite a few packages which list udev as a dependency, yet work well enough under mdev. Can you run a test for me? What happens when you... 1) insert the line sys-fs/udev into /etc/portage/package.mask 2) execute emerge -pv system 3) execute emerge -pv world 4) Remember to remove the sys-fs/udev line from package.maskG I expect that you should get an error message about not being able to emerge lvm2 due to udev being masked. This is something I intend to add to the instructions, so people can check ahead of time whether their particular setup is able to run without udev. The solution to this, ugly though it might be, is to leave udev in the system so as to allow these other packages to be merged. -- Walter Dnes waltd...@waltdnes.org -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts.
On Mar 14, 2012 9:45 PM, Alan Mackenzie a...@muc.de wrote: Hi, Walter. On Tue, Mar 13, 2012 at 04:09:46AM -0400, Walter Dnes wrote: On Mon, Mar 12, 2012 at 06:22:39PM -0500, Dale wrote I think mdev has shown it can be fixed. Given time, it just may replace udev then the udev dev can screw up his own stuff on not bother other distros. I'm giving mdev some thought here. I want /usr on LVM which means it has to be separate. Sorry, in lste-breaking news, it looks like udev is a mandatory dependancy for lvm2. No udev == No lvm2 I can mount and use my lvm2 partitions under mdev. As I said, I don't yet know whether lvm2's full functionality is available. I suspect there'll be quite a few packages which list udev as a dependency, yet work well enough under mdev. Can you run a test for me? What happens when you... 1) insert the line sys-fs/udev into /etc/portage/package.mask 2) execute emerge -pv system 3) execute emerge -pv world 4) Remember to remove the sys-fs/udev line from package.maskG I expect that you should get an error message about not being able to emerge lvm2 due to udev being masked. This is something I intend to add to the instructions, so people can check ahead of time whether their particular setup is able to run without udev. The solution to this, ugly though it might be, is to leave udev in the system so as to allow these other packages to be merged. ... or, put sys-fs/udev in package.provided Of course, if a package *actually* needs udev, that's a sure-fire recipe for catastrophe (for that package). Rgds,
RE: [gentoo-user] Re: LVM, /usr and really really bad thoughts.
From: Alan McKinnon [mailto:alan.mckin...@gmail.com] Sent: Tuesday, March 13, 2012 3:14 AM To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts. On Tue, 13 Mar 2012 11:54:58 +0700 Pandu Poluan pa...@poluan.info wrote: The idea of trying to launch udevd and initialize devices without the software, installed in /usr, which is required by those devices is a configuration that causes problems in many real-world, practical situations. The requirement of having /usr on the same partition as / is also a configuration that causes problems in many real-world, practical situations. I quite often read about this, and after some thinking, I have to ask: why? I've also thought about this and I also want to ask why? To be honest, I was simply taking for granted that all of the other people on this list who made a huge fuss about this were not lying. I, personally, have never had a use or need for a separate /usr; I know how big (approximately) /usr is going to get and I give it that much space. I guess I'm fortunate not to have ever managed a server where the hard drives were so tiny as to make that impractical. This whole udev/initrd/mdev/etc problem, for me, has been little more than an entertaining diversion, since I've been using a supported setup from the start. However, I'm confident that there are legitimate reasons why some sysadmins use certain configurations which require / and /usr to be different partitions; I'm less confident that initrd is not the real solution to their problem but that's not really my call to make. I'm *very* confident that a dismissal of this issue as the ego if one or two guys who happen to write udev is a blatant oversimplification that does not do justice to the complexities involved in making modern hardware work. --Mike
RE: [gentoo-user] Re: LVM, /usr and really really bad thoughts.
On Mar 14, 2012 11:19 PM, Mike Edenfield kut...@kutulu.org wrote: From: Alan McKinnon [mailto:alan.mckin...@gmail.com] Sent: Tuesday, March 13, 2012 3:14 AM To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts. On Tue, 13 Mar 2012 11:54:58 +0700 Pandu Poluan pa...@poluan.info wrote: The idea of trying to launch udevd and initialize devices without the software, installed in /usr, which is required by those devices is a configuration that causes problems in many real-world, practical situations. The requirement of having /usr on the same partition as / is also a configuration that causes problems in many real-world, practical situations. I quite often read about this, and after some thinking, I have to ask: why? I've also thought about this and I also want to ask why? To be honest, I was simply taking for granted that all of the other people on this list who made a huge fuss about this were not lying. I, personally, have never had a use or need for a separate /usr; I know how big (approximately) /usr is going to get and I give it that much space. I guess I'm fortunate not to have ever managed a server where the hard drives were so tiny as to make that impractical. This whole udev/initrd/mdev/etc problem, for me, has been little more than an entertaining diversion, since I've been using a supported setup from the start. However, I'm confident that there are legitimate reasons why some sysadmins use certain configurations which require / and /usr to be different partitions; I'm less confident that initrd is not the real solution to their problem but that's not really my call to make. I'm *very* confident that a dismissal of this issue as the ego if one or two guys who happen to write udev is a blatant oversimplification that does not do justice to the complexities involved in making modern hardware work. This email [1] (and the correction email right afterwards) should give some much-needed perspective on why we're driving full-speed toward an overturned manure truck (which some of us, e.g., Walter and me, are desperately pulling at the handbrakes). [1] http://lists.busybox.net/pipermail/busybox/2011-September/076713.html Rgds,
RE: [gentoo-user] Re: LVM, /usr and really really bad thoughts.
From: Pandu Poluan [mailto:pa...@poluan.info] Sent: Wednesday, March 14, 2012 12:28 PM This email [1] (and the correction email right afterwards) should give some much-needed perspective on why we're driving full-speed toward an overturned manure truck (which some of us, e.g., Walter and me, are desperately pulling at the handbrakes). [1] http://lists.busybox.net/pipermail/busybox/2011-September/076713.html Actually, that email lost me in the second sentence (though I kept reading): It is incredibly biased towards huge desktop systems and behemoth software Every machine I run Linux on is a huge desktop system running behemoth software (Eclipse, GNOME, Chromium, LibreOffice, etc.). That's why it's called a free desktop system. The author of this email is clearly baised *against* desktop systems running desktop environments, as well as any other highly dynamic system that doesn't fit the model of a simple server running Linux the way it ran 10 years ago. He seems to be producing a rather vitriolic, and IMO uncalled-for, rant against the simple fact that computers do more stuff in 2012 than they did in 1972 and the udev developers are changing with the times. The reality is, the majority of people running Linux desktop systems using big software packages want a desktop system that works out of the box so they can just turn it on and get their work done. That is the audience that udev is targeted for, and it is doing a perfectly good job at meeting the needs of that audience. The fact that the largest major distributions are currently using udev (with an initrd) successfully is all the proof you need that it actually does work. The people who want or need a more specialized solution to this same problem (dynamic device management), are generally also smart enough to avoid using udev if they so choose. Again, the fact that, with merely a few months of effort, a handful of users on this list have produced exactly such a solution is all the proof I need that such a solution is possible. I also know that I have no reason to use their solution because the one I'm using now works just fine for me. As to the email itself, I see two major technical flaws in the argument as presented: First, the fundamental argument being made is that /usr should be allowed to remain a separate partition, and that the misinformed and/or dishonest and or [lacking in] good engineering practices systemd team somehow wants to force everyone to put /usr and / together. Except that's *absolutely not at all what they are proposing*. Their proposal is precisely this: the /usr partition contains binaries that are needed on many modern desktop systems to properly populate the device tree, and thus, the /usr partition must be available early enough in the boot process for that to happen, and thus, we can move forward with our software (udev) with the assumption that /usr will be available when we need it. Second, the idea that the entire collective Fedora/Debian/etc teams somehow made a mistake by install[ing] critical software into /usr. This argument falls flat when the author fails to identify what he or she considers to be critical vs. non-critical software. Is bluetoothd critical? On my laptop it is not. On my main development workstation it is not. On my wife's desktop it is because she has a Bluetooth keyboard/mouse combination. Should bluetoothd be moved from /usr/sbin to /sbin? Along with libglib and libdbus, which it depends on? How about usbmuxd, or alsactl? You could also argue, as some here have done, that these are not truly critical software because those are not critical devices; but now, you must teach udev to know the difference between device that can be added pre-mount and device that must wait until post-mount on a per-device-per-system-per-boot basis, since that designation may change at any time. And recognize the difference between device that failed because something went horribly wrong and I should drop into rescue mode vs device that failed because I tried too early and just need to try again later. And provide a way for udev to create the devices it can, pause while the rest of the filesystems come up, detect that the rest of the filesystems are present, then go back and re-do the devices that failed originally. All the while knowing that the solution of just make /usr available is such an easy and reasonable answer 99% of the time. I know which option I'd pick to spend my limited time and resources on. There's no need to get mean-spirited about it. You are not pulling at the hand-brakes of an out-of-control manure truck. You are producing one of many possible /perfectly valid/ alternative solutions to a complex problem, one which meets your needs but does not meet mine, and there is absolutely nothing wrong with that. --Mike
Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts.
On Wed, Mar 14, 2012 at 06:15:03PM -0400, Mike Edenfield wrote Every machine I run Linux on is a huge desktop system running behemoth software (Eclipse, GNOME, Chromium, LibreOffice, etc.). I have Abiword, Gimp, Gnumeric, Firefox, etc, running just fine, thank you, on ICEWM. He seems to be producing a rather vitriolic, and IMO uncalled-for, rant against the simple fact that computers do more stuff in 2012 than they did in 1972 and the udev developers are changing with the times. This argument falls flat when the author fails to identify what he or she considers to be critical vs. non-critical software. Is bluetoothd critical? On my laptop it is not. On my main development workstation it is not. On my wife's desktop it is because she has a Bluetooth keyboard/mouse combination. Should bluetoothd be moved from /usr/sbin to /sbin? Along with libglib and libdbus, which it depends on? How about usbmuxd, or alsactl? *YOUR WIFE'S LAPTOP* won't boot properly without /usr on /, or an initramfs. OK, put /usr on /, or an initramfs *ON YOUR WIFE'S LAPTOP*. I don't have a problem with that. What gets people really upset is the dog-in-the-manger attitude of if my complex/corner-case machine won't boot up without /usr on /, or an initramfs, then by golly *NOBODY'S* machine will be allowed to boot up without /usr on /, or an initramfs. My machine does not use bluetooth/other-weird-stuff. udev doesn't need to find bluetooth drivers on /usr on my machine. Why is udev being deliberately broken to not work on *EVERYBODY'S* machine if they don't have /usr on /, or an initramfs? -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts.
Walter Dnes wrote: On Wed, Mar 14, 2012 at 06:15:03PM -0400, Mike Edenfield wrote Every machine I run Linux on is a huge desktop system running behemoth software (Eclipse, GNOME, Chromium, LibreOffice, etc.). I have Abiword, Gimp, Gnumeric, Firefox, etc, running just fine, thank you, on ICEWM. He seems to be producing a rather vitriolic, and IMO uncalled-for, rant against the simple fact that computers do more stuff in 2012 than they did in 1972 and the udev developers are changing with the times. This argument falls flat when the author fails to identify what he or she considers to be critical vs. non-critical software. Is bluetoothd critical? On my laptop it is not. On my main development workstation it is not. On my wife's desktop it is because she has a Bluetooth keyboard/mouse combination. Should bluetoothd be moved from /usr/sbin to /sbin? Along with libglib and libdbus, which it depends on? How about usbmuxd, or alsactl? *YOUR WIFE'S LAPTOP* won't boot properly without /usr on /, or an initramfs. OK, put /usr on /, or an initramfs *ON YOUR WIFE'S LAPTOP*. I don't have a problem with that. What gets people really upset is the dog-in-the-manger attitude of if my complex/corner-case machine won't boot up without /usr on /, or an initramfs, then by golly *NOBODY'S* machine will be allowed to boot up without /usr on /, or an initramfs. My machine does not use bluetooth/other-weird-stuff. udev doesn't need to find bluetooth drivers on /usr on my machine. Why is udev being deliberately broken to not work on *EVERYBODY'S* machine if they don't have /usr on /, or an initramfs? This has been one of my points too. I could go out and buy me a bluetooth mouse/keyboard but I don't because it to complicates matters. Does my BIOS see these devices so that I can access BIOS, you know, press del to enter setup. I have a desktop computer but I use PS/2 connections. Why? It always works even with the BIOS and grub. I might also add, if my keyboard gets further away than my keyboard cable, I can't exactly use the computer since I can't see the monitor any more, not and read anything anyway. I may end up with a init thingy, which I am currently using. Thing is, the first time it breaks and I can't fix it, I'll install something else. I chose Gentoo because I could build a system that has a SIMPLE boot process. Turn on power, BIOS does it's thing, grub loads and I make a selection, kernel loads, init starts. Now, I have one more item that has broken for me before when I had a initfs based distro. If I have to have a init thingy, why use Gentoo? It was one reason I left Mandrake and chose Gentoo. Actually, it was a HUGE reason. I don't want to count the number of times I would try to boot my system and the init thingy fail to work. Thing is, it is MUCH easier and faster to install Kubuntu than it is Gentoo and Kubuntu takes care of the init thingy itself. If it breaks, just reinstall. Reinstalling Gentoo takes way to long for that to be a option. Back to my hole. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts.
On Tue, 13 Mar 2012 11:54:58 +0700 Pandu Poluan pa...@poluan.info wrote: The idea of trying to launch udevd and initialize devices without the software, installed in /usr, which is required by those devices is a configuration that causes problems in many real-world, practical situations. The requirement of having /usr on the same partition as / is also a configuration that causes problems in many real-world, practical situations. I quite often read about this, and after some thinking, I have to ask: why? I've also thought about this and I also want to ask why? I stopped using a separate /usr on my workstations a long time ago when I realized it was pointless. The days of 5M hard disks when the entire OS didn't fit on one are long gone. The days of my software going tits up at the drop of a hat requiring a minimal repair environment to fix it at boot are also long gone (my desk is littered with LiveCDs and bootable flash drives). So I can't find a single good reason why /usr *must* be separate and my workstations are the only machines that will ever have hotplug booting issues. I'm even considering changing the install standards for the company servers to dispense with separate /usr, as long as there are safeguards against clowns who don't read INSTALL files and happily accept /usr/local/package/var as a storage area. -- Alan McKinnnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts.
On Mar 13, 2012 2:19 PM, Alan McKinnon alan.mckin...@gmail.com wrote: On Tue, 13 Mar 2012 11:54:58 +0700 Pandu Poluan pa...@poluan.info wrote: The idea of trying to launch udevd and initialize devices without the software, installed in /usr, which is required by those devices is a configuration that causes problems in many real-world, practical situations. The requirement of having /usr on the same partition as / is also a configuration that causes problems in many real-world, practical situations. I quite often read about this, and after some thinking, I have to ask: why? I've also thought about this and I also want to ask why? I stopped using a separate /usr on my workstations a long time ago when I realized it was pointless. The days of 5M hard disks when the entire OS didn't fit on one are long gone. The days of my software going tits up at the drop of a hat requiring a minimal repair environment to fix it at boot are also long gone (my desk is littered with LiveCDs and bootable flash drives). So I can't find a single good reason why /usr *must* be separate and my workstations are the only machines that will ever have hotplug booting issues. I'm even considering changing the install standards for the company servers to dispense with separate /usr, as long as there are safeguards against clowns who don't read INSTALL files and happily accept /usr/local/package/var as a storage area. I just did some more thinking, and *maybe* the reason is to prevent something under /usr (src and share comes to mind) from growing too big and messes up the root filesystem. Place the offenders on a separate partition, then mount them under /usr, and all should be well... Rgds,
Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts.
On Tue, Mar 13, 2012 at 1:31 AM, Pandu Poluan pa...@poluan.info wrote: On Mar 13, 2012 2:19 PM, Alan McKinnon alan.mckin...@gmail.com wrote: On Tue, 13 Mar 2012 11:54:58 +0700 Pandu Poluan pa...@poluan.info wrote: The idea of trying to launch udevd and initialize devices without the software, installed in /usr, which is required by those devices is a configuration that causes problems in many real-world, practical situations. The requirement of having /usr on the same partition as / is also a configuration that causes problems in many real-world, practical situations. I quite often read about this, and after some thinking, I have to ask: why? I've also thought about this and I also want to ask why? I stopped using a separate /usr on my workstations a long time ago when I realized it was pointless. The days of 5M hard disks when the entire OS didn't fit on one are long gone. The days of my software going tits up at the drop of a hat requiring a minimal repair environment to fix it at boot are also long gone (my desk is littered with LiveCDs and bootable flash drives). So I can't find a single good reason why /usr *must* be separate and my workstations are the only machines that will ever have hotplug booting issues. I'm even considering changing the install standards for the company servers to dispense with separate /usr, as long as there are safeguards against clowns who don't read INSTALL files and happily accept /usr/local/package/var as a storage area. I just did some more thinking, and *maybe* the reason is to prevent something under /usr (src and share comes to mind) from growing too big and messes up the root filesystem. Place the offenders on a separate partition, then mount them under /usr, and all should be well... The always used example is to have /usr shared as a read only NFS partition among several workstations. In corporate environments it is certainly used this way (or at least it was when I worked, and the way I used it in my office seven or eight years ago). Of course, for a normal desktop user, a separate /usr is basically useless. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts.
On Mar 13, 2012 2:41 PM, Canek Peláez Valdés can...@gmail.com wrote: On Tue, Mar 13, 2012 at 1:31 AM, Pandu Poluan pa...@poluan.info wrote: On Mar 13, 2012 2:19 PM, Alan McKinnon alan.mckin...@gmail.com wrote: On Tue, 13 Mar 2012 11:54:58 +0700 Pandu Poluan pa...@poluan.info wrote: The idea of trying to launch udevd and initialize devices without the software, installed in /usr, which is required by those devices is a configuration that causes problems in many real-world, practical situations. The requirement of having /usr on the same partition as / is also a configuration that causes problems in many real-world, practical situations. I quite often read about this, and after some thinking, I have to ask: why? I've also thought about this and I also want to ask why? I stopped using a separate /usr on my workstations a long time ago when I realized it was pointless. The days of 5M hard disks when the entire OS didn't fit on one are long gone. The days of my software going tits up at the drop of a hat requiring a minimal repair environment to fix it at boot are also long gone (my desk is littered with LiveCDs and bootable flash drives). So I can't find a single good reason why /usr *must* be separate and my workstations are the only machines that will ever have hotplug booting issues. I'm even considering changing the install standards for the company servers to dispense with separate /usr, as long as there are safeguards against clowns who don't read INSTALL files and happily accept /usr/local/package/var as a storage area. I just did some more thinking, and *maybe* the reason is to prevent something under /usr (src and share comes to mind) from growing too big and messes up the root filesystem. Place the offenders on a separate partition, then mount them under /usr, and all should be well... The always used example is to have /usr shared as a read only NFS partition among several workstations. In corporate environments it is certainly used this way (or at least it was when I worked, and the way I used it in my office seven or eight years ago). Of course, for a normal desktop user, a separate /usr is basically useless. Ah, thanks for the explanation. Makes sense. Rgds,
Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts.
On Mon, Mar 12, 2012 at 06:22:39PM -0500, Dale wrote I think mdev has shown it can be fixed. Given time, it just may replace udev then the udev dev can screw up his own stuff on not bother other distros. I'm giving mdev some thought here. I want /usr on LVM which means it has to be separate. Sorry, in lste-breaking news, it looks like udev is a mandatory dependancy for lvm2. No udev == No lvm2 Can you run a test for me? What happens when you... 1) insert the line sys-fs/udev into /etc/portage/package.mask 2) execute emerge -pv system 3) execute emerge -pv world 4) Remember to remove the sys-fs/udev line from package.maskG I expect that you should get an error message about not being able to emerge lvm2 due to udev being masked. This is something I intend to add to the instructions, so people can check ahead of time whether their particular setup is able to run without udev. -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts.
On Tue, Mar 13, 2012 at 2:09 AM, Walter Dnes waltd...@waltdnes.org wrote:
On Mon, Mar 12, 2012 at 06:22:39PM -0500, Dale wrote
I think mdev has shown it can be fixed. Given time, it just may replace
udev then the udev dev can screw up his own stuff on not bother other
distros. I'm giving mdev some thought here. I want /usr on LVM which
means it has to be separate.
Sorry, in lste-breaking news, it looks like udev is a mandatory
dependancy for lvm2. No udev == No lvm2
It seems so; from lvm2 2.02.93:
DEPEND_COMMON=!!sys-fs/device-mapper
readline? ( sys-libs/readline )
clvm? ( =sys-cluster/dlm-2*
cman? ( =sys-cluster/cman-2* ) )
=sys-fs/udev-151-r4
...
econf $(use_enable readline) \
$(use_enable selinux) \
--enable-pkgconfig \
--with-confdir=${EPREFIX}/etc \
--sbindir=${EPREFIX}/sbin \
--with-staticdir=${EPREFIX}/sbin \
--libdir=${EPREFIX}/$(get_libdir) \
--with-usrlibdir=${EPREFIX}/usr/$(get_libdir) \
--enable-udev_rules \
--enable-udev_sync \
--with-udevdir=${EPREFIX}/lib/udev/rules.d/ \
${myconf} \
CLDFLAGS=${LDFLAGS} || die
Maybe you could try to modify the LVM ebuild to point udevdir to a
black hole and disable udev_rules and udev_sync. But that would be at
best a hack; I'm not familiar enough with the LVM code to know if they
actually need udev to run, or it only installs some rules so it can
run better with it.
Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México
Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts.
On Tue, 13 Mar 2012 01:38:26 -0600, Canek Peláez Valdés wrote: Of course, for a normal desktop user, a separate /usr is basically useless. If you need to encrypt /etc but don't want the overhead of encrypting everything is /usr, which is basically publicly available files anyway, separating / and /usr makes sense. Compiling a kernel already takes long enough on a lower powered machine, encrypting /usr/src only makes it worse. -- Neil Bothwick C:\BELFRY is where I keep my .BAT files ^^^oo^^^ signature.asc Description: PGP signature
Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts.
On Mon, 12 Mar 2012 17:53:29 -0600 Canek Peláez Valdés can...@gmail.com wrote: As Alan said in other thread, it can be fixed (if you think is not right) for some very specific cases. Alan mentioned servers, really simple desktops with simple hotplug devices, and embedded systems. For mdev to fix the situation in the general case, it would have to cover all the setups udev covers. That means bluetooth devices (including keyboards and mice), USB soundcards, touch screens and the like, all of them being plugged and unplugged at any time in any order. Maybe someday mdev will be able to handle all the cases that udev does. If it does (which I honestly doubt), I'm pretty sure at that point it would have become as complex as udev, if not more, and it will probably need the same requirements that udev has. Including the simple one that for mounting a filesystem, the plumbing needed to mounting it has to be available before, and we cannot keep throwing everything directly on / so it can mount /usr. I'm slowly coming round to this point of view too. If you want a full blown desktop machine with all the modern bells and whistles that always JustWorks(tm), realise that you have a complex system needing complex software. And udev is designed to deal with that. To accomplish this task, udev needs to apply some constraints. For almost everything else, that sophistication is not needed and simpler (i.e. less complex) software will suffice. Currently mdev (or something else like it) fills that needs. So 2 different scenarios with different solutions. Horses for courses. -- Alan McKinnnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts.
On Mar 13, 2012 10:39 PM, Alan McKinnon alan.mckin...@gmail.com wrote: On Mon, 12 Mar 2012 17:53:29 -0600 Canek Peláez Valdés can...@gmail.com wrote: As Alan said in other thread, it can be fixed (if you think is not right) for some very specific cases. Alan mentioned servers, really simple desktops with simple hotplug devices, and embedded systems. For mdev to fix the situation in the general case, it would have to cover all the setups udev covers. That means bluetooth devices (including keyboards and mice), USB soundcards, touch screens and the like, all of them being plugged and unplugged at any time in any order. Maybe someday mdev will be able to handle all the cases that udev does. If it does (which I honestly doubt), I'm pretty sure at that point it would have become as complex as udev, if not more, and it will probably need the same requirements that udev has. Including the simple one that for mounting a filesystem, the plumbing needed to mounting it has to be available before, and we cannot keep throwing everything directly on / so it can mount /usr. I'm slowly coming round to this point of view too. If you want a full blown desktop machine with all the modern bells and whistles that always JustWorks(tm), realise that you have a complex system needing complex software. And udev is designed to deal with that. To accomplish this task, udev needs to apply some constraints. For almost everything else, that sophistication is not needed and simpler (i.e. less complex) software will suffice. Currently mdev (or something else like it) fills that needs. So 2 different scenarios with different solutions. Horses for courses. Fully agree. However, currently the 'less complex' mdev solution is not yet a 'first class citizen' anywhere. Rgds,
Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts.
On 2012-03-13 08:13, Alan McKinnon wrote: I've also thought about this and I also want to ask why? Hm... me too? :-) I stopped using a separate /usr on my workstations a long time ago when I realized it was pointless. The days of 5M hard disks when the entire Ok, you realized it was pointless for *you*, right? It's not a universal fact, as far as I can see... Recall the previous discussion about this very same subject, where I compared unix to lego? Flexibility is the keyword here, I think, that some of us do not want to forego. For instance I can very well see myself indulging in some SSDs that I could put in my 'puter where one is dedicated for /usr, one for /var and one for the root file system, whereas I would keep a big normal HDD for /home... In my opinion there's a lot of hand waving that basically says something like on a modern desktop system, complex software is needed, therefore /usr needs to be on the root file system (or mounted via initrd)... and states this as a universal fact, without answering the question Why?. Isn't it those who wants to change that should answer why they want to change? And I trust Poetterings/Sievers answer why it needs to change as far as I can throw either of them (I'm quite weak)... it's all tied in neatly into their (IMO) overly complex software. Hm, if we want to be modern, perhaps we should abolish partitions altogether and put everything in the cloud? That would be modern, right? ;-) I'm running a decent desktop system (Xfce4) and I have /usr on a separate partition without any initrd... Why would I need to change this (except from being forced if I continue to use udev)? So far the only technical reason I've heard that somehow requires udev to have access to files in /usr is a bluetooth keyboard. Anything else that *needs* to be working during boot (before a separate /usr can be mounted)? And in my opinion, if a keyboard needs complex software to work then it's broken by design. But I digress, I really should start coding my own solutions, as Canek says... Best regards Peter K
Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts.
Hi! 2012/3/11 walt w41...@gmail.com: On 03/11/2012 05:16 AM, Jorge Martínez López wrote: Hi! Hi Jorge. I had some struggle with a separate /usr on top of LVM I'm just curious why you use a separate /usr, and why you are willing to struggle to keep it that way. Several people have posted opinions here in recent months, but I don't recall that you are one of them. I believe that by the time I installed Gentoo it was recommended on the installation handbook. I did not give it much thought. I believed back then that thanks to LVM I could always grow and shrink my partitions as needed. If I had to do it again I would probably go the btrfs route (once they get fsck working). Regarding the whole /usr discussion, I trust the developers to know what they are doing better than I do and I did not find any serious flaw on their reasoning. It took me just a couple of hours to get the initrd working, so I did it and moved on. On the other hand I can understand some people disagree. I do not have a problem with that. Cheers, -- Jorge Martínez López jorg...@gmail.com http://www.jorgeml.net Google Talk / XMPP: jorg...@gmail.com
Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts.
On Mon, Mar 12, 2012 at 2:23 PM, Jorge Martínez López jorg...@gmail.com wrote: Hi! 2012/3/11 walt w41...@gmail.com: On 03/11/2012 05:16 AM, Jorge Martínez López wrote: Hi! Hi Jorge. I had some struggle with a separate /usr on top of LVM I'm just curious why you use a separate /usr, and why you are willing to struggle to keep it that way. Several people have posted opinions here in recent months, but I don't recall that you are one of them. I believe that by the time I installed Gentoo it was recommended on the installation handbook. I did not give it much thought. I believed back then that thanks to LVM I could always grow and shrink my partitions as needed. If I had to do it again I would probably go the btrfs route (once they get fsck working). Regarding the whole /usr discussion, I trust the developers to know what they are doing better than I do and I did not find any serious flaw on their reasoning. It took me just a couple of hours to get the initrd working, so I did it and moved on. On the other hand I can understand some people disagree. I do not have a problem with that. Don't forget you're using Gentoo; you're implicitly not very far removed from the skill levels of the developers themselves. -- :wq
Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts.
On March 12, 2012 at 2:30 PM Michael Mol mike...@gmail.com wrote: Don't forget you're using Gentoo; you're implicitly not very far removed from the skill levels of the developers themselves. -- :wq Maybe you're not, but it only takes me a few minutes being around chithead and NeddySeagoon for me to realize I ain't gotta Gentoo clue! -- Happy Penguin Computers`) 126 Fenco Drive( \ Tupelo, MS 38801^^ 662-269-2706; 662-491-8613 support at happypenguincomputers dot com http://www.happypenguincomputers.com
Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts.
On Monday 12 Mar 2012 18:39:26 Bruce Hill, Jr. wrote: On March 12, 2012 at 2:30 PM Michael Mol mike...@gmail.com wrote: Don't forget you're using Gentoo; you're implicitly not very far removed from the skill levels of the developers themselves. -- :wq Maybe you're not, but it only takes me a few minutes being around chithead and NeddySeagoon for me to realize I ain't gotta Gentoo clue! Crikey! Is Neddy still around! O_O ... and I thought that I was knocking on a bit. :-)) -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts.
On Mon, Mar 12, 2012 at 2:39 PM, Bruce Hill, Jr. da...@happypenguincomputers.com wrote: On March 12, 2012 at 2:30 PM Michael Mol mike...@gmail.com wrote: Don't forget you're using Gentoo; you're implicitly not very far removed from the skill levels of the developers themselves. -- :wq Maybe you're not, but it only takes me a few minutes being around chithead and NeddySeagoon for me to realize I ain't gotta Gentoo clue! Point is, most people I've seen in here know a lot more than most[1], and are generally intelligent enough to overcome any limitation that isn't fundamentally philosophical in origin (see mdev vs udev, ALSA vs OSS4 vs PulseAudio, lvm vs mdraid vs physical raid vs btrfs vs zfs). So don't sell yourself too short, and don't blindly trust the opinions and decisions of others; they're not always as right as assume them to be, and managing to get Gentoo working suggests you have some right to point out when the emperor's not wearing any clothes. [1] I like to surround myself with people smarter or more knowledgeable than I am about things, and I hit the motherload in this list... -- :wq
Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts.
On Mon, 12 Mar 2012 14:39:26 -0400 (EDT) Bruce Hill, Jr. da...@happypenguincomputers.com wrote: On March 12, 2012 at 2:30 PM Michael Mol mike...@gmail.com wrote: Don't forget you're using Gentoo; you're implicitly not very far removed from the skill levels of the developers themselves. -- :wq Maybe you're not, but it only takes me a few minutes being around chithead and NeddySeagoon for me to realize I ain't gotta Gentoo clue! And guess what? That's about where most of us started out :-) It gets better, it really does (ye gods now I sound like a behavioural therapist) -- Happy Penguin Computers`) 126 Fenco Drive( \ Tupelo, MS 38801^^ 662-269-2706; 662-491-8613 support at happypenguincomputers dot com http://www.happypenguincomputers.com -- Alan McKinnnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts.
Bruce Hill, Jr. wrote: On March 12, 2012 at 2:30 PM Michael Mol mike...@gmail.com wrote: Don't forget you're using Gentoo; you're implicitly not very far removed from the skill levels of the developers themselves. -- :wq Maybe you're not, but it only takes me a few minutes being around chithead and NeddySeagoon for me to realize I ain't gotta Gentoo clue! -- Happy Penguin Computers`) 126 Fenco Drive( \ Tupelo, MS 38801^^ 662-269-2706; 662-491-8613 support at happypenguincomputers dot com http://www.happypenguincomputers.com I like that quote. I may not be dev material but I know this /usr mess is not right. The only reason it is happening is because of one or two distros that push it to make it easier for themselves. I think mdev has shown it can be fixed. Given time, it just may replace udev then the udev dev can screw up his own stuff on not bother other distros. I'm giving mdev some thought here. I want /usr on LVM which means it has to be separate. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts.
On Mon, Mar 12, 2012 at 5:22 PM, Dale rdalek1...@gmail.com wrote: Bruce Hill, Jr. wrote: On March 12, 2012 at 2:30 PM Michael Mol mike...@gmail.com wrote: Don't forget you're using Gentoo; you're implicitly not very far removed from the skill levels of the developers themselves. -- :wq Maybe you're not, but it only takes me a few minutes being around chithead and NeddySeagoon for me to realize I ain't gotta Gentoo clue! -- Happy Penguin Computers `) 126 Fenco Drive ( \ Tupelo, MS 38801 ^^ 662-269-2706; 662-491-8613 support at happypenguincomputers dot com http://www.happypenguincomputers.com I like that quote. I may not be dev material but I know this /usr mess is not right. The only reason it is happening is because of one or two distros that push it to make it easier for themselves. I have yet to see some hard evidence on this claim. I think mdev has shown it can be fixed. As Alan said in other thread, it can be fixed (if you think is not right) for some very specific cases. Alan mentioned servers, really simple desktops with simple hotplug devices, and embedded systems. For mdev to fix the situation in the general case, it would have to cover all the setups udev covers. That means bluetooth devices (including keyboards and mice), USB soundcards, touch screens and the like, all of them being plugged and unplugged at any time in any order. Maybe someday mdev will be able to handle all the cases that udev does. If it does (which I honestly doubt), I'm pretty sure at that point it would have become as complex as udev, if not more, and it will probably need the same requirements that udev has. Including the simple one that for mounting a filesystem, the plumbing needed to mounting it has to be available before, and we cannot keep throwing everything directly on / so it can mount /usr. And BTW, the split between /bin /usr/bin has always been idiotic and it was originally an accident: you can read the true story of the split in http://lists.busybox.net/pipermail/busybox/2010-December/074114.html But for the simple cases that Alan mentioned, the mdev solution is perfectly fine if for some reason someone keeps refusing to use an initramfs. Given time, it just may replace udev I'm willing to bet a beer this will not happen. then the udev dev can screw up his own stuff on not bother other distros. No one is forcing any part of the stack on anyone. The other distros follows because it's the correct technical solution. At least I'm convinced it is; I have yet to see some hard evidence on the contrary. I'm giving mdev some thought here. I want /usr on LVM which means it has to be separate. And in this case an initramfs is the best option, so we can stop polluting / with support for everything necessary under the sun (now or in the future) for mounting /usr. That's the way I see it anyhow. Doesn't stop mdev from being a beautiful hack. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
RE: [gentoo-user] Re: LVM, /usr and really really bad thoughts.
From: Dale [mailto:rdalek1...@gmail.com] Sent: Monday, March 12, 2012 7:23 PM I like that quote. I may not be dev material but I know this /usr mess is not right. The only reason it is happening is because of one or two distros that push it to make it easier for themselves. If that's honestly what you think then I suspect you don't understand the problem as well as you believe. The idea of trying to launch udevd and initialize devices without the software, installed in /usr, which is required by those devices is a configuration that causes problems in many real-world, practical situations. The requirement of having /usr on the same partition as / is also a configuration that causes problems in many real-world, practical situations. The requirement to ensure that /usr is *somehow available* before launching udevd is a configuration that, I am told, causes problems in some specialized real-world, practical situations. (I am ignoring problems such as initramd might possibly break maybe or that's more work than I want to do as being the expected griping that always happens when you ask a group of geeks to change something.) It is impossible for udev to solve the problem for all users in all configuration. Given the three readily available options, the one that makes the most sense from a software engineering standpoint is to choose option three, thus ensuring that your solution pisses off the smallest subset of users. Those users are then free to create a solution that better suits their needs, such as replacing udev with different software which made a different choice. To call one option a mess that is not right is both an unrealistic oversimplification of a complex problem and utterly unfair to the people trying to solve that problem. --Mike
RE: [gentoo-user] Re: LVM, /usr and really really bad thoughts.
On Mar 13, 2012 9:05 AM, Mike Edenfield kut...@kutulu.org wrote: From: Dale [mailto:rdalek1...@gmail.com] Sent: Monday, March 12, 2012 7:23 PM I like that quote. I may not be dev material but I know this /usr mess is not right. The only reason it is happening is because of one or two distros that push it to make it easier for themselves. If that's honestly what you think then I suspect you don't understand the problem as well as you believe. The idea of trying to launch udevd and initialize devices without the software, installed in /usr, which is required by those devices is a configuration that causes problems in many real-world, practical situations. The requirement of having /usr on the same partition as / is also a configuration that causes problems in many real-world, practical situations. I quite often read about this, and after some thinking, I have to ask: why? The requirement to ensure that /usr is *somehow available* before launching udevd is a configuration that, I am told, causes problems in some specialized real-world, practical situations. (I am ignoring problems such as initramd might possibly break maybe or that's more work than I want to do as being the expected griping that always happens when you ask a group of geeks to change something.) When one's handling enterprise servers, might possibly break is a 95% certainty of you do that and I'll make sure to have a pink slip standing by. :-) Rgds,
