Re: [gentoo-user] merge-usr and lib[ow]crypt*
--- Original message --- From: Matthias Hanft To: gentoo-user@lists.gentoo.org Date: Mon, 15 Apr 2024 10:14:18 +0200 Hi, after updating the kernels to the latest stable version (6.6.21) and updating the profiles from 17.1 to 23.0, the last update step would be "merge-usr" as described at https://wiki.gentoo.org/wiki/Merge-usr in order to have complete up-to-date systems. But my two (nearly identical) systems generate different output when running "merge-usr --dryrun": Dry run on system 1 (a bit older than system 2) shows: INFO: Migrating files from '/bin' to '/usr/bin' INFO: Skipping symlink '/bin/awk'; '/usr/bin/awk' already exists INFO: No problems found for '/bin' INFO: Migrating files from '/sbin' to '/usr/bin' INFO: No problems found for '/sbin' INFO: Migrating files from '/usr/sbin' to '/usr/bin' INFO: No problems found for '/usr/sbin' INFO: Migrating files from '/lib' to '/usr/lib' INFO: No problems found for '/lib' INFO: Migrating files from '/lib64' to '/usr/lib64' INFO: No problems found for '/lib64' So this seems OK? The "awk thing" is a symbolic link anyway: home01 ~ # ls -l /bin/awk lrwxrwxrwx 1 root root 14 Dec 31 2022 /bin/awk -> ../usr/bin/awk home01 ~ # ls -l /usr/bin/awk lrwxrwxrwx 1 root root 4 Dec 31 2022 /usr/bin/awk -> gawk home01 ~ # ls -l /usr/bin/gawk -rwxr-xr-x 1 root root 682216 Feb 10 09:59 /usr/bin/gawk But the dry run on system 2 (a bit newer than system 1) shows: INFO: Migrating files from '/bin' to '/usr/bin' INFO: Skipping symlink '/bin/awk'; '/usr/bin/awk' already exists INFO: No problems found for '/bin' INFO: Migrating files from '/sbin' to '/usr/bin' INFO: No problems found for '/sbin' INFO: Migrating files from '/usr/sbin' to '/usr/bin' INFO: No problems found for '/usr/sbin' INFO: Migrating files from '/lib' to '/usr/lib' INFO: Skipping symlink '/lib/libcrypt.so.2'; '/usr/lib/libcrypt.so.2' already exists INFO: No problems found for '/lib' INFO: Migrating files from '/lib64' to '/usr/lib64' INFO: Skipping symlink '/lib64/libcrypt.so.2'; '/usr/lib64/libcrypt.so.2' already exists INFO: No problems found for '/lib64' Since the messages are "INFO" (and not "WARNING" or "ERROR"), I guess it's OK, too. But looking for "libcrypt*" is somewhat confusing: n ~ # ls -l /lib/libcrypt* lrwxrwxrwx 1 root root 17 Apr 14 23:39 /lib/libcrypt.so.1 -> libcrypt.so.1.1.0 -rwxr-xr-x 1 root root 218416 Apr 14 23:39 /lib/libcrypt.so.1.1.0 lrwxrwxrwx 1 root root 17 Apr 14 23:39 /lib/libcrypt.so.2 -> libcrypt.so.2.0.0 -rwxr-xr-x 1 root root 214320 Apr 14 23:39 /lib/libcrypt.so.2.0.0 n ~ # ls -l /usr/lib/libcrypt* lrwxrwxrwx 1 root root 27 Apr 14 23:39 /usr/lib/libcrypt.so -> ../../lib/libcrypt.so.2.0.0 lrwxrwxrwx 1 root root 13 Dec 8 2022 /usr/lib/libcrypt.so.2 -> libowcrypt.so n ~ # ls -l /usr/lib/libowcrypt* lrwxrwxrwx 1 root root 27 Apr 14 23:39 /usr/lib/libowcrypt.so -> ../../lib/libcrypt.so.2.0.0 On system 1, it's a bit more simple: home01 ~ # ls -l /lib/libcrypt* lrwxrwxrwx 1 root root 17 Sep 12 2023 /lib/libcrypt.so.1 -> libcrypt.so.1.1.0 -rwxr-xr-x 1 root root 218368 Sep 12 2023 /lib/libcrypt.so.1.1.0 lrwxrwxrwx 1 root root 17 Sep 12 2023 /lib/libcrypt.so.2 -> libcrypt.so.2.0.0 -rwxr-xr-x 1 root root 218368 Sep 12 2023 /lib/libcrypt.so.2.0.0 home01 ~ # ls -l /usr/lib/libcrypt* lrwxrwxrwx 1 root root 27 Sep 12 2023 /usr/lib/libcrypt.so -> ../../lib/libcrypt.so.2.0.0 (The same for "lib64" instead of "lib".) Could the symbolic links from "/usr/lib" to "../../lib" be a kind of circular references? And what is "libowcrypt" on system 2 - and why doesn't it appear on system 1? Is it safe to run "merge-usr" on both systems? If you only see INFO lines, it's safe to run "merge-usr". If you see anything else, you need to fix that first. -- Joost
Re: [gentoo-user] USE flags handling
On Saturday 02 August 2014 16:13:19 Stroller wrote: On Sat, 2 August 2014, at 2:35 pm, J. Roeleveld jo...@antarean.org wrote: ... Do you still have the bug numbers for this? I have a few machines without any sound support. If I can remove the entire sound system from it, it would save time during the updates. Please, Joost, I beg you, stop posting in HTML. Also your email is broken, I already asked you this yesterday off-list - since you neither complied then, nor told me to naff off, I assume that you're dropping messages. Actually, I wasn't ignoring you. It just took some time to find the actual cause. In the settings for KMail, I had the tick-boxes mentioning HTML off already. Took me till this morning to notice that in the edit-window, Rich Text was selected. (It acts like a button that is pushed in) If anyone can tell me how to configure that to *always* default to *off*, instead of remembering the last setting, that would help. -- Joost
Re: [gentoo-user] Re: USE flags handling
On Sunday 03 August 2014 00:38:34 Philip Webb wrote: 140802 Walter Dnes wrote: In Gentoo, *ANY* kde app which runs on the kde infrastructure requires phonon, and one of aqua/gstreamer/vlc, unless you resort to ugly hackery as per http://permalink.gmane.org/gmane.linux.gentoo.user/276393 So don't blame KDE, blame Gentoo for not handling Phonon correctly : see KDE bug 190601 Gentoo bug 265864 . +1 Had a look myself just now based on your other comments. KDE actually specifies how to build without any multimedia (audio and video) support: https://techbase.kde.org/Development/Tutorials/CMake#Command_Line_Variables cmake command line variable: KDE4_DISABLE_MULTIMEDIA=ON: Build KDE without any multimedia (audio and video) support. -- Joost
Re: [gentoo-user] Re: Recommendations for scheduler
On Saturday 02 August 2014 16:53:26 James wrote: Alan McKinnon alan.mckinnon at gmail.com writes: Well, we've found 2 projects that at least in part seek to achieve our general goals - chronos and Martin's new project. Why don't we both fool around with them for a bit and get a sense of what it will take to add features etc? Then we can meet back here and discuss. Always better to build on an existing foundation Mesos looks promising for a variety of (Apache) reasons. Some key technologies folks may want google about that are related: Quincy (fair schedular) Chronos (scheduler) Hadoop (scheduler) Hadoop not a scheduler. It's a framework for a Big Data clustered database. HDFS (clusterd file system) Unless it's changed recently, not suitable for anything else then Hadoop and contains a single point of failure. http://gpo.zugaina.org/sys-cluster/apache-hadoop-common Zookeeper (Fault tolerance) SPARK ( optimized for interative jobs where a datase is resued in many parallel operations (advanced math/science and many other apps.) https://spark.apache.org/ Dryad Torque Mpiche2 MPI Globus tookit mesos_tech_report.pdf It looks as though Amazon, google, facebook and many others large in the Cluster/Cloud arena are using Mesos..? So let's all post what we find, particularly in overlays. Unless you are dealing with Big Data projects, like Google, Facebook, Amazon, big banks,... you don't have much use for those projects. Mesos looks like a nice project, just like Hadoop and related are also nice. But for most people, they are as usefull as using Exalytics. A scheduler should not have a large set of dependencies that you wouldn't use otherwise. That makes Chronos a non-option to me. Martin's project looks promising, but doesn't store the schedules internally. For repeating schedules, like what Alan was describing, you need to put those into scripts and start those from an existing cron. Of the 2, I think improving Martin's project is the most likely option for me as it doesn't have additional dependencies and seems to be easily implemented. -- Joost
Re: [gentoo-user] Re: USE flags handling
On Wednesday 30 July 2014 20:26:48 Alan McKinnon wrote: On 30/07/2014 20:02, Volker Armin Hemmann wrote: This 'de-bloat' crap - who came up with that? People who use it all the times seldomly realize that the 'small and unbloated' software they use is in a lot of cases neither small, nor not bloated. Usually it comes from the same headspace that ricing comes from. Humans are all about perception, very very very few of them can actually look at things in an unbiased way. So it goes like this: User hates Gnome. [opinion] User decides that because Gnome integrates so many things vertically then Gnome must necessarily be bloated. [invalid conclusion not backed up by facts] User decides to try Razor|LXDE|Enlightenment|*box|whatever [valid activity] User likes whatever [opinion] User concludes that whatever is therefore better than Gnome [erronously equate specific opinion with fact for the general case] Therefore whatever is not bloated and Gnome is, to satisfy wrong conclusion at #2 [I can't even begin to think what fallacy this is] Not much opinion in any of that. We humans are mostly hard-wired to react based on past experience and data blindly accepted as fact in the past. 9 times out of 10 this helps you leap out of the way of the tiger seeking to have you for lunch. You got this ability from dad's genes and it must be raising the odds for you and he otherwise he wouldn't have survived long enough to sire you. If you stop to think about the tiger, he is for sure going to have a nice lunch. So we humans that survived did so by jumping to conclusions and having them work out OK on average. This new-fangled idea of actually thinking about things all the way through is a very new idea, and most of the species hasn't gotten the hang of it yet. This does still seem to be a valid survival requirement for a large part of the worlds population though, including where you are. For people living in a so-called civilized world, tigers are only found inside places commonly called a zoo :) So now you know why ricers swear blind that -pipe in CFLAGS *doubles* the running speed, dude! It does! I enabled -pipe in my CFLAGS and all the software was running a lot faster on my new machine compared to my old one ;) -- Joost
Re: [gentoo-user] [Less OT] Tally ho! - RC Flight Sims on Linux
On Monday 30 June 2014 01:26:48 waben...@gmail.com wrote: Am Sonntag, 29.06.2014 um 16:26 schrieb Dale rdalek1...@gmail.com: waben...@gmail.com wrote: Am Sonntag, 29.06.2014 um 20:38 schrieb Neil Bothwick n...@digimed.co.uk: On Sun, 29 Jun 2014 21:29:56 +0200, Alan McKinnon wrote: Please folks, stop that crap. It has nothing to do with gentoo or computers at all. If you wanna discuss the delightfulness of war machines then please to this at another place and not on this list. Allow me to introduce your to my good friend Delete and his lovely wife button Or you could filter anything with OT in the subject to /dev/null. It's not like this thread is masquerading as something relevant. That's not the point. If you wanna talk about stuff that's apparently absolut useless to almost every member of this ML, then you should do this at another place. Especially discussions with politically and or military background are IMHO absolutely inappropriate. But hey, maybe I'm wrong. Why shouldn't we talk here about everything that cross one's mind? We could mark it as OT in the subject line, so it should be no problem for everyone. Maybe we should discuss the local daily weather? I think, that's a pretty good idea as it would increase the noise level of this list even more. What do you think? Just a FYI. I have in the past asked questions about Windoze XP on this very list. Why, I'm not joining a windoze mailing list for just one question and I know a lot of people on this list know about windoze as well. I have seen other topics raised on this list before. It's not often but it does happen. I see Gentoo threads that don't interest me at all and I just mark them as read and move right along but I don't tell folks that I don't want to see them. I could start with systemd. If I see systemd in the subject, I mark it read and move right along usually without reading even the first post. Why, I don't use systemd so I am certainly not interested in it. There are other threads that I do the same thing with. That's right. But all examples you've mentioned are computer related topics and maybe useful for anyone on this list. We can turn this into a computer related thread. Anyone know of a way to get a flight-sim (for model planes) to run on Linux? I have a legit copy of Realflight ( http://www.realflight.com ) and occasionally have to boot into a legit copy (yes, all my software is 100% legit) of MS Windows. Ideas welcome. -- Joost
Re: [gentoo-user] mount.nfs stale nfs handle
On Sunday 29 June 2014 22:48:32 Alexander Puchmayr wrote: Am Sonntag, 29. Juni 2014, 20:41:55 schrieb Neil Bothwick: On Sun, 29 Jun 2014 21:34:07 +0200, Alexander Puchmayr wrote: After upgrading my server to latest stable release of gentoo, none of my clients is able to mount any nfs share from the server anymore. [snip] Server has kernel version 3.12.21-gentoo-r1and net-fs/nfs-utils-1.2.9 installed. As both clients and server are not accessable from outside, no firewalls are installed. That's not the latest nfs-utils in stable, it is 1.2.9-r3. This morning it was masked; OK, emerge --sync emerge nfs-utils. After restarting all nfs relevant services it is still the same :-( Just to confirm, did you update nfs-utils on both systems? -- Joost
Re: [gentoo-user] mount.nfs stale nfs handle
On Sunday 29 June 2014 21:34:07 Alexander Puchmayr wrote: Hi there, After upgrading my server to latest stable release of gentoo, none of my clients is able to mount any nfs share from the server anymore. Symptoms: $ mount -v -t nfs poseidon:/datadisk/ /mnt/gentoo/ mount.nfs: timeout set for Sun Jun 29 19:33:40 2014 mount.nfs: trying text-based options 'vers=4,addr=192.168.1.6,clientaddr=192.168.1.2' mount.nfs: mount(2): Protocol not supported mount.nfs: trying text-based options 'addr=192.168.1.6' mount.nfs: prog 13, trying vers=3, prot=6 mount.nfs: trying 192.168.1.6 prog 13 vers 3 prot TCP port 2049 mount.nfs: prog 15, trying vers=3, prot=17 mount.nfs: trying 192.168.1.6 prog 15 vers 3 prot UDP port 60058 mount.nfs: mount(2): Stale NFS file handle mount.nfs: trying text-based options 'vers=4,addr=192.168.1.6,clientaddr=192.168.1.2' mount.nfs: mount(2): Protocol not supported mount.nfs: trying text-based options 'addr=192.168.1.6' mount.nfs: prog 13, trying vers=3, prot=6 mount.nfs: trying 192.168.1.6 prog 13 vers 3 prot TCP port 2049 mount.nfs: prog 15, trying vers=3, prot=17 mount.nfs: trying 192.168.1.6 prog 15 vers 3 prot UDP port 60058 mount.nfs: mount(2): Stale NFS file handle [...] mount.nfs: Connection timed out $ [Poseidon is my server at 192.168.1.6, the client is at 192.168.1.2] Server disk to be exported is a ~9TB raid array with XFS. I'm using nfs3 with ACL and no idmapd; nfs4+ is not compiled into kernel (neither on client nor on server); Why it is trying nfs4 first as seen in the log above I don't know. nfs-utils has been compiled with USE=-nfsv4 Server has kernel version 3.12.21-gentoo-r1and net-fs/nfs-utils-1.2.9 installed. As both clients and server are not accessable from outside, no firewalls are installed. What I checked: /etc/exports: /datadisk 192.168.1.0/24(rw,async,subtree_check) portmapper, nfs-services are running normal, as far I can see. Does anyone have any suggestion? I have this occasionally due to the backup system I am using: - stop the nfs export - umount the filesystem - take LVM snapshot - remound filesystem - re-enable the nfs export When that happens, I run the following on the server: # exportfs -au sleep 1 mount -a sleep 1 exportfs -r The sleeps are necessary, without them, it doesn't always work. -- Joost
Re: [gentoo-user] [Less OT] Tally ho! - RC Flight Sims on Linux
On Monday 30 June 2014 15:40:02 microcai wrote: 在 2014年6月30日 星期一 09:17:02，Joost Roeleveld 写道： On Monday 30 June 2014 01:26:48 waben...@gmail.com wrote: Am Sonntag, 29.06.2014 um 16:26 schrieb Dale rdalek1...@gmail.com: waben...@gmail.com wrote: Am Sonntag, 29.06.2014 um 20:38 schrieb Neil Bothwick n...@digimed.co.uk: On Sun, 29 Jun 2014 21:29:56 +0200, Alan McKinnon wrote: Please folks, stop that crap. It has nothing to do with gentoo or computers at all. If you wanna discuss the delightfulness of war machines then please to this at another place and not on this list. Allow me to introduce your to my good friend Delete and his lovely wife button Or you could filter anything with OT in the subject to /dev/null. It's not like this thread is masquerading as something relevant. That's not the point. If you wanna talk about stuff that's apparently absolut useless to almost every member of this ML, then you should do this at another place. Especially discussions with politically and or military background are IMHO absolutely inappropriate. But hey, maybe I'm wrong. Why shouldn't we talk here about everything that cross one's mind? We could mark it as OT in the subject line, so it should be no problem for everyone. Maybe we should discuss the local daily weather? I think, that's a pretty good idea as it would increase the noise level of this list even more. What do you think? Just a FYI. I have in the past asked questions about Windoze XP on this very list. Why, I'm not joining a windoze mailing list for just one question and I know a lot of people on this list know about windoze as well. I have seen other topics raised on this list before. It's not often but it does happen. I see Gentoo threads that don't interest me at all and I just mark them as read and move right along but I don't tell folks that I don't want to see them. I could start with systemd. If I see systemd in the subject, I mark it read and move right along usually without reading even the first post. Why, I don't use systemd so I am certainly not interested in it. There are other threads that I do the same thing with. That's right. But all examples you've mentioned are computer related topics and maybe useful for anyone on this list. We can turn this into a computer related thread. Anyone know of a way to get a flight-sim (for model planes) to run on Linux? I have a legit copy of Realflight ( http://www.realflight.com ) and occasionally have to boot into a legit copy (yes, all my software is 100% legit) of MS Windows. X-plane ? Not what I'm looking for. That simulates 1:1 scale planes (full size). I am talking about one I can use to practice flying without risking my real planes on the first attempt. I need one where I can use my own transmitter connected to the computer. There are cables to hook them up to the USB-port. But the problem is finding a decent one that actually runs on Linux. All the commercial ones I can find are MS Windows only. -- Joost
Re: [gentoo-user] [Less OT] Tally ho! - RC Flight Sims on Linux
On Monday 30 June 2014 03:56:44 Dale wrote:
Joost Roeleveld wrote:
On Monday 30 June 2014 15:40:02 microcai wrote:
在 2014年6月30日 星期一 09:17:02，Joost Roeleveld 写道：
We can turn this into a computer related thread.
Anyone know of a way to get a flight-sim (for model planes) to run on
Linux?
I have a legit copy of Realflight ( http://www.realflight.com ) and
occasionally have to boot into a legit copy (yes, all my software is
100%
legit) of MS Windows.
X-plane ?
Not what I'm looking for.
That simulates 1:1 scale planes (full size).
I am talking about one I can use to practice flying without risking my
real
planes on the first attempt. I need one where I can use my own transmitter
connected to the computer. There are cables to hook them up to the
USB-port.
But the problem is finding a decent one that actually runs on Linux. All
the commercial ones I can find are MS Windows only.
--
Joost
Don't forget, there was a guitar that ran Gentoo Linux too.
I remember that one, still wondering about the point though, but that's just me
:)
Heck, did
plane engines have puters even back then? I know they do now, at least
according to all the stuff I see on TV. I don't think puter stuff
started until like in the 80's or something tho.
They had computers during WWII, they used them to break the german encryption.
They appeared in planes not too long after:
See: http://en.wikipedia.org/wiki/Fly-by-wire
***
The first non-experimental aircraft that was designed and flown (in 1958) with
a fly-by-
wire flight control system was the Avro Canada CF-105 Arrow[1],^{[5][2][6][3]}
a feat
not repeated with a production aircraft until Concorde[4] in 1969. This system
also
included solid-state components and system redundancy, was designed to be
integrated with a computerised navigation and automatic search and track radar,
was
flyable from ground control with data uplink and downlink, and provided
artificial feel
(feedback) to the pilot.
***
Also:
https://airandspace.si.edu/exhibitions/america-by-air/online/jetage/jetage17.cfm
***
The first autopilots were used on airliners in the mid-1930s. In the late
1950s,
electronic computers became small enough to be used aboard aircraft.
Sophisticated
digital computers can now fly aircraft in virtually any situation, while
ensuring that all
systems are functioning properly.
***
M$ Windoze. Yuck! I wouldn't put that stuff on my rig.
I do, for a few programs that aren't available on Linux (yet).
The flightsim for RC model planes is one of them.
--
Joost
[1] http://en.wikipedia.org/wiki/Avro_Canada_CF-105_Arrow
[2] http://en.wikipedia.org/wiki/Fly-by-wire#cite_note-5
[3] http://en.wikipedia.org/wiki/Fly-by-wire#cite_note-Whitcomb-6
[4] http://en.wikipedia.org/wiki/Concorde
Re: [gentoo-user] [Way OT] Tally ho!
On Monday 30 June 2014 10:22:42 Peter Humphrey wrote: On Sunday 29 June 2014 11:38:11 Dale wrote: Peter Humphrey wrote: I don't know when we'll get the Hurricane one - the man with the camera just put a two-word entry on Twitter this morning: Hashtag HEADACHE Oooops. Here's the Hurricane: https://www.facebook.com/photo.php?v=880028802011336 From the unsteadiness of the camera, I think Phil must have started the headache inducement before shooting this :-( The unsteadiness comes from trying to keep up with a fast moving object without stabilizers. Have you seen the type of contraptions used for movies? Taken from the top of the church tower at 2:15 on Saturday. You can hear some of the bells chiming the quarter-hour at the beginning. I'll stop now. Don't stop on my account ;) -- Joost
Re: [gentoo-user] [Less OT] Tally ho! - RC Flight Sims on Linux
On Monday 30 June 2014 11:51:08 Alan McKinnon wrote: On 30/06/2014 09:40, microcai wrote: 在 2014年6月30日 星期一 09:17:02，Joost Roeleveld 写道： On Monday 30 June 2014 01:26:48 waben...@gmail.com wrote: [snip] That's right. But all examples you've mentioned are computer related topics and maybe useful for anyone on this list. We can turn this into a computer related thread. Anyone know of a way to get a flight-sim (for model planes) to run on Linux? I have a legit copy of Realflight ( http://www.realflight.com ) and occasionally have to boot into a legit copy (yes, all my software is 100% legit) of MS Windows. X-plane ? wine? I try that once every few months, not been one that works yet. Problem is the copy-protection with the one I use. The CD needs to be in the drive for it to work. -- Joost
Re: [gentoo-user] [Less OT] Tally ho! - RC Flight Sims on Linux
On Monday 30 June 2014 12:09:16 Alan McKinnon wrote: On 30/06/2014 12:01, Joost Roeleveld wrote: On Monday 30 June 2014 11:51:08 Alan McKinnon wrote: On 30/06/2014 09:40, microcai wrote: 在 2014年6月30日 星期一 09:17:02，Joost Roeleveld 写道： On Monday 30 June 2014 01:26:48 waben...@gmail.com wrote: [snip] That's right. But all examples you've mentioned are computer related topics and maybe useful for anyone on this list. We can turn this into a computer related thread. Anyone know of a way to get a flight-sim (for model planes) to run on Linux? I have a legit copy of Realflight ( http://www.realflight.com ) and occasionally have to boot into a legit copy (yes, all my software is 100% legit) of MS Windows. X-plane ? wine? I try that once every few months, not been one that works yet. Problem is the copy-protection with the one I use. The CD needs to be in the drive for it to work. Can you fudge it using a ripped .iso of the CD and loop mounting it somewhere? Would work in Linux, I guess. But even with the disk in the drive, it didn't work last time I tried it. It is time for a new try though. But my preference would be something native. -- Joost
Re: [gentoo-user] [Less OT] Tally ho! - RC Flight Sims on Linux
On Monday 30 June 2014 05:23:31 Dale wrote: Alan McKinnon wrote: On 30/06/2014 09:40, microcai wrote: X-plane ? wine? Sorry, I don't drink. ROFL What about the alcohol free version? Also known as grape juice...
Re: [gentoo-user] Backups and snapshots [Was: Organising btrfs subvolumes]
On Tuesday 27 May 2014 23:35:26 Alan McKinnon wrote: On 27/05/2014 17:12, J. Roeleveld wrote: I have a yearly (full), monthly, weekly and daily. Each incremental is against the most recent one of itself or longer period. That means having to keep multiple snapshots active, which I prefer to avoid. But, it is a good idea for backing up desktops and laptops. I'm curious why you have yearly snapshots. I've yet to find any sane production system where a yearly backup had any worth at all. Even monthly is pushing it... Or do you do it to have a decent start point for incrementals? It's to have a decent start point for incrementals. Below are the 2 biggest shares on the NAS: /dev/xvda17 7.1T 5.9T 1.2T 84% /data/unsorted /dev/xvda16 3.0T 2.4T 517G 83% /data/software It is impossible to do a full backup on a daily or even weekly basis. Previously, I had 1 full backup and then a daily incremental. This appears like a good idea, untill you need to restore the filesystem from backups when the crash occured 2 years later. That is 1 full backup and over 700 incrementals Currently, I do the following: Every year, a full backup Then, every month, I have an incremental based on either the yearly or previous monthly. Ditto for the weekly (but then based on monthly or weekly) And again for the daily. -- Joost
Re: [gentoo-user] Backups and snapshots [Was: Organising btrfs subvolumes]
On Tuesday 27 May 2014 11:32:22 Rich Freeman wrote: On Tue, May 27, 2014 at 11:21 AM, J. Roeleveld jo...@antarean.org wrote: Does anyone know how these will handle (and perform) with a possible 300+ snapshots per filesystem (or volume, as I think it's called)? I can't speak for zfs. I had upwards of 1000 snapshots on my system before I stopped creating them hourly and and just started having issues with it. Ok, it can handle my backup schedule then. :) I wouldn't really say it is ready for prime time, but it is workable. Of course, you'll still want backups - a million snapshots does you no good if some bug wipes out your filesystem. For one of my ENOSPC incidents I ended up just wiping the entire filesystem and restoring from backup, though if I kept at it I'd probably have been able to fix it. Agreed, this is why the backup system would be adjusted for BTRFS on the fileserver, when I get round to it. I would probably keep snapshots active for the past 2 weeks. Oh, one other tip if you use btrfs - be sure you have a rescue disk that supports it. Hint, the old Gentoo install CD I had lying around didn't. You'll probably want to keep a rescue CD with a recent kernel and btrfs-tools handy at all times. Always important. I just saw the other email which states that the latest sysresccd supports it. That is fine for me. -- Joost
Re: [gentoo-user] Backups and snapshots [Was: Organising btrfs subvolumes]
On Tuesday 27 May 2014 11:28:17 Rich Freeman wrote: On Tue, May 27, 2014 at 11:12 AM, J. Roeleveld jo...@antarean.org wrote: On Tuesday, May 27, 2014 10:31:26 AM Rich Freeman wrote: btrfs wouldn't have any issues with this at all. You'd have an advantage in that you wouldn't have to unmount the filesystem to cleanly create the snapshot (which you have to do with lvm). That, or a sync prior to creating the snapshot. :) If the filesystem is still mounted, I'm not sure that a sync is guaranteed to give you a clean remount. It only flushes the caches/etc. You need to remount read-only or unmount before doing the sync (and the sync probably isn't actually necessary as I'd think LVM would snapshot the contents of the cache as well). I do this for the OS-partitions of my VMs. In the VM, run sync, then on the host, take an LVM snapshot and then mount the snapshot on the host. I have not had any errors from this. I have a yearly (full), monthly, weekly and daily. Each incremental is against the most recent one of itself or longer period. That means having to keep multiple snapshots active, which I prefer to avoid. You only need to store snapshots for use with incremental backups. So, if all your backups are full, then you don't need to retain any snapshots (and you wouldn't use btrfs send anyway). If your yearly is full and your monthlies are incremental against the yearly then you need to keep your yearly snapshot for a year. If your yearly is full and your monthlies are incremental against the last month, then you only need to keep the yearly until the next monthly. If your monthlies are full then you only need to keep the current monthly assuming your dailies are incremental against those, but if they're incremental from the last daily then you never need to keep anything for more than a day. That makes for an interesting option. Not sure if I would implement it that way. But, it is a good idea for backing up desktops and laptops. It is really intended more for something like datacenter replication. Snapshot every 5 min, send the data to the backup datacenter, delete the snapshots upon confirmation of successful receipt. In such a scenario you wouldn't retain the sent files but just keep playing them against the replicate filesystem. They'd be fine for backups as well, as long as you can store the snapshots online until no longer needed for incrementals. app-backup/dar uses catalogues for the incrementals. I think I will stick to that for the foreseeable future. But, you can always just create a snapshot, write it to backup with your favorite tool (it is just a directory tree), and then remove it as soon as you're done with it. Creating a snapshot is atomic at the filesystem level, though again if you want application level consistency you need to deal with that until somebody comes up with a transactional way to store files on Linux that is more elegant that fsyncing on every write. That would require a method to keep database and filesystem perfectly in sync when they are not necessarily on the same machine. Well, right now we can't even guarantee consistency when everything is written by a single process on the same machine. The best we have is a clunky fsync operation which kills the write cache and destroys performance, and even that doesn't do anything if you have more than one file that must be consistent. Yep, and that's why those filesystems are actually umounted prior to creating the LVM snapshot. Umounting forces the filesystem to be put into a consistent state. The result is journals on top of journals as nobody can trust the next layer down to do its job correctly. Going across machines does complicate things further as there are more failure modes that take out one part of the overall system but not another. However, I'd like to think that an OS that natively supports transactions could at least standardize things so that every layer along the path isn't storing its own journal. In fact, many of the optimizations possible with zfs and btrfs are due to the fact that you eliminate all those layers. Either of those 2, probably btrfs as I prefer native support in the kernel, will be implemented when I get the opportunity to get the NAS on bare metal and remove the virtualization for that component. I need to find a different host for the other services first. That might take a while. -- Joost
Re: [gentoo-user] Backups and snapshots [Was: Organising btrfs subvolumes]
On Wednesday 28 May 2014 13:07:49 Alan McKinnon wrote: On 28/05/2014 11:58, Joost Roeleveld wrote: On Tuesday 27 May 2014 23:35:26 Alan McKinnon wrote: On 27/05/2014 17:12, J. Roeleveld wrote: I have a yearly (full), monthly, weekly and daily. Each incremental is against the most recent one of itself or longer period. That means having to keep multiple snapshots active, which I prefer to avoid. But, it is a good idea for backing up desktops and laptops. I'm curious why you have yearly snapshots. I've yet to find any sane production system where a yearly backup had any worth at all. Even monthly is pushing it... Or do you do it to have a decent start point for incrementals? It's to have a decent start point for incrementals. Below are the 2 biggest shares on the NAS: /dev/xvda17 7.1T 5.9T 1.2T 84% /data/unsorted /dev/xvda16 3.0T 2.4T 517G 83% /data/software It is impossible to do a full backup on a daily or even weekly basis. Previously, I had 1 full backup and then a daily incremental. This appears like a good idea, untill you need to restore the filesystem from backups when the crash occured 2 years later. That is 1 full backup and over 700 incrementals Currently, I do the following: Every year, a full backup Then, every month, I have an incremental based on either the yearly or previous monthly. Ditto for the weekly (but then based on monthly or weekly) And again for the daily. OK, that makes sense. It reminds me of an issue my wife had with the data warehouse when she worked at the bank. In a nutshell, they needed backups but backups were impossible to achieve because physics says so. They needed to get data off the disk 4 times faster than data comes off a disk - SCSI limits being rather hard limits :-) That opinion didn't go down well when I offered it Haha :) I know the feeling. I'd love to know the final solution they came up with. The solution was to do it much like your plan above. With the benefit that the infrequent full backups would be done on a fixed schedule in a change window with X hours downtime that was known well in advance. Using snapshots, the downtime is the same couple of minutes each night. The problem is that during the backup, the performance of the server is impacted. For a full backup, that means weeks... -- Joost
Re: [gentoo-user] cpufrequtils can't find expected /sys/devices/system/cpu/cpufreq
On Thursday 24 April 2014 10:13:39 Neil Bothwick wrote:
On Thu, 24 Apr 2014 02:27:05 -0400, Walter Dnes wrote:
[aa1][root][/usr/src/linux] /etc/init.d/cpufrequtils start
* Caching service dependencies ... [ ok ]
* Running cpufreq-set --governor conservative -- ...
/usr/libexec/cpufrequtils-change.sh: line 26: cd:
/sys/devices/system/cpu/cpufreq: No such file or directory [ !! ]
* ERROR: cpufrequtils failed to start
I get a similar message, it appears to be looking in the wrong place.
/sys/devices/system/cpu/cpufreq does not exist but
/sys/devices/system/cpu/cpu{0..3}/cpufreq do
Strange, on my system it does exist:
# ls -lsa /sys/devices/system/cpu/cpufreq*
total 0
0 drwxr-xr-x 2 root root0 Apr 24 11:19 .
0 drwxr-xr-x 10 root root0 Apr 24 07:06 ..
0 -r--r--r-- 1 root root 4096 Apr 24 11:19 boost
along with the cpu{0..3} options.
When going through the CPUFREQ options in menuconfig, the following option
mentions a boost entry:
**
CONFIG_X86_ACPI_CPUFREQ_CPB:
The powernow-k8 driver used to provide a sysfs knob called cpb
to disable the Core Performance Boosting feature of AMD CPUs. This
file has now been superseeded by the more generic boost entry.
By enabling this option the acpi_cpufreq driver provides the old
entry in addition to the new boost ones, for compatibility reasons.
Symbol: X86_ACPI_CPUFREQ_CPB [=y]
Type : boolean
Prompt: Legacy cpb sysfs knob support for AMD CPUs
*
--
Joost
Re: [gentoo-user] Get bridge working for xen
On Wednesday 16 April 2014 23:17:27 Facu Curti wrote: On Thu, Apr 17, 2014 at 09:54:46AM +0800, AR wrote: On Thu, Apr 17, 2014 at 9:31 AM, Facu Curti facu.cu...@gmail.com wrote: Hi all! :) I'm following the gentoo wiki [1]. I can't find any mistake on config files, but network does not work :/. I don't have any xen configuration (or domU) yet. I'm just trying to get a bridge with functional network on my domain0. I attach my /etc/conf.d/net When I try to ping, with any iface, to to outside, or even to the getaway, it says host unreachable. Also, the system delays on load the system. It takes like 30 sec more, and conky get stuck (I use it to take data like IP, getway, dns, etc..). I hope can help me please, I need to get this working :/ Thank you! You all are the best!! Bye! Sorry if my english is not the best :/ [1] https://wiki.gentoo.org/wiki/Xen#Networking_on_Unpriviledged_Domains and what is your current network situation and your config (in /etc/conf.d/net) ? My /etc/conf.d/net is: config_enp3s0=192.168.1.2 netmask 255.255.255.0 brd 192.168.1.255 routes_enp3s0=default via 192.168.1.1 And ifconfig: enp3s0: flags=4163UP,BROADCAST,RUNNING,MULTICAST mtu 1500 inet 192.168.1.2 netmask 255.255.255.0 broadcast 192.168.1.255 ether ac:22:0b:c1:dc:de txqueuelen 1000 (Ethernet) RX packets 4630 bytes 4343241 (4.1 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 4923 bytes 686607 (670.5 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73UP,LOOPBACK,RUNNING mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 loop txqueuelen 0 (Local Loopback) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 Just for reference, here is my config. the IP on br0 is got from DHCP, everything else should be similar. modules=iproute2 # optional config_eth0=null dns_servers_br0=192.168.1.136 config_br0=dhcp # change this line if your network config is static brctl_br0=setfd 0 sethello 10 stp off bridge_br0=eth0 rc_net_br0_need=net.eth0 rc_net_eth0_provide=!net I will try this config. I need an static ip, but I can do this from router configuring the dhcp server. So, it is not a problem. I bring news in a few minutes Thank you! If you specify an IP for the interface AND the bridge, which one will be used for the communication? I would suggest the following for your net config: --- config_enp3s0=null bridge_xenbr0=enp3s0 config_xenbr0=192.168.1.2 netmask 255.255.255.0 brd 192.168.1.255 routes_xenbr0=default gw 192.168.1.1 rc_net_xenbr0_need=net.enp3s0 --- Also ensure you have a net.xenbr0 file: # cd /etc/init.d # ln -s net.xenbr0 net.lo Then start net.xenbr0: # /etc/init.d/net.xenbr0 start If this doesn't work, please send the results of the following commands: # ifconfig -a # brctl show Kind regards, Joost Roeleveld
Re: [gentoo-user] Re: WEFT Why Every F Time ?
On Thursday 17 April 2014 16:32:34 James wrote: Alan McKinnon alan.mckinnon at gmail.com writes: Is there another easy to use front end read/post to gentoo-user? I never could get the hang of reading mail in a browser Gmane is very nice. it mostly works. I noticed all the WEFT messages are gone (for now?)..Lars BUDDY! I'm still very olde skool in these matters, so: Subscribe directly to gentoo-user and pop your mail from gmail in a regular mail client? pine? common Alan, your dating us old farts.. alpine? (I guess is the current form/derivative of pine?REALLY? Pine, that brings back some old memories... If you do this, you have to delete messages. With Gmane, I can ignore gentoo-user sporadically with no consequences. Also, If I can get to any browser, I can read and post to gentoo-user; which has saved my bacon on several occations... Why delete messages when using a real mail client? What I was hoping for is some new fancy (ajax/ruby/?) frontend that works better than gmane.org? mail-client/roundcube ? With an imap-server ( net-mail/cyrus-imapd ) -- Joost
Re: [gentoo-user] Allow delay for booting from USB device?
On Friday 18 April 2014 12:02:01 Thomas Mueller wrote: Is there a way to make Gentoo or other Linux allow extra time when root is on a USB device? Any way to say just a second or more like 15 seconds before aborting with the message that root partition does not exist? In this case it's an IDE hard drive in a USB enclosure. FreeBSD seems to handle this situation better. I would get a mountroot prompt, to which I would respond ufs:/dev/ada0p3 and be good. I could avoid this situation with /boot/loader.conf legal.realtek.license_ack=1 rsu-rtl8712fw_load=YES kern.cam.scsi_delay=13000 # Delay (in ms) before probing SCSI kern.cam.boot_delay=16000# Delay (in ms) of root mount for CAM bus hint.re.0.disabled=1 but don't know if Linux has anything like this. Only lines 3 and 4 are relevant to this issue; other lines are for different issues. Tom Try adding rootdelay = 15 to the kernel commandline. This should make the kernel wait 15 seconds before trying to access the root- device. See: http://www.linuxtopia.org/online_books/linux_kernel/kernel_configuration/re58.html I used this myself in the past when booting from USB-devices. Kind regards, Joost
Re: [gentoo-user] Allow delay for booting from USB device?
On Friday 18 April 2014 10:01:35 Brian Hesdorfer wrote: On 4/18/2014 9:05 AM, Joost Roeleveld wrote: On Friday 18 April 2014 12:02:01 Thomas Mueller wrote: Is there a way to make Gentoo or other Linux allow extra time when root is on a USB device? Any way to say just a second or more like 15 seconds before aborting with the message that root partition does not exist? In this case it's an IDE hard drive in a USB enclosure. FreeBSD seems to handle this situation better. I would get a mountroot prompt, to which I would respond ufs:/dev/ada0p3 and be good. I could avoid this situation with /boot/loader.conf legal.realtek.license_ack=1 rsu-rtl8712fw_load=YES kern.cam.scsi_delay=13000 # Delay (in ms) before probing SCSI kern.cam.boot_delay=16000# Delay (in ms) of root mount for CAM bus hint.re.0.disabled=1 but don't know if Linux has anything like this. Only lines 3 and 4 are relevant to this issue; other lines are for different issues. Tom Try adding rootdelay = 15 to the kernel commandline. This should make the kernel wait 15 seconds before trying to access the root- device. See: http://www.linuxtopia.org/online_books/linux_kernel/kernel_configuration/r e58.html I used this myself in the past when booting from USB-devices. Kind regards, Joost Tiny Core linux, which is primarily booted over usb, does something similar. If I'm understanding this right, they have a loop in their initrd that just waits a maximum of X seconds until it shows up. I'm not sure how easy this would be to move into something else. Lines 114-128: http://git.tinycorelinux.net/index.cgi?url=Core-scripts.git/tree/etc/init.d/ tc-config rootdelay is a standard linux kernel option. No need to use a special script. -- Joost
Re: [gentoo-user] dracut: mount: special device /dev/disk/by-label/usr does not exist
On Sunday 16 March 2014 17:01:26 Neil Bothwick wrote: Unless there is already a VG on the other system with the same name. LVM doesn't handle VG name clashes, yet some distros still give them generic names. Not sure how others do it, but I find the following naming convention for VGs work: vg_hostname -- Joost
Re: [gentoo-user] separate / and /usr to require initramfs 2013-11-01
On Sunday 29 September 2013 14:45:05 Tanstaafl wrote: On 2013-09-29 2:25 PM, Dale rdalek1...@gmail.com wrote: Tanstaafl wrote: The way I see it, if you cannot provide a rational answer to that question, then there is no reason for you to use this as a reason to abandon gentoo, only a reason to merge /usr into /... Simple, I have never had to resize / or /boot before. I have had to resize /usr, /var and /home several times tho. THAT is the reason. Ok, but... everything I've read and personal experience over the years shows that space required for /usr should not change much, especially constantly grow over time (like requirements for /home can and will)- it may fluctuate (increase, decrease) *a little* over time, but it definitely should not grow substantially, so, if you had to resize it, most likely it is because you simply didn't allocate enough room to start with. Then what would be a correct size for the / partition when putting /usr on there as well? I have had no issues with giving / 500MB, /boot another 500MB and have everything else with minimal values on LVM and extending partitions without rebooting the machine whenever necessary. If I am now forced to put /usr on /, detailed steps on how to migrate all my systems succesfully with minimal downtime would be appreciated. Along with a size-indication that will: 1) Always be sufficient 2) Not be a waste of valuable diskspace For me, it doesn't matter if it is rational to YOU or not. Sorry, but rationality is not subjective. Just because something seems to be rational to you doesn't mean that it is. You have still not stated a logical, rational reason for wanting a separate /usr. Dale has, and so have I, see above. I am the one doing things on my puter not you or anyone else. If the init thingy fails, that will be me staring at a error message, not you. I don't want one of those things either, but that isn't what I was questioning you about. Of course you can do whatever you want *and* are technically capable of on your own computer, but that doesn't automatically make those things logical or rational. I did see one good case for a separate /usr (someone who was using ancient PATA drives, and something about striping for performance), but that was obviously a corner case... Actually, it isn't a corner case. Striping increases performance, I use it as well. Why put all the software that I load when needed (and expect to be thrown out of memory when not used) on a single disk when you have the option to put all that on a RAID0 (striping) set? -- Joost
Re: [gentoo-user] separate / and /usr to require initramfs 2013-11-01
On Sunday 29 September 2013 19:36:32 Neil Bothwick wrote: On Sun, 29 Sep 2013 10:53:26 -0400, Tanstaafl wrote: Precisely. And, it is my understanding (correct me if I'm wrong), that simply keeping your old kernel/initramfs around is NOT a guarantee (it might work - and it might NOT) of being able to fallback to a known working config until you figure it out. Installing a new kernel does not magically make the old one break. If that kernel worked yesterday, it will work today. Actually, that is not guaranteed. I remember a situation in the past where boot-critical software required a certain minimal kernel-version with specific config-settings. Without those I could not boot. Inconsistencies can, and will, happen on occasion. -- Joost
Re: [gentoo-user] separate / and /usr to require initramfs 2013-11-01
On Sunday 29 September 2013 22:09:35 Alan McKinnon wrote: On 29/09/2013 19:59, Tanstaafl wrote: I've been told that this shouldn't be a big deal... while I am a (barely) passable linux sys admin Allow me to forward an opinion. The above is not true, not even close. Don't knock yourself, you don't deserve it :-) In my day job I get to meet many people, and vast fleets of them are paid obscene amounts of money to do sysadmin work. I have an unprintable opinion of most of these folks (I'm tired of cleaning up after them and they mess they leave). I can imagine some of those opinions, I am certain I have uttered the exact same words myself on occasion. It gets worse when those are the ones holding the root-password and refuse to give it to you, even though it is obvious I know how to do things better then they do... You on the other hand would wipe the floor with easily 95% of those clowns. Seriously. And that goes for just about everyone else on this list who has been around a while. The list thanks you :) -- Joost
Re: [gentoo-user] separate / and /usr to require initramfs 2013-11-01
On Monday 30 September 2013 10:01:32 Alan McKinnon wrote: On 30/09/2013 06:14, Walter Dnes wrote: If the udev people had made net ifnames=0 the default, and allowed the small percentage of multi-nic machine admins to set net.ifnames=1, this would not have been an issue. Some corner case exotic setups require complex solutions... no ifs/ands/ors/buts. All the complaining you hear is from the other 99% who's setup worked just fine with the simple solution, suddenly finding the complex solution rammed down their throats. No, that is just plain wrong. Having interfaces on a multi-nic host come up as ethX where X is a mostly random number is just so broken it beggars belief. Trust me, it is zero fun when it happens and what makes it even worse if you have no warning at all beforehand. I trust you, but on my multi-nic systems, I found a better solution :) As I use Xen to virtualize my systems and as I don't want to have multiple network cables running side-by-side, I started using VLANs. I know have all the NICs names eth1,eth2,...ethn. I throw them all as a bonded network device: bond0 (the other ends go into a switch supporting bonding network ports) then on top of that, I have VLANs with distinctive names (lan, dmz, guest, vm,...) and link these as required to different Xen-domains. When the network names get renamed suddenly to the non-predictive scheme, my system refuses to boot. Before that, I would use mac-addresses to link ethx devices to names that make sense to me. (see above for the names) -- Joost
Re: [gentoo-user] separate / and /usr to require initramfs 2013-11-01
On Monday 30 September 2013 11:24:58 Neil Bothwick wrote: On Mon, 30 Sep 2013 12:16 +0200, Joost Roeleveld wrote: Installing a new kernel does not magically make the old one break. If that kernel worked yesterday, it will work today. Actually, that is not guaranteed. I remember a situation in the past where boot-critical software required a certain minimal kernel-version with specific config-settings. Without those I could not boot. I don't see how that is an issue with correctly written ebuilds. If you update the kernel, you are increasing the version number and your old one will still work. If you update the software, the ebuild should detect an unsuitable kernel and either warn you or abort. That is the problem though, the ebuild can't detect that there is an unsuitable kernel still available. Either way, it is irrelevant whether you are using an initramfs or not. I agree, my comment was made to point out that a kernel that worked yesterday, may no longer work tomorrow. -- Joost
Re: [gentoo-user] Re: Where does sudo get the PATH ?
On Wednesday, October 10, 2012 04:57:50 PM Nicolas Richard wrote:
Joost == J Roeleveld jo...@antarean.org writes:
Joost And, what is in the .bash_profile and .bashrc files in your
Joost homedir and in root's homedir?
In my homedir:
.bash_profile loads .bashrc
.bashrc says export PATH=~/bin/overrideglobal:${PATH}:~/bin (and
defines some aliases)
Does it load any global default?
In root's: I have no such files.
Maybe it would be less distracting if I don't use a shell at all :
youngfrog@geodiff-mac3 ~ $ sudo -i env | grep ^PATH
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/
usr/i686-pc-linux-gnu/gcc-bin/4.5.4:/usr/local/texlive/2012/bin/i386-linux:/
root/bin
youngfrog@geodiff-mac3 ~ $ sudo env | grep ^PATH
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/opt/bin:/
usr/local/texlive/2011/bin/i386-linux
Joost What do you get with echo $PATH when not using sudo?
You mean, when I'm logged in as root ? Then it's the same as when using
sudo -i.
No, when you're logged in as your normal user.
In other words, what is in the environment when you are normally logged in?
--
Joost
Re: [gentoo-user] Persistent ulimit for daemons
On Thursday, August 02, 2012 11:38:32 AM Michael Orlitzky wrote:
On 08/02/12 01:52, Joost Roeleveld wrote:
On Wednesday, August 01, 2012 10:41:41 AM Michael Orlitzky wrote:
Is there a blessed method these days for setting the ulimit per-daemon?
The best I've been able to do is a global setting in /etc/rc.conf:
rc_ulimit=-s 1048576
The entries under /etc/security seem to be ignored when using
`/etc/init.d/foo start`.
Michael,
I had to change the nofiles ulimit setting for my webserver. For that, I
simply added the settings to the following file:
# cat /etc/security/limits.conf | grep apache
apachehard nofile 4096
apachesoft nofile 4096
I would expect the same to work for any other daemon?
I thought so too, but it doesn't seem to be working (for any daemon, I
even tried with apache just now).
Can you `cat /proc/pid/limits` on one of those apache processes? I get
whatever was set for my bash shell rather than what I have in limits.conf.
I do get 4096.
Just had another good look at my notes, I also changed the init-file (Added
the ulimit-statement here):
***
start() {
checkconfig || return 1
[ -f /var/log/apache2/ssl_scache ] rm /var/log/apache2/ssl_scache
ebegin Starting ${SVCNAME}
ulimit -n 4096
${APACHE2} ${APACHE2_OPTS} -k start
i=0
while [ ! -e ${PIDFILE} ] [ $i -lt ${TIMEOUT} ]; do
sleep 1 i=$(expr $i + 1)
done
test -e ${PIDFILE}
eend $?
}
***
I don't think there is a consistent method of making this change more
permanent.
--
Joost
Re: [gentoo-user] Persistent ulimit for daemons
On Wednesday, August 01, 2012 10:41:41 AM Michael Orlitzky wrote: Is there a blessed method these days for setting the ulimit per-daemon? The best I've been able to do is a global setting in /etc/rc.conf: rc_ulimit=-s 1048576 The entries under /etc/security seem to be ignored when using `/etc/init.d/foo start`. Michael, I had to change the nofiles ulimit setting for my webserver. For that, I simply added the settings to the following file: # cat /etc/security/limits.conf | grep apache apachehard nofile 4096 apachesoft nofile 4096 I would expect the same to work for any other daemon? HTH, Joost
Re: [gentoo-user] Runlevels, ordering initscripts and running them in background
On Wednesday, May 16, 2012 02:15:19 PM Neil Bothwick wrote: On Wed, 16 May 2012 09:40:26 +0100, Ignas Anikevicius wrote: I want to do this, so that I do not have to wait while non-crucial services are being started (e.g. fcron, bitlbee, ntpd to name a few). Maybe it is possible to somehow prioritize the initscripts? Yes it is. The initscripts themselves have such a mechanism, using the before and after statements, for example making sure that network services are started after the network is brought up. You can add your own rules to the daemons' config files in /etc/conf.d or to /etc/rc.conf. To have bitlbee start after xdm either add rc_after=xdm to /etc/conf.d/bitlbee or put rc_bitlbee_after=xdm in /etc/rc.conf. Both have the same effect, it depends on whether you want to put all these settings together or in the individual services' config files. Putting them in /etc/rc.conf makes it simpler to maintain the init-scripts when updating packages. I used to put these things in the init-scripts and occasionally forgot about some of these during an update. -- Joost
Re: [gentoo-user] How to find the MAC address
On Thursday, April 19, 2012 04:12:35 PM Michael Mol wrote: On Thu, Apr 19, 2012 at 4:01 PM, Alex Schuster wo...@wonkology.org wrote: Michael Mol writes: On Thu, Apr 19, 2012 at 3:40 PM, Alex Schuster wo...@wonkology.org wrote: New output: eth0: flags=4163UP,BROADCAST,RUNNING,MULTICAST mtu 1500 inet 192.168.2.42 netmask 255.255.255.0 broadcast 192.168.2.255 inet6 fe80::be5f:f4ff:fe19:ad18 prefixlen 64 scopeid 0x20link ether bc:5f:f4:19:ad:18 txqueuelen 1000 (Ethernet) There it is. Wow. Now I feel really stupid. Because I am. I have no idea why I have overlooked this. Sorry for the noise! I didn't see it right away, either. I found it by noticing your MAC in your old output, and searched for a substring of it in your new output. Incidentally, you can derive it from your IPv6 LL address, but that's a bit of a roundabout way, and may not work if you've disabled IPv6. How do you derive it? I don't see the mac-address in the inet6 address. -- Joost
Re: [gentoo-user] sys-boot/plymouth could not work
On Thursday, April 05, 2012 01:10:46 PM Canek Peláez Valdés wrote: On Thu, Apr 5, 2012 at 2:47 AM, 张春江 zhangchunjian...@126.com wrote: On 2012-04-05 01:29:36，Canek Peláez Valdés can...@gmail.com wrote： On Wed, Apr 4, 2012 at 12:28 PM, Canek Peláez Valdés can...@gmail.com wrote: Something is wrong. There is no dracut messages in your dmesg output, so either you are not using the rd.debug command line (which, according to your logs, you *are* using), or you are not using a dracut-created initramfs, or the initramfs is somehow corrupted. I used # dracut -H -f to create my initramfs. I don't know why there is no dracut message in my dmesg output. Can I see your grub.cfg file, as it is please? Also, it seems that th e problem is OpenRC not creating the /run tmpfs early on during the boo t process: https://bugs.gentoo.org/show_bug.cgi?id=409921 Until that gets fixed, recent versions of plymouth cannot work with OpenRC. Maybe you could try an old version? Regards. Also, can I see your fstab? It seems you use quite the complex setup for your partitions. The latest version of plymouth is 0.9_pre20111013-r1. I installed sys-boot/plymouth-0.8.3-r5 but it still couldn't work, just like v0.9_pre. There is no ebuild for other versions. Then I tried to install by tarball, but version 0.8.1 and 0.8.2 have a make error: fatal error: drm/drm.h: No such file or directory, but I have already installed x11-libs/libdrm and all the other drm related applications are masked. Version 0.7.2 have an another make error. This is my grub.conf: default 0 timeout 5 #splashimage=(hd0,13)/boot/grub/splash.xpm.gz title Gentoo Linux root (hd0,13) kernel /boot/kernel-3.2.1-gentoo-r2 root=/dev/sda10 splash quiet video=radeon:1366x768 initrd /boot/initramfs-3.2.1-gentoo-r2.img title Win7 rootnoverify (hd0,0) makeactive chainloader +1 This is my /etc/fstab: # fs mountpointtype opts dump/pass # NOTE: If your BOOT partition is ReiserFS, add the notail option to opts. /dev/sda14 /boot ext4 defaults,noatime1 2 /dev/sda10 / ext4noatime 0 1 /dev/sda11 /usrext4noatime 0 0 /dev/sda12 /varext4noatime 0 0 /dev/sda13 /home ext4noatime 0 0 /dev/sda9 noneswap sw 0 0 /dev/cdrom /mnt/cdrom autonoauto,user 0 0 /dev/sda1 /media/win7 ntfs-3g rw,users,umask=000 0 0 /dev/sda5 /media/musicntfs-3g rw,users,umask=000 0 0 /dev/sda6 /media/animation ntfs-3g rw,users,umask=000 0 0 /dev/sda7 /media/data ntfs-3g rw,users,umask=000 0 0 /dev/sda8 /media/videontfs-3g rw,users,umask=000 0 0 Thank you very much for your help! I see several problems from your grub and fstab config files: 1. If you have a separate /boot partition, you should have something like kernel (hd0,14)/kernel-3.2.1-gentoo-r2 root=/dev/sda10 splash quiet video=radeon:1366x768 initrd (hd0,14)/initramfs-3.2.1-gentoo-r2.img in your grub.cfg. Grub starts counting at 0, not at 1. So the partition is marked as (hd0,13) The /boot partition has a symlink called boot pointing back to itself. (hd0,13)/boot = (hd0,13) When specifying root (hd0,13) Grub will default to that partition. Eg. the grub config matches fstab. 2. GRUB cannot read ext4 partitions (GRUB2 can), so you are reading them as ext3 (I don't know if this can cause any problems). The reason I started to use GRUB2 was because I wanted to use ext4 for my /. I don't think ext4 and ext3 use the same disk layout, eg. I don't think that can work. 3. Where is the rd.debug command line? Without it, we can't see dracut's debug messages. Delete /boot/initramfs*, and recreate the initramfs again, add the rd.debug kernel command line in grub.cfg, and reboot again. The dmesg output should have a lot of lines with dracut:; send that to the list. Why start with deleting the initramfs? Why not create a new one with a new name and keep the old one for comparison later? -- Joost
Re: [gentoo-user] Re: MTS player
On Tuesday, April 03, 2012 06:38:29 PM James wrote: Michael Mol mikemol at gmail.com writes: My new Sony camcorder produces MTS and CPI video output files. mplayer2 is a fork of mplayer. I use mplayer2 (instead of mplayer) because it has better stream seeking behavior for my use cases. I don't remember what all the differences are, though. OK I'll check out mplayer2. On another note, I have always transferred files form the sony camcorders to my linux systems, via cp or scp, without issues. Now, the new sony (HDR-PJ760V) is giving me troubles. I plugged the usb on the sony camcorder into my gentoo system. The usb was auto discovered. I am able to use Dragon player to watch the individual files, such as 1.MTS via Dragon player and the camcorder being mounted (96 G of flash). Ok so I was then initially able to use cp to copy the files off onto the gentoo hard drive. After I did a few this way, the mount point now drops almost immediately. I can re-discover the sony camcorder and automount via the file-manager. I can see the files and play them one at a time via Dragon Player. But, when I go to copy them with: cp *.MTS /usr/local/video/jeff/basketball/TR or cp 0.MTS /usr/local/video/jeff/basketball/TR I get Erno 5 as the mount is lost evey time now. The mount drops. I never had this problem before, but it is a different camera. What really has me stumped is it worked for a while for a few files, now it drops the mount every time. I even power cycled the camcorder, to no avail. Any ideas? This sounds like a problem I had with a USB harddrive. Cause: Bad connection in USB-port (dust?) Solution: Use vacuumcleaner to clear USB-port ;) HTH, Joost
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Wednesday, March 14, 2012 03:41:01 PM Michael Mol wrote: On Wed, Mar 14, 2012 at 2:45 PM, Canek Peláez Valdés can...@gmail.com wrote: Snipped Again, read about devfs. Tighly coupling is the path the developers (in general) are taking. I agree with them. I remember devfs. Never wound up using it, myself, but I followed the drama via kerneltrap and diff -u. There is no such thing as a one-size-fits-all solution, but that's not something you seem to grasp yet. devfs started as a decent tool, actually. It always worked on my desktop. It only stopped working when it was taken out of the kernel and got replaced. Or am I the only one who didn't notice any obvious problems? ;) -- Joost
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Wednesday, March 14, 2012 10:59:30 PM Pandu Poluan wrote:
On Mar 14, 2012 10:30 PM, Michael Mol mike...@gmail.com wrote:
On Wed, Mar 14, 2012 at 11:20 AM, Tanstaafl tansta...@libertytrek.org
wrote:
Or asked another way -
Why is LVM2 incapable od using mdev?
Alan has explained that LVM2 actually is able to run under mdev, and he's
investigating if there's any LVM2 feature that is not available.
So far, there's none, and I'm strongly suspicious that it's a case of
missing dev symlinks that prevented LVM2 to work; something later on the
default runlevel then created the proper dev entries that allow LVM2 to
work.
If that is the case -- which I strongly suspect -- then one can use mdev's
built-in ability to rename/move a device + create a symlink [1]
[1]
https://svn.mcs.anl.gov/repos/ZeptoOS/trunk/BGP/packages/busybox/src/docs/md
ev.txt
I don't have the time to test this yet, but I am definitely planning on trying
mdev. Especially because I don't like the direction udev is going.
Auto-creation of /dev entries. Yes, very usefull
Renaming devices according to some simple rules. Yes, very usefull.
Auto-starting programs when a device is added. Great, when are we getting
autostart support for CDs and USB-keys and under which user-account will
these be executed?
This system is mostly used by me, but my wife also uses it sometimes. Even
when I leave a desktop-session active. She simply starts a second one.
If this is implemented, will the autostart-script run under my account, my
wifes, or *shudder* as root?
Walt, keep up the good work. I need LVM to work on the server, once we have
confirmed it does work and how to configure mdev to work with it, I'll start
to switch my servers.
The presumption is that lvm's dependent binaries would be found
somewhere under a mount point other than / (such as /usr), which gives
you a chicken-and-egg problem if mounting that mount point requires
lvm.
Uh... mounting filesystems is not the purview of {u,m}dev...
...yet ;)
That is, untill someone comes up with the clever idea of shoving an
automounter into udev. (Will it then also auto-unmount when I want my CD
back?)
--
Joost
Re: [gentoo-user] mdev + xorg + Gnome up and running. :-)
On Friday, March 16, 2012 02:54:16 PM Pandu Poluan wrote: On Fri, Mar 16, 2012 at 14:32, Walter Dnes waltd...@waltdnes.org wrote: On Fri, Mar 16, 2012 at 08:41:48AM +0700, Pandu Poluan wrote Hmmm... are you planning to host an overlay? If so, I'll be willing to donate some of my time to provide some patched ebuilds for packages that can function without udev but lazily specify DEPEND=sys-fs/udev... I wouldn't call it lazy. Before the hulabaloo about udev/initramfs, I don't think anybody was running mdev on Gentoo. So there was no need for mdev in the ebuilds. The only non-embedded distro to use mdev was Alpine linux. And they also use uclibc. Ah yes, sorry. That was originally tongue-in-cheek, but I now see it may be too disparaging. My bad. I'm not familiar with the server side of things. I can follow instructions if supplied. I don't know if the hosting provider I'm thinking of does rsync. I never theought to ask. I'll check on the dev list about the etiquitte regarding contacting upstream. Even if a package works today with mdev, there's no guarantee about tomorrow. It'll help if upstream knows that people are using their packages with mdev, and they take that into account when updating the software. Note that my request for updating virtual/dev-manager went through OK. Once we test a udev-required package with mdev, and confirm it works, we should post a request on the Gentoo bugzilla to update Gentoo's ebuild. Good idea. ... and while at it, let's see if I can make a package containing scripts to ease transitioning from udev to mdev. Maybe call it, sys-utils/mdev-helper? The kernel reconfig and rebuild, and sticking init=/sbin/linuxrc into the append line are user-specific. I dual-boot 2 kernels (production and experimental), and I run lilo. Somebody with only one kernel, and/or running GRUB will need to do things differently. So a script won't help. This is simple enough to copy+paste from docs to your terminal. Well... as to the kernel requirement... nothing's stopping one from emerging sys-fs/reiserfsprogs even when the kernel doesn't support reiserfs ;) The init=/sbin/linuxrc can be automated using script (and sed), which we can imbue with the intelligence necessary to edit LILO/GRUB conf. I do have a collection of my own scripts to make it easier to install new Gentoo systems; one of them I whup up to automatically add a new kernel into menu.lst and (optionally) modify the default kernel [1]. What I have in mind for helper scripts would be (for example) a script to ensure that, on boot, ethernet devices will maintain their relative order. This needs to be stuck into /etc/mdev.conf (already part of stage3). (And if someone's well-versed enough in Linux, maybe he/she will convert the shellscript into a simple -- and faster -- binary with exact same functionality). I think you are talking about a script that handles a more dynamic database to force renames/softlinks for devices keeping names identical? I haven't played with mdev yet, but isn't that already in mdev? Or does mdev require it to be set manually? Btw, the keep same devicename is rather annoying when having to replace the network card and the network then doesn't come back up... -- Joost
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Friday, March 16, 2012 08:46:05 AM Neil Bothwick wrote: On Fri, 16 Mar 2012 07:13:46 +0100, Joost Roeleveld wrote: Auto-starting programs when a device is added. Great, when are we getting autostart support for CDs and USB-keys and under which user-account will these be executed? This is for running programs from the computer against the device, not autorunning programs on the device - such as initialising USB modems. How long till autorunning programs becomes the next great thing on the desktop for Linux? That is, untill someone comes up with the clever idea of shoving an automounter into udev. (Will it then also auto-unmount when I want my CD back?) That's already been done, * sys-apps/uam Available versions: 0.2.1 (~)0.3 Homepage:https://github.com/mgorny/uam/ Description: Simple udev-based automounter for removable USB media This is an automounter, not autounmounter... What I would like is one where a CDrom is automounted when inserted and when I press the eject-button, the cdrom is umounted and I get my cd back... The action that (used to) cause BSODs on MS Windows... I also have a rule on a headless media server to run a script that mounts a USB stick, copies files to it, unmounts it and lets me know when it is done. I can mark files for copying at any time and my wife can just plug in a stick when she wants to copy them for viewing on a small, non-connected TV by her treadmill (her treadmill, I emphasise - I find a keyboard and trackball give me all the exercise I want). Why not connect that TV? ;) -- Joost
Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts.
On Thursday, March 15, 2012 01:05:12 PM Neil Bothwick wrote: On Thu, 15 Mar 2012 08:41:38 -0400, Tanstaafl wrote: That's why I build the initramfs into the kernel and not as a separate file. If I do something to break the initramfs I just boot the previous kernel knowing it will still work. Ok, time to show my ignorance... How would I know if I am using an initramfs, and if I was, whether it was built into the kernel or not? Well, you built the kernel, so you should know. Technically, we are all using an initramfs as all 2.6/3 kernels mount an initramfs when they load. If does not contain an init script, they fall back to the legacy behaviour. See /usr/src/linux/Documentation/filesystems/ramfs-rootfs-initramfs.txt Even when the init-options are not set? *** admin@hera ~ $ uname -a Linux hera 2.6.34-xen-r4_dom0 #1 SMP Wed Dec 8 15:52:31 CET 2010 x86_64 AMD Phenom(tm) II X4 955 Processor AuthenticAMD GNU/Linux admin@hera ~ $ zcat /proc/config.gz | grep -i init CONFIG_INIT_ENV_ARG_LIMIT=32 # CONFIG_BLK_DEV_INITRD is not set # CONFIG_SCSI_OSD_INITIATOR is not set CONFIG_DEBUG_MEMORY_INIT=y # CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set *** -- Joost
Re: [gentoo-user] Gentoo location for squirrelmail attachments
On Friday, December 09, 2011 07:51:16 AM Grant wrote: SNIPPED The script is in the webroot where you installed squirrelmail and is called configure. Simply run that, then select option 4 (General Options). The directories you want to check/change are the first 2. That is the script which sets the location of the attachment directory, which I think is what you meant. I could be wrong but I think Stroller was referring to a script that actually creates the directory. - Grant I don't think there is a script that automatically creates the directory. If there is, I haven't seen it yet. -- Joost
Re: [gentoo-user] How can I keep baselayout-1?
On Friday, December 09, 2011 04:45:05 PM Pandu Poluan wrote: On Dec 9, 2011 2:18 PM, J. Roeleveld jo...@antarean.org wrote: On Thu, December 8, 2011 5:01 pm, Pandu Poluan wrote: On Dec 8, 2011 9:46 PM, Jarry mr.ja...@gmail.com wrote: This server is ~50 miles away, and if I screw something and it does not boot up, I will have to go there and fix it on place. One small typo in ~50 config-files which must be updated is just enough to cause it... That's why I no longer deploy baremetal servers these days. Always as a VM on top of a hypervisor, with a small VM dedicated as an SSH tunnel. If I mess up, I can use the hypervisor management tool to reboot the VM, or open a console session, or even revert to a known good state. A seperate machine with serial-console or Ethernet-KVM on the mainboard also helps. Especially when updating the host :) My new servers will all have Ethernet-KVM for this reason. How I wish I can deploy an Ethernet KVM... my boss thought it was a good idea, until he saw the price tag :-/ Rgds, My new server has one on the mainboard (Tyan S5512GM4NR) that has a web- interface from which I can start a java-app for remote desktop. Other options: reset/power control, online read-out of sensor-data and I can patch the BIOS without starting the server. First time I got this and I like it enough to want it for future servers. -- Joost
Re: [gentoo-user] Gentoo location for squirrelmail attachments
On Friday, December 09, 2011 07:49:13 AM Grant wrote: I ran squirrelmail/configtest.php and realized I don't have an attachment directory set up for Squirrelmail: ERROR: Attachment dir (/var/local/squirrelmail/attach/) does not exist! I don't even have a /var/local/. Would a good Gentoo'er create the directory in that location? If a website needs to write files, let it do so under its own directory hierarchy. All of our PHP sites have something equivalent to the following in their apache vhost configs: php_admin_value open_basedir /var/www/example.com/www/ php_admin_value upload_tmp_dir /var/www/example.com/www/tmp php_admin_value session.save_path /var/www/example.com/www/tmp That way, if www.example.com is compromised, the rest of the machine is still safe (barring PHP bugs). There is a Squirrelmail document recommending that the Squirrelmail data and attachments directories are established outside of the web server's reach. /var is given as an example. They also recommend root:apache 0730 for both directories. This is a little disturbing because my Squirrelmail data directory was created under the webroot as apache:apache 0755 at some point. Would this have been done by Gentoo? Should I file a bug? Prepare data and attachment directories http://squirrelmail.org/docs/admin/admin-3.html - Grant I think the data-directory is included from upstream and is there to have it work when installing it blindly. Recommendations are not always possible (think hosted environments) -- Joost
Re: [gentoo-user] LVM and LABELS in fstab
On Thursday, November 17, 2011 10:43:28 AM Florian Philipp wrote: Am 17.11.2011 07:50, schrieb Dale: [...] One more question. I have two drives. A 250Gb and a 750Gb. Originally the data was on the 750Gb drive. I set the 250Gb up on LVM then moved things over from the 750Gb. I then added the 750Gb to the VG and resized the file system. So, in theory the data is on the 250Gb drive. Let's say I want to remove the 250Gb drive. I would use pvmove to do that right? When I ran pvmove /dev/sdb, which is the 250Gb drive, then it would remove all the data from that drive so that it could be removed. Am I close? I'm not planning to do that but just wanting to get a better understanding of this LVM thing. Dale Yes, that is correct. It moves the data by mirroring it temporarily on the new location before updating the metadata so that only the new location is used. Therefore you can safely reboot or abort operations. Also, this will only work if the VG has sufficient unused space (eg. not used by LVs) on the other disk(s) to accomodate the data moved. -- Joost
Re: [gentoo-user] Something weird and I'm confused. BIOS and SATA is empty
On Friday, November 11, 2011 08:48:42 AM Dale wrote: J. Roeleveld wrote: On Tue, November 8, 2011 10:33 am, Dale wrote: The only report that raccoon will give is a bright flash of light. Shorting out 250,000 volts sort of puts a period on the end of the briefest report there has ever been. Those lines are the TVA lines that come from a few hundred miles away. There is no telling how much power comes through those lines either. Heck, even one amp is a lot. That raccoon better get a new plan. The current one is shockingly the wrong way to do it. lol Plus I hate when the lights go out. Winter is about here and we have electric heat. :/ Nah, no new plan needed. The raccoon that physically caused the problem was a convicted criminal. (For refusing to cause havoc) and was sentenced to death by electrocution. The specific location was picked by the actual scientist running the experiments. -- Joost Now that you mention it, maybe they will run out of test subjects. o_O They're currently in the middle of negotiations to take over the penal system of the rabbits ;) Once they get that contract, they'll have a really steady supply. -- Joost
Re: [gentoo-user] udev rules for an iPod Touch?
On Friday, November 04, 2011 06:03:55 PM Mark Knecht wrote: 2011/11/4 Jorge Martínez López jorg...@gmail.com: Did you install app-pda/ifuse and app-pda/libimobiledevice (dependency of ifuse and gtkpod)?. I do not recall touching any udev rule. Greetings, -- Jorge Martínez López jorg...@gmail.com http://www.jorgeml.net Google Talk / XMPP: jorg...@gmail.com Hi Jorge, Thanks for the ifuse idea. ifuse /mnt/ipod does seem to get the device mounted. However just poking around in the /mnt/ipod directory isn't very clear by itself about how music (and one day hopefully videos) are stored. Maybe I can find some info somewhere to help with that if necessary. Even with the device mounted it doesn't seem to be visible to gtkpod, and there aren't any new USB disk messages in dmesg. Just a single ifuse message is all that's added. Well, at least I can sort of communicate with the ipod even if I cannot do anything interesting yet. Thanks! - Mark Mark, I haven't played with my iPod touch yet, but the older models all worked with gtkpod. You might need to tell gtkpod to open the ipod by pointing it where it is mounted. Menu: Edit - Repository/iPod Options Then click on Add new repository/iPod and fill in the details for your iPod. (The backup-file is in my home-dir on my desktop for mine) Any files you manually copy to the iPod will NOT be picked up as a database file needs to be updated as well. Apple also has this annoying tendency to change the DB-structure for every version and gtkpod needs to have specific support for your model for it to work. -- Joost
Re: [gentoo-user] udev rules for an iPod Touch?
On Saturday, November 05, 2011 04:48:54 AM Mark Knecht wrote: On Sat, Nov 5, 2011 at 2:39 AM, Joost Roeleveld jo...@antarean.org wrote: On Friday, November 04, 2011 06:03:55 PM Mark Knecht wrote: 2011/11/4 Jorge Martínez López jorg...@gmail.com: Did you install app-pda/ifuse and app-pda/libimobiledevice (dependency of ifuse and gtkpod)?. I do not recall touching any udev rule. Greetings, -- Jorge Martínez López jorg...@gmail.com http://www.jorgeml.net Google Talk / XMPP: jorg...@gmail.com Hi Jorge, Thanks for the ifuse idea. ifuse /mnt/ipod does seem to get the device mounted. However just poking around in the /mnt/ipod directory isn't very clear by itself about how music (and one day hopefully videos) are stored. Maybe I can find some info somewhere to help with that if necessary. Even with the device mounted it doesn't seem to be visible to gtkpod, and there aren't any new USB disk messages in dmesg. Just a single ifuse message is all that's added. Well, at least I can sort of communicate with the ipod even if I cannot do anything interesting yet. Thanks! - Mark Mark, I haven't played with my iPod touch yet, but the older models all worked with gtkpod. You might need to tell gtkpod to open the ipod by pointing it where it is mounted. Menu: Edit - Repository/iPod Options Then click on Add new repository/iPod and fill in the details for your iPod. (The backup-file is in my home-dir on my desktop for mine) Any files you manually copy to the iPod will NOT be picked up as a database file needs to be updated as well. Apple also has this annoying tendency to change the DB-structure for every version and gtkpod needs to have specific support for your model for it to work. -- Joost Hi Joost, Ah...insomnia...a great excuse for playing with computers and answering emails... ;-) I had the same idea about telling gtkpod to use this specific iPod when I started with this, but as best I can tell so far gtkpod won't see the iPod unless it shows up in dmesg as a USB disk drive. I believe I read that on their Wiki and was going to try and find the link at www.gtkpod.org to verify that but the web site isn't responding right now. I'll double check that later. Maybe for auto-detection, but the first time I played with gtkpod, I had problems auto-mounting usb-devices and always did the mounting as root. Telling gtkpod where the iPod was mounted was sufficient. The iPod she has is a First Generation version. It won't run iOS more recent that 3.x so she cannot get any of the newer features with iOS5 like NetFlix movies. (At least as far as I can tell so far. I haven't checked that out very much yet.) I never did, my previous employer had a tendency to give out new iPods each year. Not sure if they still do, I would have preferred something more usefull, like an eReader. My real need here is pretty small. I was trying to find something nice for my wife 'cause she's been doing nice things for me, but there's no rush on this. My personal interest was really because I've got a Kindle Fire coming in a couple of weeks which I want to use to watch movies when I'm donating blood. (I do that a lot because my blood is pretty unique.) Anyway, I figured out Handbrake for ripping my DVD collection and was going to use the iPod to test the video playback. Anyway, I can probably do that from a Windows VM, or worst case boot my laptop into Windows and do it native if required. Virtualbox has decent USB-pass-through support. Even quite high performance. Thanks for your help. I do appreciate it.
Re: [gentoo-user] Does this drive need a funeral?
On Tuesday, November 01, 2011 02:47:27 PM Dale wrote: Mark Knecht wrote: On Tue, Nov 1, 2011 at 11:58 AM, Dalerdalek1...@gmail.com wrote: Hi, For the first time in my life, I think I have a drive failing on me. Here is the info: SNIP What you folks think? Can I fix it somehow? I got a good shovel handy just in case. Dale Start doing backups before you write even 1 more email! ;;-) - Mark Well, it was in my brothers winders rig. Winders couldn't do anything but puke on the keyboard so I brought it down here and put it in my old Linux rig. I mounted it ro and got the data off it FIRST THING. Good idea... MS Windows has a tendency not to be able to handle failing disks... There was a boatload of pictures from their camera. Anyway, the data seems to be safe tho a few may have gotten messed up. I got to test that in a bit. If there were no read errors, any damaged files were caused by ms windows, not the disk. Is this terminal or can something be done to correct this? I did run the dd command before I ran the selftest. I don't think it matters but thought it wouldn't hurt either. If it is terminal, I'll get my screwdriver out and see what these drives look like on the inside. The last one I looked into was a old 14 thing many years ago. Platters were about the size of 33 rpm records. lol Dang I'm old. O_O If SMART is saying it will die in 24 hours it will make a nice doorstop :) I wouldn't use it for data (even throw away stuff) anymore. -- Joost
Re: [gentoo-user] Apologize to everyone for my nonprofessional
On Saturday, October 15, 2011 12:34:10 AM Canek Peláez Valdés wrote: I noticed the other day that when LVM tries to start, it fails. I have /var on a separate partition here. It was complaining about something on /var missing. So, you may be late in reporting this. I think it is already needed for LVM if /usr or /var is on a separate partition. Again, get the facts right. If you use LVM you will need to use an initramfs. If you only use a separated /usr you will be able to use Zac's proposal. Get your own facts right. I use LVM for everything except / and I do NOT need to use an initramfs. It has worked this way for years and making an initramfs mandatory for this is a REGRESSION. -- Joost
Re: [gentoo-user] Apologize to everyone for my nonprofessional
On Saturday, October 15, 2011 03:34:27 AM Canek Peláez Valdés wrote:
On Sat, Oct 15, 2011 at 3:05 AM, Michael Schreckenbauer grim...@gmx.de
wrote:
On Saturday, 15. October 2011 02:47:26 Canek Peláez Valdés wrote:
On Sat, Oct 15, 2011 at 2:31 AM, Michael Schreckenbauer
grim...@gmx.de
wrote:
On Saturday, 15. October 2011 02:11:43 Canek Peláez Valdés wrote:
On Sat, Oct 15, 2011 at 1:53 AM, Michael Schreckenbauer
grim...@gmx.de
wrote:
On Saturday, 15. October 2011 01:42:10 Canek Peláez Valdés wrote:
/var/lib usually stores whole
databases. The difference is important and relevant.
My systems has directories alsa, bluetooth, hp and many
more
there that are not databases at all.
So?
Which one? That /var is not going into /?
No. That /var/lib contains databases. Is this so difficult
to get?
I get it; it's just not relevant.
On my system /var/lib/alsa contains data, that alsa uses to
restore
mixer- levels.
Yeah, it does.
So *my* /var/lib is used during boot and *my* /var/lib has
to be
mounted by the initramfs.
No, it doesn't. What are you talking about? Look at
/etc/init.d/alsasound:
depend() {
need localmount
after bootmisc modules isapnp coldplug hotplug
}
Look at the first need from alsasound depend: it says, that it
goes
after localmount. If you have /var in NFS (a very weird setup
for a
desktop machine) maybe it will cause problems: but then it would
be
fault of OpenRC (or the alsasound init script). If /var is on a
different partition, localmount will mount it and *then*
alsasound
will execute.
And it makes sense: the volume restoring doesn't matter until
immediately before running gdm and going into the desktop; of
course
you can mount /var before that.
That's the situation on nearly every gentoo system
using sound
Yeah, and as I explained, thanks to need localmount there is no
problem.
(systemd might handle this different, I have no idea)
Yeah, it does more intelligently: as I said, the volume
restoring is
only needed just before starting X.
Got it? Your system is not the center of the world.
No, but I start to think you don't know *your* system. Check the
alsasound init script.
*lol*
Now, this is getting ridiculous.
Indeed, it is getting ridiculous.
I don't know my system?
No, you don't.
Have a look into
/lib/udev/rules.d/90-alsa-restore.rules
to realize, that this is a hack, that restores alsa-levels *twice*
on
systems that have /var/lib on /. The levels are supposed to be
restored by *udev* not the script.
Yeah, but it doesn't run when udev *starts*. It runs when a card is
*added* to the system; that is the reason for the ACTION=add part.
It's inteded to be used for USB cards (like external speakers with a
little sound card incorporated), so its volume is restored *at insert
time*.
Nonsense. Action add is used for every device in your system, built-in
or plugged in later. So this rule is not only used for
hotplug-USB-soundcards, but for every soundcard in your system.
Yeah, you are right. Sorry. I forgot about the little numbers udev uses:
10-dm.rules
11-dm-lvm.rules
13-dm-disk.rules
60-persistent-storage.rules
70-persistent-net.rules
90-alsa-restore.rules
These only matter when there are conflicting rules in these files. The rule in
the lower number is used. Higher numbers are then ignored.
So, the same way that in the alsasound init script need localmount
guarantee that /var is mounted, the 60-persistent-storage.rules
guarantees that /var is mounted before the 90-alsa-restore.rules
restores ALSA's volume.
Wrong, see above.
Again, there is no problem. Yeah, the rule is executed at udev
execution time... but after the persisten-storage rule. So, you see,
no problem. No need for /var in the same partition as /.
Wrong, /etc/init.d/alsasound is a fix for that.
Udev should handle the situation where filesystems are not available yet and
keep those in a retry-queue for when all filesystems are available.
You guys keep speculating. As of *now*, there is not a single line of
code that prevents a system from booting correctly if /var lives in
another partition, no matter if the system uses an initramfs or not.
As of *now* nobody is discussing, proposing, or even mentioning
(except for you guys) about requiring /var to live in the same
partition as /.
/var will be required. alsasound is a workaround for this.
--
Joost
Re: [gentoo-user] [OT] Should I be worried that I won't be able to dual boot in Gentoo?
On Monday, September 26, 2011 10:26:03 PM Jonas de Buhr wrote: I am assuming that unlike the old days when I used to boot Linux on PCs using a floppy with SmartBootManager, now we'll need to generate some key/hash for our freshly compiled kernel, then add it to the BIOS firmware and flash the BIOS with it before we are able to boot into it? Is it more complicated than that? how are you going to write to the bios if it doesn't let you? maybe you are determined enough to manually flash the chip every time you update grub but i think thats a buzzkill for 90% of the users ;) Eerhm... If Grub is the bootloader, wouldn't we just need to have a signed version of Grub? -- Joost
Re: [gentoo-user] Re: mplayer(2) ???
On Friday, September 23, 2011 01:56:38 PM Mick wrote: On Friday 23 Sep 2011 09:58:35 Florian Philipp wrote: Am 22.09.2011 23:54, schrieb Mick: On Thursday 22 Sep 2011 09:15:42 Nikos Chantziaras wrote: On 09/22/2011 12:58 AM, Mick wrote: On Wednesday 21 Sep 2011 09:19:39 Sebastian Beßler wrote: Does mplayer2 work with smplayer or kmplayer? I use mplayer2 with smplayer for a few month now and everything works just fine for me. Any idea when ffmpeg-mt might make it to the main portage tree? It's already in the tree. Both ffmpeg as well as libav now have it. Sorry I can't see a USE flag or ffmpeg-mt package in portage: $ eix -l ffmpeg | grep mt $ or are you saying that the code has been merged in the vanilla ffmpeg and libav without the need for a USE flag? The bug I linked to mentioned that it has been merged into ffmpeg and libav. Both packages have USE=threads. If you use mplayer2, you also see some output that mentions starting ffmpeg with x threads. Ah! Yes, of course! I was looking for the wrong thing. Thanks! I've enabled USE=threads and remerged ffmpeg (don't have libav installed). However, when I try to install mplayer2 it tells me that I should disable USE=threads. Am I missing something? # emerge -uaDv mplayer2 These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] media-sound/mpg123-1.13.2 USE=alsa ipv6 sdl sse (-3dnow) (-3dnowext) (-altivec) (-coreaudio) -jack (-mmx) -nas -oss -portaudio - pulseaudio 747 kB [ebuild R] media-video/ffmpeg-0.7.5 USE=3dnow 3dnowext X aac alsa amr bzip2 encode faac hardcoded-tables mmx mmxext mp3 rtmp sdl ssse3 truetype v4l2 vaapi vorbis x264 xvid zlib (-altivec) -avx -bindist (-celt) -cpudetection - custom-cflags -debug -dirac -doc -frei0r -gsm -ieee1394 -jack -jpeg2k -network -oss -pic -qt-faststart -schroedinger -speex -static-libs -test -theora - threads* -v4l -vdpau -vpx VIDEO_CARDS=-nvidia 0 kB [ebuild N ] media-video/mplayer2-2.0 USE=X a52 alsa ass cddb cdio cdparanoia dts dv dvd dvdnav enca faad gif iconv ipv6 jpeg live mad mmx mmxext mng mp3 network opengl osdmenu png quicktime rar rtc sdl shm speex sse sse2 ssse3 theora truetype unicode v4l2 vorbis xscreensaver xv xvid xvmc -3dnow -3dnowext -aalib (-altivec) (-aqua) -bidi -bindist -bl -bluray -bs2b - cpudetection -custom-cflags -custom-cpuopts -debug -dga -directfb (-doc) -dvb -dxr3 -esd -fbcon -ftp -ggi -jack -joystick -ladspa -libcaca -lirc -md5sum - nas -nut -oss -pnm -pulseaudio -pvr -radio (-real) -samba -tga -v4l -vdpau (- win32codecs) -xanim -xinerama VIDEO_CARDS=-mga -s3virge -tdfx -vesa 3,589 kB Total: 3 packages (2 new, 1 reinstall), Size of downloads: 4,336 kB The following USE changes are necessary to proceed: #required by virtual/ffmpeg-0.6.90, required by media-video/mplayer2-2.0, required by mplayer2 (argument) =media-video/ffmpeg-0.7.5 -threads Short answer: Please add virtual/ffmpeg threads to /etc/portage/package.use and try again. Longer answer: required by virtual/ffmpeg means that the virtual-ebuild is asking for that change and that ebuild also has a threads USE-flag. I actually have threads enabled in /etc/make.conf. -- Joost
Re: [gentoo-user] otrs
On Thursday, September 22, 2011 11:11:52 AM Stefan G. Weichinger wrote: Anyone installed otrs with webapp-config? I just don't get it! otrs emerged fine, but I get: # webapp-config -I -h localhost -d 'otrs' otrs 3.0.10 * Fatal error: Unable to determine location of master copy * Fatal error(s) - aborting Could someone please help? google doesn't get me fitting answers for gentoo Thanks! Stefan I have been using webapp-config for all the webapps on my server and it does work for me. Not seen that error before. I am wondering if something might be configured incorrectly. Do you have the folder: /usr/share/webapps/otrs/3.0.10 ? Also, I would try not to put quotes arount the -d parameter. I have never needed that myself. -- Joost
Re: [gentoo-user] otrs
On Thursday, September 22, 2011 12:19:15 PM Marius Vaitiekunas wrote: On Thu, Sep 22, 2011 at 12:11 PM, Stefan G. Weichinger li...@xunil.at wrote: Anyone installed otrs with webapp-config? I just don't get it! otrs emerged fine, but I get: # webapp-config -I -h localhost -d 'otrs' otrs 3.0.10 * Fatal error: Unable to determine location of master copy * Fatal error(s) - aborting Could someone please help? google doesn't get me fitting answers for gentoo Thanks! Stefan Hi, I strongly suggest you to use source package installation method. I am using it without any problem. I actually prefer using vhosts USE-flags. It allows me to test new versions before wiping the existing onces. Is there any reason why you advice against the vhosts-method? -- Joost
Re: [gentoo-user] otrs
On Thursday, September 22, 2011 12:25:59 PM Stefan G. Weichinger wrote: Am 22.09.2011 12:09, schrieb Joost Roeleveld: I have been using webapp-config for all the webapps on my server and it does work for me. Not seen that error before. I am wondering if something might be configured incorrectly. Do you have the folder: /usr/share/webapps/otrs/3.0.10 ? No, I don't have that! Then I think this is the problem. Did you install with the vhosts USE-flag? If yes, where did the ebuild place the files? (You should be able to see this in the output from the ebuild and/or in the emerge-logfiles. -- Joost
Re: [gentoo-user] otrs
Please don't CC me into all the emails, list-mails end up correctly. On Thursday, September 22, 2011 01:10:48 PM Stefan G. Weichinger wrote: Am 22.09.2011 12:41, schrieb Joost Roeleveld: On Thursday, September 22, 2011 12:25:59 PM Stefan G. Weichinger wrote: Am 22.09.2011 12:09, schrieb Joost Roeleveld: I have been using webapp-config for all the webapps on my server and it does work for me. Not seen that error before. I am wondering if something might be configured incorrectly. Do you have the folder: /usr/share/webapps/otrs/3.0.10 ? No, I don't have that! Then I think this is the problem. Did you install with the vhosts USE-flag? otrs doesn't have that flag! Just noticed, the 3.x versions appear to have that flag removed. I wonder why they did that as it makes managing webapplications a lot simpler that way. If yes, where did the ebuild place the files? (You should be able to see this in the output from the ebuild and/or in the emerge-logfiles. everything is put to /var/lib/otrs/ The permissions don't fit the apache-user, and the file /var/lib/otrs/scripts/apache2-httpd.include.conf gives me headaches as well when put to /etc/apache2/vhosts.d I am unsure where to put it and fiddle around for hours already. That's why I would love the webapp-config-approach. Yes, it would be easier. The 3.0.10 version wants me to unmask a few too many other packages for my liking to have a quick check. Did you read the documentation and have a look at the sample configuration provided? From what I see in the patch for the httpd.include file, I don't think it belongs in the vhosts.d folder as this is supposed to be for definitions of vhosts-files. -- Joost
Re: [gentoo-user] otrs
On Thursday, September 22, 2011 01:49:14 PM Stefan G. Weichinger wrote:
Am 22.09.2011 13:29, schrieb Joost Roeleveld:
Please don't CC me into all the emails, list-mails end up correctly.
sorry for the noise
otrs doesn't have that flag!
Just noticed, the 3.x versions appear to have that flag removed. I
wonder why they did that as it makes managing webapplications a lot
simpler that way.
The ebuild seems a bit outdated and non-maintained.
The 3.0.10 version wants me to unmask a few too many other packages
for my liking to have a quick check.
Understood.
Did you read the documentation and have a look at the sample
configuration provided?
sure, I did
From what I see in the patch for the
httpd.include file, I don't think it belongs in the vhosts.d folder
as this is supposed to be for definitions of vhosts-files.
Yep. I had it pasted into the existing default-host already, but the
problem was that the path of otrs was outside the setting of:
DocumentRoot /var/www/localhost/htdocs
I wanted to avoid moving the stuff there from /var/lib/otrs manually, to
keep portage happy in future.
Might try to cp the ebuild into a local overlay and edit $OTRS_HOME to
something like /var/www/localhost/htdocs/otrs, just to get on with it.
I have people waiting to use OTRS ...
I really wonder that I am the first person hitting these issues.
btw, just found that bug and updated it ...
https://bugs.gentoo.org/show_bug.cgi?id=220553
Thanks, Stefan
It could be that you're one of the few people actually using OTRS.
There are 2 older versions in layman overlays:
# eix otrs
* www-apps/otrs
Available versions:
(2.4.7) ~2.4.7[2]
(0) ~2.4.11[1] ~3.0.10
{apache2 cjk fastcgi (+)gd ldap mod_perl (+)mysql pdf postgres +rpc
soap vhosts}
Homepage:http://otrs.org/
Description: OTRS is an Open source Ticket Request System
[1] rion layman/rion
[2] zugaina layman/zugaina
Either of these might work on your system. At least one of these 2 appear to
provide the vhosts USE-flag as well.
I still have 2.3.3 installed in a virtual host intended for testing when I was
looking for possible webapps for a friend of mine. But we both then decided it
was not suitable for his needs.
It does have part of it outside of the Documentroot. As I wasn't too
interested at the time, I didn't look why it wants to have files in a
different location.
--
Joost
Re: [gentoo-user] grub and what happens exactly when booting.
On Monday, September 19, 2011 03:01:32 AM Dale wrote: Alan McKinnon wrote: On Mon, 19 Sep 2011 13:51:03 +0700 Pandu Poluanpa...@poluan.info wrote: I'm not sure if LVM by itself implement striping. Most likely not because LVM usually starts with 1 HD then gets additional PVs added. Plus there's the possibility that the second PV has a different size. I might be wrong, though, since all my experience with LVM involves only one drive. LVM does do striping according to the man page. I've never tried it, mostly because LVM is the wrong place to do that IMHO. Use RAID for that instead and leave LVM to do what it's good at - managing storage volumes What I was thinking about is this. You have two drives that is one lv. It has to be data stored on both drives at some point. Example, you have a data base that is 500Gbs. You have two drives that are 300Gbs each that are in the same lv. Well obviously 200Gbs has to be on a different drive. Isn't that striping which would would result in a speed increase? I think you're using the wrong names for the different pieces. The 2 300GB drives will be Physical Volumes (PV) These 2 PVs are in the Volume Group (VG) This VG has 1 LV for database. This LV, as it's at least 500GB will have parts on both PVs (harddrives) This will have increased performance when the data being read happens to be on 2 physically different drives. If you just extend over 2 (or more) drives, this is not very likely as the first 300GB of data will still, physically, be on the same drive. To spread the data more equally (eg. sequential parts will be on alternating drives) you have 2 options: 1) Merge the 2 drives in a single RAID0-device (for striping) 2) Tell LVM to use striping for the LV when creating it. My personal preference would be option 1 as I agree with Alan that LVM should stick to managing LVs and leave striping and other options to RAID- devices/software. Now if it is like me and is only one drive, then that won't happen. With only one drive, definitely not :) -- Joost
Re: [gentoo-user] udev + /usr
On Saturday, September 17, 2011 02:43:00 PM Canek Peláez Valdés wrote: On Sat, Sep 17, 2011 at 10:50 AM, Canek Peláez Valdés can...@gmail.com wrote: On Sat, Sep 17, 2011 at 2:45 AM, Joost Roeleveld jo...@antarean.org wrote: On Friday, September 16, 2011 10:53:47 AM Canek Peláez Valdés wrote: On Fri, Sep 16, 2011 at 5:08 AM, Joost Roeleveld jo...@antarean.org wrote: On Thursday, September 15, 2011 05:05:00 PM Canek Peláez Valdés wrote: Last time I checked, neither GNOME nor Emacs demanded that Gentoo developers or users had to write a fork/replacement for a core component of the system. GNOME and Emacs just need ebuilds and adapting their configuration to Gentoo-isms. Testing and bug reporting, as usual. The only code needed is some small patches for both and around 200 lines of emacslisp for site-gentoo.el. Funny that you mention this. There might be something similar brewing for users of Gnome where quite a few low-level parts will end up being mandatory for Gnome: ...but I'm increasingly seeing talk on the gnome side of the Gnome OS, to include pulse-audio, systemd, policykit, udev/u* (thus forcing lvm as well, at least lvm installation tho nothing forces one to use it... yet, since lvm is required for udisks), etc. I'm pretty sure the last part is false. I certainly have udisk installet (it's pulled by gnome-disk-utility), but I don't use LVM. So there. I don't use Gnome and haven't looked into all this. Udev also doesn't appear to have a LVM-useflag. But as I do use LVM, I can't actually check. Do you have sys-fs/lvm2 on your system? The ebuild does list it as RDEPEND. Yes, I got it installed. I didn't noticed until now. Then again, it takes 1 minute to install in my puny laptop, and uses 7 Mb of hard drive. But anyhow, I was mistaken: it is forced by udisks. I think udisks depending on LVM is an error, so I decided I would took this Saturday and see if I was able to write a patch that makes it optional. However, as per free software rules, I first visited the Freedesktop.org bugzilla. Gustavo Barbieri (who I mentioned before) got there first: https://bugs.freedesktop.org/show_bug.cgi?id=37647 As I said before, Gustavo has contributed a lot to systemd, usually making stuff optional. I'm sure his patch (or a similar version of it) will be accepted. I hope so too. I do use LVM, so having LVM used by udisks is logical. But if LVM isn't used, the tools shouldn't have to be present. I did notice on that bug-link that it was raised nearly 4 months ago with no response from the developers even though a patch exists was provided. As I keep saying: code talks. Yes, but the developers are quiet with regards to that patch. I can understand if it takes some time to analyse a patch, but 4 months with no response is, in my view, similar to the devs saying they don't care. -- Joost
Re: [gentoo-user] udev + /usr
On Friday, September 16, 2011 11:21:12 PM Pandu Poluan wrote: On Sep 16, 2011 11:00 PM, Dale rdalek1...@gmail.com wrote: Canek Peláez Valdés wrote: On Fri, Sep 16, 2011 at 5:29 AM, Pandu Poluanpa...@poluan.info wrote: Speaking of fsck, didn't someone lamented the fact that fsck can no longer be statically linked, thus making initr* 'blew up' in size? When more and more utilities go the non-statically-linked way... congratulations! You now have an initr* that's practically a cpio-ized version of / Now, common: that's an exaggeration. My dracut generated initramfs (with systemd, plymouth, udev, and I don't remember what many things more) is 5 Mb. That's a little less than my several-gigabytes /. Regards. Give it time. Something will need /home on the root partition next. Like someone else posted, we are headed towards windows land with this. I won't be surprised if /boot will have to be on / next too. Heh. If it's only limited to 'everything in /' it's still acceptable. MIGHTY annoying, and most likely an admin hell, but workable. Would it? :) If there would be a filesystem that reads from the in-memory-part and only accesses the disk for write-actions, then the / can be a ramdisk... :) Now, if everything needs to go into initr* (yes, I'm exaggerating, but...) Like a live-dvd? -- Joost
Re: [gentoo-user] udev + /usr
On Friday, September 16, 2011 10:53:47 AM Canek Peláez Valdés wrote: On Fri, Sep 16, 2011 at 5:08 AM, Joost Roeleveld jo...@antarean.org wrote: On Thursday, September 15, 2011 05:05:00 PM Canek Peláez Valdés wrote: Last time I checked, neither GNOME nor Emacs demanded that Gentoo developers or users had to write a fork/replacement for a core component of the system. GNOME and Emacs just need ebuilds and adapting their configuration to Gentoo-isms. Testing and bug reporting, as usual. The only code needed is some small patches for both and around 200 lines of emacslisp for site-gentoo.el. Funny that you mention this. There might be something similar brewing for users of Gnome where quite a few low-level parts will end up being mandatory for Gnome: ...but I'm increasingly seeing talk on the gnome side of the Gnome OS, to include pulse-audio, systemd, policykit, udev/u* (thus forcing lvm as well, at least lvm installation tho nothing forces one to use it... yet, since lvm is required for udisks), etc. I'm pretty sure the last part is false. I certainly have udisk installet (it's pulled by gnome-disk-utility), but I don't use LVM. So there. I don't use Gnome and haven't looked into all this. Udev also doesn't appear to have a LVM-useflag. But as I do use LVM, I can't actually check. Do you have sys-fs/lvm2 on your system? The ebuild does list it as RDEPEND. It's a reply in the gentoo-dev thread I started. Requiring pulse-audio and policykit, I can understand. But requiring a specific init-system for the desktop seems a bit overkill. I don't think that will happen, although certainly is what Lennart (and probably Kay) wants. What I think will happen is that, if available, GNOME will use systemd. FreeBSD does not have udev, and GNOME works there (with diminished functionality). That's the future, I believe: you will be able to use GNOME without systemd, but it will be like more awesomer with systemd. I still think Gnome (or any other desktop environment) should not care about which init-system is being used. I'm not a gnome user and am happy with my KDE-desktop. But the same post also mentions KDE seems to be headed in a similar direction. Just slower. Because it makes sense for the full-fledge desktop. Notice that Gustavo Barbieri (who works a lot on e17) is a heavy promoter of systemd. Maybe even makes sense for Xfce, but that I don't know. At the end of the day, systemd manages how to start and stop processes. Which is basically the task of gnome-session-manager (and whatever is the equivalent in KDE). systemd, like any init-system, should start services. KDE has some kde-services like akonadi, nepomuk,... that get controlled by the kde-system internally. I would NOT want to see these controlled by systemd. These are running for the user that is logged in. Having these running for all users at once leads to the multi-user-kludge that MS Windows tries to have and for which Citrix was invented ontop of MS Windows We already have a decent multi-user environment, why would we want to kill that? If I wanted a single-user system, I'd be running MS Windows. Mind you, I do think systemd is nice and usefull on a desktop machine, but I don't see much need for this on a server where the sysadmins generally prefer to have a much more detailed control of what is happening. I think systemd gives you that in servers. With OpenRC and Apache with user CGI scripts, ¿do you know how to list the httpd daemon spawned processes, and only those? Remember that a CGI script can double fork. With systemd is a matter of: systemctl status apache-httpd.service Did you look at the output of pstree? Try pstree -pu and you see all the PIDs and whenever there is a user- switch, it also lists the new user. And you can kill every process related to a daemon, no matter how many forks its children process make. That alone makes systemd more usefull for servers thatn SysV+OpenRC, I think. Systemd handles this through process-groups. This can be done in different ways. Then again, I don't feel Gnome or KDE have any reason to be installed on a server, but that's just how I see it. Dear evolution, of course not. Why would you install GNOME or KDE in a server? My two servers run with systemd, and not a single GUI library is installed in them. I consider dbus to be part of the GUI as I don't see a reason for apache, syslog, nfs, samba, to be using dbus to communicate with each other. There are already well-tested and working mechanisms for communication where needed. -- Joost
Re: [gentoo-user] HPLIP plugin file
On Friday, September 16, 2011 06:50:14 PM Paul Hartman wrote: Does anyone here use HPLIP and happen to have the file hplip-3.11.7-plugin.run that they can send to me or upload somewhere? openprinting.org is down because of the LF hack and it could be more weeks before it's back up. There are apparently no mirrors of this file... I can't install my printer until I obtain this file. Thanks in advance. ;) Try it from here: http://agni.csa.iisc.ernet.in/CASL/printer It appears to have it's own local copy. Found it by googling for the filename :) -- Joost
Re: [gentoo-user] udev + /usr
On Saturday, September 17, 2011 08:45:15 AM Joost Roeleveld wrote: On Friday, September 16, 2011 10:53:47 AM Canek Peláez Valdés wrote: I think systemd gives you that in servers. With OpenRC and Apache with user CGI scripts, ¿do you know how to list the httpd daemon spawned processes, and only those? Remember that a CGI script can double fork. With systemd is a matter of: systemctl status apache-httpd.service Did you look at the output of pstree? Try pstree -pu and you see all the PIDs and whenever there is a user- switch, it also lists the new user. Had a quick look to get a more detailed list: Specifically only for apache: # pstree -pu `cat /var/run/apache2.pid` /var/run/apache2.pid gets the PID for the parent process automatically. With this list, I can get a more detailed picture of which process calls which child-process / thread and which user(s) are used for which process. -- Joost
Re: [gentoo-user] udev + /usr
On Thursday, September 15, 2011 06:44:58 PM Canek Peláez Valdés wrote: On Thu, Sep 15, 2011 at 6:26 PM, Mark Knecht markkne...@gmail.com wrote: On Thu, Sep 15, 2011 at 3:05 PM, Mike Edenfield kut...@kutulu.org wrote: On Thursday, September 15, 2011 11:16:03 PM Joost Roeleveld wrote: On Thursday, September 15, 2011 04:42:23 PM Mike Edenfield wrote: I would estimate that the vast, vast, vast majority of users are those such as myslelf, who have no opinion whatsoever, and either will not be affected at all by these changes (because they don't separate / and /usr), or will simply apply the proposed initramfs solution and move on. You also don't have /var (or /var/log) seperated? Or any of the other parts of the filesystem that might be required by udev-rules? Speaking solely for myself, no. Years ago I routinely split /, /usr, and /var when setting up my FreeBSD systems, and found that it only ever caused problems when I could not get /usr or /var mounted when I needed them. At least since I switched to Gentoo, I've simply set up one partition with everything on it, and kept regular backups in case of failure. I clearly recognize that there are valid reasons to split your partitions, I have just never found any of them applicable to my situations. --Mike My first response to this 300+ post thread, and only to say that in something like 15 years of playing with using Linux I've never split /usr no longer split /var. I also don't use LVM or anything fancy like that. I just keep backups and use them if there's a failure. Life is pretty simple. My suspicion is that by far most casual desktop users of Linux, Gentoo based or not, run pretty much this way and will be unaffected by this whole change and as such have no reason to post. Ubuntu recommends /, /home and swap [1]. Fedora recommends /, /boot and swap [2]. OpenSUSE has several sets, but the simple and dual booting recommends /, /boot, /home and swap [3]. Debian says [4]: For new users, personal Debian boxes, home systems, and other single-user setups, a single / partition (plus swap) is probably the easiest, simplest way to go. However, this might not be such a good idea when you have lots of disk capacity, e.g., 20GB or so. Ext2 partitions tend to perform poorly on file system integrity checking when they are larger than 6GB or so. For multi-user systems or systems with lots of disk, it's best to put /usr, /var, /tmp, and /home each on their own partitions separate from the / partition. Interestingly, the Gentoo handbook [5] recommends /, /boot and swap. Damn, I haven't installed Gentoo in a long time, I hadn't looked at the handbook in years. Anyway, Debian is the only big distro recommending separated /usr, and then only for multiuser setups. It's really years since I've looked at the recommended partition schemes: when I started using Linux, a separated /home was almost a must. And we had tiny hard drives then. Now get out of my lawn. Gentoo still has some guides recommending split /usr: http://www.gentoo.org/doc/en/gentoo-x86+raid+lvm2-quickinstall.xml There are several people using this type of layout. The suggested partitioning scheme is usually for beginner installations. Not necessarily for larger installations with specific requirements. The debian guide talks about 20GB drives. I don't have those anymore. the smallest drive I have is a 320GB IDE-drive for the database server in the lab. The server has 2 mirrored 500GB drives for the OS, email and websites. The rest of the data is on drives larger then 1TB. Sticking all these on a single partition is going to take forever to fsck and will make maintenance a nightmare. I like the flexibility LVM brings me. On the gentoo-dev list, I am now hearing that in future, I will need to use a full initramfs for my usecase. I'm trying to find out if there is a way to avoid this. Once I find out, I will post the info here. -- Joost Regards. [1] http://www.easy-ubuntu-linux.com/ubuntu-installation-606-7.html [2] http://docs.fedoraproject.org/en-US/Fedora/13/html/Installation_Guide/s2-di skpartrecommend-x86.html [3] http://en.opensuse.org/SDB:Partitioning [4] http://www.debian.org/releases/woody/i386/ch-partitioning.en.html [5] http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?full=1
Re: [gentoo-user] udev + /usr
On Thursday, September 15, 2011 05:34:11 PM Canek Peláez Valdés wrote: On Thu, Sep 15, 2011 at 5:25 PM, Joost Roeleveld jo...@antarean.org wrote: [ Hugemongous snip ] If the Gentoo-devs come up with a fool-proof solution No such thing in computing, I think. I'm afraid you're right on this as that is also my experience. And not just in computing. The biggest difficult with designing fool-proof systems is the fact that designers will always underestimate the ingenuity of fools. But I also think is really laudable that you want to ensure no many users will get bitten by this change. I work in IT. Currently in support (enterprise-software, not home users) and moving into consulting soon. I don't like to see broken systems and always want to find solutions to problems I encounter. I might not always succeed, but I will certainly try. And I also tend to believe that Gentoo users are more than able to deal with this and almost any other thing. I agree, the vast majority of people on this list know how to solve issues for themselves or are able to formulate their problems/questions in such a way that others with more experience in that particular field can come up with the answer. However, I also think there are plenty of Gentoo-users who don't subscribe to this list and may easily get caught out when this situation really starts affecting them. -- Joost
Re: [gentoo-user] udev + /usr
On Thursday, September 15, 2011 05:38:41 PM Canek Peláez Valdés wrote: On Thu, Sep 15, 2011 at 5:30 PM, Joost Roeleveld jo...@antarean.org wrote: On Thursday, September 15, 2011 03:04:37 PM Canek Peláez Valdés wrote: On Thu, Sep 15, 2011 at 1:59 PM, Mick michaelkintz...@gmail.com wrote: On Thursday 15 Sep 2011 16:13:26 Michael Schreckenbauer wrote: 1. The minimal initramfs will only need to be built once (and rarely rebuilt thereafter). This removes one of my fears and it was a main objection for me - I would hate to have to rebuild initramfs every time I roll a new kernel, or libs and what not of fs happen to be udpated, etc. In my experience, it takes more time to build the kernel than it takes to rebuild the initramfs. And if you choose to use dracut, the process is automatic (you always call dracut with the same options, unless you suddenly add LVM or something similar). Canek, as you've been using dracut already extensively, is it possible to set default options/modules/whatever to get to the situation where simply running dracut without any extra options will always recreate the correct initramfs? The modules get defined by the DRACUT_MODULES variable, which is use-expanded. The options are configured in /etc/dracut.conf, but I believe there are some command line options not configurable. The developers suggested I try dracut and I do intend to do that. My problem is, the one most likely affected by this is also the one I want to experiment the least with. Guess I'll have to test this inside a VM. I didn't use an initramfs for my first years using Gentoo. Since I started to use media-gfx/splashutils a couple of years ago, every time I upgraded my kernel, I splash_geninitramfs'd my initramfs. Now I do the same, but with plymouth and systemd using dracut. It's just part of the process of getting a new kernel. And, if the initramfs has other tools in it, after every emerge of these tools. This is where I see a possible cause for failure as then the situation arises where the initramfs will still start correctly, but because it's using older tools it's possible that older versions and new versions start running simultaneously and get mixed up in a way that is not immediately apparent. I see it the other way around: you ensure that your initramfs is in sync with your system. In other words: the initramfs contains a subset of your normal installation. That is why it makes redundant /lib, /sbin and /bin. The reason I ditched lilo when grub came out was because I always would forget to run the lilo-command. (Another was that lilo wouldn't work on a new machine, but that's not important) The same will be true for dracut. And probably not just for me. The on-disk-format may stay the same and the tools (am thinking LVM here) should always be able to find my filesystems. But, what if the initramfs does the fsck with older tools? Currently, the fsck runs before actually mounting the filesystems. If the filesystems end up being pre-mounted, when will fsck run and which version? -- Joost
Re: [gentoo-user] udev + /usr
On Thursday, September 15, 2011 05:05:00 PM Canek Peláez Valdés wrote: On Thu, Sep 15, 2011 at 4:53 PM, Sebastian Beßler sebast...@darkmetatron.de wrote: Am 15.09.2011 22:27, schrieb Canek Peláez Valdés: On Thu, Sep 15, 2011 at 4:05 PM, Sebastian Beßler sebast...@darkmetatron.de wrote: Am 15.09.2011 16:57, schrieb Canek Peláez Valdés: with an initramfs you will be able to do anything, so it will make no sense to keep supporting initramfs-less systems. With Microsoft Windows you will be able to do anything, so it will make no sense to keep supporting Microsoft Windows-less systems. Irrelevant: see the name on the list? It's called Gentoo Linux. I know you are trying to be witty, but only shows you are comparing apples and oranges. No, because first it was sarcasm and second it shows that your argument is invalid. For near to every X there is some Y that can do what X can do, but there are still many good and valid reasons to have X. So it will make sense to keep supporting Y-less systems. And you conveniently skipped my answer to your last two examples. No problem, here it goes again: Last time I checked, neither GNOME nor Emacs demanded that Gentoo developers or users had to write a fork/replacement for a core component of the system. GNOME and Emacs just need ebuilds and adapting their configuration to Gentoo-isms. Testing and bug reporting, as usual. The only code needed is some small patches for both and around 200 lines of emacslisp for site-gentoo.el. Funny that you mention this. There might be something similar brewing for users of Gnome where quite a few low-level parts will end up being mandatory for Gnome: ...but I'm increasingly seeing talk on the gnome side of the Gnome OS, to include pulse-audio, systemd, policykit, udev/u* (thus forcing lvm as well, at least lvm installation tho nothing forces one to use it... yet, since lvm is required for udisks), etc. It's a reply in the gentoo-dev thread I started. Requiring pulse-audio and policykit, I can understand. But requiring a specific init-system for the desktop seems a bit overkill. I'm not a gnome user and am happy with my KDE-desktop. But the same post also mentions KDE seems to be headed in a similar direction. Just slower. Mind you, I do think systemd is nice and usefull on a desktop machine, but I don't see much need for this on a server where the sysadmins generally prefer to have a much more detailed control of what is happening. Then again, I don't feel Gnome or KDE have any reason to be installed on a server, but that's just how I see it. -- Joost
Re: [gentoo-user] udev + /usr
On Friday, September 16, 2011 12:00:16 PM Alan McKinnon wrote: On Fri, 16 Sep 2011 10:46:02 +0200 Joost Roeleveld jo...@antarean.org wrote: Anyway, Debian is the only big distro recommending separated /usr, and then only for multiuser setups. It's really years since I've looked at the recommended partition schemes: when I started using Linux, a separated /home was almost a must. And we had tiny hard drives then. Now get out of my lawn. Gentoo still has some guides recommending split /usr: http://www.gentoo.org/doc/en/gentoo-x86+raid+lvm2-quickinstall.xml There are several people using this type of layout. The suggested partitioning scheme is usually for beginner installations. Not necessarily for larger installations with specific requirements. Using layout suggestions from install docs to justify what the udev maintainers want to do is simply disingenuous. I referenced that asa response to the list of distro-guides. The install docs are obviously a guideline only and do not form any sort of requirement. That is obvious to anyone with some experience in the field. Anyone suggesting otherwise is either being hyper-literal or is following some sneaky agenda. Either way, neither type should be allowed anywhere near policy making as their goals conflict with the community. I agree and I used my example to point out that any layout that is used by a few people is likely to be documented somewhere on the internet. The debian guide talks about 20GB drives. I don't have those anymore. the smallest drive I have is a 320GB IDE-drive for the database server in the lab. I need 73G SCSI drives for some old servers still running, they cost a fortune from Dell. The nice man from Dell sales tells me they haven't had 20G drives in the stores for years and years, he mentioned numbers like 5 or 8 Yes, the 320GB disk is in a machine that was written off by some company about 4 or 5 years ago. Not sure how long that company used it before they got rid of it. -- Joost
Re: [gentoo-user] grub and what happens exactly when booting.
On Friday, September 16, 2011 11:58:11 AM Dale wrote: Alan McKinnon wrote: On Fri, 16 Sep 2011 10:47:01 -0500 Dalerdalek1...@gmail.com wrote: Mick wrote: You will need to patch your kernel (in your sdb test OS) and then you will also need to make a reiser4 fs on your sdb partition(s) (for that you'll need to emerge sys-fs/reiser4progs). If you want to be able to mount reiser4 from within your sda OS, you will need of course to patch your current kernel to start with, alternatively use a LiveCD like sysrescue which comes already patched. For patches look in here: http://www.kernel.org/pub/linux/kernel/people/edward/reiser4/reiser4 -for-2.6/ The way I do what you are trying to do is start with the existing OS on sda, partition sdb, tar contents of sda partitions into corresponding sdb partitions and then modify fstab. Depending on what you want to test you may not need grub installed into sdb's MBR and you may not need a /boot in sdb. As long as you are not going to remove sda from the machine you should be able to add a couple of lines in the original grub.conf to select to boot /dev/sdb, while using sda's MBR and /boot partition. HTH. I could have swore reiserfs4 was in the kernel. Sure enough, it ain't. I'll wait then. I don't want to take the chance that something goes belly up then not have a bootable way to fix things. reiser4 was never in the kernel and the odds of it ever making it there were about zero (coding style issues and many other things that pissed Linux off). And that was in the days when Hans was physically located in a place where he was allowed to code. For all practical purposes Reiser4 is dead. I haven't heard a peep out of anyone claiming to maintain it for a few years now. New question. I'm playing with LVM. What is the best file system to use that with? I know LVM can shrink and grow so a file system should be able to do the same, online would be great but not required. That would be good for a / partition but not needed for the rest. I can always go to single user and resize things. LVM is great, when installing a large package, downloading large files or finding out I need a lot more diskspace for the VMs I am running to do some testing, I can simply increase the LV (LVM-partition) and then increase the filesystem to match. All this while the filesystem is being written to. I don't want XFS tho. I used it before and it was a total disaster. I have a UPS but I also recall having to pull the plug when hal showed up too. No need for a repeat. I know from personal experience that the following support online resizing: ext2/3, reiserfs (v3), XFS, JFS. I would expect ext4 to also support that. One thing to remember, the online resizing only allows growing of the filesystem. For shrinking, you still need to umount it first. Also, XFS and JFS don't support shrinking at all. For testing, I would suggest starting with ext3 and/or reiserfs. Both work. I haven't tried ext4 yet, maybe someone who runs that on top of LVM can comment? Hmm, maybe I am thinking of ext4? Life's confusing. :/ I think you might be thinking of ext4. Btw, a brief description on how resizing would work. When growing the filesystem: 1) lvextend . 2) resizefs (different filesystems, different commands) This will work for all filesystems supporting online resizing. (I know of one that actually only allows growing when it IS mounted) When shrinking a filesystem: 1) umount 2) resizefs to less then what you want to shrink it to 3) lvreduce 4) resizefs The resizefs will default to growing to the full extend of the partition/LV it resides on. -- Joost PS. With LVM, I find it easier to make the partitions smaller to start with and leave un-assigned space in the VG for the LVs to grow.
Re: [gentoo-user] udev + /usr
On Wednesday, September 14, 2011 10:30:03 AM Canek Peláez Valdés wrote: On Wed, Sep 14, 2011 at 1:52 AM, Joost Roeleveld jo...@antarean.org wrote: On Tuesday, September 13, 2011 06:33:01 PM Canek Peláez Valdés wrote: On Tue, Sep 13, 2011 at 6:10 PM, Michael Schreckenbauer grim...@gmx.de wrote: If gentoo follows fedora on this mandatory initramfs trail, I'll switch to FreeBSD completely. My software works on way more systems than just Linux. That's of course your prerogative. And, as I said before: Linux strives to be much more than Unix, and that means do things differently. If you want to do things the same way that it was done in the last 20 years, maybe Linux is not the best of choices. I read it before, but to be much more then Unix, Linux should be doing things better. Being different is what led to MS Windows' But that's the thing: we (you and me) don't see the situation the same way. To me, the proposed changes are for the better. There are not many people who agree with you here. The changes will lead to a C:-drive, similar to MS Windows, where everything has to be a single partition. For various reasons, using seperate partitions are a better solution: - It allows for the use of filesystems better suited to the type of files and usage on each partition. - It prevents a single part of the filesystem to kill the entire system. (I can risk loosing 1 partition and not loose the rest of my data) I myself think the new technologies are worth to change the way we did things before. But that's just me. The new technologies have great merit. But, the implementation of it isn't thought through. In my humble opinion, what you just said is a little pedantic. You can disagree with the proposed changes, you can argue why you think another approach could be better. But just saying the implementation of it isn't thought through, is a little insulting to the devs. I think they though about the implementation a lot. They may have thought about it, but didn't think things through. I have already stated a better way of doing it in the past few days. I will repeat it here. The problem-scope that udev is TRYING to solve should NOT be solved in a single tool. The main purpose of udev is to populate the /dev-tree. The running of scripts based on /dev-tree events should be in a seperate tool that starts later in the boot-process. Merging these 2, without properly handling failures, is bad design. Forcing ALL Linux users to use a C-drive is one of the worst design flaws I have ever encountered. Forcing the use of an init* which can leave systems unbootable, is also a design flaw. How do you propose to fix the situation where the init* is broken and someone is unable to mount all the filesystems needed to rebuild the init* because udev, which SHOULD be populating the /dev-tree, refuses to do the single job it is designed to do? Then rethink about the fact that not all computers are easily accessible and/or have cd-drives/usb-ports active. My desktop has them active, my servers don't as I do not need USB on the server. And maybe I shouldn't even mention it, but I don't use OpenRC. I use systemd. And it works great on Gentoo. Well. Linux only. If I wanted a monoculture, I would use MS-Windows or OSX. Relax man. I mention what I use: I'm not forcing you (or anybody else) to use it. But I repeat (because I said it before) that I care about Linux, and Linux only. If you care about Linux, why do you allow it to be broken in such a fundamental way? Again, to me is not breaking it. To me is improving it. Adding another SPOF (Single Point Of Failure) is not an improvement. -- Joost
Re: [gentoo-user] udev + /usr
On Wednesday, September 14, 2011 10:37:14 AM Canek Peláez Valdés wrote: On Wed, Sep 14, 2011 at 5:06 AM, Neil Bothwick n...@digimed.co.uk wrote: On Tue, 13 Sep 2011 17:10:40 -0400, Canek Peláez Valdés wrote: No, by you know what needs to be done I mean: code. Contribute. Become a developer. Make shit happens the way you think it should happen. You're happy to run an important system service coded by someone with less experience than their dislike of the way things are going. Someone with less experience? As I said before, Kay has been working in udev for more than eight years. I think he's entitle to receive the acknowledge of his experience. A certain amount of years of experience doesn't mean the person can not make mistakes. Kay has done a lot of good work with udev, but he should rethink his design and breaking a lot of systems just to satisfy his insane desire to make everyone do whatever he dreamed up is simply wrong. -- Joost
Re: [gentoo-user] udev + /usr
On Wednesday, September 14, 2011 06:40:44 PM Sebastian Beßler wrote: This thread goes in endless circles, round and round and round. In the last 20 posts or so is not one new argument pro or con can be found, both sides only repeating their pov over and over again. Nothing will be achieved by that, it is only a big waste of time and energy that could be used better. Create documents with all your arguments, maybe a reply to that blog post that claims that split of /usr is broken. Flameing here on -user helps noone, because the devs must be convinced not the users. Just my 2 €-cent Greetings Sebastian Beßler I agree, I also wanted to leave a comment on that page about systemd and /usr written by the same guy who is making this decision for udev. Comments and changes are not possible on that page at all. -- Joost
Re: [gentoo-user] New gentoo installation fails when trying to install syslog-ng
On Thursday, September 15, 2011 01:58:59 AM Trifu Catalin Florin wrote: On Thursday, 15. September 2011 01:16:12 Trifu Catalin Florin wrote: snipped undecypherable part Dear Michael Thank you for your help! I didn't reboot my machine as the installation is not complete yet. How can I reboot when the installation isn't finish, if things that should work don't work in the first place? I could not find the currently running kernel you are using in this thread. Possibly, you are hitting an issue caused by a feature lacking in that kernel. What did you boot your machine with prior to starting the installation? Please also include the version and URL where you downloaded this from. I didn't try your advices as I don't now how to try them. How do I deactivate sandbox? Michael grimlog Schreckenbauer actually already told you how to do this: ** If you cannot upgrade your kernel right now, you can disable the sandbox FEATURES=-sandbox in /etc/make.conf (I do not recommend this) ** The sandbox is a security feature. If you disable it to get the install working and a newer kernel-version. Please undo this change after the first boot into the new kernel. I tried to search for touch: setting times of gentoo but I don't understand how this is related to my problem. Yahoo reply broken? I don't know what to say about that... gmail works in the same way, outlook in the same way, thunderbird in the same way. In other words, they're all broken. A good Email client will allow you to send non-HTML email. Puts quote marks in front of the lines and add a bladibla wrote this or similar line. It should also allow you to easily put your reply at the bottom of the email. GMail has been mentioned a few times as doing things wrongly. I won't even mention the many ways in which MS Outlook does things badly and Thunderbird wants to be a copy of MS Outlook. Now I'm at work, but when I will get home I will try your advices. I don't know how to that but I will find a way. Suppose that it will work, I'm afraid that I will have big problems with my server after that. I think it will keep stop me from working with errors similar to this one. Sorry for shouting but I do not have power to continue anymore... :(( what should have been a straight forward installation, converted into a nightmare Lets see if we can find out. Using the current live-cd from the gentoo website, I managed to install Gentoo without problem. If you are using an older kernel-version, you are likely using an older live-cd / host-environment. For this, there are usually work- arounds, but it might be an idea to start with a more current live-cd environment. -- Joost
Re: [gentoo-user] New gentoo installation fails when trying to install syslog-ng
On Thursday, September 15, 2011 11:37:12 AM Michael Schreckenbauer wrote: Yahoo reply broken? I don't know what to say about that... gmail works in the same way, outlook in the same way, thunderbird in the same way. In other words, they're all broken. A good Email client will allow you to send non-HTML email. Puts quote marks in front of the lines and add a bladibla wrote this or similar line. It should also allow you to easily put your reply at the bottom of the email. GMail has been mentioned a few times as doing things wrongly. I won't even mention the many ways in which MS Outlook does things badly and Thunderbird wants to be a copy of MS Outlook. Afaict, there are quite a few people here using thunderbird. Most replies are wellformed. Outlook, well... it's not a mail-client after all. Thunderbird works fine, if you're ok to do things Thunderbird wants to do things. The last time I tried it, it decided it wants to have copy of all the email from my IMAP-server locally. If it were a laptop with sufficient disk-space, then it would be ok. But as it's a desktop where I want to have usefull stuff locally. Having a copy of all my email locally on a desktop with gigabit connectivity to the mail-server doesn't really give any benefit. With that behaviour, I never bothered to see how replies would look. -- Joost
Re: [gentoo-user] udev + /usr
On Thursday, September 15, 2011 09:47:34 AM Michael Mol wrote: The main purpose of udev is to populate the /dev-tree. The running of scripts based on /dev-tree events should be in a seperate tool that starts later in the boot-process. I'm not entirely convinced this is the case, because it feels like some situations like network devices (nbd, iSCSI) or loopback would require userland tools to bring up once networking is up. Yes, but the kernel-events referencing those devices won't appear untill after the networking is brought up. The scripts that udev starts are run *after* a device-event is created. If the device itself has not been spotted by the kernel (for instance, the networking doesn't exist yet), the event won't be triggered yet. This situation does not require udev to start all these tools when network- devices appear. I hope the following would make my thoughts a bit clearer: 1) kernel boots 2) kernel detects network device and places network-device-event in the queue 3) further things happen and kernel places relevant events in the queue (some other events may also already be in the queue before step 2) 4) udev starts and starts processing the queue 5) For each event, udev creates the corresponding device-entry and places action-entries in a queue 6) system-init-scripts mount all local filesystems 7) udev-actions starts (I made up this name) 8) udev-actions processes all the entries in the action-queue From step 4, udev will keep processing further events it gets, which means that if any action taken by udev-actions causes further devices to become available, udev will create the device-entries and place the action in the action-queue. If anyone has a setup where /usr can not be mounted easily, it won't work currently either and a init* would be necessary anyway. (Am thinking of NFS, CIFS, iSCSI, NBD, special raid-drivers, hosting /usr or other required filesystems) But anyone with a currently working environment should be able to expect a currently working environment. If it fails to boot with only updating versions, it's a regression. And one of the worst kinds of all. -- Joost
Re: [gentoo-user] udev + /usr
On Thursday, September 15, 2011 10:32:50 AM Michael Mol wrote:
On Thu, Sep 15, 2011 at 10:11 AM, Joost Roeleveld jo...@antarean.org
wrote:
I'm not entirely convinced this is the case, because it feels like
some situations like network devices (nbd, iSCSI) or loopback would
require userland tools to bring up once networking is up.
Yes, but the kernel-events referencing those devices won't appear untill
after the networking is brought up.
The scripts that udev starts are run *after* a device-event is
created. If the device itself has not been spotted by the kernel (for
instance, the networking doesn't exist yet), the event won't be
triggered yet.
This situation does not require udev to start all these tools when
network- devices appear.
I hope the following would make my thoughts a bit clearer:
1) kernel boots
2) kernel detects network device and places network-device-event in
the
queue
3) further things happen and kernel places relevant events in the queue
(some other events may also already be in the queue before step 2)
4) udev starts and starts processing the queue
5) For each event, udev creates the corresponding device-entry and
places
action-entries in a queue
6) system-init-scripts mount all local filesystems
7) udev-actions starts (I made up this name)
8) udev-actions processes all the entries in the action-queue
From step 4, udev will keep processing further events it gets, which
means that if any action taken by udev-actions causes further devices
to become available, udev will create the device-entries and place
the action in the action-queue.
So, if I read this correctly, there are two classes of processing
events. kernel events and scripted actions. Here's rough pseudocode
describing what I think you're saying. (Or perhaps what I'm hoping
you're saying)
while(wait_for_event())
{
kevent* pkEvent = NULL;
if(get_waiting_kernel_event(pkEvent)) // returns true if an event was
waiting {
process_kernel_event(pkEvent);
}
else
{
aevent* pAction = NULL;
if(get_waiting_action(pAction)) // Returns true if there's an
action waiting.
{
process_action(pAction);
}
}
}
This is, sort-of, what I feel should happen. But currently, in pseudo-code,
the following seems to happen:
while(wait_for_event())
{
kevent* pkEvent = NULL;
if(get_waiting_kernel_event(pkEvent)) // returns true if an event was
waiting {
process_kernel_event(pkEvent);
}
}
I would prefer to see 2 seperate processes:
--- process 1 ---
while(wait_for_event())
{
kevent* pkEvent = NULL;
if(get_waiting_kernel_event(pkEvent)) // returns true if an event was
waiting
{
action_event = process_kernel_event(pkEvent);
if (action_event != NULL)
{
put_action_event(pkEvent);
}
}
}
--
--- process 2 ---
while(wait_for_event())
{
aevent* paEvent = NULL;
if(get_waiting_action_event(paEvent)) // returns true if an event was
waiting
{
process_action_event(paEvent);
}
}
---
So, udev processes one event at a time, and always processes kernel
events with a higher priority than resulting scripts. This makes a
certain amount of sense; an action could launch, e.g. nbdclient, which
would cause a new kernel event to get queued.
Yes, except that udev ONLY handles kernel-events and doesn't process any
actions itself.
These are placed on a seperate queue for a seperate process.
If anyone has a setup where /usr can not be mounted easily, it won't
work
currently either and a init* would be necessary anyway.
(Am thinking of NFS, CIFS, iSCSI, NBD, special raid-drivers, hosting
/usr or other required filesystems)
I don't see how this is relevant to actually fixing udev. (See below)
But anyone with a currently working environment should be able to expect
a currently working environment. If it fails to boot with only updating
versions, it's a regression. And one of the worst kinds of all.
I agree that the direction udev is going is a regression. There aren't
very many people active in this thread who would disagree with that
point. So let's just drop it and focus on what a good, general
solution would look like. (And anyone who says something amounting to
'status quo' for udev needs another explanation of why the udev
developer sees the current scenario as broken. And he's right; the
current scenario is architecturally unsound. I just think he's wrong
about the solution.)
I agree he is wrong about the solution as well.
I have actually just posted my idea to the gentoo-dev list to see how the
developers actually feel about possible splitting udev into 2 parts.
I'm not a good enough programmer to do this myself. But if anyone who can code
and who also agrees with me that my idea for a solution is actually a good
idea, please let me know and lets see how far we can get with implementing
this solution.
--
Joost
Re: [gentoo-user] udev + /usr
On Thursday, September 15, 2011 10:57:27 AM Canek Peláez Valdés wrote: snipped to keep only the email from Canek Let me throw my own guess of how they came out with the corrent proposed solution. I repeat: is my own guess: I am not the one calling the shots, so maybe I'm completely wrong. Ok and I do actually think you are correct with your guess as to why the developer came up with his solution. As many of you guys said, there are ways of solving the problem without requiring an initramfs. Note that if you decide to use an initramfs, every use case works: You can have a practically empty /, throw everything in /usr, and have /usr in another partition, maybe even an encrypted remote NFS share. With an initramfs you can have a separate /var, you can even have a separated /etc, mounted even by NFS too. You can do pretty much whatever you want, because you have a full userspace *the moment you boot*. Bluetooth, network, LVM, crypto-filesystems: Everything is available from the instant zero. For these specific custom environments, yes, I agree. An initramfs is mandatory. From that perspective, the problem then is trying to support the initramfs-less setups. Putting myself in the shoes of the developers, the smart solution is to simply force an initramfs. KISS is to force an initramfs, because it solves everything. The Gentoo devs are working in a minimal initramfs that works for most normal usecases. Everything else will be handled by dracut or genkernel. Initramfs is already supported. so is initramfs-less. An initramfs is not an initrd. And is not a binary blob coming who knows from where; with dracut, your initramfs is simply a subset of your normal installation, and can be as simple (just mount /usr) or as complicated (LVM+crypto+network+NFS+whatever) as you want. I haven't looked at dracut yet, but as far as I understand, it does create an initramfs with the script(s), libraries and binaries needed to start whatever is needed to get to the stage where udev is happy. Of course you can solve it differently, for example splitting udev as Joost proposes. But then is more code to maintain, and the number of possible setups is suddenly the double it was before. It. Is. Not. KISS. Depends on your definition of Simple. It's a lot like the CUPS/lprng situation we discussed before. CUPS can do anything that lprng does, so it makes no sense to keep support for lprng. It's the same: with an initramfs you will be able to do anything, so it will make no sense to keep supporting initramfs-less systems. The situation with Cups and lprng is different. If either of these fail, the system will still boot and then you can spend the time to fix the problem. If this change continues, an initramfs failure, will mean the system will not boot correctly. And when all the tools needed to fix the system are moved to /usr, what options are there to actually analyse and solve the problem? In my opinion, the simplest solution will be to make the tool(s) do what they're supposed to do. udev should, in my opinion, create the devices in userspace. That it also allows for programs/scripts to be executed when a device is created is a nice thing to have. Unfortunately, this leads to chicken-and-egg style problems when the scripts are on a filesystem that hasn't been mounted yet. There are 3 solutions for this: 1) The easy way out: the whole user-space must be available before udev 2) udev actually includes correct error-handling for this and retries 3) udev splits this into 2 seperate tools Option 1 is what is currenty proposed and what you appear to be in favour off. Except, what is the point of having udev when the entire user-space already exists before it starts? You yourself said it's nice to have everything already available from the beginning. But isn't the problem that udev can't start bluetoothd because /usr/bin/bluetoothd can't be found when /usr doesn't exist yet? How would udev handle a situation where I have /usr on my mobile phone which shares the filesystem over bluetooth? Option 2 has been suggested and rejected. And I happen to agree with this as it would make udev, a vital part of the system, bigger and will increase the chances of problems/bugs. Option 3, which I have proposed, would actually make the first part smaller and simpler. The action-handling can then be run at a later stage, when /usr is available and could then easier implement a retry-queue. With this being a seperate tool, not needed for the /dev-tree creation, failure on this should not lead to an unusable system. -- Joost
Re: [gentoo-user] udev + /usr
On Thursday, September 15, 2011 11:03:09 AM Michael Mol wrote:
On Thu, Sep 15, 2011 at 10:48 AM, Joost Roeleveld jo...@antarean.org
wrote:
On Thursday, September 15, 2011 10:32:50 AM Michael Mol wrote:
On Thu, Sep 15, 2011 at 10:11 AM, Joost Roeleveld jo...@antarean.org
wrote:
I'm not entirely convinced this is the case, because it feels
like
some situations like network devices (nbd, iSCSI) or loopback
would
require userland tools to bring up once networking is up.
Yes, but the kernel-events referencing those devices won't appear
untill after the networking is brought up.
The scripts that udev starts are run *after* a device-event is
created. If the device itself has not been spotted by the kernel
(for
instance, the networking doesn't exist yet), the event won't be
triggered yet.
This situation does not require udev to start all these tools when
network- devices appear.
I hope the following would make my thoughts a bit clearer:
1) kernel boots
2) kernel detects network device and places network-device-event
in
the
queue
3) further things happen and kernel places relevant events in the
queue (some other events may also already be in the queue before
step 2)
4) udev starts and starts processing the queue
5) For each event, udev creates the corresponding device-entry and
places
action-entries in a queue
6) system-init-scripts mount all local filesystems
7) udev-actions starts (I made up this name)
8) udev-actions processes all the entries in the action-queue
From step 4, udev will keep processing further events it gets,
which
means that if any action taken by udev-actions causes further
devices to become available, udev will create the
device-entries and place the action in the action-queue.
So, if I read this correctly, there are two classes of processing
events. kernel events and scripted actions. Here's rough pseudocode
describing what I think you're saying. (Or perhaps what I'm hoping
you're saying)
while(wait_for_event())
{
kevent* pkEvent = NULL;
if(get_waiting_kernel_event(pkEvent)) // returns true if an event
was
waiting {
process_kernel_event(pkEvent);
}
else
{
aevent* pAction = NULL;
if(get_waiting_action(pAction)) // Returns true if there's an
action waiting.
{
process_action(pAction);
}
}
}
This is, sort-of, what I feel should happen. But currently, in
pseudo-code, the following seems to happen:
while(wait_for_event())
{
kevent* pkEvent = NULL;
if(get_waiting_kernel_event(pkEvent)) // returns true if an event was
waiting {
process_kernel_event(pkEvent);
}
}
I would prefer to see 2 seperate processes:
--- process 1 ---
while(wait_for_event())
{
kevent* pkEvent = NULL;
if(get_waiting_kernel_event(pkEvent)) // returns true if an event was
waiting
{
action_event = process_kernel_event(pkEvent);
if (action_event != NULL)
{
put_action_event(pkEvent);
}
}
}
--
--- process 2 ---
while(wait_for_event())
{
aevent* paEvent = NULL;
if(get_waiting_action_event(paEvent)) // returns true if an event was
waiting
{
process_action_event(paEvent);
}
}
---
So, udev processes one event at a time, and always processes kernel
events with a higher priority than resulting scripts. This makes a
certain amount of sense; an action could launch, e.g. nbdclient, which
would cause a new kernel event to get queued.
Yes, except that udev ONLY handles kernel-events and doesn't process any
actions itself.
These are placed on a seperate queue for a seperate process.
The problem with this is that you now need to manage synchronization
between the kernel event processor and the action processor, which is
actually more complicated than keeping them together in a
single-threaded, single-process scenario.
I don't agree. Why does this need to be synchronized?
The kernel puts events in the new-dev-event-queue that process 1 picks up.
process 1 creates the /dev-entrie(s) and, if there is an action to be taken,
puts the action in the new-action-event-queue.
Process 2 will then pick up this action from the new-action-event-queue and
will process this.
If, as a side-effect, of the action processed by process 2, a new device
appears for the kernel, the kernel will simply put a corresponding event in
the new-dev-event-queue.
At which state does this need to be synchronized?
We can simply use a pipe-device as, for instance, used for syslog?
--
Joost
Re: [gentoo-user] udev + /usr
On Thursday, September 15, 2011 12:16:24 PM Michael Mol wrote: On Thu, Sep 15, 2011 at 11:43 AM, Joost Roeleveld jo...@antarean.org wrote: On Thursday, September 15, 2011 11:03:09 AM Michael Mol wrote: On Thu, Sep 15, 2011 at 10:48 AM, Joost Roeleveld jo...@antarean.org wrote: The problem with this is that you now need to manage synchronization between the kernel event processor and the action processor, which is actually more complicated than keeping them together in a single-threaded, single-process scenario. I don't agree. Why does this need to be synchronized? The kernel puts events in the new-dev-event-queue that process 1 picks up. process 1 creates the /dev-entrie(s) and, if there is an action to be taken, puts the action in the new-action-event-queue. Process 2 will then pick up this action from the new-action-event-queue and will process this. If, as a side-effect, of the action processed by process 2, a new device appears for the kernel, the kernel will simply put a corresponding event in the new-dev-event-queue. At which state does this need to be synchronized? We can simply use a pipe-device as, for instance, used for syslog? Let's assume that you have a single-reader, single-writer scenario, and that either the protocol includes a 'record end' marker, or that protocol messages are all of a fixed length and are written atomically. With that out of the way, I don't know. Perhaps no additional synchronization is necessary. You still have a problem with race conditions. Virtually all scripts I've read and written assume a single-threaded environment, but you've defined a two-threaded environment. Here's a potential scenario: 1) A kernel hotplug event comes in when a device is inserted. 2) keventler catches the hotplug event, creates the device node, queues an action event. 3) actionhandler catches the action event, launches the script. 4) The action handler script is still running for the plug-in event, when A kernel hotplug event comes in indicating the device was removed. keventler catches the new hotplug event, removes the device node-- 5) --the scheduler comes around and resumes working on the action handler script. Or perhaps the action handler script was on a different CPU core, and never needed to be unscheduled. The device node it was expecting to be there just disappeared out from under it, violating one of its assumptions, and putting it in an inconsistent state. The inconsistency might occur in a place the script author expected it, or the inconsistency might have occurred in an unexpected place. One presumes the script author didn't sign up to deal with concurrency issues in a bash or python script. 6) keventler registers a new action event, for actioning on the disconnect. 7) actionhandler picks up this new action event, runs the script. Kudos to the script author for thinking ahead to have a shutdown script properly clean up an inconsistent system state left by the partially failed setup script. Steps 3-5 are a classic example of a race condition, and stem from two active threads operating concurrently. Entire programming languages are developed with the core intent of reducing the programmer's need to worry about such things. You _must not_ change the operating environment of a script out from under it. In bash scripts, this is an extraordinarily common pattern: if [ -d $SOME_PATH ]; then // do something fi That's common and accepted; nobody expects a shell script to fail in a scenario like that, because it's is a single-threaded language, and that's been true since its inception. When something keventler does causes the result of [ -d $SOME_PATH ] to change after the test had already been done, then the script is only broken because keventler/actionhandler broke it, not because the script was badly written. Ok, didn't think of this scenario. Thank you for pointing this out to me. Your pseudo-code would be better then, except there should be some way of delaying action-tasks based on wether or not required files (including dependencies) are available. Or a retry-queue that retries an action a few times with certain intervals. This, however, will be more difficult to implement especially with the race-condition you mentioned. I've really got to get back to working on stuff I'm being paid for. I'll chat with you guys this weekend. I'm very interested in helping with a reasoned critical perspective, so if this wanders over to a new mailing list or discussion environment, drop me an invite. We will, but for now, why not keep it on here? :) Was wondering, does udev actually support actions for when a device is removed? Ok, just checked on my server and it does. All nicely pointing to scripts in /etc/ Also, anyone knows how udev handles the scenario where a device is removed while the script is still running? Wouldn't it fail mid-execution
Re: [gentoo-user] udev + /usr
On Thursday, September 15, 2011 04:42:23 PM Mike Edenfield wrote: On Wednesday, September 14, 2011 01:36:56 PM Dale wrote: Canek Peláez Valdés wrote: But that's the thing: we (you and me) don't see the situation the same way. To me, the proposed changes are for the better. You are one of very few that feel this way. You are probably correct that he's one of the relatively few people (along with the udev developer, and those few people for whom it will fix their problems) who think these changes are a real improvement. If for those people using an initramfs solves their problems, then I'm not against it. And I don't think many others are either. But why are people forced to use an initramfs where it is not needed? I would estimate that the vast, vast, vast majority of users are those such as myslelf, who have no opinion whatsoever, and either will not be affected at all by these changes (because they don't separate / and /usr), or will simply apply the proposed initramfs solution and move on. You also don't have /var (or /var/log) seperated? Or any of the other parts of the filesystem that might be required by udev-rules? Then there are those relatively few people, such as the handful making up the rest of this thread, who think that these changes are a horrible idea and will have a severe deterimental affect on their systems. Any added complexity is another thing that can go wrong. In the thread on gentoo-dev, I am trying to figure out 3 things: 1) How are the Gentoo Developers planning on adding this new change? 2) What are the options for not having to have an initramfs if the udev-rules used don't actually require /usr and co to be mounted. 3) Get their input in a possible alternative (like fixing the, what I see, design-flaws of udev) On 1, I am actually quite pleased. The actual information I could find previously sounded a lot worse. I've just got a few more questions open based on their answers. Once I have the full picture, I'll post it back here. For 2, I've only just started. I'll also post back here on what my findings are. For 3, I've got some feedback on how udev currently handles things. These actually have given me a few other ways in which to try to solve the issue. I'll need to try to find out how udev actually handles the retry queue currently. Not that the relative size of the various sides in this debate is really the issue, but despite the tone of this and the other thread, I don't think there's really a huge, overwhelming outcry against these changes. I wonder how many are actually aware of these changes. But yes, I think plenty of people will not care and if the Gentoo-devs handle this correctly (which, so far, I think they are) those people won't even notice. But, there will always be some people who get bitten by this and my reasons for going with parts 1 and 2 is to see how to keep this group as small as possible. -- Joost
Re: [gentoo-user] udev + /usr
On Thursday, September 15, 2011 01:43:17 PM Canek Peláez Valdés wrote: On Thu, Sep 15, 2011 at 10:58 AM, Canek Peláez Valdés can...@gmail.com wrote: (This mail is to keep the guys un -user in the loop about -devel). OK, so Joost posted his proposal to -dev: snipped brief discussion on gentoo-dev The thread on gentoo-dev is not yet finished and I intend to try to get some more information. As I mentioned in my other email. I would also like to point you guys to this article in LWN.net: http://lwn.net/SubscriberLink/458789/3ae00c9827889929/ The article (the second part about systemd) closes with: “The overall picture was of a project that is on a roll, gaining features and users at a fast rate. The Systemd view of the world has not yet won over everybody, but the opposition seems to be fading. Systemd looks like the init system of the future (and more) for a lot of high-profile distributions.” The article was written by Jonathan Corbet, editor of LWN and (I think most people would agree with me) someone who has always tried to be objective and impartial. I'll read this later (probably tomorrow) and get back to you on this if necessary. So, if Joost and others are willing and able to implement the necessary bits to avoid the need for an initramfs, I salute them and wish them luck. But the most probable outcome is this: * The fork/replacement will take years of man-effort: design, implementation, debug, documentation, mainteinance. * At the same time, the dev-approved solution of a minimal initramfs or a dracut/genkernel generated one will be available and working. * If the forking/replacement team manages to create a workable fork/replacement, it will have to sell it to the Gentoo devs, and if the initramfs solution is working properly the most rational answer will be no, thank you. The time needed for this is not certain as we are planning on basing it on the current udev and see what is possible. If the Gentoo-devs come up with a fool-proof solution, which is one of the possible outcomes I am trying to get to in the gentoo-dev thread, I will be happy there as well. As for the udev-fork to ever becoming mainstream, I can't say. It might not even work the way we are hoping. Only time will tell. I'm sorry if my analysis bother some people, but it's basically what I've been saying from the beginning. I'm glad Joost asked the developers for their input. I think it clears the air about a lot of things. I have no problem with your analysis and yes, the initial response from Zac was what you've been saying. I am hoping to get more information on this and I will have no problem if you keep reporting it back here. One of the reasons I asked it on Gentoo-dev is simply because I agree with some people here that this thread was starting to go in circles and no new information was being added. -- Joost
Re: [gentoo-user] udev + /usr
On Thursday, September 15, 2011 03:04:37 PM Canek Peláez Valdés wrote: On Thu, Sep 15, 2011 at 1:59 PM, Mick michaelkintz...@gmail.com wrote: On Thursday 15 Sep 2011 16:13:26 Michael Schreckenbauer wrote: 1. The minimal initramfs will only need to be built once (and rarely rebuilt thereafter). This removes one of my fears and it was a main objection for me - I would hate to have to rebuild initramfs every time I roll a new kernel, or libs and what not of fs happen to be udpated, etc. In my experience, it takes more time to build the kernel than it takes to rebuild the initramfs. And if you choose to use dracut, the process is automatic (you always call dracut with the same options, unless you suddenly add LVM or something similar). Canek, as you've been using dracut already extensively, is it possible to set default options/modules/whatever to get to the situation where simply running dracut without any extra options will always recreate the correct initramfs? I didn't use an initramfs for my first years using Gentoo. Since I started to use media-gfx/splashutils a couple of years ago, every time I upgraded my kernel, I splash_geninitramfs'd my initramfs. Now I do the same, but with plymouth and systemd using dracut. It's just part of the process of getting a new kernel. And, if the initramfs has other tools in it, after every emerge of these tools. This is where I see a possible cause for failure as then the situation arises where the initramfs will still start correctly, but because it's using older tools it's possible that older versions and new versions start running simultaneously and get mixed up in a way that is not immediately apparent. -- Joost
Re: [gentoo-user] udev + /usr
On Thursday, September 15, 2011 07:15:27 PM Neil Bothwick wrote: On Thu, 15 Sep 2011 17:37:53 +0200, Joost Roeleveld wrote: There are 3 solutions for this: 1) The easy way out: the whole user-space must be available before udev 2) udev actually includes correct error-handling for this and retries 3) udev splits this into 2 seperate tools 4) udev remains one tool but with two modes of operation. when in early-boot mode, it can only run a restricted set of rules - such as those using LVM, RAID, cryptsetup, network device naming. When switched to full mode later in the boot process, it loads the rest of the rules. Yes, I've been thinking about this option as well, after some comments on the gentoo-dev list. Which rules it runs it early-boot mode could be decided by adding a flag to the rule to mark it acceptable for early boot usage. That way, existing rules would automatically be deferred unless package maintainers update the rules for those they know will work early in the boot process. It saves writing/learning/debugging a new tool and gives maximum compatibility with existing configurations. This is pretty similar in concept to your suggestion 3, but a different approach to its implementation. And might be the simpler option. Currently, I'm planning on checking if the retry-queue can be abused for this purpose. -- Joost
Re: [gentoo-user] udev + /usr
On Thursday, September 15, 2011 07:37:17 PM pk wrote: On 2011-09-15 16:57, Canek Peláez Valdés wrote: Of course you can solve it differently, for example splitting udev as Joost proposes. But then is more code to maintain, and the number of possible setups is suddenly the double it was before. It. Is. Not. KISS. https://secure.wikimedia.org/wikipedia/en/wiki/Unix_philosophy I can especially point out: Rule of Modularity Rule of Parsimony Rule of Diversity I like those :) It's a lot like the CUPS/lprng situation we discussed before. CUPS can do anything that lprng does, so it makes no sense to keep support for lprng. It's the same: with an initramfs you will be able to do anything, so it will make no sense to keep supporting initramfs-less systems. ... one ring to rule them all... ...My Precious... :) -- Joost
Re: IDE for C/C++ (Was: Really OT now (Re: [gentoo-user] udev + /usr)
On Thursday, September 15, 2011 04:05:29 PM Michael Mol wrote:
On Thu, Sep 15, 2011 at 3:59 PM, Chris Brennan xa...@xaerolimit.net wrote:
On Thu, Sep 15, 2011 at 3:47 PM, Leonardo Guilherme
leonardo.guilhe...@gmail.com wrote:
I do not know the state of Geanny since I last checked (couple of
years
ago), but the highlight capabilites of KDevelop got my eye. It
highlights local variables in different colors in the same context,
so something like int foo(float bar, float baz) {
}
will have bar and baz in different colors. Also, support for CMake in
KDevelop got really great and useful. Plus, it supports debugging
inside the editor. Its awesome.
If you want something in a gui, what about Code::Blocks? It's also
multi-platform
Ok, what are the atom names for all these? I'll start them building,
and they should be done before I get home. (Not so likely if I have to
build all of KDE, but I've got some Qt apps installed, so...)
As Nikos mentioned, I would try qtcreator (dev-util/qt-creator) before
kdevelop (dev-util/kdevelop).
--
Joost
Re: [gentoo-user] udev + /usr
On Monday, September 12, 2011 10:24:05 PM Alex Schuster wrote: 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. What about dependencies for: /var/lock/lvm/. (For LVM-operations) /var/run/dbus/system_bus_socket (Isn't dbus going to be part of systemd?) To me, this seems like either these need to be moved to /, or there is a dependency for /var. 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. The migration to openrc went fine for me when it went into stable. The only issue I had was that /etc/init.d/net.eth0 didn't exist. That was an easy fix. I'm glad I always have access to the console here. This was also reported quite early in the documentation and mailing lists, which I checked *after* I upgraded one of the xen-domains on the server. This requirement is going to force me to use an init* for all my machines and I need to check how to get this to work for Xen PV-domains. I have managed to avoid using bootloaders for this as I don't store the kernel on the domains themselves. -- Joost
Re: [gentoo-user] udev + /usr
On Tuesday, September 13, 2011 04:18:38 AM Peter Humphrey wrote: 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. You'd still need to keep those updated with current versions and tools. Even for my desktop I find that a non-usable solution. The rescue-systems are nice, for when my system won't boot at all. The likelihood of needing a rescue-cd/usb/... will increase substantially when all partitions need to be mounted even before init starts. Especially as I don't expect an automated tool that will keep the init* updated after EVERY emerge/kernel-compile/ I see a requirement for every ebuild to add the following: *** pseude-code *** if ebuild part of set in init* then rebuild init* *** When the rebuild part ever breaks, the whole boot-process will break. We'll be making Linux worse then MS Windows 95. -- Joost
Re: [gentoo-user] udev + /usr
On Monday, September 12, 2011 04:07:46 PM Michael Mol 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. Since when does NFS need credentials to connect to the server? :) also, why use NTFS on a flash-drive storing the keys, this is simply an example of someone trying to be clever and being far too lazy to properly implement it. It should fail and the error message should read: PEBKAC (Problem Exists Between Keyboard And Chair) 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. In other words, this dev has a god-complex and feels he should fix all that is wrong in this world. He should do his job and fix his error-reporting and documentation to specify that EITHER the people demanding this ensure the scripts run by udev will work with only / mounted or ensure all other required partitions are mounted by init*. Not force all partitions to be available when init starts. 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. Fixing the docs and error-reporting is the logical and least invasive option. -- Joost
Re: [gentoo-user] udev + /usr
On Monday, September 12, 2011 07:31:54 PM Canek Peláez Valdés wrote: 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. Having to specify all these options doesn't show dracut to be very clever to me. It should automatically parse someones configuration and create the required init* to get to a udev-god-supported-version. A tool that does that will make this less invasive. -- Joost
Re: [gentoo-user] [off-topic] - can /var be placed in a separate partition?
On Tuesday, September 13, 2011 03:23:45 PM Daniel Troeder wrote: On 09/12/2011 01:53 AM, Alex Schuster wrote: Francisco Ares writes: Is it possible to have /var in a separate partition, mounted during boot? This is very common. The advantage is that a process filling up the /var directory (which is bad) will not fill the root partition (which would be worse). Just wanted to throw in, that on servers I also create a separate /var/log partition. Reasoning: If your logs fill up /var, than for ex. mysql won't be able to write anymore. So to decouple systems and problems even further I have /var and /var/log on separate partitions, hoping for higher service availability. I actually have seperate partitions for the databases (Postgresql, OpenLdap, cyrus,...) to avoid any service interfering with any other. But the more seperate partitions someone has, the more of a problem this change is going to be. I have yet to find a filesystem that is optimal for all use-cases. -- Joost
Re: [gentoo-user] udev + /usr
On Tuesday, September 13, 2011 04:49:25 PM Neil Bothwick wrote: On Tue, 13 Sep 2011 11:21:22 -0400, Walter Dnes wrote: This is why the whole /usr issue is irrelevant and not a fix at all. All it does is avoid the most common breakages caused by udev trying to run all its rules too early in the boot process. Putting /var on / would fix your example, but what if a rule required access to an NFS mount? Every time you fix one of these breakages, you are kludging around the real problem. How many people really need to run *ARBITRARY* binaries that early in the boot process? The 1% who do shouldn't force the other 99% of us to go with initramfs or a Windows C:\ drive. There is no 1%. The problem is that udev is able to run arbitrary binaries, which has its advantages, but it also has to be started early in the boot process to fulfil its other duties. It is trying to combine these two functions that leads to the need for more than / to be available before filesystems are mounted. And these 2 capabilities should be handled by different processes. Process 1: Populate the /dev-tree Process 2: Run scripts when necessary Process 2 should NOT be started untill after the local filesystems are mounted. I have not seen any realistic use-cases where process 2 should be started sooner. Any script/tool/program that is required to get to the stage where process 2 can run should be either in / or in an init*. Eg. for the use-case where fuse, ntfs-3g, nfs, crypt-setup, are needed to mount the local filesystems, go build an init* and let the rest build more sane environments. -- Joost
Re: [gentoo-user] udev + /usr
On Tuesday, September 13, 2011 06:33:01 PM Canek Peláez Valdés wrote: On Tue, Sep 13, 2011 at 6:10 PM, Michael Schreckenbauer grim...@gmx.de wrote: If gentoo follows fedora on this mandatory initramfs trail, I'll switch to FreeBSD completely. My software works on way more systems than just Linux. That's of course your prerogative. And, as I said before: Linux strives to be much more than Unix, and that means do things differently. If you want to do things the same way that it was done in the last 20 years, maybe Linux is not the best of choices. I read it before, but to be much more then Unix, Linux should be doing things better. Being different is what led to MS Windows' I myself think the new technologies are worth to change the way we did things before. But that's just me. The new technologies have great merit. But, the implementation of it isn't thought through. And maybe I shouldn't even mention it, but I don't use OpenRC. I use systemd. And it works great on Gentoo. Well. Linux only. If I wanted a monoculture, I would use MS-Windows or OSX. Relax man. I mention what I use: I'm not forcing you (or anybody else) to use it. But I repeat (because I said it before) that I care about Linux, and Linux only. If you care about Linux, why do you allow it to be broken in such a fundamental way? -- Joost
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] /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
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
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 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 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
