Re: [gentoo-user] /dev/sda* missing at boot
On Saturday, September 10, 2011 02:54:58 AM Dale wrote: Alan McKinnon wrote: You give me too much credit :-) There's also Neil, Wonko, Volker, Stroller, Grant, meino.cramer, Mick, Paul, Harry, Albert, Alex, Walter, Alan Mackenzie (awesome name!), James, kashani, Pandu and about a 1000 more whose names I can't exactly recall right now. This here mailing-list has got the most varied and highest skills of any technical list I've ever subscribed to. We have regular desktop users, folks who work in server rooms, devs, owners of software companies, regular sysadmins, fellows who ship embedded devices, and at least one of everything in between. I don't mean to go all fuzzy feel-good here, but it's an honour to be able to communicate and interact with so many skilled people for so many years. I agree here. There are a few other lists with people with really good technical skills. But some of those are quite strict with what is on-topic and what isn't. On this list, we tend to cover anything that is related to computers. That is true. There are lots who post a lot here. I just recall seeing some stats somewhere and me and you were the top two. That was about a year ago so it may have changed. Just had to go find that link again. Here it is: http://archives.gentoo.org/stats/gentoo-user-per-year.xml Nice, I'm in the top 10 :) We have a new comer. lol I think the mailing lists, and forums, are one of the key features of Gentoo. The docs seemed to have slumped some but I think it was down to one or two people for a while. I think someone jumped in the fire a few weeks ago tho. Maybe they will catch up. I'm sure it is hard to keep up with all the changes that are going on tho. Gentoo has a LOT of stuff to document. Documenting Gentoo is difficult. I think this list is a good start for documentation though. If we are so skilled, why is the Fedora dev not listening you reckon? Is the Fedora dev aware of non-Fedora installations? -- Joost
Re: [gentoo-user] /dev/sda* missing at boot
On Saturday, September 10, 2011 02:56:48 AM Dale wrote: Alan McKinnon wrote: On Fri, 09 Sep 2011 20:25:22 -0500 Dalerdalek1...@gmail.com wrote: Alan McKinnon wrote: I'm lucky, I can vote with my feet. Out of 140, I have two servers that *require* Linux. One runs Sybase ASE, the other runs Oracle. Everything else works like a bomb on FreeBSD. kthankxbyeudev, thanksfornotplayingnicely Not everyone else is so fortunate though. I guess I understood more than I thought then. Shocking. I understand that but the udev guru doesn't. ;-) I may go the BSD route too if I leave Gentoo. So, my feet works too. I wonder if I would even be missed here? :/ Dale N Dale you can't lavveee! Seriously, you're an institution around here, you would be sorely missed. I sometimes think people get tired of the chatter box. lol I wonder if I am on somebody's blacklist? :/ If you are, that person is missing out on some good entertainment :)
Re: [gentoo-user] vmplayer wont start
2011-09-08 23:07 keltezéssel, Mick írta: On Thursday 08 Sep 2011 09:29:38 ifj. Stefán István wrote: Hello! I've installed vmware-player, but can't start it. It outputs a lot of messages (none of them seems to be error msgs) and gives back the prompt: localhost ~ # vmplayer Logging to /tmp/vmware-root/setup-8401.log filename: /lib/modules/2.6.38-gentoo-r6/misc/vmmon.ko supported: external license:GPL v2 description:VMware Virtual Machine Monitor. author: VMware, Inc. depends: vermagic: 2.6.38-gentoo-r6 SMP mod_unload modversions filename: /lib/modules/2.6.38-gentoo-r6/misc/vmnet.ko supported: external license:GPL v2 description:VMware Virtual Networking Driver. author: VMware, Inc. depends: vermagic: 2.6.38-gentoo-r6 SMP mod_unload modversions filename: /lib/modules/2.6.38-gentoo-r6/misc/vmblock.ko supported: external version:1.1.2.0 license:GPL v2 description:VMware Blocking File System author: VMware, Inc. srcversion: B89EB740A79434530BAB81F depends: vermagic: 2.6.38-gentoo-r6 SMP mod_unload modversions parm: root:The directory the file system redirects to. (charp) filename: /lib/modules/2.6.38-gentoo-r6/misc/vmci.ko supported: external supported: external license:GPL v2 description:VMware Virtual Machine Communication Interface (VMCI). author: VMware, Inc. depends: vermagic: 2.6.38-gentoo-r6 SMP mod_unload modversions filename: /lib/modules/2.6.38-gentoo-r6/misc/vsock.ko supported: external license:GPL v2 version:1.0.0.0 description:VMware Virtual Socket Family author: VMware, Inc. srcversion: CC633F42818AB6B4476CF99 depends:vmci vermagic: 2.6.38-gentoo-r6 SMP mod_unload modversions filename: /lib/modules/2.6.38-gentoo-r6/misc/vmmon.ko supported: external license:GPL v2 description:VMware Virtual Machine Monitor. author: VMware, Inc. depends: vermagic: 2.6.38-gentoo-r6 SMP mod_unload modversions localhost ~ # Content of the log file: szept 08 10:21:19.939: app| Log for VMware Workstation pid=8401 version=6.5.5 build=build-328052 option=Release szept 08 10:21:19.939: app| Host codepage=UTF-8 encoding=UTF-8 szept 08 10:21:19.939: app| Logging to /tmp/vmware-root/setup-8401.log I use version app-emulation/vmware-player-2.5.5.328052. It wont start even if I add a virtual machine config file parameter to vmplayer. Is there any trick to start it? Have you tried starting it as a plain user, or is vmplayer meant to be started as root? Yes, I1ve tried starting it as a simple user also.
Re: [gentoo-user] vmplayer wont start
2011-09-09 04:18 keltezéssel, Michael Higgins írta: On Thu, 08 Sep 2011 10:29:38 +0200 ifj. Stefán Istvániste...@stef.hu wrote: Hello! I've installed vmware-player, but can't start it. It outputs a lot of messages [ 8 ] It wont start even if I add a virtual machine config file parameter to vmplayer. Is there any trick to start it? Thanks, István WAG here, but maybe this will help:| http://www.google.com/search?q=vmplayer%20USE_SHIPPED_GTK%20ie=utf-8oe=utf-8aq=trls=org.mozilla:en-US:unofficialclient=firefox-asource=hpchannel=np Cheers, VMWARE_USE_SHIPPED_GTK=force vmplayer works! (now I have problem with vmware modules, but this will be another thread...) Thanks, István
Re: [gentoo-user] /dev/sda* missing at boot
On Friday, September 09, 2011 07:24:06 PM pk wrote: On 2011-09-09 10:53, Dale wrote: Can I slap whoever started this? The more I think on this, the worse it Yes Dale, you have my permission! And while you're at it, slap him from me too! ;-) It _may_ be this guy that's responsible for this crap: http://linuxplumbersconf.org/ocw/users/58 Also: http://comments.gmane.org/gmane.linux.hotplug.devel/16994 Interesting read, also that link for systemd. What about the following as a gentoo-solution: As long as filesystem-support for /usr is in the kernel, why can't /usr be mounted right after /? Eg. instead of worrying with an init*, why not edit the boot-scripts to have /usr mounted before udev and colleagues start? mount is still in /bin fstab is still in /etc Both should be available during boot. A script that does: mount / check /etc/fstab to see if /usr is seperate if yes: mount /usr -- Joost
Re: [gentoo-user] /dev/sda* missing at boot
Joost Roeleveld wrote: On Saturday, September 10, 2011 02:56:48 AM Dale wrote: I sometimes think people get tired of the chatter box. lol I wonder if I am on somebody's blacklist? :/ If you are, that person is missing out on some good entertainment :) That may depend on my meds. lol Dale :-) :-)
Re: [gentoo-user] Re: X keyboard model insists of being pc104
On Mon, 12 Sep 2011 05:04:24 +0200, meino.cra...@gmx.de wrote: I copied /etc/X11/xorg.conf.d/10-evdev.conf to /etc/X11/xorg-conf.d/99-evdev.conf and edited it No, you are right! I inserted 99-evdev.conf, because 10-evdev.conf will be overwritten when updateing, No it won't. Most of /etc, including /etc/XX11, is CONFIG_PROTECTed. -- Neil Bothwick Many husbands go broke on the money their wives save on sales. signature.asc Description: PGP signature
Re: [gentoo-user] /dev/sda* missing at boot
On Sunday, September 11, 2011 08:44:20 PM James Wall wrote: On Sun, Sep 11, 2011 at 4:46 PM, David W Noon dwn...@ntlworld.com wrote: On Sun, 11 Sep 2011 16:07:23 -0500, Dale wrote about Re: [gentoo-user] /dev/sda* missing at boot: Mick wrote: On Sunday 11 Sep 2011 19:56:48 Dale wrote: I always have /boot on a separate partition and it is always ext2. So, that is done. I also have a 200Mb /boot partition. It sometimes gets about half full but I could just clean out old kernels more often. I could always make /boot larger too. It seems that I'm gonna have fun with a 35M /boot soon (and no LVM of course). ;-) I'm doing some thinking and reading. I'm either going to go back to a rpm based thing and let something besides me deal with the init* stuff IMO, better to use Debian or Slackware. I went through RPM Hell back in the days when I ran S.u.S.E. (complete with full-stops in the name) and I will never go back. Don't remind me, I used to install RPM-systems with the option install everything just to avoid having to find all the dependencies. After install, I'd compile my own software (installing over distro-supplied files) or simply do a full new install. (Like I do with MS Windows...) or stick around and dive into this init* crap and add LVM on top. Watch this space. You might read something to your advantage in the next few days. If you're building something and needs testers, let me know. I have some scripts that generate LVM rebuild scripts. These scan the current logical volumes and generate lvcreate commands into a script that can rebuild your LVM set-up in seconds. You (or anybody else) are welcome to a copy if you wish. I am interested in the backup scripts to help improve my backup/restore system. Same here, I've been using LVM for a while and I generally remember how to fix things when it breaks. But as these occurences are now rare and far between, I always need to find my old notes again and then update them to new syntax. -- Joost
Re: [gentoo-user] /dev/sda* missing at boot
Joost Roeleveld writes: What about the following as a gentoo-solution: As long as filesystem-support for /usr is in the kernel, why can't /usr be mounted right after /? Eg. instead of worrying with an init*, why not edit the boot-scripts to have /usr mounted before udev and colleagues start? mount is still in /bin fstab is still in /etc Both should be available during boot. But there are no /dev/sd* entries yet for the device /usr is on. That's what udev is for in the first place, creating them. We could add those devices manually, like the essential /dev/console and /dev/null that also have to be there before udev kicks in. Might be simpler than creating the initramfs thing. But probably only with real disk partitions. For LVM, many more devices will be necessary, and I don't creating them all by hand might not be so easy. When udev does so many things these days, couldn't udev itself mount the /usr partition, and then continue with the rules in /etc/udev/rules.d/? But I really think that either udev should just not depend on stuff in /usr, or consist of two stages, one for the essential device nodes, and one that is run later, after /usr is mounted, dealing with stuff in /etc/udev/rules.d. Which will not solve the problems with a bluetooth keyboard, though. But for most of us it might work. Just thinking, Wonko
Re: [gentoo-user] /dev/sda* missing at boot
On Sat, 10 Sep 2011 09:59:41 -0500, Dale wrote: http://archives.gentoo.org/stats/gentoo-user-per-year.xml I had absolutely no idea I sent *that* much mail to gentoo-user :-) Me either. That's when I had to accept that I was a true chatter box. O_O I wonder if Neil knows this? He may not realize how many he sends either. He comes in third several times. Does that qualify as a chatter box too? I have never in my life been accused of talking too much (and if you believe that, you'll believe anything). Although the figures look high, it only works out to around 2 mails per day - or 3 per day if you only post in work time :) -- Neil Bothwick Confucius says He who posts with broken addresses gets no replies.. signature.asc Description: PGP signature
Re: [gentoo-user] /dev/sda* missing at boot
On Sat, 10 Sep 2011 18:34:42 +0200, Alex Schuster wrote: Me either. That's when I had to accept that I was a true chatter box. O_O I wonder if Neil knows this? He may not realize how many he sends either. Since I am on this list, I tend to confuse Alan and Neil. Is this only me? No, it's not only you. Dale confuses the hell out of me regularly ;-) -- Neil Bothwick Being politically correct means always having to say you're sorry. signature.asc Description: PGP signature
[gentoo-user] Re: /dev/sda* missing at boot
The 09/09/11, Michael Schreckenbauer wrote: The question arose, when Canek mentioned bluetoothd, that udev seems to need in some cases. This is wrong. udev on its own does not require extra tools from /usr. Though, the rules used by udev do use software in /usr. It's NOT a udev fault _at all_. This is how developers wrote software and because they wanted to hook themselves early at boot time, using udev facility. They are PulseAudio, NetworkManager, libatasmart, ALSA, D-Bus, CUPS, VirtualBox, usbmuxd, bluetoothd and a LOT of other tools. It's even worse when you know that some scripts are written in python. Everybody can write its own rules without even think about direct (or hidden) /usr dependency. Again, udev is NOT to blame. If bluetoothd doesn't quite fit to /bin or /sbin (I tend to agree here), but is needed before /usr is mounted, then it has to be put *somewhere*. I don't say, that this is the way to go. Only searching for alternatives to a forced initramfs. So, what's the good way to fix all that mess? Certainly not moving most of software to /. Fortunately, we can expect /usr to be mounted before udev starts via the initramfs. It does NOT mean everybody will require a initramfs. It means people WANTING a seperate /usr will need a initramfs. The good thing is that a lot of tools now in / will be granted back to /usr. Let's clean up /. Also, it's a _good_ news for admins expecting to maintain systems with a shared /usr (e.g. over the network). -- Nicolas Sebrecht
Re: [gentoo-user] /dev/sda* missing at boot
On Sat, 10 Sep 2011 23:15:52 +0200, Alan McKinnon wrote: Since I am on this list, I tend to confuse Alan and Neil. Is this only me? girlfriend says that Alan and Neil are both male bald middle-aged pedantic old gits with a fascination for the writing of Douglas Adams. And they are both grammar Nazis. I still strenuously deny being balding, although I won't be able to do so for much longer :( She is not in the least surprised you get them confused. If Neil ever confesses to owning and riding motorcycles, she thinks she might get them mixed up herself. I haven't ridden a bike for years, too many injuries from the days I used to race them. Those walls on the Isle of Man are rather hard. -- Neil Bothwick Criminal Lawyer is a redundancy. signature.asc Description: PGP signature
Re: [gentoo-user] /dev/sda* missing at boot
On Sun, 11 Sep 2011 10:37:25 +0100, Peter Humphrey wrote: So I wonder what Neil will write about this. He seems to be lying low. Just in an area with very poor Internet access. I'm back in England now :) -- Neil Bothwick Top Oxymorons Number 31: Small crowd signature.asc Description: PGP signature
Re: [gentoo-user] /dev/sda* missing at boot
On Mon, 12 Sep 2011 09:45:44 +0200, Joost Roeleveld wrote: As long as filesystem-support for /usr is in the kernel, why can't /usr be mounted right after /? Eg. instead of worrying with an init*, why not edit the boot-scripts to have /usr mounted before udev and colleagues start? Because it is udev that creates the device entries needed to mount /usr - and that doesn't even touch other cases, like /usr being on a software block device, like LVM or dmcrypt. The problem here is that udev is trying to do too much. On the one hand it handles the initial population of /dev/ and all that is needed to mount the contents of fstab. On the other hand, it is trying to be an all-encompassing device and hotplug manager. the latter function should be started relatively late in the boot sequence, the former as soon as possible. I'd like to know why these functions cannot be separated, run the command to populate /dev early on, then start the udev daemon after the filesystems have been mounted. Some sort of early boot rules file would need to be used to handle things like setting up symlinks for block devices to avoid breaking some users' fstabs. -- 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] /dev/sda* missing at boot
Neil Bothwick writes: On Sat, 10 Sep 2011 18:34:42 +0200, Alex Schuster wrote: Since I am on this list, I tend to confuse Alan and Neil. Is this only me? Whoops, which should be: I tend to confuse Alan _with_ Neil. But then, both may be right. No, it's not only you. Dale confuses the hell out of me regularly ;-) Me too :) Wonko
Re: [gentoo-user] /dev/sda* missing at boot
On Monday, September 12, 2011 09:49:22 AM Neil Bothwick wrote: On Mon, 12 Sep 2011 09:45:44 +0200, Joost Roeleveld wrote: As long as filesystem-support for /usr is in the kernel, why can't /usr be mounted right after /? Eg. instead of worrying with an init*, why not edit the boot-scripts to have /usr mounted before udev and colleagues start? Because it is udev that creates the device entries needed to mount /usr - and that doesn't even touch other cases, like /usr being on a software block device, like LVM or dmcrypt. Thanks Alex and Neil. I didn't think it through properly. Which is why I posted it here, rather then try to see how to get the scripts updated for it. The problem here is that udev is trying to do too much. On the one hand it handles the initial population of /dev/ and all that is needed to mount the contents of fstab. On the other hand, it is trying to be an all-encompassing device and hotplug manager. the latter function should be started relatively late in the boot sequence, the former as soon as possible. I'd like to know why these functions cannot be separated, run the command to populate /dev early on, then start the udev daemon after the filesystems have been mounted. Some sort of early boot rules file would need to be used to handle things like setting up symlinks for block devices to avoid breaking some users' fstabs. Yes, which means udev would need to be split into: * devd (which controls the /dev-tree) * plugd (which handles all the hotplug-events where special things happen) The communication between the 2 could be done using a simple /dev/udev_pipe device. devd throws events onto the pipe and plugd handles these events. That would also make things easier to configure as the renaming and such is for devd. But the commands to be executed can then be based on the actual name in /dev. Rather then on the kernel-name/id//whatever. Any thoughts on this? -- Joost PS. I'm throwing ideas here, hopefully we can come to a sane and logical option here
Re: [gentoo-user] /dev/sda* missing at boot
On Mon, 12 Sep 2011 11:07:12 +0200, Joost Roeleveld wrote: I'd like to know why these functions cannot be separated, run the command to populate /dev early on, then start the udev daemon after the filesystems have been mounted. Some sort of early boot rules file would need to be used to handle things like setting up symlinks for block devices to avoid breaking some users' fstabs. Yes, which means udev would need to be split into: * devd (which controls the /dev-tree) * plugd (which handles all the hotplug-events where special things happen) The communication between the 2 could be done using a simple /dev/udev_pipe device. devd throws events onto the pipe and plugd handles these events. I wonder if it could be done more simply. udevd loads but only parses those rule files marked as suitable for early boot time. Later in the boot it switches to full mode and loads all rule files. This is so simple it is either pure genius or completely naive and unworkable. I know which option my money is on... -- Neil Bothwick Diarrhoea is hereditary, it runs in your genes. signature.asc Description: PGP signature
Re: [gentoo-user] Re: /dev/sda* missing at boot
Hi, On Monday, 12. September 2011 10:40:02 Nicolas Sebrecht wrote: The 09/09/11, Michael Schreckenbauer wrote: The question arose, when Canek mentioned bluetoothd, that udev seems to need in some cases. This is wrong. udev on its own does not require extra tools from /usr. Though, the rules used by udev do use software in /usr. It's NOT a udev fault _at all_. Well, this is details. Where's the diffference from user-point-of-view, whether it's udev itself or some scripts executed by udev? And I tend to disagree, with the not udev's fault part. udev treats all exit-codes from scripts as if the device were not present. This includes errors of all kinds. How is this supposed to work at all? So, what's the good way to fix all that mess? Certainly not moving most of software to /. Fortunately, we can expect /usr to be mounted before udev starts via the initramfs. That's *your* opinion. Most people on this list disagree. It does NOT mean everybody will require a initramfs. It means people WANTING a seperate /usr will need a initramfs. The good thing is that a lot of tools now in / will be granted back to /usr. Let's clean up /. Also, it's a _good_ news for admins expecting to maintain systems with a shared /usr (e.g. over the network). Since when is a mandatory initramfs a good thing for admins? Care to explain? Regards, Michael
Re: [gentoo-user] /dev/sda* missing at boot
On Monday, September 12, 2011 10:13:45 AM Neil Bothwick wrote: On Mon, 12 Sep 2011 11:07:12 +0200, Joost Roeleveld wrote: I'd like to know why these functions cannot be separated, run the command to populate /dev early on, then start the udev daemon after the filesystems have been mounted. Some sort of early boot rules file would need to be used to handle things like setting up symlinks for block devices to avoid breaking some users' fstabs. Yes, which means udev would need to be split into: * devd (which controls the /dev-tree) * plugd (which handles all the hotplug-events where special things happen) The communication between the 2 could be done using a simple /dev/udev_pipe device. devd throws events onto the pipe and plugd handles these events. I wonder if it could be done more simply. udevd loads but only parses those rule files marked as suitable for early boot time. Later in the boot it switches to full mode and loads all rule files. This is so simple it is either pure genius or completely naive and unworkable. I know which option my money is on... This would depend on wether or not udev (or whatever program handles the events) can pick specific events out of the queue. I think the events are placed on a queue waiting for some process to handle them and that process then does the following in an endless loop: 1) get event from queue 2) handle event In order to split the 2 options, there needs to be something that sorts them between init-level and run-level events where init-level is what is needed/possible during boot. As I currently understand it, the kernel does not support cherry-picking / multiple queues for hotplug-events and all devices cause a hotplug-event for the /dev-tree creation part of udev. A second queue will need to be handled somehow. I also don't see why udev needs to get the additional code to handle delaying running external tools when this could be split off into seperate process. This way, if the program/script that is configured in the udev-rules causes a system-crash, avoiding the handler for these to start up, will actually provide a better fail-safe. The part that creates the dev-tree will still run and has become smaller and simpler. Would a udev-fork work for Gentoo? -- Joost
Re: [gentoo-user] /dev/sda* missing at boot
On Mon, 12 Sep 2011 11:34:17 +0200, Joost Roeleveld wrote: I wonder if it could be done more simply. udevd loads but only parses those rule files marked as suitable for early boot time. Later in the boot it switches to full mode and loads all rule files. This is so simple it is either pure genius or completely naive and unworkable. I know which option my money is on... This would depend on wether or not udev (or whatever program handles the events) can pick specific events out of the queue. I think the events are placed on a queue waiting for some process to handle them and that process then does the following in an endless loop: 1) get event from queue 2) handle event In order to split the 2 options, there needs to be something that sorts them between init-level and run-level events where init-level is what is needed/possible during boot. If the rules are not loaded, the events are ignored. They are not run handled until the full set of rules are loaded later on. Alternatively, the first rules file parsed would do whatever is necessary for other rules to be handled, such as doing whatever is necessary to make all programs and libraries available. Then it would be the responsible of who/whatever adds the rules to make sure the setup is complete. -- Neil Bothwick To be sure of hitting the target, shoot first and call whatever you hit the target. signature.asc Description: PGP signature
Re: [gentoo-user] RootFS not umounting at shutdown?
On Mon 12 Sep 2011 08:07:27 AM IST, Dale wrote: Nilesh Govindarajan wrote: On Mon 12 Sep 2011 07:32:25 AM IST, Dale wrote: Nilesh Govindarajan wrote: Ever since I have updated my system on 20th September, my rootfs (/dev/sda2) isn't umounted (remounted ro) on shutdown, due to which I see recover messages by kernel at boot (before init starts up). What's going wrong? I added the rc-service named root to the sysinit runlevel, but it seems nothing happened. https://bugs.gentoo.org/show_bug.cgi?id=381783 There you go. Look at the bottom posts and you can see what version has the fix. Dale :-) :-) There it goes. Thanks for the link. Updated to openrc 0.9.3-r1, let's see if it does the job or not. :-) If not, let them know on the bug too. Dale :-) :-) Update- It works. :-) -- Nilesh Govindarajan http://nileshgr.com
Re: [gentoo-user] [off-topic] - can /var be placed in a separate partition?
On 9/11/2011 8:28 PM, Albert W. Hopkins wrote: On Sunday, September 11 at 18:54 (-0500), Dale said: I think I saw it mentioned on -dev that some time shortly /usr and /var will be needed on / or you will need the init* thingy to boot. Hmm, that doesn't smell right to me. What I think you may have heard is about /run. systemd and some other things are preferring to move /var/run to /run. The reason being is that /var does not have to be on the root fs. sysdemd needs /run early (before mounting filesystems) so the idea was to put /var/run on the rootfs, thus /run. I don't think /usr should or ever will be required to be on the rootfs. That's just dumb. The reason we have /bin /sbin, etc. is so that /usr need not be on the rootfs. It doesn't make sense to change that well known/established notion. Nope, Dale is exactly correct. If the upcoming changes to udev make it into Gentoo unaltered and unscathed, it will become necessary to have essentially your full system available very early in the boot process -- at least as early as when udev runs. This includes /usr, where I believe the udev scripts and libraries are being moved, and anything that any program in those scripts might access, which almost definitely includes /var. Any setup where only / is mounted when udev's device population happens will become unsupported (if not impossible). The proposed alternative to a single huge partition is to use an initramfs that mounts your separate /usr (and /var) very early in the boot process. --Mike
Re: [gentoo-user] /dev/sda* missing at boot
On 9/12/2011 3:12 AM, Joost Roeleveld wrote: On Saturday, September 10, 2011 02:54:58 AM Dale wrote: If we are so skilled, why is the Fedora dev not listening you reckon? Is the Fedora dev aware of non-Fedora installations? He is, because a Gentoo user/dev explicitly pointed out the problems this will cause Gentoo. His response, to me, appeared to be a heavy dose of way more people use Fedora/Debian/etc than Gentoo so I'm tailoring my fix to those people combined with a touch of if you're running Gentoo you're smart enough to figure this out on your own. Possibly with a subtle, hidden hint of that's what you get for not running Fedora, but I could be imagining that. --Mike
Re: [gentoo-user] /dev/sda* missing at boot
On Monday, September 12, 2011 08:14:57 AM Mike Edenfield wrote: On 9/12/2011 3:12 AM, Joost Roeleveld wrote: On Saturday, September 10, 2011 02:54:58 AM Dale wrote: If we are so skilled, why is the Fedora dev not listening you reckon? Is the Fedora dev aware of non-Fedora installations? He is, because a Gentoo user/dev explicitly pointed out the problems this will cause Gentoo. Awareness comes at different levels. It's like the difference of looking and seeing. :) He seems to recall there is a world outside of Fedora, but doesn't seem to believe it... His response, to me, appeared to be a heavy dose of way more people use Fedora/Debian/etc than Gentoo so I'm tailoring my fix to those people combined with a touch of if you're running Gentoo you're smart enough to figure this out on your own. Possibly with a subtle, hidden hint of that's what you get for not running Fedora, but I could be imagining that. Of that's how he sees it, then he is admitting that Gentoo-users are smarter then he is I like the compliment :) -- Joost
[gentoo-user] Re: Gentoo on MacBook
* Stroller strol...@stellar.eclipse.co.uk [09/09/11 12:27]: On 9 September 2011, at 04:50, Moshe Kamensky wrote: ... I was happy to soon... It now boots, but after asking me about keyboard layout, it tries to find the cdrom and fails, with messages like: Looking for CDROM Attempting to mount media /dev/sda1 Attempting to mount media /dev/sda2 Attempting to mount media /dev/sda3 Attempting to mount media /dev/sda4 Media not found Determining root device... Could not find the root block device in . Please specify another value or: press Enter for the same, type shell for a shell, or q to skip (The /dev/sda* are partitions on my HD). What CD are you trying to boot? I would try different LiveCDs until you find one that works. The Gentoo wiki suggests that an older version of the Gentoo Minimal CD might work (2008.0 or earlier), otherwise try SystemRescueCD, Knoppix, Ubuntu and others. Thanks for the help. I was using the latest LiveCD version (Sep 8, I believe). I also tried a recent grml, no luck. I could probably make it work, but I have no time right now. I am now running Gentoo within VirtualBox, which works fine and is actually better, because some people are using the osx. Anyway, thank for the help. Moshe
[gentoo-user] Re: Gentoo on MacBook
Why not install it as a virtual machine under the OSX? Much easier and you can have both working at once and the performance is not bad at all. I didn't consider it, since I don't really need the OSX, but I might give it a try. Is there a particular VM you recommend? Vmware fusion is good, and I have heard good things about parallells. Also remember they use a different BIOS on the MAC and this may be part of the problem you are having. Thanks for the suggestion. As I wrote in the other post, I started using VirtualBox, and it works perfectly, and is actually better than the dual boot option. Thanks, Moshe
[gentoo-user] two question about Xfce
Dear All, I have two question about Xfce: - I have two monitors and the panel takes place on the right side of the left monitor vertically. To put another form, the panel takes place in 1440x0 position. The applications are able to go down to the panel if I put them full screen mode. To be honest, it's annoying me. I'm not able to decide whether is this a bug or I configured something in bad way. The situation is the same under KDE. I wrote about this problem earlier and somebody mentioned that there is a related bug in the bugtracker of the KDE Team and it could be KWin defect. Is used kwin under xfce somehow? If a KDE application is used kwin always gets in the picture? - How can I set up the position of the newly started application in Xfce? For example, if I start a new application (Openoffice, Chromium, Kile, etc.) it's fitted to the center of the screen. In this case it's very uncomfortable for me because my screen is 2880x900 px (because of the two monitors) and the center is 1440x0 which is under the panel. Thanks for any help in advance! András -- - - -- Csanyi Andras (Sayusi Ando) -- http://sayusi.hu -- http://facebook.com/andras.csanyi -- Trust in God and keep your gunpowder dry! - Cromwell
[gentoo-user] /etc/portage/patches/
Some packages can apply patches from /etc/portage/patches/, other don't. Why don't all packages do that? Is there a way to make all packages use /etc/portage/patches?
Re: [gentoo-user] two question about Xfce
Hi, On Monday, 12. September 2011 15:01:34 András Csányi wrote: Dear All, I have two question about Xfce: Is used kwin under xfce somehow? If a KDE application is used kwin always gets in the picture? No, unless you tell it to (kwin --replace iirc) and no. How to fix your problem, I have no idea. - How can I set up the position of the newly started application in Xfce? For example, if I start a new application (Openoffice, Chromium, Kile, etc.) it's fitted to the center of the screen. In this case it's very uncomfortable for me because my screen is 2880x900 px (because of the two monitors) and the center is 1440x0 which is under the panel. That seems to be smart placement, which is based on the windows size. You can adjust that in Settings-Window Manager Tweaks-Placement. If that doesn't suffice, you could experiment with x11-misc/wmctrl Thanks for any help in advance! András Hth, Michael
Re: [gentoo-user] /etc/portage/patches/
On 9/12/11 3:21 PM, Nikos Chantziaras wrote: Some packages can apply patches from /etc/portage/patches/, other don't. Why don't all packages do that? Is there a way to make all packages use /etc/portage/patches? It a specific function which needs to be added to the ebuild by the writer. To make all ebuilds respect user patches (where there are pros and cons) the package manager must handle that function internally. justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Gentoo counter?
Well...to get back on topic... - Original Message - From: David W Noon dwn...@ntlworld.com On Sun, 11 Sep 2011 13:52:53 +0700, Pandu Poluan wrote about [gentoo-user] Gentoo counter?: I've just read about the 'new' Linux Counter from a slashdot article, and I wonder: is there a 'Gentoo Counter' that tracks (voluntarily, of course) the number of active Gentoo systems in the world? Why not just look at Linux Counter and see how many run Gentoo? The Linux Counter collects the distro information, so there is no need for a separate counter for each distro. Linux Counter is but one of several projects trying to do that. It is perhaps the more well known and more public. According to Wikipedia there is also another big project lead by Fedora called Smolt, which is also available in Gentoo. http://en.wikipedia.org/wiki/Smolt_%28Linux%29 Now, I don't now if the Gentoo folks patched Smolt to report to Gentoo infrastructure instead of Fedora infrastructure (probably a good thing to do). And I haven't tried it myself (yet) - though I do have LinuxCounter listings for most of my systems (not automatically updated). $0.02 Ben
[gentoo-user] Re: /etc/portage/patches/
On 09/12/2011 04:41 PM, justin wrote: On 9/12/11 3:21 PM, Nikos Chantziaras wrote: Some packages can apply patches from /etc/portage/patches/, other don't. Why don't all packages do that? Is there a way to make all packages use /etc/portage/patches? It a specific function which needs to be added to the ebuild by the writer. To make all ebuilds respect user patches (where there are pros and cons) the package manager must handle that function internally. This sucks. Is there anything I can in /etc/portage/env to make all ebuilds call epatch_user() ?
Re: [gentoo-user] Re: /etc/portage/patches/
A hacky trick would be to implement it yourself by adding the appropriate function to post_src_unpack of post_src_prepare in /etc/portage/bashrc. Nut this is out of warranty, but should work On 9/12/11 3:51 PM, Nikos Chantziaras wrote: On 09/12/2011 04:41 PM, justin wrote: On 9/12/11 3:21 PM, Nikos Chantziaras wrote: Some packages can apply patches from /etc/portage/patches/, other don't. Why don't all packages do that? Is there a way to make all packages use /etc/portage/patches? It a specific function which needs to be added to the ebuild by the writer. To make all ebuilds respect user patches (where there are pros and cons) the package manager must handle that function internally. This sucks. Is there anything I can in /etc/portage/env to make all ebuilds call epatch_user() ? signature.asc Description: OpenPGP digital signature
[gentoo-user] Re: /etc/portage/patches/
Thanks! A bashrc with the following in it seems to work here just fine:
post_src_unpack() {
epatch_user
}
Also, the epatch_user() docs mention that it's safe to call epatch_user
multiple times, so I support no breakages should be expected with
ebuilds and eclasses that call this function on their own.
On 09/12/2011 05:14 PM, justin wrote:
A hacky trick would be to implement it yourself by adding the
appropriate function to post_src_unpack of post_src_prepare in
/etc/portage/bashrc.
Nut this is out of warranty, but should work
On 9/12/11 3:51 PM, Nikos Chantziaras wrote:
On 09/12/2011 04:41 PM, justin wrote:
On 9/12/11 3:21 PM, Nikos Chantziaras wrote:
Some packages can apply patches from /etc/portage/patches/, other don't.
Why don't all packages do that? Is there a way to make all packages
use /etc/portage/patches?
It a specific function which needs to be added to the ebuild by the
writer. To make all ebuilds respect user patches (where there are pros
and cons) the package manager must handle that function internally.
This sucks. Is there anything I can in /etc/portage/env to make all
ebuilds call epatch_user() ?
Re: [gentoo-user] /dev/sda* missing at boot
On Mon, Sep 12, 2011 at 19:28, Joost Roeleveld jo...@antarean.org wrote: On Monday, September 12, 2011 08:14:57 AM Mike Edenfield wrote: His response, to me, appeared to be a heavy dose of way more people use Fedora/Debian/etc than Gentoo so I'm tailoring my fix to those people combined with a touch of if you're running Gentoo you're smart enough to figure this out on your own. Possibly with a subtle, hidden hint of that's what you get for not running Fedora, but I could be imagining that. Of that's how he sees it, then he is admitting that Gentoo-users are smarter then he is I like the compliment :) That's a nice way of finding the silver lining, Joost :-D That said... Anyone up to forking udev? What will we be needing? I can volunteer virtual servers (on top of XenServer and/or VMware -- take your pick). And maybe one physical server. Rgds, -- FdS Pandu E Poluan ~ IT Optimizer ~ • LOPSA Member #15248 • Blog : http://pepoluan.tumblr.com • Linked-In : http://id.linkedin.com/in/pepoluan
Re: [gentoo-user] Where has my sound gone?
On 12 September 2011, at 04:52, Peter Humphrey wrote: On Monday 12 September 2011 04:41:53 I wrote: I've added USE=alsa and I'm remerging world now. Let's hope I'll be able to listen to my favourite BBC Radio 3 soon! Now playing happily, though the BBC do still insist on Flash. get_iplayer http://www.infradead.org/get_iplayer/html/get_iplayer.html Stroller.
[gentoo-user] Re: /etc/portage/patches/
On 09/12/2011 05:42 PM, Nikos Chantziaras wrote:
Thanks! A bashrc with the following in it seems to work here just fine:
post_src_unpack() {
epatch_user
}
In case anyone else is trying this, the above should be:
post_src_unpack() {
cd ${S}
epatch_user
}
[gentoo-user] udev + /usr
Hi, everybody. Hope nobody minds me starting a new thread with an accurate name. Which version of udev is it that has this nauseating feature of needing /usr loaded to boot? Somewhere in that version's source will be several (or lots of) /usr. Just how difficult is it going to be to replace /usr/bin with /bin throughout the source? udev is part of the kernel. How come the kernel hackers aren't up in arms about this as much as we are? Or are they, maybe? In which case, maybe the kernel people would welcome an option to disrequire the early mounting of /usr as much as we would. Anyhow, I'd like to take a peek at the source code which does this evil thing. Would somebody please tell me which version of udev is involved. Thanks. -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] /dev/sda* missing at boot
On Mon, Sep 12, 2011 at 10:47 AM, Pandu Poluan pa...@poluan.info wrote: On Mon, Sep 12, 2011 at 19:28, Joost Roeleveld jo...@antarean.org wrote: On Monday, September 12, 2011 08:14:57 AM Mike Edenfield wrote: His response, to me, appeared to be a heavy dose of way more people use Fedora/Debian/etc than Gentoo so I'm tailoring my fix to those people combined with a touch of if you're running Gentoo you're smart enough to figure this out on your own. Possibly with a subtle, hidden hint of that's what you get for not running Fedora, but I could be imagining that. Of that's how he sees it, then he is admitting that Gentoo-users are smarter then he is I like the compliment :) That's a nice way of finding the silver lining, Joost :-D That said... Anyone up to forking udev? What will we be needing? I can volunteer virtual servers (on top of XenServer and/or VMware -- take your pick). And maybe one physical server. Interested (it gives me an opportunity to learn a great deal about another area of the system), though I've never hacked on anything like udev, or anything early in the boot process, before. I'd probably be limited to testing. -- :wq
Re: [gentoo-user] udev + /usr
Hi Alan, On Monday, 12. September 2011 15:02:48 Alan Mackenzie wrote: Hi, everybody. Hope nobody minds me starting a new thread with an accurate name. Which version of udev is it that has this nauseating feature of needing /usr loaded to boot? Somewhere in that version's source will be several (or lots of) /usr. Just how difficult is it going to be to replace /usr/bin with /bin throughout the source? you misunderstood something. udev is able to run arbitrary scripts. Some of those scripts are located in /usr/* or need something there. I doubt you will find references to /usr in the udev-sources. udev is part of the kernel. No. udev is usperspace. How come the kernel hackers aren't up in arms about this as much as we are? Or are they, maybe? In which case, maybe the kernel people would welcome an option to disrequire the early mounting of /usr as much as we would. Anyhow, I'd like to take a peek at the source code which does this evil thing. Would somebody please tell me which version of udev is involved. Every udev version works this way. Fixing udev to continue working with separate /usr is far from trivial imo. Changing some paths is not the way to go for sure. First of all, udev has to distinguish between device not present and script error of some kind. Failing scripts have to be queued somehow for later execution. If a script keeps failing, it has to be removed from that queue, with a message to syslog or something like that. If udev needs a script in /usr/* to mount /usr then there's a chicken-egg-problem, which could be hard to solve (if possible at all without moving things from /usr/ to /). Note, that I am wild guessing here, I did not study the udev sources or any related script/rule :) Thanks. Best, Michael
Re: [gentoo-user] udev + /usr
On Mon, Sep 12, 2011 at 11:02 AM, Alan Mackenzie a...@muc.de wrote: Hi, everybody. Hope nobody minds me starting a new thread with an accurate name. Which version of udev is it that has this nauseating feature of needing /usr loaded to boot? Somewhere in that version's source will be several (or lots of) /usr. Just how difficult is it going to be to replace /usr/bin with /bin throughout the source? udev is part of the kernel. How come the kernel hackers aren't up in arms about this as much as we are? Or are they, maybe? In which case, maybe the kernel people would welcome an option to disrequire the early mounting of /usr as much as we would. Anyhow, I'd like to take a peek at the source code which does this evil thing. Would somebody please tell me which version of udev is involved. Thanks. (This would be my only post in this new thread: I think I have made my point of view clear in the other thread). I have seen a lot of disinformation going on in the other threads (like some people suggesting that /var would not be able to be on its own partition at some point in the future). Just before everyone start to wildy conjecture, please take a look at this: http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken Also, a look at this thread is maybe justified: http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/1728/ Both things are in the context of systemd, but it's related to the discussion at hand. I know not everybody wants to use systemd, and think Lennart and Kay are the root of all that is wrong and evil on the world, but I will recommend everyone interested in the reasons of the push for a recommended initramfs to take a look at the page in fd.org, and the thread in the systemd mailing list. Even if you don't agree with the reasoning, it is worth to take a look at it. As for me, I would say one last time my POV: Linux strives to be much more than Unix, and that means do things differently. It will always be capable of do anything that Unix does, and most of the time it will do it better. But that doesn't (necessarily) means that it will do it in the same way. And many of us don't take but my config/setup/partition works now as a valid argument to restrain progress. Change happens. Regards everyone. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
[gentoo-user] package.provided messes up emerging of package slots?
In my /etc/portage/profile/package.provided, I have this: media-libs/freetype-1.4_pre20080316-r2 When I try to emerge freetype however, instead of emerging the newer version, I get: $ emerge freetype WARNING: A requested package will not be merged because it is listed in package.provided: freetype pulled in by 'args' Nothing to merge; would you like to auto-clean packages? [Yes/No] Trying emerge freetype:2 also won't work. The only only to emerge it seems is by using the whole version (emerge =freetype-2.4.6). Is this a bug?
Re: [gentoo-user] /dev/sda* missing at boot
On Monday, September 12, 2011 11:29:12 AM Michael Mol wrote: On Mon, Sep 12, 2011 at 10:47 AM, Pandu Poluan pa...@poluan.info wrote: On Mon, Sep 12, 2011 at 19:28, Joost Roeleveld jo...@antarean.org wrote: On Monday, September 12, 2011 08:14:57 AM Mike Edenfield wrote: His response, to me, appeared to be a heavy dose of way more people use Fedora/Debian/etc than Gentoo so I'm tailoring my fix to those people combined with a touch of if you're running Gentoo you're smart enough to figure this out on your own. Possibly with a subtle, hidden hint of that's what you get for not running Fedora, but I could be imagining that. Of that's how he sees it, then he is admitting that Gentoo-users are smarter then he is I like the compliment :) That's a nice way of finding the silver lining, Joost :-D That said... Anyone up to forking udev? What will we be needing? I can volunteer virtual servers (on top of XenServer and/or VMware -- take your pick). And maybe one physical server. Interested (it gives me an opportunity to learn a great deal about another area of the system), though I've never hacked on anything like udev, or anything early in the boot process, before. I'd probably be limited to testing. I'm also interested. Not entirely sure how much I can help. Testing, definitely. Coding, I'll try. :) -- Joost
Re: [gentoo-user] udev + /usr
Hi Canek, On Monday, 12. September 2011 11:35:13 Canek Peláez Valdés wrote: (This would be my only post in this new thread: I think I have made my point of view clear in the other thread). I have seen a lot of disinformation going on in the other threads (like some people suggesting that /var would not be able to be on its own partition at some point in the future). Just before everyone start to wildy conjecture, please take a look at this: http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken well, the culprit here is: The binaries called from these rules are sometimes located on /usr/bin, or link against libraries in /usr/lib, or use data files from /usr/share. If these rules fail udev will proceed with the next one, however later on applications will then not properly detect these udev devices or features of these devices. Why doesn't udev queue failing scripts for later execution? It just assumes everything is in place in the moment it needs it. This is bad design for a tool, coming in so early in the boot process. Also, a look at this thread is maybe justified: http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/1728/ Same thing here. This all basically reads We did some really bad design choices, now let's fix the surroundings. The following sentence really made me laugh: If so, what does LSB say to this new directory? Nothing really, they just document current common practice. We might request an update to LSB after it is used for a while and has shown that it is what we want. He does not know, if the thing he designed is the thing he wants. That's ridiculous! Change happens. We already know this. Regards everyone. Best, Michael
Re: [gentoo-user] udev + /usr
Canek Peláez Valdés wrote: On Mon, Sep 12, 2011 at 11:02 AM, Alan Mackenziea...@muc.de wrote: Hi, everybody. Hope nobody minds me starting a new thread with an accurate name. Which version of udev is it that has this nauseating feature of needing /usr loaded to boot? Somewhere in that version's source will be several (or lots of) /usr. Just how difficult is it going to be to replace /usr/bin with /bin throughout the source? udev is part of the kernel. How come the kernel hackers aren't up in arms about this as much as we are? Or are they, maybe? In which case, maybe the kernel people would welcome an option to disrequire the early mounting of /usr as much as we would. Anyhow, I'd like to take a peek at the source code which does this evil thing. Would somebody please tell me which version of udev is involved. Thanks. (This would be my only post in this new thread: I think I have made my point of view clear in the other thread). I have seen a lot of disinformation going on in the other threads (like some people suggesting that /var would not be able to be on its own partition at some point in the future). Just before everyone start to wildy conjecture, please take a look at this: http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken Also, a look at this thread is maybe justified: http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/1728/ Both things are in the context of systemd, but it's related to the discussion at hand. I know not everybody wants to use systemd, and think Lennart and Kay are the root of all that is wrong and evil on the world, but I will recommend everyone interested in the reasons of the push for a recommended initramfs to take a look at the page in fd.org, and the thread in the systemd mailing list. Even if you don't agree with the reasoning, it is worth to take a look at it. As for me, I would say one last time my POV: Linux strives to be much more than Unix, and that means do things differently. It will always be capable of do anything that Unix does, and most of the time it will do it better. But that doesn't (necessarily) means that it will do it in the same way. And many of us don't take but my config/setup/partition works now as a valid argument to restrain progress. Change happens. Regards everyone. You say it was disinformation about /var. Care to explain why me and one other person read the same thing? It was mentioned on -dev. I was pretty sure it was and then another person posted they read the same. So, I'm almost certain it was said at this point. Surely we can't both be wrong. Dale :-) :-)
Re: [gentoo-user] package.provided messes up emerging of package slots?
On Sep 12, 2011 11:11 PM, Nikos Chantziaras rea...@arcor.de wrote: In my /etc/portage/profile/package.provided, I have this: media-libs/freetype-1.4_pre20080316-r2 When I try to emerge freetype however, instead of emerging the newer version, I get: $ emerge freetype WARNING: A requested package will not be merged because it is listed in package.provided: freetype pulled in by 'args' Nothing to merge; would you like to auto-clean packages? [Yes/No] Trying emerge freetype:2 also won't work. The only only to emerge it seems is by using the whole version (emerge =freetype-2.4.6). Is this a bug? Why did you have that line in package.provided, in the first place? Did you install freetype on your own, without using portage? The way I see it, Portage worked perfectly: it saw that you have installed a certain version of freetype on your own, and it didn't want to mess up your installed package. Just delete the line and emerge freetype. (someone please CMIIW) Rgds,
Re: [gentoo-user] udev + /usr
On Mon, Sep 12, 2011 at 12:21 PM, Dale rdalek1...@gmail.com wrote: Canek Peláez Valdés wrote: On Mon, Sep 12, 2011 at 11:02 AM, Alan Mackenziea...@muc.de wrote: Hi, everybody. Hope nobody minds me starting a new thread with an accurate name. Which version of udev is it that has this nauseating feature of needing /usr loaded to boot? Somewhere in that version's source will be several (or lots of) /usr. Just how difficult is it going to be to replace /usr/bin with /bin throughout the source? udev is part of the kernel. How come the kernel hackers aren't up in arms about this as much as we are? Or are they, maybe? In which case, maybe the kernel people would welcome an option to disrequire the early mounting of /usr as much as we would. Anyhow, I'd like to take a peek at the source code which does this evil thing. Would somebody please tell me which version of udev is involved. Thanks. (This would be my only post in this new thread: I think I have made my point of view clear in the other thread). I have seen a lot of disinformation going on in the other threads (like some people suggesting that /var would not be able to be on its own partition at some point in the future). Just before everyone start to wildy conjecture, please take a look at this: http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken Also, a look at this thread is maybe justified: http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/1728/ Both things are in the context of systemd, but it's related to the discussion at hand. I know not everybody wants to use systemd, and think Lennart and Kay are the root of all that is wrong and evil on the world, but I will recommend everyone interested in the reasons of the push for a recommended initramfs to take a look at the page in fd.org, and the thread in the systemd mailing list. Even if you don't agree with the reasoning, it is worth to take a look at it. As for me, I would say one last time my POV: Linux strives to be much more than Unix, and that means do things differently. It will always be capable of do anything that Unix does, and most of the time it will do it better. But that doesn't (necessarily) means that it will do it in the same way. And many of us don't take but my config/setup/partition works now as a valid argument to restrain progress. Change happens. Regards everyone. You say it was disinformation about /var. Care to explain why me and one other person read the same thing? It was mentioned on -dev. I was pretty sure it was and then another person posted they read the same. So, I'm almost certain it was said at this point. Surely we can't both be wrong. Where did you guys read it? Who said /var could not be in its own partition anymore? What piece of code stops working if /var it's in its own partition? Who is proposing that a separated /var will not be supported in the future? The thread I post talks about /var/run and /var/lock needing to be symbolic links to /run and /lock, but AFAIK (and I tend to follow this sort of things) /var not only can be in its own partition, it is the recommended setup. Saying that proposing /run and /lock to be available at boot time means that in the future a separated /var partition could be not supported is, in my book, disinformation. /var/run and /var/lock (by definition) are almost empty (in space). /var/lib usually stores whole databases. The difference is important and relevant. Damn, this list is like crack. Regards everyone. -- 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] package.provided messes up emerging of package slots?
On Monday, 12. September 2011 18:41:37 Nikos Chantziaras wrote: In my /etc/portage/profile/package.provided, I have this: media-libs/freetype-1.4_pre20080316-r2 When I try to emerge freetype however, instead of emerging the newer version, I get: $ emerge freetype WARNING: A requested package will not be merged because it is listed in package.provided: freetype pulled in by 'args' Nothing to merge; would you like to auto-clean packages? [Yes/No] Trying emerge freetype:2 also won't work. The only only to emerge it seems is by using the whole version (emerge =freetype-2.4.6). Is this a bug? At least it's inconsistent. I would expect that the emerge with complete version also fails. Regards, Michael
[gentoo-user] Re: package.provided messes up emerging of package slots?
On 09/12/2011 07:31 PM, Pandu Poluan wrote: On Sep 12, 2011 11:11 PM, Nikos Chantziaras rea...@arcor.de mailto:rea...@arcor.de wrote: In my /etc/portage/profile/package.provided, I have this: media-libs/freetype-1.4_pre20080316-r2 When I try to emerge freetype however, instead of emerging the newer version, I get: $ emerge freetype WARNING: A requested package will not be merged because it is listed in package.provided: freetype pulled in by 'args' Nothing to merge; would you like to auto-clean packages? [Yes/No] Trying emerge freetype:2 also won't work. The only only to emerge it seems is by using the whole version (emerge =freetype-2.4.6). Is this a bug? Why did you have that line in package.provided, in the first place? Did you install freetype on your own, without using portage? Portage installs both freetype-1 as well as freetype-2. texlive has freetype-1 as a dep, and I don't want it installed because I'm not using ttf2tfm. The way I see it, Portage worked perfectly: it saw that you have installed a certain version of freetype on your own, and it didn't want to mess up your installed package. Just delete the line and emerge freetype. From my point of view, it doesn't work perfectly, because it behaves differently when freetype-1 is really installed, and when it's not but listed in package.provided. If I install freetype-1 and type: emerge freetype it will emerge freetype:2. So the behavior is vastly different between having freetype really installed, and when not but listed in package.provided.
Re: [gentoo-user] Re: /dev/sda* missing at boot
Michael Schreckenbauer wrote: Hi, On Monday, 12. September 2011 10:40:02 Nicolas Sebrecht wrote: So, what's the good way to fix all that mess? Certainly not moving most of software to /. Fortunately, we can expect /usr to be mounted before udev starts via the initramfs. That's *your* opinion. Most people on this list disagree. It does NOT mean everybody will require a initramfs. It means people WANTING a seperate /usr will need a initramfs. The good thing is that a lot of tools now in / will be granted back to /usr. Let's clean up /. Also, it's a _good_ news for admins expecting to maintain systems with a shared /usr (e.g. over the network). Since when is a mandatory initramfs a good thing for admins? Care to explain? Regards, Michael Couldn't agree more. Dale :-) :-)
Re: [gentoo-user] udev + /usr
On Monday, 12. September 2011 12:42:00 Canek Peláez Valdés wrote: On Mon, Sep 12, 2011 at 12:21 PM, Dale rdalek1...@gmail.com wrote: You say it was disinformation about /var. Care to explain why me and one other person read the same thing? It was mentioned on -dev. I was pretty sure it was and then another person posted they read the same. So, I'm almost certain it was said at this point. Surely we can't both be wrong. Where did you guys read it? Who said /var could not be in its own partition anymore? What piece of code stops working if /var it's in its own partition? Who is proposing that a separated /var will not be supported in the future? Just have a look in /var/lib/* for example. You guarantee, that nothing of this stuff is or will be needed by udev? The thread I post talks about /var/run and /var/lock needing to be symbolic links to /run and /lock, but AFAIK (and I tend to follow this sort of things) /var not only can be in its own partition, it is the recommended setup. Yes. Until this dev has his next brilliant idea. Saying that proposing /run and /lock to be available at boot time Damn, this list is like crack. For sure :) Regards everyone. Best, Michael
Re: [gentoo-user] udev + /usr
On Mon, Sep 12, 2011 at 12:42 PM, Canek Peláez Valdés can...@gmail.com wrote: On Mon, Sep 12, 2011 at 12:21 PM, Dale rdalek1...@gmail.com wrote: Canek Peláez Valdés wrote: On Mon, Sep 12, 2011 at 11:02 AM, Alan Mackenziea...@muc.de wrote: Hi, everybody. Hope nobody minds me starting a new thread with an accurate name. Which version of udev is it that has this nauseating feature of needing /usr loaded to boot? Somewhere in that version's source will be several (or lots of) /usr. Just how difficult is it going to be to replace /usr/bin with /bin throughout the source? udev is part of the kernel. How come the kernel hackers aren't up in arms about this as much as we are? Or are they, maybe? In which case, maybe the kernel people would welcome an option to disrequire the early mounting of /usr as much as we would. Anyhow, I'd like to take a peek at the source code which does this evil thing. Would somebody please tell me which version of udev is involved. Thanks. (This would be my only post in this new thread: I think I have made my point of view clear in the other thread). I have seen a lot of disinformation going on in the other threads (like some people suggesting that /var would not be able to be on its own partition at some point in the future). Just before everyone start to wildy conjecture, please take a look at this: http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken Also, a look at this thread is maybe justified: http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/1728/ Both things are in the context of systemd, but it's related to the discussion at hand. I know not everybody wants to use systemd, and think Lennart and Kay are the root of all that is wrong and evil on the world, but I will recommend everyone interested in the reasons of the push for a recommended initramfs to take a look at the page in fd.org, and the thread in the systemd mailing list. Even if you don't agree with the reasoning, it is worth to take a look at it. As for me, I would say one last time my POV: Linux strives to be much more than Unix, and that means do things differently. It will always be capable of do anything that Unix does, and most of the time it will do it better. But that doesn't (necessarily) means that it will do it in the same way. And many of us don't take but my config/setup/partition works now as a valid argument to restrain progress. Change happens. Regards everyone. You say it was disinformation about /var. Care to explain why me and one other person read the same thing? It was mentioned on -dev. I was pretty sure it was and then another person posted they read the same. So, I'm almost certain it was said at this point. Surely we can't both be wrong. Where did you guys read it? Who said /var could not be in its own partition anymore? What piece of code stops working if /var it's in its own partition? Who is proposing that a separated /var will not be supported in the future? The thread I post talks about /var/run and /var/lock needing to be symbolic links to /run and /lock, but AFAIK (and I tend to follow this sort of things) /var not only can be in its own partition, it is the recommended setup. Saying that proposing /run and /lock to be available at boot time means that in the future a separated /var partition could be not supported is, in my book, disinformation. /var/run and /var/lock (by definition) are almost empty (in space). /var/lib usually stores whole databases. The difference is important and relevant. Damn, this list is like crack. http://xkcd.com/386/ -- :wq
Re: [gentoo-user] /dev/sda* missing at boot
Pandu Poluan wrote: On Mon, Sep 12, 2011 at 19:28, Joost Roeleveldjo...@antarean.org wrote: On Monday, September 12, 2011 08:14:57 AM Mike Edenfield wrote: His response, to me, appeared to be a heavy dose of way more people use Fedora/Debian/etc than Gentoo so I'm tailoring my fix to those people combined with a touch of if you're running Gentoo you're smart enough to figure this out on your own. Possibly with a subtle, hidden hint of that's what you get for not running Fedora, but I could be imagining that. Of that's how he sees it, then he is admitting that Gentoo-users are smarter then he is I like the compliment :) That's a nice way of finding the silver lining, Joost :-D That said... Anyone up to forking udev? What will we be needing? I can volunteer virtual servers (on top of XenServer and/or VMware -- take your pick). And maybe one physical server. Rgds, I noticed a new directory the other day. I found out it belongs to cups. It is named Resources. If cups can use that, why not put the stuff udev needs in there? Dale :-) :-)
[gentoo-user] Re: package.provided messes up emerging of package slots?
On 09/12/2011 07:42 PM, Michael Schreckenbauer wrote: On Monday, 12. September 2011 18:41:37 Nikos Chantziaras wrote: In my /etc/portage/profile/package.provided, I have this: media-libs/freetype-1.4_pre20080316-r2 When I try to emerge freetype however, instead of emerging the newer version, I get: $ emerge freetype WARNING: A requested package will not be merged because it is listed in package.provided: freetype pulled in by 'args' Nothing to merge; would you like to auto-clean packages? [Yes/No] Trying emerge freetype:2 also won't work. The only only to emerge it seems is by using the whole version (emerge =freetype-2.4.6). Is this a bug? At least it's inconsistent. I would expect that the emerge with complete version also fails. It's slotted, so it shouldn't fail. Freetype 1 and 2 can be installed at the same time.
Re: [gentoo-user] Re: package.provided messes up emerging of package slots?
On Monday, 12. September 2011 20:04:47 Nikos Chantziaras wrote: On 09/12/2011 07:42 PM, Michael Schreckenbauer wrote: On Monday, 12. September 2011 18:41:37 Nikos Chantziaras wrote: In my /etc/portage/profile/package.provided, I have this: media-libs/freetype-1.4_pre20080316-r2 When I try to emerge freetype however, instead of emerging the newer version, I get: $ emerge freetype WARNING: A requested package will not be merged because it is listed in package.provided: freetype pulled in by 'args' Nothing to merge; would you like to auto-clean packages? [Yes/No] Trying emerge freetype:2 also won't work. The only only to emerge it seems is by using the whole version (emerge =freetype-2.4.6). Is this a bug? At least it's inconsistent. I would expect that the emerge with complete version also fails. It's slotted, so it shouldn't fail. Freetype 1 and 2 can be installed at the same time. Yes, that's true for the packages provided by portage. portage does not know anything about the freetype you provide, so it shouldn't install any freetype from any slot by any command. Best, Michael
Re: [gentoo-user] udev + /usr
Hi, Michael. On Mon, Sep 12, 2011 at 05:33:34PM +0200, Michael Schreckenbauer wrote: Hi Alan, On Monday, 12. September 2011 15:02:48 Alan Mackenzie wrote: Hope nobody minds me starting a new thread with an accurate name. Which version of udev is it that has this nauseating feature of needing /usr loaded to boot? Somewhere in that version's source will be several (or lots of) /usr. Just how difficult is it going to be to replace /usr/bin with /bin throughout the source? you misunderstood something. udev is able to run arbitrary scripts. Some of those scripts are located in /usr/* or need something there. I doubt you will find references to /usr in the udev-sources. Well, I'm a hacker. udev is free source, therefore fair game. I don't intend to put up with this nonsense without a fight. As far as I can make out, this is just one guy, Kay Sievers, who's on a power trip. Are there any indications at all that he actually talked to anybody in the wide world before making such a far reaching decision? On my current system, udev (164-r2) works without an earlily loaded /usr. Seemingly, later versions don't. That was why I was asking for somebody to identify one of these later versions for me. udev is part of the kernel. No. udev is usperspace. OK, udev is in userspace, _very_ _close_ to the kernel. ;-) How come the kernel hackers aren't up in arms about this as much as we are? Or are they, maybe? In which case, maybe the kernel people would welcome an option to disrequire the early mounting of /usr as much as we would. Anyhow, I'd like to take a peek at the source code which does this evil thing. Would somebody please tell me which version of udev is involved. Every udev version works this way. My udev (164-r2) is just fine at the moment. I'm not sure what you mean by that statement. Fixing udev to continue working with separate /usr is far from trivial imo. Changing some paths is not the way to go for sure. Maybe, maybe not. But it seems a changing of paths (/ - /usr) is precisely what is breaking newer udevs. It might be possible to change them back. This could involve moving a fair amount of stuff from /usr to /, but not half as much as moving the entire /usr partition. First of all, udev has to distinguish between device not present and script error of some kind. Failing scripts have to be queued somehow for later execution. If a script keeps failing, it has to be removed from that queue, with a message to syslog or something like that. If udev needs a script in /usr/* to mount /usr then there's a chicken-egg-problem, which could be hard to solve (if possible at all without moving things from /usr/ to /). Note, that I am wild guessing here, I did not study the udev sources or any related script/rule :) This sounds like a separate (if related) problem. Thanks. Best, Michael -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] udev + /usr
On Mon, Sep 12, 2011 at 1:17 PM, Alan Mackenzie a...@muc.de wrote: On Mon, Sep 12, 2011 at 05:33:34PM +0200, Michael Schreckenbauer wrote: On Monday, 12. September 2011 15:02:48 Alan Mackenzie wrote: Hope nobody minds me starting a new thread with an accurate name. Which version of udev is it that has this nauseating feature of needing /usr loaded to boot? Somewhere in that version's source will be several (or lots of) /usr. Just how difficult is it going to be to replace /usr/bin with /bin throughout the source? you misunderstood something. udev is able to run arbitrary scripts. Some of those scripts are located in /usr/* or need something there. I doubt you will find references to /usr in the udev-sources. Well, I'm a hacker. udev is free source, therefore fair game. I don't intend to put up with this nonsense without a fight. As far as I can make out, this is just one guy, Kay Sievers, who's on a power trip. Are there any indications at all that he actually talked to anybody in the wide world before making such a far reaching decision? udev has always been able to run arbitrary scripts. The trouble is that the arbitrary scripts other packages provide sometimes call for things under /usr. If I've read messages over the last couple days correctly, I think the recent change is that some stuff udev *directly* depends on, as part of the udev package itself, is being moved into /usr. My best guess is that this allows udev to force the issue; it gets blamed for other packages not loading correctly (when those other packages put things in places which may or may not be available yet), so the udev developer chose to force systems to have all of /usr available before udev is run. The first step in a clean solution, IMO, is to revert that change. The second step is to fix the 'silent failure' problem for packages which depend on /usr before /usr is available. You might do it with a dependency tree which would control the order things are done, but some packages may not be able to know what they depend on. (take dhcpd, for example; it doesn't know what kind of weird magic someone else put in exit-hooks) Another solution would be to have a retry queue like what Schreckenbauer (sorry; too many Mikes) was suggesting. It might be difficult to discern a rulescript failure that stems from another rule needing to be run first versus a rulescript failure that stems from, e.g. a syntax error. -- :wq
Re: [gentoo-user] udev + /usr
Hi Alan, On Monday, 12. September 2011 17:17:37 Alan Mackenzie wrote: Hi, Michael. On Mon, Sep 12, 2011 at 05:33:34PM +0200, Michael Schreckenbauer wrote: Hi Alan, On Monday, 12. September 2011 15:02:48 Alan Mackenzie wrote: Hope nobody minds me starting a new thread with an accurate name. Which version of udev is it that has this nauseating feature of needing /usr loaded to boot? Somewhere in that version's source will be several (or lots of) /usr. Just how difficult is it going to be to replace /usr/bin with /bin throughout the source? you misunderstood something. udev is able to run arbitrary scripts. Some of those scripts are located in /usr/* or need something there. I doubt you will find references to /usr in the udev-sources. Well, I'm a hacker. udev is free source, therefore fair game. I don't intend to put up with this nonsense without a fight. As far as I can make out, this is just one guy, Kay Sievers, who's on a power trip. Are there any indications at all that he actually talked to anybody in the wide world before making such a far reaching decision? On my current system, udev (164-r2) works without an earlily loaded /usr. Seemingly, later versions don't. That was why I was asking for somebody to identify one of these later versions for me. it works for you, because your udev-rules need nothing from /usr/* It's *not* udev requiring /usr, it's the scripts triggered by the rules. udev is part of the kernel. No. udev is usperspace. OK, udev is in userspace, _very_ _close_ to the kernel. ;-) How come the kernel hackers aren't up in arms about this as much as we are? Or are they, maybe? In which case, maybe the kernel people would welcome an option to disrequire the early mounting of /usr as much as we would. Anyhow, I'd like to take a peek at the source code which does this evil thing. Would somebody please tell me which version of udev is involved. Every udev version works this way. My udev (164-r2) is just fine at the moment. I'm not sure what you mean by that statement. It works for you. Every udev-version I know of, is able to run any script you like it to. Fixing udev to continue working with separate /usr is far from trivial imo. Changing some paths is not the way to go for sure. Maybe, maybe not. No, I wrote for sure, because I *know* this. But it seems a changing of paths (/ - /usr) is precisely what is breaking newer udevs. No, it is *not* It might be possible to change them back. This could involve moving a fair amount of stuff from /usr to /, but not half as much as moving the entire /usr partition. Again, udev can run arbitrary scripts. First of all, udev has to distinguish between device not present and script error of some kind. Failing scripts have to be queued somehow for later execution. If a script keeps failing, it has to be removed from that queue, with a message to syslog or something like that. If udev needs a script in /usr/* to mount /usr then there's a chicken-egg-problem, which could be hard to solve (if possible at all without moving things from /usr/ to /). Note, that I am wild guessing here, I did not study the udev sources or any related script/rule :) This sounds like a separate (if related) problem. No, this *is* the problem.Canek has posted some links in the other thread, some other guy, I have forgotten who it was, posted others. If interested read them. I really don't want to offend you, but unless you understand, how things work and what the problem is, don't waste your time looking at udev's sources. Best, Michael
Re: [gentoo-user] udev + /usr
On Monday, 12. September 2011 13:39:59 Michael Mol wrote: On Mon, Sep 12, 2011 at 1:17 PM, Alan Mackenzie a...@muc.de wrote: On Mon, Sep 12, 2011 at 05:33:34PM +0200, Michael Schreckenbauer wrote: On Monday, 12. September 2011 15:02:48 Alan Mackenzie wrote: you misunderstood something. udev is able to run arbitrary scripts. Some of those scripts are located in /usr/* or need something there. I doubt you will find references to /usr in the udev-sources. Well, I'm a hacker. udev is free source, therefore fair game. I don't intend to put up with this nonsense without a fight. As far as I can make out, this is just one guy, Kay Sievers, who's on a power trip. Are there any indications at all that he actually talked to anybody in the wide world before making such a far reaching decision? udev has always been able to run arbitrary scripts. The trouble is that the arbitrary scripts other packages provide sometimes call for things under /usr. Exactly. If I've read messages over the last couple days correctly, I think the recent change is that some stuff udev *directly* depends on, as part of the udev package itself, is being moved into /usr. I seem to have missed that part. My best guess is that this allows udev to force the issue; it gets blamed for other packages not loading correctly (when those other packages put things in places which may or may not be available yet), so the udev developer chose to force systems to have all of /usr available before udev is run. Sounds reasonable. The first step in a clean solution, IMO, is to revert that change. The second step is to fix the 'silent failure' problem for packages which depend on /usr before /usr is available. ack. You might do it with a dependency tree which would control the order things are done, but some packages may not be able to know what they depend on. (take dhcpd, for example; it doesn't know what kind of weird magic someone else put in exit-hooks) Sounds good. Another solution would be to have a retry queue like what Schreckenbauer (sorry; too many Mikes) was suggesting. It might be difficult to discern a rulescript failure that stems from another rule needing to be run first versus a rulescript failure that stems from, e.g. a syntax error. Maybe a combination of the two? If dhcpd fails in your example, put it in the retry queue. After some failing attempts, remove it from there and log the error. BTW: if there are too many Michaels/Mikes on the list, call me grimlog. I am used to that nick and feel strange if someone calls me Schreckenbauer :) Best, Michael, aka grimlog
Re: [gentoo-user] udev + /usr
On Mon, Sep 12, 2011 at 12:52 PM, Michael Schreckenbauer grim...@gmx.de wrote: On Monday, 12. September 2011 12:42:00 Canek Peláez Valdés wrote: On Mon, Sep 12, 2011 at 12:21 PM, Dale rdalek1...@gmail.com wrote: You say it was disinformation about /var. Care to explain why me and one other person read the same thing? It was mentioned on -dev. I was pretty sure it was and then another person posted they read the same. So, I'm almost certain it was said at this point. Surely we can't both be wrong. Where did you guys read it? Who said /var could not be in its own partition anymore? What piece of code stops working if /var it's in its own partition? Who is proposing that a separated /var will not be supported in the future? Just have a look in /var/lib/* for example. I did mentioned /var/lib two paragraphs below. Do you guys respond an email while you read it? You guarantee, that nothing of this stuff is or will be needed by udev? I don't have to. Contrary to most of the guys here (I'm not saying you are one of them), I don't see the proposed change as irrational. It makes complete sense (you actually mention several reasons why it makes sense in others emails here to Alan and others). Requiring /var to be on / would not make sense. Even more: then the idea of /run and /lock on / would be completely insane, if eventually they would require a non separated /var. The proposal of /run and /lock on / is exactly to allow /var to be on its own partition on te foreseeable future. The thread I post talks about /var/run and /var/lock needing to be symbolic links to /run and /lock, but AFAIK (and I tend to follow this sort of things) /var not only can be in its own partition, it is the recommended setup. Yes. Until this dev has his next brilliant idea. Give them some credit. This whole lot of changes is not the imposition of some crazy dev. Is the result of years of the Open Source stack evolving, and writing the code that implements a design. In particula Kay has been writing code in udev since 2003, with version 003. I would think he actually knows the problem, and even if you don't agree with his design, you got to recognize that he is the most knowledgeable guy wrt the problem. And I mean the *general* problem, not the I have a server since 1964 and if the design I've been using since the Middle Ages has been working all this time I don't see any reason to change it. Saying that proposing /run and /lock to be available at boot time Damn, this list is like crack. For sure :) Yeah. I will need to break out cold turkey at some point. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
[gentoo-user] Re: package.provided messes up emerging of package slots?
On 09/12/2011 08:17 PM, Michael Schreckenbauer wrote: On Monday, 12. September 2011 20:04:47 Nikos Chantziaras wrote: On 09/12/2011 07:42 PM, Michael Schreckenbauer wrote: On Monday, 12. September 2011 18:41:37 Nikos Chantziaras wrote: In my /etc/portage/profile/package.provided, I have this: media-libs/freetype-1.4_pre20080316-r2 When I try to emerge freetype however, instead of emerging the newer version, I get: $ emerge freetype WARNING: A requested package will not be merged because it is listed in package.provided: freetype pulled in by 'args' Nothing to merge; would you like to auto-clean packages? [Yes/No] Trying emerge freetype:2 also won't work. The only only to emerge it seems is by using the whole version (emerge =freetype-2.4.6). Is this a bug? At least it's inconsistent. I would expect that the emerge with complete version also fails. It's slotted, so it shouldn't fail. Freetype 1 and 2 can be installed at the same time. Yes, that's true for the packages provided by portage. portage does not know anything about the freetype you provide, so it shouldn't install any freetype from any slot by any command. I don't see how it doesn't know anything about it, given that it requires me to list a full package atom in package.provided. So it always knows which version should be considered as being provided.
Re: [gentoo-user] udev + /usr
On Mon, Sep 12, 2011 at 1:39 PM, Michael Mol mike...@gmail.com wrote: On Mon, Sep 12, 2011 at 1:17 PM, Alan Mackenzie a...@muc.de wrote: On Mon, Sep 12, 2011 at 05:33:34PM +0200, Michael Schreckenbauer wrote: On Monday, 12. September 2011 15:02:48 Alan Mackenzie wrote: Hope nobody minds me starting a new thread with an accurate name. Which version of udev is it that has this nauseating feature of needing /usr loaded to boot? Somewhere in that version's source will be several (or lots of) /usr. Just how difficult is it going to be to replace /usr/bin with /bin throughout the source? you misunderstood something. udev is able to run arbitrary scripts. Some of those scripts are located in /usr/* or need something there. I doubt you will find references to /usr in the udev-sources. Well, I'm a hacker. udev is free source, therefore fair game. I don't intend to put up with this nonsense without a fight. As far as I can make out, this is just one guy, Kay Sievers, who's on a power trip. Are there any indications at all that he actually talked to anybody in the wide world before making such a far reaching decision? udev has always been able to run arbitrary scripts. The trouble is that the arbitrary scripts other packages provide sometimes call for things under /usr. If I've read messages over the last couple days correctly, I think the recent change is that some stuff udev *directly* depends on, as part of the udev package itself, is being moved into /usr. My best guess is that this allows udev to force the issue; it gets blamed for other packages not loading correctly (when those other packages put things in places which may or may not be available yet), so the udev developer chose to force systems to have all of /usr available before udev is run. The first step in a clean solution, IMO, is to revert that change. The second step is to fix the 'silent failure' problem for packages which depend on /usr before /usr is available. No fixable, in reality. The flexibility of udev is in part in that the userspace can (and actually do) run arbitrary scripts and binaries from udev rules. You can fix the ones that require binaries in /usr *NOW*, but not forever, unless you forbid the use of arbitrary binaries from udev rules. And then you lose the flexibility. The explanation from http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken seems more than reasonable to me: /lib and /bin and /sbin were the way old-Unix solved the problem of needing some binaries before /usr was mounted. Linux has a much better, flexible and automatized (dracut) way of doing this, by using an initramfs. With an initramfs you can have the smallest / in the world, and mount everything else afterwards. The initramfs memory is free'd after the pivot_root happens, so who cares how big it is? And yeah, that's not how classical Unix do things. Who cares? Linux does it so much better. 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] udev + /usr
On Monday, 12. September 2011 14:26:13 Canek Peláez Valdés wrote: On Mon, Sep 12, 2011 at 12:52 PM, Michael Schreckenbauer grim...@gmx.de wrote: On Monday, 12. September 2011 12:42:00 Canek Peláez Valdés wrote: On Mon, Sep 12, 2011 at 12:21 PM, Dale rdalek1...@gmail.com wrote: You say it was disinformation about /var. Care to explain why me and one other person read the same thing? It was mentioned on -dev. I was pretty sure it was and then another person posted they read the same. So, I'm almost certain it was said at this point. Surely we can't both be wrong. Where did you guys read it? Who said /var could not be in its own partition anymore? What piece of code stops working if /var it's in its own partition? Who is proposing that a separated /var will not be supported in the future? Just have a look in /var/lib/* for example. I did mentioned /var/lib two paragraphs below. Do you guys respond an email while you read it? Of course I read the mails I answer! You wrote: var/lib usually stores whole databases. And I said, have a look into it. You did? Could you explain to me, what /var/lib/alsa has to do with databases? Or /var/lib/dbus? You guarantee, that nothing of this stuff is or will be needed by udev? I don't have to. Contrary to most of the guys here (I'm not saying you are one of them), I don't see the proposed change as irrational. It makes complete sense (you actually mention several reasons why it makes sense in others emails here to Alan and others). No, I don't say, it makes sense, because it does not. I know, *why* this is done, that's something completly different from making sense. What makes sense is fixing udev. Marking devices as not present, because scripts are not available, is bad design. Requiring /var to be on / would not make sense. Yes. Makes no sense. And now *look* into /var/lib. You guarantee, nothing in there is or will be needed by udev? Even more: then the idea of /run and /lock on / would be completely insane, if eventually they would require a non separated /var. The proposal of /run and /lock on / is exactly to allow /var to be on its own partition on te foreseeable future. The thread I post talks about /var/run and /var/lock needing to be symbolic links to /run and /lock, but AFAIK (and I tend to follow this sort of things) /var not only can be in its own partition, it is the recommended setup. Yes. Until this dev has his next brilliant idea. Give them some credit. This whole lot of changes is not the imposition of some crazy dev. Is the result of years of the Open Source stack evolving, and writing the code that implements a design. I give him credits. I don't think, he is an idiot. But I really think, the design is bad and needs to be fixed. Regards, Michael
Re: [gentoo-user] udev + /usr
On Mon, Sep 12, 2011 at 2:37 PM, Canek Peláez Valdés can...@gmail.com wrote: On Mon, Sep 12, 2011 at 1:39 PM, Michael Mol mike...@gmail.com wrote: The first step in a clean solution, IMO, is to revert that change. The second step is to fix the 'silent failure' problem for packages which depend on /usr before /usr is available. No fixable, in reality. The flexibility of udev is in part in that the userspace can (and actually do) run arbitrary scripts and binaries from udev rules. You can fix the ones that require binaries in /usr *NOW*, but not forever, unless you forbid the use of arbitrary binaries from udev rules. And then you lose the flexibility. Here's the chief problem with that argument...it's not just limited to /usr. If you're going to say that a script can do whatever it wants, and udev will make declarative statements about supported and unsupported filesystem layouts to allow that to work, then you *must* say that the entire filesystem be on the same partition as /, or that one must use initramfs. Because you can't know that a script won't depend on something under /var. Or /opt. Or /home. And if if /home is excluded from this must-be-available set, what makes it more special than /usr? If it's OK to say no script must access files under /home, then why isn't it OK to say no script must access files under /usr? You're imposing a rule either way. If a script author must be aware of rules, why can't he be aware of something like be aware of when a file may or may not be available, and do not access files which are not yet available. If you can't know, document the requirement so that a package maintainer or sysadmin can ensure your constraints are met. That seems pretty simple to me. It's the *job* of package maintainers to understand how software interacts with a distro's infrastructure. The explanation from http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken seems more than reasonable to me: /lib and /bin and /sbin were the way old-Unix solved the problem of needing some binaries before /usr was mounted. I read that page. I understand the problem. I'm not convinced. Linux has a much better, flexible and automatized (dracut) way of doing this, by using an initramfs. With an initramfs you can have the smallest / in the world, and mount everything else afterwards. The initramfs memory is free'd after the pivot_root happens, so who cares how big it is? People you (and the Fedora dev) don't care about, clearly. You ask who cares rhetorically, when people on this very list have said, hey, I care! There's a disconnect there I don't quite grasp. A change like this is going to make life more difficult for embedded hardware manufacturers, too. They'll have to have more memory available for a larger initrd if they want to do something so simple as a print server or a plug-and-play NAS node. And then there was that mention of MIPS, earlier, that highlighted architectural physical constraints that this would break. That's not exactly a trivial problem. And yeah, that's not how classical Unix do things. Who cares? Linux does it so much better. I really don't see where you're getting better. You're saying, Hey! This is more flexible than any other solution. What you're not saying (or noticing) is that you're kicking the can farther down the road; the same fundamental complexities will pop up later unless you use the initrd. With the initrd, you're turning every disk-installed system into something equivalent to a livecd, with the capability of updating the live cd as you go along. If that's actually the desire, there would be far better options than initrd. -- :wq
Re: [gentoo-user] Re: package.provided messes up emerging of package slots?
On Monday, 12. September 2011 21:31:59 Nikos Chantziaras wrote: On 09/12/2011 08:17 PM, Michael Schreckenbauer wrote: On Monday, 12. September 2011 20:04:47 Nikos Chantziaras wrote: On 09/12/2011 07:42 PM, Michael Schreckenbauer wrote: On Monday, 12. September 2011 18:41:37 Nikos Chantziaras wrote: In my /etc/portage/profile/package.provided, I have this: media-libs/freetype-1.4_pre20080316-r2 When I try to emerge freetype however, instead of emerging the newer version, I get: $ emerge freetype WARNING: A requested package will not be merged because it is listed in package.provided: freetype pulled in by 'args' Nothing to merge; would you like to auto-clean packages? [Yes/No] Trying emerge freetype:2 also won't work. The only only to emerge it seems is by using the whole version (emerge =freetype-2.4.6). Is this a bug? At least it's inconsistent. I would expect that the emerge with complete version also fails. It's slotted, so it shouldn't fail. Freetype 1 and 2 can be installed at the same time. Yes, that's true for the packages provided by portage. portage does not know anything about the freetype you provide, so it shouldn't install any freetype from any slot by any command. I don't see how it doesn't know anything about it, given that it requires me to list a full package atom in package.provided. So it always knows which version should be considered as being provided. Yes. freetype version 1. So if a package depends on freetype version 1, portage assumes, the dep is already installed. It does not know, where it is installed, or what files it installed. So it has to assume, that an emerge of freetype-2 actually could overwrite some of your freetype-1 files. Therefore it should not install freetype-2 with any command, if you have any version of freetype in package.provided. Best, Michael
Re: [gentoo-user] udev + /usr
On Monday, 12. September 2011 14:37:24 Canek Peláez Valdés wrote: On Mon, Sep 12, 2011 at 1:39 PM, Michael Mol mike...@gmail.com wrote: On Mon, Sep 12, 2011 at 1:17 PM, Alan Mackenzie a...@muc.de wrote: On Mon, Sep 12, 2011 at 05:33:34PM +0200, Michael Schreckenbauer wrote: On Monday, 12. September 2011 15:02:48 Alan Mackenzie wrote: Hope nobody minds me starting a new thread with an accurate name. Which version of udev is it that has this nauseating feature of needing /usr loaded to boot? Somewhere in that version's source will be several (or lots of) /usr. Just how difficult is it going to be to replace /usr/bin with /bin throughout the source? you misunderstood something. udev is able to run arbitrary scripts. Some of those scripts are located in /usr/* or need something there. I doubt you will find references to /usr in the udev-sources. Well, I'm a hacker. udev is free source, therefore fair game. I don't intend to put up with this nonsense without a fight. As far as I can make out, this is just one guy, Kay Sievers, who's on a power trip. Are there any indications at all that he actually talked to anybody in the wide world before making such a far reaching decision? udev has always been able to run arbitrary scripts. The trouble is that the arbitrary scripts other packages provide sometimes call for things under /usr. If I've read messages over the last couple days correctly, I think the recent change is that some stuff udev *directly* depends on, as part of the udev package itself, is being moved into /usr. My best guess is that this allows udev to force the issue; it gets blamed for other packages not loading correctly (when those other packages put things in places which may or may not be available yet), so the udev developer chose to force systems to have all of /usr available before udev is run. The first step in a clean solution, IMO, is to revert that change. The second step is to fix the 'silent failure' problem for packages which depend on /usr before /usr is available. No fixable, in reality. The flexibility of udev is in part in that the userspace can (and actually do) run arbitrary scripts and binaries from udev rules. You can fix the ones that require binaries in /usr *NOW*, but not forever, unless you forbid the use of arbitrary binaries from udev rules. Why do you need to run arbitrary scripts to mount /usr? Linux has a much better, flexible and automatized (dracut) way of doing this, by using an initramfs. With an initramfs you can have the smallest / in the world, and mount everything else afterwards. The initramfs memory is free'd after the pivot_root happens, so who cares how big it is? KISS. An initramfs is an additional layer, that can fail. Regards. Regards, Michael
Re: [gentoo-user] /dev/sda* missing at boot
On Sun, 11 Sep 2011 20:44:20 -0500, James Wall wrote about Re: [gentoo-user] /dev/sda* missing at boot: On Sun, Sep 11, 2011 at 4:46 PM, David W Noon dwn...@ntlworld.com wrote: [snip] I have some scripts that generate LVM rebuild scripts. These scan the current logical volumes and generate lvcreate commands into a script that can rebuild your LVM set-up in seconds. You (or anybody else) are welcome to a copy if you wish. I am interested in the backup scripts to help improve my backup/restore system. Attached. I hope this list permits binary attachments. Reply by private email if it doesn't get through. Note that it is a zsh script, so you'll need zsh installed. The output script will run under any shell. I keep mine installed in /usr/local/bin/. You can test the script by running: lvm_rebuild.zsh | less and you should see the output script displayed on the screen. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* dwn...@ntlworld.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* lvm_rebuild.tgz Description: application/compressed-tar signature.asc Description: PGP signature
Re: [gentoo-user] udev + /usr
On Mon, Sep 12, 2011 at 3:07 PM, Michael Schreckenbauer grim...@gmx.de wrote: On Monday, 12. September 2011 14:37:24 Canek Peláez Valdés wrote: No fixable, in reality. The flexibility of udev is in part in that the userspace can (and actually do) run arbitrary scripts and binaries from udev rules. You can fix the ones that require binaries in /usr *NOW*, but not forever, unless you forbid the use of arbitrary binaries from udev rules. Why do you need to run arbitrary scripts to mount /usr? It's not specifically that you need to run arbitrary scripts to mount /usr. It's that it's unknown that /usr must be mounted before some hotplug events are handled. Linux has a much better, flexible and automatized (dracut) way of doing this, by using an initramfs. With an initramfs you can have the smallest / in the world, and mount everything else afterwards. The initramfs memory is free'd after the pivot_root happens, so who cares how big it is? KISS. An initramfs is an additional layer, that can fail. Concur. While a massive machine full of moving parts is beautiful to behold, it's also the easiest thing to break, accidentally or otherwise. -- :wq
Re: [gentoo-user] udev + /usr
On Mon, Sep 12, 2011 at 3:00 PM, Michael Mol mike...@gmail.com wrote: On Mon, Sep 12, 2011 at 2:37 PM, Canek Peláez Valdés can...@gmail.com wrote: On Mon, Sep 12, 2011 at 1:39 PM, Michael Mol mike...@gmail.com wrote: The first step in a clean solution, IMO, is to revert that change. The second step is to fix the 'silent failure' problem for packages which depend on /usr before /usr is available. No fixable, in reality. The flexibility of udev is in part in that the userspace can (and actually do) run arbitrary scripts and binaries from udev rules. You can fix the ones that require binaries in /usr *NOW*, but not forever, unless you forbid the use of arbitrary binaries from udev rules. And then you lose the flexibility. Here's the chief problem with that argument...it's not just limited to /usr. If you're going to say that a script can do whatever it wants, and udev will make declarative statements about supported and unsupported filesystem layouts to allow that to work, then you *must* say that the entire filesystem be on the same partition as /, or that one must use initramfs. Because you can't know that a script won't depend on something under /var. Or /opt. Or /home. And if if /home is excluded from this must-be-available set, what makes it more special than /usr? If it's OK to say no script must access files under /home, then why isn't it OK to say no script must access files under /usr? You're imposing a rule either way. If a script author must be aware of rules, why can't he be aware of something like be aware of when a file may or may not be available, and do not access files which are not yet available. If you can't know, document the requirement so that a package maintainer or sysadmin can ensure your constraints are met. That seems pretty simple to me. It's the *job* of package maintainers to understand how software interacts with a distro's infrastructure. The explanation from http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken seems more than reasonable to me: /lib and /bin and /sbin were the way old-Unix solved the problem of needing some binaries before /usr was mounted. I read that page. I understand the problem. I'm not convinced. I can respect that. I can only then say that we must agree to disagree, because I also understand the problem, and I am convinced. But what you guys don't seem to realize is that /lib and /bin and /sbin was the original hack: everything really should go into /usr, because now (with an initramfs) we can do what we were not able 30 years ago. We not need anything in /, really. Anyway, I'm not trying to convince anyone. Just wanted to show the links and to make clear among other things that *no one* has ever proposed (even less try to force) a non separatable /var. You can speculate all you want, but that's all: speculation. Going back to work: nice chatting with you guys. 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] udev + /usr
On Monday, 12. September 2011 15:18:53 Michael Mol wrote: On Mon, Sep 12, 2011 at 3:07 PM, Michael Schreckenbauer grim...@gmx.de wrote: On Monday, 12. September 2011 14:37:24 Canek Peláez Valdés wrote: No fixable, in reality. The flexibility of udev is in part in that the userspace can (and actually do) run arbitrary scripts and binaries from udev rules. You can fix the ones that require binaries in /usr *NOW*, but not forever, unless you forbid the use of arbitrary binaries from udev rules. Why do you need to run arbitrary scripts to mount /usr? It's not specifically that you need to run arbitrary scripts to mount /usr. It's that it's unknown that /usr must be mounted before some hotplug events are handled. Claiming this is not fixable... unless you forbid the use of arbitrary binaries from udev rules implies, that you need to run arbitrary scripts to mount /usr. Otherwise a fix would be to mount /usr with whatever is needed to do this and then run the arbitrary scripts. Sadly udev does not support this. Best, Michael
Re: [gentoo-user] udev + /usr
On Mon, Sep 12, 2011 at 3:35 PM, Canek Peláez Valdés can...@gmail.com wrote: On Mon, Sep 12, 2011 at 3:00 PM, Michael Mol mike...@gmail.com wrote: On Mon, Sep 12, 2011 at 2:37 PM, Canek Peláez Valdés can...@gmail.com wrote: On Mon, Sep 12, 2011 at 1:39 PM, Michael Mol mike...@gmail.com wrote: The first step in a clean solution, IMO, is to revert that change. The second step is to fix the 'silent failure' problem for packages which depend on /usr before /usr is available. No fixable, in reality. The flexibility of udev is in part in that the userspace can (and actually do) run arbitrary scripts and binaries from udev rules. You can fix the ones that require binaries in /usr *NOW*, but not forever, unless you forbid the use of arbitrary binaries from udev rules. And then you lose the flexibility. Here's the chief problem with that argument...it's not just limited to /usr. If you're going to say that a script can do whatever it wants, and udev will make declarative statements about supported and unsupported filesystem layouts to allow that to work, then you *must* say that the entire filesystem be on the same partition as /, or that one must use initramfs. Because you can't know that a script won't depend on something under /var. Or /opt. Or /home. And if if /home is excluded from this must-be-available set, what makes it more special than /usr? If it's OK to say no script must access files under /home, then why isn't it OK to say no script must access files under /usr? You're imposing a rule either way. If a script author must be aware of rules, why can't he be aware of something like be aware of when a file may or may not be available, and do not access files which are not yet available. If you can't know, document the requirement so that a package maintainer or sysadmin can ensure your constraints are met. That seems pretty simple to me. It's the *job* of package maintainers to understand how software interacts with a distro's infrastructure. The explanation from http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken seems more than reasonable to me: /lib and /bin and /sbin were the way old-Unix solved the problem of needing some binaries before /usr was mounted. I read that page. I understand the problem. I'm not convinced. I can respect that. I can only then say that we must agree to disagree, because I also understand the problem, and I am convinced. But what you guys don't seem to realize is that /lib and /bin and /sbin was the original hack: everything really should go into /usr, because now (with an initramfs) we can do what we were not able 30 years ago. We not need anything in /, really. Then is / anything other than a root node in a logical tree? Anyway, I'm not trying to convince anyone. Just wanted to show the links and to make clear among other things that *no one* has ever proposed (even less try to force) a non separatable /var. You can speculate all you want, but that's all: speculation. Everything seems to revolve around coming upon a more-correct or most-correct solution. The speculation is nothing more than thinking ahead about consequences, and whether or not the change to udev ultimately solves anything, or whether it is merely change for change's sake. I don't see that it solves the logical problem the Fedora dev claims it solves. -- :wq
Re: [gentoo-user] udev + /usr
Canek Peláez Valdés wrote: And yeah, that's not how classical Unix do things. Who cares? Linux does it so much better. Regards. Some of us here care. That is the reason we are not liking this one bit. Dale :-) :-)
Re: [gentoo-user] udev + /usr
On Mon, Sep 12, 2011 at 3:41 PM, Michael Schreckenbauer grim...@gmx.de wrote: On Monday, 12. September 2011 15:18:53 Michael Mol wrote: On Mon, Sep 12, 2011 at 3:07 PM, Michael Schreckenbauer grim...@gmx.de wrote: On Monday, 12. September 2011 14:37:24 Canek Peláez Valdés wrote: No fixable, in reality. The flexibility of udev is in part in that the userspace can (and actually do) run arbitrary scripts and binaries from udev rules. You can fix the ones that require binaries in /usr *NOW*, but not forever, unless you forbid the use of arbitrary binaries from udev rules. Why do you need to run arbitrary scripts to mount /usr? It's not specifically that you need to run arbitrary scripts to mount /usr. It's that it's unknown that /usr must be mounted before some hotplug events are handled. Claiming this is not fixable... unless you forbid the use of arbitrary binaries from udev rules implies, that you need to run arbitrary scripts to mount /usr. No, it states that it's not solveable for the broadest set of cases (I hesitate to say 'universally') unless you can run arbitrary scripts which may be in /usr. Consider it possible that nfsd is needed to mount /usr. The credentials needed for NFS to connect to the server are on an encrypted partition. The key for decrypting that partition is stored on a USB flash drive. The USB flash drive is formatted using a very recent version of NTFS. FUSE is necessary to read that flash drive's filesystem. In this scenario, the NFS binaries and FUSE binaries are located under /usr. It's this kind of scenario that falls under the general class that udev's trying to solve. If I understand it properly, the mentality is, I can't forsee what distros and sysadmins will want to do, I get bug reports when peoples' configurations fail because they were trying to load things from unmounted filesystems, so if I say the filesystem *must* be mounted (or they must use an initramfs) in order to use udev, those bug reports will solve themselves. Otherwise a fix would be to mount /usr with whatever is needed to do this and then run the arbitrary scripts. Sadly udev does not support this. Which requires some kind of dependency or retry scheme, which adds complexity to udev that the Fedora dev decided he didn't want to spend the time on. -- :wq
Re: [gentoo-user] udev + /usr
On Mon, 12 Sep 2011 15:00:49 -0400, Michael Mol wrote about Re: [gentoo-user] udev + /usr: On Mon, Sep 12, 2011 at 2:37 PM, Canek Peláez Valdés can...@gmail.com wrote: [snip] And then you lose the flexibility. Here's the chief problem with that argument...it's not just limited to /usr. If you're going to say that a script can do whatever it wants, and udev will make declarative statements about supported and unsupported filesystem layouts to allow that to work, then you *must* say that the entire filesystem be on the same partition as /, or that one must use initramfs. Because you can't know that a script won't depend on something under /var. Or /opt. Or /home. And if if /home is excluded from this must-be-available set, what makes it more special than /usr? If it's OK to say no script must access files under /home, then why isn't it OK to say no script must access files under /usr? This gets back to what I wrote a few days back: put everything on / and call it C:. The real question is: how much flexibility do udev scripts actually need? My take is that udev scripts should only need to handle hardware interfaces presenting devices to the system, at least early in the bootstrap sequence. Later on, virtual devices, such as those presented by virtual machine managers to connect to the outside, need also to be handled. Then we have to consider what resources these scripts should be allowed to use. The main bugbear here is [semi-]interpretive scripting languages, such as Perl and Python. Quite simply, these should not be used. The external resources used by udev scripts should be statically linked, native object code binaries; this includes the system shells such as bash, zsh, etc. This has always been the case for hardware management code -- and with good reason: the greater the complexity of getting a piece of functionality running, the higher the likelihood that something is not yet available and it will fail. Yes, this is old; it's FORTRAN; it's COBOL; but it works reliably with minimal stress on the hardware. Now it becomes a matter of identifying those udev scripts that violate this idea and replacing them with better code. Logging script failures would be a first step in the right direction. However, given that many of the people coding these scripts don't bother checking return codes, this could be asking for the moon on a stick. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* dwn...@ntlworld.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* signature.asc Description: PGP signature
Re: [gentoo-user] udev + /usr
Canek Peláez Valdés writes: But what you guys don't seem to realize is that /lib and /bin and /sbin was the original hack: everything really should go into /usr, because now (with an initramfs) we can do what we were not able 30 years ago. We not need anything in /, really. You do have a point here. Anyway, I'm not trying to convince anyone. Just wanted to show the links and to make clear among other things that *no one* has ever proposed (even less try to force) a non separatable /var. You can speculate all you want, but that's all: speculation. I cannot find it, but I'm very sure I just read about /var also being affected. But it looks indeed like that will not be necessary at all. Going back to work: nice chatting with you guys. Thanks for your input and your time. Personally, I don't really care that much. Either I somehow update my initramfs (I expect this to be easy) to include the stuff needed formounting /usr, or I extend my root partition and put /usr in it. I still don't like that much, but there are just more important problems, and it's really not such a big deal. Just another big update that needs manual intervention, as it happens from time to time. Like the migration to openrc for example. I wonder why no one complained about that when it happened. Wonko
Re: [gentoo-user] Re: package.provided messes up emerging of package slots?
On Mon, 12 Sep 2011 19:49:28 +0300 Nikos Chantziaras rea...@arcor.de wrote: On 09/12/2011 07:31 PM, Pandu Poluan wrote: On Sep 12, 2011 11:11 PM, Nikos Chantziaras rea...@arcor.de mailto:rea...@arcor.de wrote: In my /etc/portage/profile/package.provided, I have this: media-libs/freetype-1.4_pre20080316-r2 When I try to emerge freetype however, instead of emerging the newer version, I get: $ emerge freetype WARNING: A requested package will not be merged because it is listed in package.provided: freetype pulled in by 'args' Nothing to merge; would you like to auto-clean packages? [Yes/No] Trying emerge freetype:2 also won't work. The only only to emerge it seems is by using the whole version (emerge =freetype-2.4.6). Is this a bug? Why did you have that line in package.provided, in the first place? Did you install freetype on your own, without using portage? Portage installs both freetype-1 as well as freetype-2. texlive has freetype-1 as a dep, and I don't want it installed because I'm not using ttf2tfm. The way I see it, Portage worked perfectly: it saw that you have installed a certain version of freetype on your own, and it didn't want to mess up your installed package. Just delete the line and emerge freetype. From my point of view, it doesn't work perfectly, because it behaves differently when freetype-1 is really installed, and when it's not but listed in package.provided. If I install freetype-1 and type: emerge freetype it will emerge freetype:2. So the behavior is vastly different between having freetype really installed, and when not but listed in package.provided. That's because a package being installed and being provided are not the same thing and are treated very differently. If you install xyz-1.2.3 then portage knows what it did to achieve that and can deal with it as normal. If you provide xyz-1.2.3 then portage does not know what *you* did to achieve that and makes no attempt to deal with it at all. You are expected to completely 100% deal with all of xyz, including all slots. man 5 portage mentions that the version number is there in package.provided so that portage can alert you if some other package has a dep on a version of xyz you did not provide. Seen in that light, the behaviour is indeed sensible, just not consistent if you haven't read the docs yet. I don't think it's wise to try and change portage's behaviour with this, as Michael said in another sub-thread portage has no idea what you did so it can't even try to take control of different slots for fear it might clobber all your manual hard work -- Alan McKinnnon alan.mckin...@gmail.com
Re: [gentoo-user] udev + /usr
On Mon, 12 Sep 2011 12:42:00 -0400 Canek Peláez Valdés can...@gmail.com wrote: On Mon, Sep 12, 2011 at 12:21 PM, Dale rdalek1...@gmail.com wrote: Canek Peláez Valdés wrote: On Mon, Sep 12, 2011 at 11:02 AM, Alan Mackenziea...@muc.de wrote: Hi, everybody. Hope nobody minds me starting a new thread with an accurate name. Which version of udev is it that has this nauseating feature of needing /usr loaded to boot? Somewhere in that version's source will be several (or lots of) /usr. Just how difficult is it going to be to replace /usr/bin with /bin throughout the source? udev is part of the kernel. How come the kernel hackers aren't up in arms about this as much as we are? Or are they, maybe? In which case, maybe the kernel people would welcome an option to disrequire the early mounting of /usr as much as we would. Anyhow, I'd like to take a peek at the source code which does this evil thing. Would somebody please tell me which version of udev is involved. Thanks. (This would be my only post in this new thread: I think I have made my point of view clear in the other thread). I have seen a lot of disinformation going on in the other threads (like some people suggesting that /var would not be able to be on its own partition at some point in the future). Just before everyone start to wildy conjecture, please take a look at this: http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken Also, a look at this thread is maybe justified: http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/1728/ Both things are in the context of systemd, but it's related to the discussion at hand. I know not everybody wants to use systemd, and think Lennart and Kay are the root of all that is wrong and evil on the world, but I will recommend everyone interested in the reasons of the push for a recommended initramfs to take a look at the page in fd.org, and the thread in the systemd mailing list. Even if you don't agree with the reasoning, it is worth to take a look at it. As for me, I would say one last time my POV: Linux strives to be much more than Unix, and that means do things differently. It will always be capable of do anything that Unix does, and most of the time it will do it better. But that doesn't (necessarily) means that it will do it in the same way. And many of us don't take but my config/setup/partition works now as a valid argument to restrain progress. Change happens. Regards everyone. You say it was disinformation about /var. Care to explain why me and one other person read the same thing? It was mentioned on -dev. I was pretty sure it was and then another person posted they read the same. So, I'm almost certain it was said at this point. Surely we can't both be wrong. The issue is not /var, it is /var/run. This dir can be needed early in the boot process, but cannot be mounted before /var is mounted. The solution is /run. $DEITY help us when people start finding needed crap in /var/lib and other such insanities. -- Alan McKinnnon alan.mckin...@gmail.com
Re: [gentoo-user] udev + /usr
On Mon, Sep 12, 2011 at 03:35:19PM -0400, Canek Peláez Valdés wrote: I read that page. I understand the problem. I'm not convinced. I can respect that. I can only then say that we must agree to disagree, because I also understand the problem, and I am convinced. But what you guys don't seem to realize is that /lib and /bin and /sbin was the original hack: everything really should go into /usr, because now (with an initramfs) we can do what we were not able 30 years ago. We not need anything in /, really. They could have put everything on /usr 30 years ago, if they'd have seen fit. They saw then good reason not to. What you and KS seem oblivious to is the reason for /bin, /sbin. It is to allow a small boot so as to permit system maintenance - fsck, resizing or moving partions, even undeleting files - all these things are difficult, or even impossible perhaps, if the pertinent partition is mounted. To pretend otherwise is disingenuous. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México -- Alan Mackenzie (Nuremberg, Germany).
[gentoo-user] Re: package.provided messes up emerging of package slots?
On 09/12/2011 10:02 PM, Michael Schreckenbauer wrote: On Monday, 12. September 2011 21:31:59 Nikos Chantziaras wrote: On 09/12/2011 08:17 PM, Michael Schreckenbauer wrote: On Monday, 12. September 2011 20:04:47 Nikos Chantziaras wrote: On 09/12/2011 07:42 PM, Michael Schreckenbauer wrote: On Monday, 12. September 2011 18:41:37 Nikos Chantziaras wrote: In my /etc/portage/profile/package.provided, I have this: media-libs/freetype-1.4_pre20080316-r2 When I try to emerge freetype however, instead of emerging the newer version, I get: $ emerge freetype WARNING: A requested package will not be merged because it is listed in package.provided: freetype pulled in by 'args' Nothing to merge; would you like to auto-clean packages? [Yes/No] Trying emerge freetype:2 also won't work. The only only to emerge it seems is by using the whole version (emerge =freetype-2.4.6). Is this a bug? At least it's inconsistent. I would expect that the emerge with complete version also fails. It's slotted, so it shouldn't fail. Freetype 1 and 2 can be installed at the same time. Yes, that's true for the packages provided by portage. portage does not know anything about the freetype you provide, so it shouldn't install any freetype from any slot by any command. I don't see how it doesn't know anything about it, given that it requires me to list a full package atom in package.provided. So it always knows which version should be considered as being provided. Yes. freetype version 1. So if a package depends on freetype version 1, portage assumes, the dep is already installed. It does not know, where it is installed, or what files it installed. So it has to assume, that an emerge of freetype-2 actually could overwrite some of your freetype-1 files. Therefore it should not install freetype-2 with any command, if you have any version of freetype in package.provided. I disagree. A slotted package is practically two different packages that simply share the same name. If one slot is assumed as being provided, then that slot should have no effect on the other ones. With your argument, portage should not install *any* packages at all if there's even a single entry in package.provided, because it doesn't know what that package installs and therefore *any other* package could results in conflicts.
[gentoo-user] Re: package.provided messes up emerging of package slots?
On 09/12/2011 11:31 PM, Alan McKinnon wrote: On Mon, 12 Sep 2011 19:49:28 +0300 Nikos Chantziarasrea...@arcor.de wrote: On 09/12/2011 07:31 PM, Pandu Poluan wrote: On Sep 12, 2011 11:11 PM, Nikos Chantziarasrea...@arcor.de mailto:rea...@arcor.de wrote: In my /etc/portage/profile/package.provided, I have this: media-libs/freetype-1.4_pre20080316-r2 When I try to emerge freetype however, instead of emerging the newer version, I get: $ emerge freetype WARNING: A requested package will not be merged because it is listed in package.provided: freetype pulled in by 'args' Nothing to merge; would you like to auto-clean packages? [Yes/No] Trying emerge freetype:2 also won't work. The only only to emerge it seems is by using the whole version (emerge =freetype-2.4.6). Is this a bug? Why did you have that line in package.provided, in the first place? Did you install freetype on your own, without using portage? Portage installs both freetype-1 as well as freetype-2. texlive has freetype-1 as a dep, and I don't want it installed because I'm not using ttf2tfm. The way I see it, Portage worked perfectly: it saw that you have installed a certain version of freetype on your own, and it didn't want to mess up your installed package. Just delete the line and emerge freetype. From my point of view, it doesn't work perfectly, because it behaves differently when freetype-1 is really installed, and when it's not but listed in package.provided. If I install freetype-1 and type: emerge freetype it will emerge freetype:2. So the behavior is vastly different between having freetype really installed, and when not but listed in package.provided. That's because a package being installed and being provided are not the same thing and are treated very differently. If you install xyz-1.2.3 then portage knows what it did to achieve that and can deal with it as normal. If you provide xyz-1.2.3 then portage does not know what *you* did to achieve that and makes no attempt to deal with it at all. You are expected to completely 100% deal with all of xyz, including all slots. man 5 portage mentions that the version number is there in package.provided so that portage can alert you if some other package has a dep on a version of xyz you did not provide. Yes, on a *version*, not on a *slot*, which is in effect a different package but simply using the same name. Seen in that light, the behaviour is indeed sensible, just not consistent if you haven't read the docs yet. I don't think it's wise to try and change portage's behaviour with this, as Michael said in another sub-thread portage has no idea what you did so it can't even try to take control of different slots for fear it might clobber all your manual hard work As I mentioned in my other post, portage should stop working altogether then, because conflicts can arise with any other package. But portage *does* allows me to install package foo if I have bar-1.0 listed in package.provided. For the same reason, it should allow me install foo:2 if I have a foo in package.provided that belongs to the foo:1 slot.
Re: [gentoo-user] Re: package.provided messes up emerging of package slots?
On Sep 13, 2011 2:10 AM, Nikos Chantziaras rea...@arcor.de wrote: On 09/12/2011 08:17 PM, Michael Schreckenbauer wrote: On Monday, 12. September 2011 20:04:47 Nikos Chantziaras wrote: On 09/12/2011 07:42 PM, Michael Schreckenbauer wrote: On Monday, 12. September 2011 18:41:37 Nikos Chantziaras wrote: In my /etc/portage/profile/package.provided, I have this: media-libs/freetype-1.4_pre20080316-r2 When I try to emerge freetype however, instead of emerging the newer version, I get: $ emerge freetype WARNING: A requested package will not be merged because it is listed in package.provided: freetype pulled in by 'args' Nothing to merge; would you like to auto-clean packages? [Yes/No] Trying emerge freetype:2 also won't work. The only only to emerge it seems is by using the whole version (emerge =freetype-2.4.6). Is this a bug? At least it's inconsistent. I would expect that the emerge with complete version also fails. It's slotted, so it shouldn't fail. Freetype 1 and 2 can be installed at the same time. Yes, that's true for the packages provided by portage. portage does not know anything about the freetype you provide, so it shouldn't install any freetype from any slot by any command. I don't see how it doesn't know anything about it, given that it requires me to list a full package atom in package.provided. So it always knows which version should be considered as being provided. Well, Portage in your case only knows 'which' version is provided so packages that depend on that version can be emerged. But, Portage has no knowledge of the 'provided' package's files (e.g., no data about the package in /var/db) since listing a package in package.provided implies the package is not managed by Portage. This means, Portage can't do anything to the 'provided' package. Rgds,
Re: [gentoo-user] udev + /usr
On Sep 13, 2011 3:16 AM, Michael Mol mike...@gmail.com wrote: On Mon, Sep 12, 2011 at 3:41 PM, Michael Schreckenbauer grim...@gmx.de wrote: On Monday, 12. September 2011 15:18:53 Michael Mol wrote: On Mon, Sep 12, 2011 at 3:07 PM, Michael Schreckenbauer grim...@gmx.de wrote: On Monday, 12. September 2011 14:37:24 Canek Peláez Valdés wrote: No fixable, in reality. The flexibility of udev is in part in that the userspace can (and actually do) run arbitrary scripts and binaries from udev rules. You can fix the ones that require binaries in /usr *NOW*, but not forever, unless you forbid the use of arbitrary binaries from udev rules. Why do you need to run arbitrary scripts to mount /usr? It's not specifically that you need to run arbitrary scripts to mount /usr. It's that it's unknown that /usr must be mounted before some hotplug events are handled. Claiming this is not fixable... unless you forbid the use of arbitrary binaries from udev rules implies, that you need to run arbitrary scripts to mount /usr. No, it states that it's not solveable for the broadest set of cases (I hesitate to say 'universally') unless you can run arbitrary scripts which may be in /usr. Consider it possible that nfsd is needed to mount /usr. The credentials needed for NFS to connect to the server are on an encrypted partition. The key for decrypting that partition is stored on a USB flash drive. The USB flash drive is formatted using a very recent version of NTFS. FUSE is necessary to read that flash drive's filesystem. In this scenario, the NFS binaries and FUSE binaries are located under /usr. It's this kind of scenario that falls under the general class that udev's trying to solve. If I understand it properly, the mentality is, I can't forsee what distros and sysadmins will want to do, I get bug reports when peoples' configurations fail because they were trying to load things from unmounted filesystems, so if I say the filesystem *must* be mounted (or they must use an initramfs) in order to use udev, those bug reports will solve themselves. Otherwise a fix would be to mount /usr with whatever is needed to do this and then run the arbitrary scripts. Sadly udev does not support this. Which requires some kind of dependency or retry scheme, which adds complexity to udev that the Fedora dev decided he didn't want to spend the time on. -- :wq Hmmm... after reading Michael (non_grimlog)'s explanation, I'm starting to understand udev's dev's thoughts. It seems too many people (mis)use udev to execute something in /usr while at the same time using a separated /usr that needs to be mounted first. Too many people are perhaps too lazy to RTFM, and blame the resulting boot failure to udev. Understandable, but his way out is instead by forcing a 'way of life' that's incompatible with what many sysadmins (especially Gentoo sysadmins) are familiar with. So the solution IMO should be: * Keep udev as it was before (i.e., living in / instead of in /usr) and somehow make sure that everyone RTFM/RTFFAQ, or * Make two versions of udev, one which lives in / for those who've done their homework, and another version in /usr for the ignoramuses Users of 'Technical Distros' like Gentoo can choose between root-udev or usr-udev, while 'Less Technical Distros' can just use usr-udev out-of-the-box. Rgds,
Re: [gentoo-user] Re: package.provided messes up emerging of package slots?
On Monday, 12. September 2011 23:42:30 Nikos Chantziaras wrote: On 09/12/2011 10:02 PM, Michael Schreckenbauer wrote: On Monday, 12. September 2011 21:31:59 Nikos Chantziaras wrote: On 09/12/2011 08:17 PM, Michael Schreckenbauer wrote: On Monday, 12. September 2011 20:04:47 Nikos Chantziaras wrote: On 09/12/2011 07:42 PM, Michael Schreckenbauer wrote: On Monday, 12. September 2011 18:41:37 Nikos Chantziaras wrote: In my /etc/portage/profile/package.provided, I have this: media-libs/freetype-1.4_pre20080316-r2 When I try to emerge freetype however, instead of emerging the newer version, I get: $ emerge freetype WARNING: A requested package will not be merged because it is listed in package.provided: freetype pulled in by 'args' Nothing to merge; would you like to auto-clean packages? [Yes/No] Trying emerge freetype:2 also won't work. The only only to emerge it seems is by using the whole version (emerge =freetype-2.4.6). Is this a bug? At least it's inconsistent. I would expect that the emerge with complete version also fails. It's slotted, so it shouldn't fail. Freetype 1 and 2 can be installed at the same time. Yes, that's true for the packages provided by portage. portage does not know anything about the freetype you provide, so it shouldn't install any freetype from any slot by any command. I don't see how it doesn't know anything about it, given that it requires me to list a full package atom in package.provided. So it always knows which version should be considered as being provided. Yes. freetype version 1. So if a package depends on freetype version 1, portage assumes, the dep is already installed. It does not know, where it is installed, or what files it installed. So it has to assume, that an emerge of freetype-2 actually could overwrite some of your freetype-1 files. Therefore it should not install freetype-2 with any command, if you have any version of freetype in package.provided. I disagree. A slotted package is practically two different packages that simply share the same name. If one slot is assumed as being provided, then that slot should have no effect on the other ones. You cannot provide a slot - you provide a package - freetype in this case. A slot is a gentoo specific thing. If you provide a package, you lose the advantages of portage. One of them being slots. With your argument, portage should not install *any* packages at all if there's even a single entry in package.provided, because it doesn't know what that package installs and therefore *any other* package could results in conflicts. Say, you had freetype-2.x in your package provided and for some reason you configured it to install to /usr/include/freetype, /usr/lib/freetype and so on. What should emerge do, if you now emerge freetype:1? Install it and overwrite your provided package? I only flipped versions here, because configuring freetype:1 to install to */freetype-2 sounds a bit strange :) If you tell portage I care for freetype myself, then you have to deal with it. If you really need freetype:2 together with freetype:1, you have to provide freetype:2 also. Only you know, how to configure it, so it does not conflict with your freetype:1 Best, Michael
Re: [gentoo-user] udev + /usr
On Mon, 12 Sep 2011 17:33:34 +0200 Michael Schreckenbauer grim...@gmx.de wrote: Every udev version works this way. Fixing udev to continue working with separate /usr is far from trivial imo. Changing some paths is not the way to go for sure. First of all, udev has to distinguish between device not present and script error of some kind. Failing scripts have to be queued somehow for later execution. If a script keeps failing, it has to be removed from that queue, with a message to syslog or something like that. If udev needs a script in /usr/* to mount /usr then there's a chicken-egg-problem, which could be hard to solve (if possible at all without moving things from /usr/ to /). Note, that I am wild guessing here, I did not study the udev sources or any related script/rule :) To expand on that: udev running at early boot time and udev running later with a full userspace mounted are very different things. udev should be able to differentiate between these two phases and modify it's behaviour. Put another way: The thing that lays the foundation for the full userspace to be in place *CANNOT* assume the existence of the full userspace. That's like the wall assuming the roof must exist. Furthermore, it's not at all a case that /usr must be mounted - that's just an interesting artifact, and expression of where stuff is. The correct description is more like the script that udev launches must be available to udev *when* udev launches it. I think concentrating on the problem expressed in this wise would open the door to better solutions. I do like the idea of a phase 1 and phase 2 approach by udev - early boot and full userspace running. -- Alan McKinnnon alan.mckin...@gmail.com
Re: [gentoo-user] udev + /usr
On Mon, 12 Sep 2011 16:07:46 -0400 Michael Mol mike...@gmail.com wrote: No, it states that it's not solveable for the broadest set of cases (I hesitate to say 'universally') unless you can run arbitrary scripts which may be in /usr. Consider it possible that nfsd is needed to mount /usr. The credentials needed for NFS to connect to the server are on an encrypted partition. The key for decrypting that partition is stored on a USB flash drive. The USB flash drive is formatted using a very recent version of NTFS. FUSE is necessary to read that flash drive's filesystem. You do realize what you just did, right? You ruined a wonderfully heated argument by inserting perfectly valid facts. I must now wander off and re-consider my position. I don't like you and you're not my friend anymore wah, weep :-) -- Alan McKinnnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: package.provided messes up emerging of package slots?
On Mon, 12 Sep 2011 23:48:01 +0300 Nikos Chantziaras rea...@arcor.de wrote: If you provide xyz-1.2.3 then portage does not know what *you* did to achieve that and makes no attempt to deal with it at all. You are expected to completely 100% deal with all of xyz, including all slots. man 5 portage mentions that the version number is there in package.provided so that portage can alert you if some other package has a dep on a version of xyz you did not provide. Yes, on a *version*, not on a *slot*, which is in effect a different package but simply using the same name. I can't explain that (and reading the portage sources is not something that fills me with joy). I can think up a few possibilities ranging from the .provided code predates slots and has never been touched since all the way up to there being some real conflict you and I don't know about. Seen in that light, the behaviour is indeed sensible, just not consistent if you haven't read the docs yet. I don't think it's wise to try and change portage's behaviour with this, as Michael said in another sub-thread portage has no idea what you did so it can't even try to take control of different slots for fear it might clobber all your manual hard work As I mentioned in my other post, portage should stop working altogether then, because conflicts can arise with any other package. But portage *does* allows me to install package foo if I have bar-1.0 listed in package.provided. For the same reason, it should allow me install foo:2 if I have a foo in package.provided that belongs to the foo:1 slot. If portage tries to clobber a file you provided, then portage will see it and collision-protect will do it's job. If you clobber an existing file while installing something you provided, well that's your fault and you should have paid attention. So I don't think the foo|bar scenario you describe is anything worth worrying about. Maybe it really is just a case of You provided xyz, you will therefore provide everything about xyz, even slots. I know that's the starting position I would take if I were Zac. -- Alan McKinnnon alan.mckin...@gmail.com
Re: [gentoo-user] udev + /usr
On Monday, 12. September 2011 22:57:40 Alan McKinnon wrote: On Mon, 12 Sep 2011 16:07:46 -0400 Michael Mol mike...@gmail.com wrote: No, it states that it's not solveable for the broadest set of cases (I hesitate to say 'universally') unless you can run arbitrary scripts which may be in /usr. Consider it possible that nfsd is needed to mount /usr. The credentials needed for NFS to connect to the server are on an encrypted partition. The key for decrypting that partition is stored on a USB flash drive. The USB flash drive is formatted using a very recent version of NTFS. FUSE is necessary to read that flash drive's filesystem. You do realize what you just did, right? You ruined a wonderfully heated argument by inserting perfectly valid facts. I'd love to see the working initramfs for that scenario... and then the version dracut made :) I must now wander off and re-consider my position. I don't like you and you're not my friend anymore wah, weep :-) Best, Michael
[gentoo-user] Re: package.provided messes up emerging of package slots?
On 09/13/2011 12:18 AM, Michael Schreckenbauer wrote: On Monday, 12. September 2011 23:42:30 Nikos Chantziaras wrote: On 09/12/2011 10:02 PM, Michael Schreckenbauer wrote: On Monday, 12. September 2011 21:31:59 Nikos Chantziaras wrote: On 09/12/2011 08:17 PM, Michael Schreckenbauer wrote: On Monday, 12. September 2011 20:04:47 Nikos Chantziaras wrote: On 09/12/2011 07:42 PM, Michael Schreckenbauer wrote: On Monday, 12. September 2011 18:41:37 Nikos Chantziaras wrote: In my /etc/portage/profile/package.provided, I have this: media-libs/freetype-1.4_pre20080316-r2 When I try to emerge freetype however, instead of emerging the newer version, I get: $ emerge freetype WARNING: A requested package will not be merged because it is listed in package.provided: freetype pulled in by 'args' Nothing to merge; would you like to auto-clean packages? [Yes/No] Trying emerge freetype:2 also won't work. The only only to emerge it seems is by using the whole version (emerge =freetype-2.4.6). Is this a bug? At least it's inconsistent. I would expect that the emerge with complete version also fails. It's slotted, so it shouldn't fail. Freetype 1 and 2 can be installed at the same time. Yes, that's true for the packages provided by portage. portage does not know anything about the freetype you provide, so it shouldn't install any freetype from any slot by any command. I don't see how it doesn't know anything about it, given that it requires me to list a full package atom in package.provided. So it always knows which version should be considered as being provided. Yes. freetype version 1. So if a package depends on freetype version 1, portage assumes, the dep is already installed. It does not know, where it is installed, or what files it installed. So it has to assume, that an emerge of freetype-2 actually could overwrite some of your freetype-1 files. Therefore it should not install freetype-2 with any command, if you have any version of freetype in package.provided. I disagree. A slotted package is practically two different packages that simply share the same name. If one slot is assumed as being provided, then that slot should have no effect on the other ones. You cannot provide a slot - you provide a package - freetype in this case. A slot is a gentoo specific thing. So is package.provided :-) With your argument, portage should not install *any* packages at all if there's even a single entry in package.provided, because it doesn't know what that package installs and therefore *any other* package could results in conflicts. Say, you had freetype-2.x in your package provided and for some reason you configured it to install to /usr/include/freetype, /usr/lib/freetype and so on. What should emerge do, if you now emerge freetype:1? Install it and overwrite your provided package? Yes. It should do exactly that. Because of lack of information, it should assume that I know what I'm doing. Fortunately, it does exactly that :-) The original point of my post is why it works with emerge foo-version but not with emerge foo:slot.
Re: [gentoo-user] Re: package.provided messes up emerging of package slots?
On Tuesday, 13. September 2011 01:11:39 Nikos Chantziaras wrote: On 09/13/2011 12:18 AM, Michael Schreckenbauer wrote: On Monday, 12. September 2011 23:42:30 Nikos Chantziaras wrote: On 09/12/2011 10:02 PM, Michael Schreckenbauer wrote: On Monday, 12. September 2011 21:31:59 Nikos Chantziaras wrote: On 09/12/2011 08:17 PM, Michael Schreckenbauer wrote: On Monday, 12. September 2011 20:04:47 Nikos Chantziaras wrote: On 09/12/2011 07:42 PM, Michael Schreckenbauer wrote: On Monday, 12. September 2011 18:41:37 Nikos Chantziaras wrote: In my /etc/portage/profile/package.provided, I have this: media-libs/freetype-1.4_pre20080316-r2 When I try to emerge freetype however, instead of emerging the newer version, I get: $ emerge freetype WARNING: A requested package will not be merged because it is listed in package.provided: freetype pulled in by 'args' Nothing to merge; would you like to auto-clean packages? [Yes/No] Trying emerge freetype:2 also won't work. The only only to emerge it seems is by using the whole version (emerge =freetype-2.4.6). Is this a bug? At least it's inconsistent. I would expect that the emerge with complete version also fails. It's slotted, so it shouldn't fail. Freetype 1 and 2 can be installed at the same time. Yes, that's true for the packages provided by portage. portage does not know anything about the freetype you provide, so it shouldn't install any freetype from any slot by any command. I don't see how it doesn't know anything about it, given that it requires me to list a full package atom in package.provided. So it always knows which version should be considered as being provided. Yes. freetype version 1. So if a package depends on freetype version 1, portage assumes, the dep is already installed. It does not know, where it is installed, or what files it installed. So it has to assume, that an emerge of freetype-2 actually could overwrite some of your freetype-1 files. Therefore it should not install freetype-2 with any command, if you have any version of freetype in package.provided. I disagree. A slotted package is practically two different packages that simply share the same name. If one slot is assumed as being provided, then that slot should have no effect on the other ones. You cannot provide a slot - you provide a package - freetype in this case. A slot is a gentoo specific thing. So is package.provided :-) Of course :) Point is, you provide a package from the outside world, you tell that portage via package.provided. In the outside world, there is no slot. So you cannot provide slots. With your argument, portage should not install *any* packages at all if there's even a single entry in package.provided, because it doesn't know what that package installs and therefore *any other* package could results in conflicts. Say, you had freetype-2.x in your package provided and for some reason you configured it to install to /usr/include/freetype, /usr/lib/freetype and so on. What should emerge do, if you now emerge freetype:1? Install it and overwrite your provided package? Yes. It should do exactly that. Because of lack of information, it should assume that I know what I'm doing. Fortunately, it does exactly that :-) The original point of my post is why it works with emerge foo-version but not with emerge foo:slot. Yes, it does that. In my opinion, that behaviour is not correct. I think, you are abusing package.provided for something, that should be handled by a local overlay with patched freetype-ebuilds. Best, Michael
[gentoo-user] Re: package.provided messes up emerging of package slots?
On 09/13/2011 01:26 AM, Michael Schreckenbauer wrote: On Tuesday, 13. September 2011 01:11:39 Nikos Chantziaras wrote: [...] You cannot provide a slot - you provide a package - freetype in this case. A slot is a gentoo specific thing. So is package.provided :-) Of course :) Point is, you provide a package from the outside world, you tell that portage via package.provided. In the outside world, there is no slot. So you cannot provide slots. I think Alan actually provided a more correct POV, namely that package.provided was never updated to consider slots. If in the outside world there are no slots, then portage shouldn't have introduced that feature in the first place. But it did, and the package.provided mechanism was never updated. Say, you had freetype-2.x in your package provided and for some reason you configured it to install to /usr/include/freetype, /usr/lib/freetype and so on. What should emerge do, if you now emerge freetype:1? Install it and overwrite your provided package? Yes. It should do exactly that. Because of lack of information, it should assume that I know what I'm doing. Fortunately, it does exactly that :-) The original point of my post is why it works with emerge foo-version but not with emerge foo:slot. Yes, it does that. In my opinion, that behaviour is not correct. I think, you are abusing package.provided for something, that should be handled by a local overlay with patched freetype-ebuilds. I'm pretty sure you know very well by now that forking the portage tree isn't a Gentooer's idea of a great time ;-) We use Gentoo's tools to their fullest in order to lower burden and overhead, not raise it. Forking my own ebuild means I need to maintain it; forever and ever. And stuff like that will keep piling up over time, leading to a big, magnificent pile of unmaintainable mess, leading to a bad experience and the question of I use Gentoo in the first place if all it will give me is annoyance and stress. On the other hand, if a single line in package.provided does the job just as well, oh hell, I'm going for that one instead.
Re: [gentoo-user] udev + /usr
On Mon, Sep 12, 2011 at 6:00 PM, Michael Schreckenbauer grim...@gmx.de wrote: On Monday, 12. September 2011 22:57:40 Alan McKinnon wrote: On Mon, 12 Sep 2011 16:07:46 -0400 Michael Mol mike...@gmail.com wrote: No, it states that it's not solveable for the broadest set of cases (I hesitate to say 'universally') unless you can run arbitrary scripts which may be in /usr. Consider it possible that nfsd is needed to mount /usr. The credentials needed for NFS to connect to the server are on an encrypted partition. The key for decrypting that partition is stored on a USB flash drive. The USB flash drive is formatted using a very recent version of NTFS. FUSE is necessary to read that flash drive's filesystem. You do realize what you just did, right? You ruined a wonderfully heated argument by inserting perfectly valid facts. I'd love to see the working initramfs for that scenario... and then the version dracut made :) Not my use case, so maybe wrong, but: USE=crypt crypt-gpg nfs emerge -v sys-kernel/dracut dracut -H -m crypt crypt-gpg nfs --filesystems fuse ...and maybe some -i flags to include the ntfs-3g binaries. 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] udev + /usr
On Tue, Sep 13, 2011 at 04:14:26AM +0700, Pandu Poluan wrote * Keep udev as it was before (i.e., living in / instead of in /usr) and somehow make sure that everyone RTFM/RTFFAQ, or * Make two versions of udev, one which lives in / for those who've done their homework, and another version in /usr for the ignoramuses Users of 'Technical Distros' like Gentoo can choose between root-udev or usr-udev, while 'Less Technical Distros' can just use usr-udev out-of-the-box. Gimmee an F FF Gimmee an O OO Gimmee an R RR Gimmee a K KK What does that spell? FORK What does that spell? FORK What does that spell? FORK Well come on all you big stronger coders Uncle UDEV is stinking up with nasty odors Got himself in a terrible jam Won't boot up without INIT RAM(fs) That's about all I can come up with on short notice... NSFW (Not Safe For Work) video, due to coarse language, search for Woodstock Cheer on YouTube. -- Walter Dnes waltd...@waltdnes.org
[gentoo-user] Keyboard hangs after wake up from hinernation
Hi, I run my IBM model M keyboard (1987 :) via a Belkin USB-PS2 converter. This results in a problem Sometimes after wakeup from supsend to disk (supend to RAM is not check yet) the keyboard hangs: All LEDs are flashing and not key is accepted. Power cycling via USB plug helps. I am using sys-power/hibernate-script for hibernation. I listed the usb-ohci as module wich gets unloaded/loaded while hibernation/wake-up in /etc/hibernate/common.conf which helps in most but not all cases. Since power cycling the keyboard help: Is there a way to do this via software/script when hibernate wakes the PC? Thank you very much in advance for any help! Best regards, mcc
[gentoo-user] Compose key and UTF8
Hi, I am using the US layout for my keyboard in the altgr-intlk variant. UTF8 is activated. Furthermore I use CAPS LOCK as compose key. I tried compose key sequences from /usr/share/X11/locale/en_US.UTF-8/Compose and many do work. So I think the basic mechanism is ok. But some came out as unfilled squares -- I think a glyph is missing here in the font. What is the best monospaced font to be used with UTF8 and which supports as many glyphs as possible? Thank you very much in advance for any help! Best regards, mcc
Re: [gentoo-user] udev + /usr
On Monday 12 September 2011 21:31:09 Alan Mackenzie wrote: They could have put everything on /usr 30 years ago, if they'd have seen fit. They saw then good reason not to. What you and KS seem oblivious to is the reason for /bin, /sbin. It is to allow a small boot so as to permit system maintenance - fsck, resizing or moving partions, even undeleting files - all these things are difficult, or even impossible perhaps, if the pertinent partition is mounted. It wouldn't be everyone's favourite method, but for those purposes I always install a small rescue system at the end of the the disk, with its own entry in grub.conf, and with fstab and mount points arranged for convenient maintenance. And nowadays, of course, the ready availability of rescue systems on USB, CD etc saves you even having to set that up if you prefer not to. That might not be useful on server farms, though. -- Rgds Peter Linux Counter 5290, 1994-04-23
Re: [gentoo-user] udev + /usr
On Mon, Sep 12, 2011 at 02:37:24PM -0400, Canek Pel??ez Vald??s wrote No fixable, in reality. The flexibility of udev is in part in that the userspace can (and actually do) run arbitrary scripts and binaries from udev rules. You can fix the ones that require binaries in /usr *NOW*, but not forever, unless you forbid the use of arbitrary binaries from udev rules. No the problem is that I don't think we should force 100% of all users to migrate to initramfs or a Windows-like C:\ simply to satisfy the 1% that run into problems with the current udev. Let *THOSE* users migrate to initramfs or a Windows-like C:\. And then you lose the flexibility. And then *I* lose the flexibility of a small / *WITHOUT* initramfs. [i3][root][/] fdisk -l shows Device Boot Start End Blocks Id System /dev/sda1 63 1953520064 9767600015 Extended /dev/sda5 126 530144 265009+ 83 Linux /dev/sda6 53020819422584 9446188+ 82 Linux swap / Solaris /dev/sda719422648 1953520064 967048708+ 83 Linux Some lines from /etc/fstab /dev/sda5 / ext2 noatime,nodiratime,async 0 1 /dev/sda7 /home reiserfs noatime,nodiratime,async,notail 0 1 /home/bindmounts/opt/opt auto bind 0 0 /home/bindmounts/var/var auto bind 0 0 /home/bindmounts/usr/usr auto bind 0 0 /home/bindmounts/tmp/tmp auto bind 0 0 /dev/sda6 none swap sw 0 0 [i3][root][/] du -cs /usr 5664646 /usr 5664646 total And yeah, that's not how classical Unix do things. Who cares? Linux does it so much better. And yeah, that's not how classical Gentoo does things. Who cares? Distro X does it so much better. /SARCASM Guess what, if I really wanted to run Distro X, I'd be running Distro X. And for those that claim /var would never be needed early, what if somebody's weirdo setup wants a network connection early? I assume they'd want the firewall to be up when the network goes up. Ever heard of /var/lib/iptables/rules-save ? -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-user] [off-topic] - can /var be placed in a separate partition?
On Monday 12 Sep 2011 13:11:51 Mike Edenfield wrote: On 9/11/2011 8:28 PM, Albert W. Hopkins wrote: On Sunday, September 11 at 18:54 (-0500), Dale said: I think I saw it mentioned on -dev that some time shortly /usr and /var will be needed on / or you will need the init* thingy to boot. Hmm, that doesn't smell right to me. What I think you may have heard is about /run. systemd and some other things are preferring to move /var/run to /run. The reason being is that /var does not have to be on the root fs. sysdemd needs /run early (before mounting filesystems) so the idea was to put /var/run on the rootfs, thus /run. I don't think /usr should or ever will be required to be on the rootfs. That's just dumb. The reason we have /bin /sbin, etc. is so that /usr need not be on the rootfs. It doesn't make sense to change that well known/established notion. Nope, Dale is exactly correct. If the upcoming changes to udev make it into Gentoo unaltered and unscathed, it will become necessary to have essentially your full system available very early in the boot process -- at least as early as when udev runs. This includes /usr, where I believe the udev scripts and libraries are being moved, and anything that any program in those scripts might access, which almost definitely includes /var. Any setup where only / is mounted when udev's device population happens will become unsupported (if not impossible). The proposed alternative to a single huge partition is to use an initramfs that mounts your separate /usr (and /var) very early in the boot process. No! This is throwing a major spanner on all my boxen! Agh! :@ There's a lot of Gentoo users and I would imagine other Linux users who do not use initr* and still have a separate /var (because of logs, or mail, or news, or PORTAGE_TMPDIR, etc.). I seriously hope that a Gentoo specific fix comes out soon and Fedora and their devs can carry on this way. This M$Windows 'solution' looks more and more like major bad programming and is getting really really stupid! /rant -- Regards, Mick signature.asc Description: This is a digitally signed message part.
