Re: [arch-general] What happens with extra?
Sergej Pupykin schrieb: ftp://ftp.archlinux.org/extra/os/i686/ has ~140 packages This is known and should be fixed soon. Sadly, it takes a while until everything is rsynced again. signature.asc Description: OpenPGP digital signature
Re: [arch-general] What happens with extra?
Thomas Bächler schrieb: Sergej Pupykin schrieb: ftp://ftp.archlinux.org/extra/os/i686/ has ~140 packages This is known and should be fixed soon. Sadly, it takes a while until everything is rsynced again. Okay, we just found out WHY exactly those packages got removed (an error in our scripts in combination with a pacman update). They were just moved to the cleanup directory, so all we had was move them back (twice, *sigh*). signature.asc Description: OpenPGP digital signature
Re: [arch-general] Painful installation of 4.3 - some general advice needed.
richard terry schrieb: 1) the libjepg.7 vs 62 problem - I've exhaustively tried every solution over the last few hours on the forums and cannot get kmail to work - loads but 'poof; up in smoke once the gui appears On a fresh install, there is no issue with libjpeg at all, there's just the .so.7, nothing else. Didn't try kmail, but I've seen it working. 2) Dolphin - I really liked konqueror - can one still install this as a file browser. I note there is a kdebase-konqueror package, using this > multiple 'file exists in the filesystem' messages I could use a force but god knows what this will trash. Any alternatives. No problems here, kdebase-konqueror is installed here and there was never any conflict. 5) Kwrite ? same applies kdebase-kwrite but is it possible to install under kde4.3? kdebase-kwrite is also installed here. What did you screw up to get all these conflicts? There is no problem with the packages in extra. Overall this has been a very very painful experience. I found the archlinux iso would in no way allow me to partition and format my disk - I created these with an external program > once they were recognised, at other times not, but at the end of the day installation was impossible. Also never seen that. Chakra was kinder to me - recognised the existing partitions, and installed everything (alpha3), mind you no keyboard, so it died at the add user, so I used the arch install disk to boot that system, and manually added users and grub-install. Then every second program seems to whinge about the libjepg thing. Probably chakra installed tons of crap that is out of date or broken. When you install Arch from our repositories, there will be no problem with libjpeg or KDE, so please report these problems to chakra, not us. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Painful installation of 4.3 - some general advice needed.
Ali H. Caliskan schrieb: Well, I'm not a Chakra or kde user but I can say that I quite familiar with the PKGBUILDS of core and extra packages, and needless to say, it's not always consistent most of the times. So stop blaming others and work your ass off when required! Very polite of you. Let me reply with an equally polite "Shut up, when you don't know what you are talking about". None of the packaging problems mentioned in the original post exist in core/extra, there are no file conflicts when using kde from extra, and there is not a single package in extra (and probably also community)that requires or uses libjpeg.so.62. The only explanation I have is: - chakra installs outdated versions of arch packages in combination with kdemod packages which depend on libjpeg.so.6 - chakra installs kdemod, which since extra/kde 4.3 was released don't have proper conflicts= tags, so there will be file conflicts unless you delete the kdemod packages first. All the problems mentioned in this "fresh installation" result from the fact that the system was installed from chakra and has non-official packages on it that induce incompatibilities with the stock package set. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Painful installation of 4.3 - some general advice needed.
Ali H. Caliskan schrieb: ...says the "sweet talker" who knows what he talks about. Why don't you patch your fracking mount as you patch the PKGBUILDS! If there was in fact something broken, you could tell me what it is. But you don't do that, you are simply trolling, that's it. So, what should I patch/fix again? (Not saying that nothing is broken in the repositories, just saying that we are not responsible for any of the breakage the original poster mentioned) signature.asc Description: OpenPGP digital signature
Re: [arch-general] Painful installation of 4.3 - some general advice needed.
Nathan K. Bathory schrieb: On Mon, 17 Aug 2009 16:10:27 +0200 "Ali H. Caliskan" wrote: ...says the "sweet talker" who knows what he talks about. Why don't you patch your fracking mount as you patch the PKGBUILDS! please, please don't disrupt this list with your negativity... i have personally installed kde 4.3 3 twice.. there are no conflicts as the packages are, there was a problem from the day before kde 4.3 was pushed and that apeared to be from kde-unstable packages(4.2.90) which dissappeared the very next day, this caused files conflicts and the remedy, as has been stated may be to remove the existing packages prior to install. You also refuse to help yourself? in your arrogance, a question was asked which might have lead to you issue being resolved and you willfully chose to ignore it. Beware: The original poster in the thread is not the one who replied here. The original poster was friendly all the time, sadly he only posted once and never got back to us. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Problems with install Iso
richard terry schrieb: I tried to ask this a couple of days ago and for some reason it ended up as a flame war about chakra between people I don't even know and I'm not sure what triggered it, so I'll try again. Sorry about that, it happens. However, this post has more details about what exactly failed in OUR installer, so Dieter will probably reply later. I've used arch for many years and always been happy (I actually run it on 5-6 machines which I maintain ok). My laptop got a libreadline file problem after upgrading, so after backing up I just decided to reformat the drive the the latest arch linux iso I downloaded last weekend intending hence to use kde4.3, and have been spectacularly unsuccessful in getting the drive formatted using the install iso. with the /arch/setup program I tried auto to do the whole drive (it was a brand new seagate 500gig HDD) > no action, just sat there. I tried using CFDISK > create partitions > then the setting the mount points didn't recognise any partitions were there. After a couple of reboots and retries it did recognise the partition was there, but wouldn't let me allocate mount points. On one occasion it allowed me to allocated mount points but then just died. As I said, Dieter will be the most competent to help here, I don't know the exact cause and all, but I might be able to offer you an ugly workaround: As you seem to be good with Linux and Arch, you can try the following: - Boot the Arch install CD, partition everything as you like it and mount it manually before even launching /arch/setup - Skip all "mount partitions" steps in /arch/setup and simply proceed to the package selection/installation. - Adjust your fstab manually after you finished installing This used to work in our old installer once you found out where /arch/setup wants its destination to be mounted. I don't know if AIF has safeguards to prevent you from installing without letting it mount partitions before (If it does, you can comment them out in the script, the live system is read/write). The fact that AIF doesn't allow you to select the newly created partitions looks very much like a bug. I'll wait until Dieter has time to reply. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Problems with install Iso
Thomas Bächler schrieb: As you seem to be good with Linux and Arch, you can try the following: - Boot the Arch install CD, partition everything as you like it and mount it manually before even launching /arch/setup - Skip all "mount partitions" steps in /arch/setup and simply proceed to the package selection/installation. - Adjust your fstab manually after you finished installing This used to work in our old installer once you found out where /arch/setup wants its destination to be mounted. I don't know if AIF has safeguards to prevent you from installing without letting it mount partitions before (If it does, you can comment them out in the script, the live system is read/write). The fact that AIF doesn't allow you to select the newly created partitions looks very much like a bug. I'll wait until Dieter has time to reply. Instead of "/arch/setup", please try "/arch/aif -p interactive -d" and save/upload the log files from /var/log/aif/ that will be created. That will be useful in any case. signature.asc Description: OpenPGP digital signature
Re: [arch-general] bluetooth pairing with cellphone
Dieter Plaetinck schrieb: I have a system where everything is up to date, bluez is installed etc. the configs are all pretty much default. I did need to enable HID2HCI_ENABLE="true" in /etc/conf.d/bluetooth otherwise the bluetoothd daemon would abort immediately after startup ( ? ) Your bluetooth dongle shows in the system as a HID device. This allows operating systems that are not bluetooth-aware (or even the bootloader) to use a bluetooth keyboard or mouse. hid2hci switches your bluetooth dongle to HCI mode, so you have full bluetooth functionality. I've never had such a dongle before. ERROR:dbus.proxies:Introspect error on org.bluez:/: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 2 matched rules; type="method_call", sender=":1.33" (uid=1000 pid=5982 comm="/usr/bin/python /usr/bin/blueman-manager ") interface="org.freedesktop.DBus.Introspectable" member="Introspect" error name="(unset)" requested_reply=0 destination="org.bluez" (uid=0 pid=4642 comm="/usr/sbin/bluetoothd ")) This error is different from the one we had on the weekend. Probably because none of us thought about "ps ax|grep bluetoothd" do i need to be in some kind of group or something? There was no post install message, nor info about this on the wiki page (http://wiki.archlinux.org/index.php/Bluetooth) I still think this is some dbus permission stuff, but that is voodoo for me. 2b) if I run blueman-manager as root I can pair (hooray). But actually I don't want to run stuff as root, nor do I want to use the bloatware that is blueman-manager. You only need to pair once, so you don't need root for now. However, it would be nice to do the next pairing without it. signature.asc Description: OpenPGP digital signature
Re: [arch-general] which package provides ifup & ifdown command ?
Partha Chowdhury schrieb: i cannot find ifup and ifdown in any of the paths- not as a normal user nor as root user. only command i can use is ifconfig. so i was wondering which package provides these two binaries ? alias ifup='/etc/rc.d/network ifup' alias ifdown='/etc/rc.d/network ifdown' There you go. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Script for finding and "moving" older duplicate packages from /var/cache/pacman/pkg
Patrick Brisbin schrieb: A while back i wrote a similar script which extracts the .PKGINFO file from each package in one's cache. slow, but I think this is a more accurate way to compare versions. We had that discussion on arch-dev-public a while ago. makepkg always puts .PKGINFO to the beginning of the tarball. Also, tar and bsdtar both have options to ensure that after the file is found, they stops extracting - therefore, the .PKGINFO file will be extracted instantly, independent of package size. Look at the tar or bsdtar manpages, unfortunately I forgot exactly how it works. signature.asc Description: OpenPGP digital signature
Re: [arch-general] introducing kernel26-lts
David C. Rankin schrieb: > How do you handle the situation where you are running the nvidia driver on the normal kernel and then boot to the lts kernel? The kernel boots fine, but X is dead, presumably because the nvidia driver isn't compiled against that kernel and laughs when you tell it to start. You don't. It's a kernel meant for servers, there won't be any module packages for it. A machine that needs the nvidia driver is not a server. Any way of having a separate driver in the lts kernel module tree? To do that would you just install the nvidia driver again while the lts kernel is running and have it get put in the right place? There's a PKGBUILD for nvidia, you can make it nvidia-lts with a few simple modifications. But again, you miss the point of this kernel package. signature.asc Description: OpenPGP digital signature
Re: [arch-general] arch-release
Gerhard Brauer schrieb: Neat! Or the percentage of our roadmap to world domination (BTW: i always missed this in Roadmap on Flyspray) It's not nearly complete. Right now, Arch runs on a very small percentage of computers world-wide. We need at least 20% until we can inject our world-domination-ware (wdm) into glibc. Also, the wdm is not nearly finished, I'll set up a public git repository soon so the community can help. signature.asc Description: OpenPGP digital signature
Re: [arch-general] 404 on 'view svn entries' in package details on archlinux.rog
solsTiCe d'Hiver schrieb: hello, when you click on 'View svn entries' on quite a few package in details on archlinux.org, you end up on 404 page. is it a side effect of the massive package deletion reported some time ago ? is it another quirk or hiccup, or server migration ? This is due to archweb being unable to set the root correctly for community packages, as they are in a separate SVN repository. However, even if that got fixed, http://repos.archlinux.org/viewvc.cgi/?root=community still doesn't work for other reasons which I won't get into right now. Suffice it to say that at least this second part should hopefully be fixed after the weekend, as there will be some work going on on the servers (it's not been announced yet what will happen, so I won't mention the details here, there should be an announcement soon). signature.asc Description: OpenPGP digital signature
Re: [arch-general] Problem with udev 145?
Sebastian Schwarz schrieb: I can also confirm this. I have exactly the same problem here. One of my two external encrypted USB drives doesn't have a /dev/disk/by-uuid symlink with udev-145-1. However all other /dev/disk/by-* links for this drive are present. It is always the same drive that is affected. And it is only the by-label link for this drive which is missing. I am several hundred kilometers away from the machine in question, so debugging is impossible. It's an external drive for you, so can you run: udevadm --kernel --udev --env and then plug it in? Maybe we can find the problem in the output. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Problem with udev 145?
Sebastian Schwarz schrieb: I forgot to mention that I do not use any custom udev rules. Just Arch's defaults. On 2009-08-29 at 01:43 +0200, Thomas Bächler wrote: It's an external drive for you, so can you run: udevadm --kernel --udev --env and then plug it in? Maybe we can find the problem in the output. Here you go. Hope it helps: Can't see anything here. Can you call blkid /dev/sdb1 (or whetever the partition is)? Should return something like: /dev/sda6: UUID="a008dfd5-385b-4c24-81e1-5f741132c400" TYPE="crypto_LUKS" signature.asc Description: OpenPGP digital signature
Re: [arch-general] Problem with udev 145?
Sebastian Schwarz schrieb: On 2009-08-29 at 13:52 +0200, Thomas Bächler wrote: Can't see anything here. Can you call blkid /dev/sdb1 (or whetever the partition is)? The following command for the partition in question did not output anything: $ blkid /dev/sdc1 Yes, I am sure this is the right device file. :) $ ls -l /dev/disk/by-id/usb-Maxtor_OneTouch_III_00F3127F-0:0-part1 lrwxrwxrwx 1 root root 10 2009-08-29 11:01 /dev/disk/by-id/usb-Maxtor_OneTouch_III_00F3127F-0:0-part1 -> ../../sdc1 This is what I get for my other external hard drive: $ blkid /dev/sdd1 /dev/sdd1: UUID="87536fef-2136-4341-ac23-ceff7d220c07" TYPE="crypto_LUKS" So we narrowed the problem down. Does cryptsetup luksDump show the UUID for both of them. And cryptsetup luksUUID? I'll have to look into blkid and see why it fails. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Problem with udev 145?
Sebastian Schwarz schrieb: On 2009-08-29 at 14:26 +0200, Thomas Bächler wrote: So we narrowed the problem down. Does cryptsetup luksDump show the UUID for both of them. And cryptsetup luksUUID? I'll have to look into blkid and see why it fails. Yes, both luksDump and luksUUID show the UUIDs for both drives. http://thread.gmane.org/gmane.linux.utilities.util-linux-ng/2563 So, this is what happens. Input is welcome :) signature.asc Description: OpenPGP digital signature
Re: [arch-general] Problem with udev 145?
Sebastian Schwarz schrieb: As I had nowhere enough space to backup the hard drive and recreate the LUKS volume I was desperate enough to use the dd method Karel Zak mentioned in his second post: # dd if=/dev/zero of=/dev/sdc1 bs=1 seek=1080 count=2 conv=notrunc It worked just fine on the (former ext3) partition. blkid now reports the UUID correctly and the /dev/disk/by-label link for it is created when plugging in the USB drive. # blkid /dev/sdc1 /dev/sdc1: UUID="e3c24abf-143a-4d84-92b1-113f02a49a16" TYPE="crypto_LUKS" Haha, nice. However I've come to wonder what the correct partition type for LUKS might be. Usually I use just 83 (Linux), but I also have an encrypted swap partition of type 82 (Linux swap / Solaris). Both work. Linux completey ignores partition types, it's that simple :) signature.asc Description: OpenPGP digital signature
Re: [arch-general] A little weirdness at boot time
Tom K schrieb: SImplest, most Arch-like solution is to load the modules in the required order in the rc.conf MODULES array. I hope that's what you mean by "manually". :) With the asynchronous "trigger && load MODULES=() && settle", there is no way anymore to ensure module loading order! You need to fix this using persistent naming schemes, which is easy for network interfaces. It is also easy on alsa devices (index= option) and hard drives (uuid, label symlinks). signature.asc Description: OpenPGP digital signature
Re: [arch-general] A little weirdness at boot time
JM schrieb: There appears to be an optional udev rule to sort this out (/etc/udev/rules.d/75-persistent-net-generator.rules.optional). Since I removed the ".optional" from the filename I am no longer experiencing this issue. However, this file is not described in the wiki and no one at #archlinux could explain to me what it does. Seems to work, though. It's an upstream udev rule file, we just rename it as it seem so un-Arch. People who want these generated rules can rename it. signature.asc Description: OpenPGP digital signature
Re: [arch-general] An evil idea --- use Git to manage the repositories
goodme...@gmail.com schrieb: Is it possible? advantage: 1 The mirrors do not need download the total new pkgs if it just updated several files. 2 old versions of package can be retrived. 3 GIT is fast. 4 It seems cool! dis-advantage: 1 It is a torture of GIT 2 Huge of works to be done. I don't think git is suitable for maintaining large amounts of binary files. The diffs probably won't be very efficient, so storage size will explode. And - all mirrors use rsync (they also mirror other stuff besides Arch), we can't just tell them all to do it differently. signature.asc Description: OpenPGP digital signature
Re: [arch-general] since the fglrx legacy driver is now static - any will to make a run at getting it to work?
David C. Rankin schrieb: Now with the driver static, I wonder if it might not be worth looking into to see if it is even feasable to try and make it work with the current arch setup. That doesn't change anything. The driver is incompatible with the current Xorg ABI - and if it isn't, be sure it'll be incompatible with the next version for at least half a year. It is also incompatible with the latest kernel - if not, it will be with the next version. ATI completely fails to keep up with Xorg and kernel development and simply sticks to what Ubuntu releases. Nobody in the Arch team will put that kind of effort in a piece of binary-blob software whose upstream maintainer doesn't even care. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Audio cd ripper
o...@larstennstedt.de schrieb: Hello, I am searching for an audio cd ripper for my Arch Linux box and have some questions about that. 1.) K3B fails to encode to mp3 (lame) on my computer maybe because of being an alpha version. Encoding to ogg works fine. Can anyone confirm this behaviour? 2.) If I use soundKonverter (KDE 3 version) from the repos, nothing happend by starting the progress by clicking the button. Did I forget anything to configure? There is an awesome and easy converter in KDE (already in KDE3), but it's invisible since KDE4 (they forgot to add a UI that appears when you insert a CD). Fire up konqueror or dolphin, enter "audiocd:/" into the URL field and feel the love. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Audio cd ripper
Fabian Schölzel schrieb: 2009/9/4 Thomas Bächler : There is an awesome and easy converter in KDE (already in KDE3), but it's invisible since KDE4 (they forgot to add a UI that appears when you insert a CD). Fire up konqueror or dolphin, enter "audiocd:/" into the URL field and feel the love. You can adjust the settings for encoding as well as querys for automatic track tagging in the "Advanced" tab in systemsettings under the category "Audio CD" and "CDDB Retrieval". Yes - however, the default settings are quite good, I don't think I ever changed something here. signature.asc Description: OpenPGP digital signature
Re: [arch-general] archlinux.org/~thomas/autowifi = 404
Rogutės Sparnuotos schrieb: And, after writing the initial question, I've read the man page for wpa_cli: wpa_cli -iwlan0 -a/path/to/wpa_action_script.sh seems to be able to fully replace autowifi, except for logging to syslog. Need to test this more, though. It doesn't when your AP is broken. I had the following problem: My old AP sometimes would drop the connection, and immediately re-establish it. This lead to the problem that action_script was called twice within less than a second (which in the end got me stupid race conditions). autowifi is more advanced than wpa_cli: If you get disconnected from the AP, it assumes that you are still connected for a small timeout (default 20 seconds iirc) and only then calls the disconnect event. If you reconnect to the same AP within this timeout, nothing happens. I have had way less trouble with this setup than with wpa_cli. BTW, this trick has been stolen from ifplugd, which also has a timeout before calling the disconnect event. signature.asc Description: OpenPGP digital signature
Re: [arch-general] [signoff] device-mapper & lvm2 2.02.52
Eric Bélanger schrieb: Hi, device-mapper & lvm2 2.02.52-1 are now in testing. Update: - Minor upstream update: lvm2: 2.02.48 -> 2.02.52 device-mapper: 1.02.33 -> 1.02.37 - Implemented split package. For this to work, I had to set the package version of device-mapper to 2.02.52 as I found out that the dbscripts can't handle split packages with different pkgver. -Renamed pkgconfig file (close FS#15909) Please test and signoff. Users signoff would be appreciated as very few dev uses this. Looking fine, /arch/signoff64 signature.asc Description: OpenPGP digital signature
Re: [arch-general] dd and bash_completion
Thomas Göbel schrieb: Hi all, i noticed that bash_completion and dd do not work together. Tiping dd if=/h will not complete to if=/home. Without bash_completion everything works fine. Maybo someone knows how to fix this? Same here. If you come up with a fix, tell me. signature.asc Description: OpenPGP digital signature
Re: [arch-general] dd and bash_completion
goodme...@gmail.com schrieb: I have the same problems. Maybe it is a good design? After all, dd is a danger cmd It is supposed to work if you look at /etc/bash_completion and search for _dd. signature.asc Description: OpenPGP digital signature
Re: [arch-general] dd and bash_completion
Alessandro Doro schrieb: On Wed, Sep 23, 2009 at 01:15:25PM +0200, Thomas Göbel wrote: Hi all, i noticed that bash_completion and dd do not work together. Tiping dd if=/h will not complete to if=/home. Without bash_completion everything works fine. Maybo someone knows how to fix this? After these updates: [2009-09-24 13:23] upgraded bash (4.0.028-1 -> 4.0.033-1) [2009-09-24 13:23] upgraded bash-completion (1.0-2 -> 1.0-3) completion of file/directory names after if= works here. The completion of the dd command line options doesn't work. The difference is in the bash package: We now also load bash_completion by default in non-login shells, while it only happened for login-shells before. signature.asc Description: OpenPGP digital signature
Re: [arch-general] dd and bash_completion
Xavier schrieb: Before this update, bash completion was enabled by default only for login shells. After this update, only for non login shells. Wrong. /etc/profile.d/bash_completion.sh still exists and is executed for login shells. signature.asc Description: OpenPGP digital signature
Re: [arch-general] dd and bash_completion
Xavier schrieb: On Thu, Sep 24, 2009 at 2:32 PM, Thomas Bächler wrote: Xavier schrieb: Before this update, bash completion was enabled by default only for login shells. After this update, only for non login shells. Wrong. /etc/profile.d/bash_completion.sh still exists and is executed for login shells. in 1.0-3 ? http://repos.archlinux.org/viewvc.cgi/bash-completion/repos/extra-any/PKGBUILD?r1=43692&r2=52863 Oh, I still seem to have 1.0-2 here, my bad. signature.asc Description: OpenPGP digital signature
Re: [arch-general] dd and bash_completion
Xavier schrieb: I just tried git, before realizing there was a good pkgbuild for it : http://aur.archlinux.org/packages.php?ID=27520 and it does not work either. I also checked the git code for dd and it is identical to the 1.0 code. signature.asc Description: OpenPGP digital signature
Re: [arch-general] dd and bash_completion
Aaron Griffin schrieb: And this appears to be fixed in git http://code.phraktured.net/cgit.cgi/bash-completion/commit/?id=f733e71e1f8d63c072a402346d8162f9c6b63ae2 http://code.phraktured.net/cgit.cgi/bash-completion/commit/?id=f871fe4101ed89cb98e201aed8c975fd3061905b I can confirm this is fixed. I wonder if it might be a good idea to switch bash_completion back to git snapshots now that development is more active, yet their releases are few and far between Haha, I cloned this morning and it was still broken :) Anyway, I'm fine with having bash_completion git snapshots. signature.asc Description: OpenPGP digital signature
[arch-general] [signoff] kernel26 2.6.31.1-1
Kernel is in testing for both architectures, please sign off (at least one for x86_64, two for i686). I think tpowa had the kernel all ready to move to core, except he was waiting for the .1 release, which is there now. The only thing bugging me is http://bugs.archlinux.org/task/16149, opinions? signature.asc Description: OpenPGP digital signature
Re: [arch-general] [signoff] kernel26 2.6.31.1-1
Damjan Georgievski schrieb: Just be aware of this problem http://bbs.archlinux.org/viewtopic.php?pid=627145 This Arch user lost /dev/tty0,1,2,3 device nodes on boot with 2.6.31 from the Arch testing repositry. A friend of mine also had the same issue with a self compiled 2.6.31. On my laptop the same config works just fine - the only difference is he uses highmem=4G, while I don't - I only have 1G ram.. Even our hardware is allmost the same (thinkpad X60s his is an USA model mine is a EU model). The problem is mentioned here too http://lkml.org/lkml/2009/9/24/444 but there hasn't been any response. I was unaware of this, as there is no bug report assigned to me about it. Does this also happen with 2.6.31.1? signature.asc Description: OpenPGP digital signature
Re: [arch-general] [signoff] kernel26 2.6.31.1-1
Damjan Georgievski schrieb: The problem is mentioned here too http://lkml.org/lkml/2009/9/24/444 but there hasn't been any response. I was unaware of this, as there is no bug report assigned to me about it. Does this also happen with 2.6.31.1? yes there's a bit of discussion here... but, afaik, the patch linked after several back-and-forths didn't actually solve the problem for sure. http://lkml.org/lkml/2009/9/24/167 The commit mentioned here happened just a few days ago, way after the 2.6.31 release, so how can it even be related to the problem? Without a full dmesg from a failed boot attempt, we cannot say anything. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Thunderbird
Ondřej Kučera schrieb: Hello, I've been meaning to ask. What's going on with the thunderbird package? Version 2.0.0.23 was released more than month ago, it isn't usual with Arch for such a package to be left outdated for so long (especially since it is a security update). I know I can use ABS and rebuild it myself and I have, but still. Is there a particular reason for the delay? Shouldn't a bug report be created (when package remains out of date for this long)? I just found this out today as well and was wondering the same thing. Probably Jan had no time or forgot. If I get to it, I can try and rebuild it tomorrow. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Thunderbird
Thomas Bächler schrieb: Ondřej Kučera schrieb: I've been meaning to ask. What's going on with the thunderbird package? Version 2.0.0.23 was released more than month ago, it isn't usual with Arch for such a package to be left outdated for so long (especially since it is a security update). I know I can use ABS and rebuild it myself and I have, but still. Is there a particular reason for the delay? Shouldn't a bug report be created (when package remains out of date for this long)? I just found this out today as well and was wondering the same thing. Probably Jan had no time or forgot. If I get to it, I can try and rebuild it tomorrow. I took the liberty of rebuilding thunderbird, sorry for the delay. It appears Jan had serious time issues and doesn't use thunderbird himself. Packages are up in extra. signature.asc Description: OpenPGP digital signature
Re: [arch-general] let's discuss /srv again
Sergej Pupykin schrieb: I do not want to split packages into /etc, /usr/share and /var folders with kludge symlinking. Would it be good if I replace /srv/http with /var/www/ or something like this? I would say, use /usr/share/www/ (or similar) for static/php files, and provide proper configuration files that set the correct Alias and Directory directives for popular servers like apache and lighttpd. Users can then use Include directives (in case of apache) to load those confighuration files and enable the web app. signature.asc Description: OpenPGP digital signature
Re: [arch-general] let's discuss /srv again
Sergej Pupykin schrieb: >> I would say, use /usr/share/www/ (or similar) for static/php files, and provide proper configuration >> files that set the correct Alias and Directory directives for popular servers like apache and >> lighttpd. Users can then use Include directives (in case of apache) to load those confighuration >> files and enable the web app. It is good idea, but it needs patching for most of webapps because of webapps configs should be in /etc and user data - in /var by default. Patching them is overkill, it would be an example of the unnecessary patching we do not want in Arch. I would keep them self-contained, no matter which solution will be used in the end. I wouldn't even have such a big problem with having configuration in /usr/share/www/phpmyadmin/config.inc.php or so. In any way, filling /srv with data from pacman is a bad idea, /home and /srv should be user territory only. signature.asc Description: OpenPGP digital signature
Re: [arch-general] let's discuss /srv again
Sergej Pupykin schrieb: >> Patching them is overkill, it would be an example of the unnecessary patching we do not want in >> Arch. I would keep them self-contained, no matter which solution will be used in the end. I >> wouldn't even have such a big problem with having configuration in >> /usr/share/www/phpmyadmin/config.inc.php or so. >> In any way, filling /srv with data from pacman is a bad idea, /home and /srv should be user territory only. It is not problem for user, but as I understand it should not be modificable files in /usr/share/ There are many "should"s here: - You should not unnecessarily patch applications. - You should not fill /srv or /home with pacman data - You should not put user-modifiable files in /usr/share The last "should" is IMO the weakest of all. You can easily avoid violating the first two though. I would say this is the best solution, but it would be great to have some more opinions from other devs and TUs here, maybe even some from our overlord. As for not packaging phpmyadmin and similar: I am with Dieter here, a webapp shouldn't include a package manager, we should rather use the existing package manager to track the webapp if we want to - so IMO it is legitimate to have these things in pacman. I'll also provide a short example of a /etc/httpd/conf/extra/httpd-phpmyadmin.conf file: # phpMyAdmin Alias /phpMyAdmin /usr/share/www/phpmyadmin AllowOverride None Options None Order allow,deny Allow from 127.0.0.1 If you also include a similar file for lighttpd, it should be fine. signature.asc Description: OpenPGP digital signature
Re: [arch-general] let's discuss /srv again
Sergej Pupykin schrieb: I put new phpmyadmin into community-testing To use it you should: - add FollowSymlinks options - append directories to php.ini open_basedir = /usr/share/webapps/:/etc/webapps - change web-alias to /usr/share/webapps/phpMyAdmin What do you think about this solution? (I hope all webapps can be adjusted with symlinking) Ugh, I forgot the open_basedir problem. I'll look at what you did and will comment on it later. Generally I don't like having FollowSymlinks enabled. signature.asc Description: OpenPGP digital signature
Re: [arch-general] archweb isn't updating its record.
Aaron Griffin schrieb: Looks like it was just a timing thing. The DB is only updated every hour. I ran the script manually and it succeeded. And the packages are only synced from sigurd to gerolde every hour, half an hour or so. So it might take a while until they show. signature.asc Description: OpenPGP digital signature
Re: [arch-general] VPS hosting with Arch
Dan McGee schrieb: 3. We aren't using an Arch dom0 on our main (virtualized) Arch server, so you probably shouldn't either. :) The domU is Arch, however, running the Debian provided domU kernel. That will probably change: I will test if a 2.6.31.2 pv_ops Xen kernel will work as domU. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Plasma segmentation faults
Lars Tennstedt schrieb: Hello, Plasma crashes several times a day on my Arch Linux installation (32 bit) with a segmentation fault and recovers immediately. The problem has been occured since the release of version 4.3.0. I did not remember such a problem using version 4.2.x. My system is up-to-date, installed software is taken only from the official repositories core, extra and community, the desktop effects are enabled and the graphics card driver is the nvidia closed source one. There is no bug report about this on bugs.archlinux.org. Does anybody have similar problems? Plasma crashes once a week or so here, maybe even less. Using intel opensource drivers, DRI2 and effects enabled. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Which security setting in Arch prevents forwarding X apps when su root?
David C. Rankin schrieb: Listmates, Which setting in Arch prevents forwarding apps when you ssh -X in an Arch box, su and then try to start a kde app, etc.? X forwarding works just fine as a user, but when trying it su'ed to root, I get the following error: [23:29 archangel:/etc] # kwrite X11 connection rejected because of wrong authentication. kwrite: cannot connect to X server localhost:10.0 kdm config? X config? Any pointers/links would be appreciated. The suggestions made so far are either dangerous (xhost) or complicated (xauth, sux, kdesu, ...). You can have pam handle your authentication cookies if you add the following line to /etc/pam.d/su: session optional pam_xauth.so Now, run "su" or "su -" to get root, and it will have access to X. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Master mode and Intel 4965AGN
Adam Lloyd schrieb: The issue seems to be that the card won't enter master mode. Trying to set it up manually with `iwconfig wlan0 mode master` results in "SET failed on device wlan0 ; Invalid argument." (As an interesting side note, I can easily put it into ad-hoc, managed, or even monitor mode this way.) Intel doesn't support master mode for their cards. signature.asc Description: OpenPGP digital signature
Re: [arch-general] /dev/tty* borked ...
Firmicus schrieb: Hi folks, My system is uptodate with the current testing repo. During bootup today I noticed the error message: /etc/rc.sysinit: line 364: /dev/tty[0-9]*: no such file or directory To my surprise, only /dev/tty was present, but none of tty0..9. Instead there was a device literally named '/dev/tty[0-9]*' !! I deleted the latter, and attempted to create the missing ones with mknod. But I think I took the wrong major number, and now my system has started to behave a bit crazy... Any idea what I should do to restore it to sanity? Thanks, F rm -f /etc/udev/rules.d/udev.rules signature.asc Description: OpenPGP digital signature
Re: [arch-general] /dev/tty* borked ...
Xavier schrieb: Unfortunately we can no longer check the cvs repo afaik. We cannot see earlier than April 2008 : http://repos.archlinux.org/viewvc.cgi/udev/trunk/PKGBUILD?view=log I am also curious to know how did that file stay. Why wasn't it tracked and removed by pacman ? The old cvs-arch and cvs-core are still around somewhere, but not public. signature.asc Description: OpenPGP digital signature
Re: [arch-general] /dev/tty* borked ...
Aaron Griffin schrieb: On Fri, Oct 9, 2009 at 7:20 AM, Thomas Bächler wrote: Xavier schrieb: Unfortunately we can no longer check the cvs repo afaik. We cannot see earlier than April 2008 : http://repos.archlinux.org/viewvc.cgi/udev/trunk/PKGBUILD?view=log I am also curious to know how did that file stay. Why wasn't it tracked and removed by pacman ? The old cvs-arch and cvs-core are still around somewhere, but not public. They used to be listed in viewvc. Did we kill that off with the server move? Yes, I found it confusing to have so many repositories with different names, there was nothing to uniquely point out that all the CVS stuff was historical. We don't even have CVS installed anymore. signature.asc Description: OpenPGP digital signature
Re: [arch-general] can't unlock a luks encrypted partition. (urgent).
Hussam Al-Tayeb schrieb: Hi, I'm having a problem with disk encryption using luks. I have my /home disk (on a separate disk 'sdb') encrypted using luks. I have this in /etc/cryptsetup home/dev/sdb1 ASK and this in /etc/fstab /dev/mapper/home /home ext4 defaults,user_xattr 0 1 Suddenly today, it won't accept the passphrase on boot. I'm sure that I'm entering it correctly. It took me 32 tries the first time and many more the second reboot after kernel 2.6.31.3 update. I don't really know what's happening right now. However, you should comment out that crypttab line, mark /home as noauto in fstab, boot your system and try unlocking there manually. That way, it will be much easier to investigate the problem. signature.asc Description: OpenPGP digital signature
Re: [arch-general] can't unlock a luks encrypted partition. (urgent).
Heiko Baums schrieb: Well, I can't say anything about this issue, but I'd like to suggest not to move kernel26 2.6.31.3 from testing to core, until this issue is fixed, because I think this is a major issue, if it's really kernel related. It is very unlikely to be kernel related. And 2.6.31 has been in testing far too long, it should really be moved. signature.asc Description: OpenPGP digital signature
Re: [arch-general] can't unlock a luks encrypted partition. (urgent).
solsTiCe d'Hiver schrieb: i am beginning to think there really is a problem. i have a luks encrypted partition that i automatically mount at boot via /etc/crypttab with a *keyfile* so this has never failed and it can't fail except if the keyfile is damaged. and today the luks partition failed to be opened for the *first* time *ever* by cryptsetup because of a password problem. once i rebooted it worked. so the keyfile is not wrong. and i double check it with my backup keyfile this looks like your problem Hussam. it sometimes fails sometimes works. When did any of you guys upgrade to cryptsetup 1.0.7? Can you grep this from pacman.log please? signature.asc Description: OpenPGP digital signature
Re: [arch-general] can't unlock a luks encrypted partition. (urgent).
solsTiCe d'Hiver schrieb: it has been sometime ago # grep cryptsetup /var/log/pacman.log [2008-07-16 11:03] upgraded cryptsetup (1.0.6-1 -> 1.0.6-1) [2008-10-08 14:29] upgraded cryptsetup (1.0.6-1 -> 1.0.6-2) [2009-06-19 21:52] upgraded cryptsetup (1.0.6-2 -> 1.0.6-3) [2009-08-10 14:52] upgraded cryptsetup (1.0.6-3 -> 1.0.7-1) So that's not it. 1.0.7 should be working better anyway. Sadly, a viable debug option has only been introduced in 1.1.0rc1 afaik, 1.0.7 doesn't have anything that will help here. We need to find out where exactly it fails. Maybe I could write an email to Milan Broz about this, because I am out of ideas. signature.asc Description: OpenPGP digital signature
Re: [arch-general] can't unlock a luks encrypted partition. (urgent).
Hussam Al-Tayeb schrieb: I compiled 1.1.0rc2 then copied cryptsetup libcryptsetup.so libcryptsetup.so.1 libcryptsetup.so.1.0.0 to /tmp/testfolder then cd /tmp/testfolder then LD_LIBRARY_PATH=./ ./cryptsetup --debug luksOpen /dev/sdb1 home and it unlocks it correctly everytime! Nice. I suggest you upgrade to 1.1.0rc2 then (changes to the PKGBUILD should be trivial). I hope it won't break anything for you further. If the problem stays away with 1.1.0, that is solution enough for me. If it returns, we need to really find out what's wrong. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Arch Linux installation only with pacman
Ciprian Dorin, Craciun schrieb:
Hello all!
I remember looking at the installation script about one year ago,
and all it had done (to install the base packages), was to use pacman.
Now if I try to use the same procedure now (or what I remember from
it), I get a lot of errors from the install hooks (script-lets). I've
tried to install them once without by disabling scriptlets, and then
once more by using them, but the errors are still there.
So my question is: how can I install Arch Linux now, by having
only a static built pacman? (I want to use this for an automated
installation procedure for virtual machines.) (I think I've tried the
procedure on the Wiki page with the same outcome.)
Thanks,
Ciprian Craciun.
P.S.: Maybe it's Ok to have those scriptlet errors?
Install to /mnt as root (provided you have a working pacman.conf in .)
# mkdir -p /mnt/var/lib/pacman/{local,sync}
# ./pacman.static --root /mnt --config ./pacman.conf -Sy base
That's it, all you need to do is configure the system (you need to know
how) and install a bootloader. I did this recently and the system worked
(it was a test system though, it's not in any productive use).
There will be _some_ errors from scriptlets in the beginning, but those
should be fine - you can paste the output here in case you are unsure.
signature.asc
Description: OpenPGP digital signature
Re: [arch-general] Arch Linux installation only with pacman
Thomas Bächler schrieb:
Install to /mnt as root (provided you have a working pacman.conf in .)
# mkdir -p /mnt/var/lib/pacman/{local,sync}
# ./pacman.static --root /mnt --config ./pacman.conf -Sy base
That's it, all you need to do is configure the system (you need to know
how) and install a bootloader. I did this recently and the system worked
(it was a test system though, it's not in any productive use).
There will be _some_ errors from scriptlets in the beginning, but those
should be fine - you can paste the output here in case you are unsure.
Forgot something: It might be a good idea to run those commands before
you start:
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
mount --bind /dev /mnt/dev
signature.asc
Description: OpenPGP digital signature
Re: [arch-general] Arch Linux installation only with pacman
Ciprian Dorin, Craciun schrieb:
Thank you all for your feedback! I'm more confident now that I can
just ignore those errors.
One observation though: having dev, proc, and sys mounted in the
new chroot, wouldn't it misslead the scriptlets? Because these special
files would be from the live host machine, and not the guest machine?
(Anyway I could just boot inside the guest machine and have the
installation done there...)
The only thing that really depends on /sys is the autodetection in
mkinitcpio - if you're going to boot this on another machine, you'll
have to boot the fallback initramfs anyway, so it doesn't matter.
I remember some install scriptlets look at files in /proc, but not
having /proc shouldn't make problems either.
The only thing you really need is /dev - or at least some nodes. If you
don't want to bind-mount /dev, you need to create at least /mnt/dev/null
(maybe also zero, not sure). On udev installation,
/dev/{zero,null,console} are created there anyway, but that happens later.
Note that our installer also bind-mounts proc, sys and dev from the live
system to the installation system - it's safe and can avoid problems.
signature.asc
Description: OpenPGP digital signature
Re: [arch-general] packages deleted from db but still on repos
Gerardo Exequiel Pozzi schrieb: And this is a complete list, doing a complete scan for all repos: [ftp://ftp.archlinux.org/community/os/i686/] arora-git-20090531-1.pkg.tar.gz aurtools-1.5.6.2-1.pkg.tar.gz katapult-0.3.2.2-1.pkg.tar.gz knetdockapp-0.82.3-1.pkg.tar.gz libgadu-1.8.2-2.pkg.tar.gz libpq++-4.0-2.pkg.tar.gz libtelepathy-0.3.3-4.pkg.tar.gz libvc-003-1.pkg.tar.gz mplayerthumbs-1.2-1.pkg.tar.gz mtaskbar-0.7-1.pkg.tar.gz mutt_vc_query-002-1.pkg.tar.gz nautilus-locked-folder-1.0.1-1.pkg.tar.gz nilfs-2.0.14-1.pkg.tar.gz pandoc-0.46-1.pkg.tar.gz pizza_party-0.1.b-2.pkg.tar.gz pykde-3.16.2-1.pkg.tar.gz python-notify-0.1.1-5.pkg.tar.gz rolo-011-2.pkg.tar.gz shfs-0.35-13.pkg.tar.gz shorewall-perl-4.2.10.1-1.pkg.tar.gz system-config-printer-gnome-1.1.7-3.pkg.tar.gz testdisk-6.11-2.pkg.tar.gz wlassistant-0.5.7-2.pkg.tar.gz xerces-c-2-2.8.0-1.pkg.tar.gz The above list is also applied to community/os/x86_64/ but only differs on aurtools-1.5.6.2-1.1.pkg.tar.gz The cleanup script doesn't handle packages without the -$ARCH extension properly. That's a legacy we only have left on community, as we switched to the new db scripts there only recently. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Is it possible to move Mumble to community repository?
Lauri Niskanen schrieb: Hello, Mumble [1] is an open source, low-latency, high quality voice chat software. It has a stable version package on AUR [2]. Would it be possible to have Mumble in [community]? Mumble is very popular application and it doesn't have any license issues [3]. It has 216 votes on AUR. Pkgstats reports 8.91 % usage [4]. Having Mumble in official repository would help users installing it and keeping it up-to-date. [1] http://mumble.sourceforge.net/Main_Page [2] http://aur.archlinux.org/packages.php?ID=10221 [3] It's licensed as BSD and GPL. [4] http://www.archlinux.de/?page=PackageStatistics -- Ape With 8,91% usage, this would also be a candidate for extra. You just need to find someone willing to maintain it - I use mumble occasionally, but not on Linux. I am interested in murmurd though, so I'll think about it. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Is it possible to move Mumble to community repository?
Lauri Niskanen schrieb: I would be willing to maintain it myself. But was it so that the maintainer in community or at least in extra must be a TU (or have a special status of some kind)? -- Ape The maintainer has to have ssh access to our repository servers, so yes, only TUs and Devs can do it. signature.asc Description: OpenPGP digital signature
[arch-general] [signoff] iw 0.9.17-1
Upstream update, please sign off (due to the low usage of this package among developers, I also ask users to sign off). signature.asc Description: OpenPGP digital signature
[arch-general] [signoff] openvpn 2.1_rc20-1
Upstream update, please sign off (due to the low usage of this package among developers, I also ask users to sign off). signature.asc Description: OpenPGP digital signature
Re: [arch-general] makepkg git download agent
Ciprian Dorin, Craciun schrieb: Hello all! Just a small question: is there somewhare a download agent for makepkg that uses Git? Thanks, Ciprian. Wouldn't the PKGBUILD-git.proto do what you want? signature.asc Description: OpenPGP digital signature
Re: [arch-general] can't unlock a luks encrypted partition. (urgent).
Hussam Al-Tayeb schrieb: Done! I updated to 1.1.0-rc2 then I also upgraded to kernel 2.6.31.4 After rebooting, things are still fine. /dev/sdb1 unlocked correctly :) Someone else hit this too: http://bugs.archlinux.org/task/16735 My last comment might provide a fix. signature.asc Description: OpenPGP digital signature
Re: [arch-general] CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
Sascha Siegel schrieb:
Hi,
can someone tell my whats the reason for building the arch-kernel with
"# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set"?
Thank you!
Optimizing for size sacrifices performance. Read the gcc documentation
about the -O{1,2,3,s} options.
signature.asc
Description: OpenPGP digital signature
Re: [arch-general] Full system encryption with support for hibernation
Karol Babioch schrieb:
Hi,
I've recently set up full encryption of my system (including swap), but
therefore lost the possibility to suspend my device to disk (hibernate).
The only way mentioned in the wiki is highly not recommended as you
would have to place your key on the unencrypted boot partition, which
basically conflicts the idea of full encryption (see
http://wiki.archlinux.org/index.php/System_Encryption_with_LUKS_for_dm-crypt#Encrypted_swap_with_suspend-to-disk_support).
By looking for some solution, the only thing I could figure out was to
set up lvm, and encrypting the whole lvm partition, which would include
the swap. This way all of my stuff would get unlocked, including the
swap and therefore my system could resume from a former hibernation.
Before setting this up (which will cost some time, as I have to back up,
configure and restore my stuff) I wanted to ask you, whether this will
work as supposed, and if there may be any better solutions?
How do you get both hibernation and full encryption working together?
It is possible. Consider the following setup:
You have two partitions, one small (50MB) /boot /dev/sda1, the rest
/dev/sda2. Now you create a LUKS-Volume in /dev/sda2, let's call this
volume enc. Inside /dev/mapper/enc create a LVM physical volume. Then,
create your root, swap, home, ... filesystems as logical volumes inside
the LVM (let's say they are called /dev/vg/{root,swap,home,...}. That
way, you just need to enter ONE passphrase to be able to access all your
volumes, including swap and root.
The installer (AIF) can set all the above up correctly, however, the
current version will make the wrong grub line. In the described setup,
it should be:
cryptdevice=/dev/sda2:enc root=/dev/vg/root resume=/dev/vg/swap ro
Your mkinitcpio.conf should have the following line:
HOOKS="base udev pata scsi sata keymap encrypt lvm2 resume filesystems"
(note that lvm2 is before resume, not after)
This setup will make it possible to use hibernation on an encrypted
system without a separate key storage and without having to enter more
than one passphrase. It is also a very elegant setup, as you have the
usual advantages of LVM.
Have fun!
signature.asc
Description: OpenPGP digital signature
Re: [arch-general] Full system encryption with support for hibernation
Thomas Bächler schrieb:
How do you get both hibernation and full encryption working together?
It is possible. Consider the following setup:
You have two partitions, one small (50MB) /boot /dev/sda1, the rest
/dev/sda2. Now you create a LUKS-Volume in /dev/sda2, let's call this
volume enc. Inside /dev/mapper/enc create a LVM physical volume. Then,
create your root, swap, home, ... filesystems as logical volumes inside
the LVM (let's say they are called /dev/vg/{root,swap,home,...}. That
way, you just need to enter ONE passphrase to be able to access all your
volumes, including swap and root.
The installer (AIF) can set all the above up correctly, however, the
current version will make the wrong grub line. In the described setup,
it should be:
cryptdevice=/dev/sda2:enc root=/dev/vg/root resume=/dev/vg/swap ro
Your mkinitcpio.conf should have the following line:
HOOKS="base udev pata scsi sata keymap encrypt lvm2 resume filesystems"
(note that lvm2 is before resume, not after)
This setup will make it possible to use hibernation on an encrypted
system without a separate key storage and without having to enter more
than one passphrase. It is also a very elegant setup, as you have the
usual advantages of LVM.
Have fun!
Forgot to add: This is supported out of the box by Arch without any
modifications to mkinitcpio hooks (unlike the other suggested setups).
I have it set up right now, but I only hibernate rarely, I like suspend
to ram better.
signature.asc
Description: OpenPGP digital signature
Re: [arch-general] We have lost the desktop war. The reason? Windows 7.
RedShift schrieb: This thread will probably erupt in a massive flamewar, yet I decided to post my story anyway. I am talking about the desktop experience in general, not the technical details behind it. Keep that in mind. I've been working these past few months with KDE 4.3 and it feels very sluggish and incomplete. I can't enable the desktop effects because that makes things even slower. I'm doing this on a fairly decent setup, an AMD Sempron 2 Ghz with an nVidia FX5500. My laptop suffers from this sluggishness as well. On top of that, lots of things annoy me in KDE 4.3, see the end of this post for my top annoyances. I stopped reading here, as everything after that is probably shit anyway. Suffice it to say: Blame nvidia - KDE4/QT4 is (despite it being supposedly fixed) still amazingly slow on nvidia, my desktop with a 8500GT feels sluggish too. On a bunch of SuSE machines at work (all with nvidia), it is just as slow. On my laptop with intel 2.9, everything is as fast as you can get. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Full system encryption with support for hibernation
vlad schrieb: > Thanks, helpful hints. But does this also work with "suspend-to-ram"? I mean, when suspending to ram everything remains unencrypted? Do I see this right? Suspend to RAM always works - however, there are potential attacks where people freeze your laptop, take out the (frozen) RAM and recover the encryption keys from there. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Encrypted ram disk?
Ciprian Dorin, Craciun schrieb: Just out of curiosity: what solution did you use for full system encryption? And if this thread was started, what solutions do other ArchLinux users recommend? Ciprian. I guess that would be it: http://mailman.archlinux.org/pipermail/arch-general/2009-October/008409.html signature.asc Description: OpenPGP digital signature
Re: [arch-general] Encrypted ram disk?
Tamir Daniely schrieb: >From a technical prospective, reading ram post system shutdown or crash is definitely possible, the data is preserved for several minutes depending on the ram technology, and the time the data can be accessed can be increased significantly by cooling or freezing the ram itself. Yes, this is a problem. It is possible to wipe the encryption key from memory when hibernation has finished or generally before poweroff, but I have no idea if this is done in Linux. What poses a bigger problem is suspending: Your RAM stays powered all the time and contains your encryption key. cryptsetup has (in its latest release candidate) gained a feature where you can "suspend" a volume by killing the encryption key and later "resume" it by reentering the passphrase. I think it should even be possible to combine this with full system encryption, using a chroot with static cryptsetup and a minimal static shell, which would reside either in a tmpfs or on an unencrypted disk. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Why qemu/kqemu conflict to kvm ?
goodme...@gmail.com schrieb: OK, ok, I want install qemu+kqemu and KVM in my machine. Why does they conflict? Sometime, I want my virtual machine run faster, so KVM is a great choice. But sometime, I need simulate other CPU: ppc arm ... , so qemu is the best choice. Why does them conflict? Can the community do some works to let them co-exist in the SAME archlinux installation? KVM works with the qemu package - The "kvm" package just has a newer version of the KVM code than the qemu package. signature.asc Description: OpenPGP digital signature
Re: [arch-general] netcfg
f...@kokkinizita.net schrieb: The one remaining problem is with netcfg 2.2.1. On my laptop I have the drivers e1000 and ipw2200 loaded in rc.conf, providing the devices eth0 and eth1 in fixed order. It's not guaranteed to provide a fixed order any more, you should really look into udev rules or ifrename (there is something included in netcfg for this). For the first I use: CONNECTION="ethernet-iproute" DESCRIPTION="Local ethernet - zita1 router" INTERFACE="eth0" IP="static" ADDR="192.168.2.241" GATEWAY="192.168.2.240" and this works nicely. The only strange thing is that it fails when the interface is not connected. I've never seen this on the systems I used before, and since you can disconnect the network cable and put it back without any ill effect on the interface configuration I'd really expect it to be configured as well if the physical connection is not present. First of all, the whole connection types in the current netcfg are a bit screwed up and not all examples are correct. This should be cleaned up in the git version (which should have been released by now, but James said he had to document it first and then went MIA), and also the examples should be cleaned up. About the actual problem: netcfg checks for the presence of a link and doesn't bring the connection up if no link exists. This is certainly useful for dhcp, but not so useful for static, as you have seen. IMO, this should be optional, but I have no idea if it changed in the git version. For the wireless connection all the examples use dhcp but I need a fixed address. Combining the examples I arrived at: CONNECTION="wireless" DESCRIPTION="Wireless connection at Basilicanova" INTERFACE="eth1" SECURITY="wep" ESSID="lovettanet" KEY="" IP="static" ADDR=192.168.1.241 GATEWAY="192.168.1.1" which fails with: lovetta up SIOCADDRT: No such process Adding gateway failed. Same point, the examples are bit of a chaos. I figured it out once, but I forgot which combination works. That said, it is possible :) signature.asc Description: OpenPGP digital signature
Re: [arch-general] Encrypted ram disk?
Karol Babioch schrieb: On Mi, 2009-10-28 at 18:50 +0100, Thomas Bächler wrote: ryptsetup has (in its latest release candidate) gained a feature where you can "suspend" a volume by killing the encryption key and later "resume" it by reentering the passphrase. Have you more information about this? Would be great to have this working. I know its a little bit paranoiac, but my intention is curiosity whether I can get it working, not the little amount of special security I get ;). http://thread.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/3639 This, and the manpage of the new cryptsetup release candidates. signature.asc Description: OpenPGP digital signature
Re: [arch-general] ssh broken?
Tobias Kieslich schrieb: Hi, I frequently ssh into localhost to sync files with unison. THat seems to be broken after the lates pacman -Syu which removed /var/empty. Is there sombody else who sees the same behavior? -T http://bugs.archlinux.org/task/16886 I'll push a version with [ -d /var/empty ] || mkdir -p /var/empty in the init script tonight. This is the safest way IMO. signature.asc Description: OpenPGP digital signature
Re: [arch-general] how to boot Windows and Arch...
Preston C. schrieb: Thank you Magnus, very much. Windows is on the first SATA port, though. Any difference in the configuration of Grub since Windows is on the first SATA port? That's difficult indeed. Grub will be installed in the MBR of the first disk and as far as I know will need its files to be on the same disk - in a FAT32, ext2/3/4, xfs, jfs, ... (not NTFS) partition. Having Arch on the first BIOS disk including grub is probably easier, but you have to do some magic device-swapping in Windows' grub entry, which will otherwise refuse to start. I don't exactly remember the details. signature.asc Description: OpenPGP digital signature
Re: [arch-general] how to boot Windows and Arch...
Preston C. schrieb: On Fri, Oct 30, 2009 at 4:26 AM, Thomas Bächler wrote: That's difficult indeed. Grub will be installed in the MBR of the first disk and as far as I know will need its files to be on the same disk - in a FAT32, ext2/3/4, xfs, jfs, ... (not NTFS) partition. Having Arch on the first BIOS disk including grub is probably easier, but you have to do some magic device-swapping in Windows' grub entry, which will otherwise refuse to start. I don't exactly remember the details. Do you think I should physically swap the hard disk locations? Such as put Windows on the second SATA port and Arch on the first SATA port? Thanks. Swapping the boot device order in BIOS will do the same. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Encrypted ram disk?
Santhosh Joseph schrieb: For disk encryption, why not use truecrypt ? Why use truecrypt? signature.asc Description: OpenPGP digital signature
Re: [arch-general] Encrypted ram disk?
Santhosh Joseph schrieb: On Fri, Oct 30, 2009 at 4:21 PM, Thomas Bächler wrote: Santhosh Joseph schrieb: For disk encryption, why not use truecrypt ? Why use truecrypt? http://www.truecrypt.org/ You didn't answer my question. We discussed dm-crypt and you suggested to use truecrypt - without relating in any way to the problem being discussed or providing a solution that truecrypt may or may not have for it. Why is that? Can you even boot from a truecrypt-encrypted volume on Linux? If so, is that implemented on Arch Linux? How secure is truecrypt's key setup and how does it work? The only advantage of truecrypt against LUKS is the plausible denialbility feature that LUKS doesn't have, and the "hidden volumes", which IIRC only work with FAT32 file systems on truecrypt and are thus useless. Also, truecrypt has had serious security problems in the past, and instead of fixing them right away and informing the public, they just took the website down for several months until they released a new (on-disk incompatible) version (this is only as far as I remember it though, and I don't have a source for it, but it must have been 3 years ago or so). LUKS has a mathematically/cryptographically well-founded key setup procedure that makes brute force attacks against the passphrase infeasible in pratice and thus provides a very high level of security. It also allows to use any cipher and cipher operation mode available in the Linux kernel, which includes (but is not limited to) the ones provided by truecrypt. signature.asc Description: OpenPGP digital signature
Re: [arch-general] how to boot Windows and Arch...
Preston C. schrieb: Swapping the boot device order in BIOS will do the same. Well that is good news. Now I do not have to open the computer! Magnus I have done some research, your way is right, although, it seems I should do something more like this. With the "map" parameter: # (2) Windows XP title Windows XP map (hd0) (hd1) map (hd1) (hd0) rootnoverify (hd1,0) makeactive chainloader +1 Is the mapping parameter necessary? You have to try. I think it is, but Magnus claims that this is old news. Just pick a configuration that works and stick with it. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Encrypting remote system
Karol Babioch schrieb: Hi, I'm wondering whether there is a possibility to encrypt a remote system using Arch Linux? I have installed Arch on a remote server, and don't like the idea that anyone with physical access to my system has access to my data. So is there something I can do about it? Using dm-crypt (with luks) doesn't work at all, as I can't input the passphrase when I reboot my system, the technician would really hate me if I ask them to attach a remote console each time I reboot my system. So is there anything I can do? I thought about this topic and concluded that security will be the same as without encryption: What is encryption good for? It protects against someone with physical access being able to decrypt your data. Once the machine is running, you'd have to circumvent the usual access control, whether the system is encrypted or not. This security relies on two things: 1) The passphrase ensures that only authorized people can access the data on the drive. 2) Somehow, you need to ensure that you only give the passphrase to the machine it belongs to. The first point would be rather easy, even with a remote system. But the second is the problem. On your desktop or laptop, you verify 2) by looking at it and saying "Yes, this is definitely my machine, so I can give it the passphrase". For a remote machine, you have to rely on cryptography. The security of cryptography is based on the remote machine having a private secret (like a private key to a certificate or a SSH private host key). Now, as we said, encrypting the hard drive is for protecting against people getting physical access to your hard drive. So if someone has physical access to the machine, he/she can easily grab that private secret and perform an effective man-in-the-middle attack and sniff your passphrase - or even better, install a modified cryptsetup binary and make it save the raw encryption key in some place. In other words: You'd have to trust the unencrypted portion of your system to do what you expect it to do - which you can't. That said, such an attack is also easily possible on your desktop or laptop. If someone would steal the laptop, modify your kernel or initramfs and then give it back to you, he/she could have done anything to it to sniff the passphrase as you enter it. In case you can not ensure that the laptop has not been tampered with, you'd have to re-create your bootloader, kernel and initramfs from a trusted source before using it again (also impossible for a remote machine). However, one bit of added security is possible for a remote machine: If someone steals the hard drive without getting to your passphrase first, he/she would not be able to obtain any data. But someone who would simply steal it, wouldn't be interested in your data anyway. Everyone who is interested can (as seen above) easily get it. My conclusion: You should rather concentrate on securing against remote attacks via the network, which are more likely than physical attacks, and you can actually protect yourself effectively against those. signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] Vacation Nov 7th - 14th
Evangelos Foutras schrieb: Does this mean that RAID 1 is used and one of the two drives failed? :) Indeed. Actually, we failed it because performance was crappy due to the slowly dying drive. Also, is there a page describing the current Arch server(s) setup? I remember reading something about Xen being used and I'd be interested in knowing more. I understand this information is only useful to the admins, but I'm curious. Some of it is already out of date, but here it is: http://wiki.archlinux.org/index.php?title=Category:DeveloperWiki:Server_Configuration signature.asc Description: OpenPGP digital signature
Re: [arch-general] Segmentation fault in X after last upgrade
Lars Tennstedt schrieb: Hi, Xorg with nvidia-96xx for a GeForce 3 Ti 200 does not start anymore on my Arch Linux installation (i686). First I thought that it was a failure caused by SLiM because the error output on screen was "respawning too fast" and I switched from respawn to once but that did not help. Even standalone X does not start. I looked into the log file and there were messages about that freetype and kbd cannot be found. But both are installed. Are these problems connected to each other? http://mailman.archlinux.org/pipermail/arch-dev-public/2009-October/014167.html Or better: http://www.nvnews.net/vbulletin/showthread.php?t=139388 I don't know what you think, but I don't get the part where the nvidia dev says they plan to fix it, but he can't promise if and when. So they plan to fix it, but don't really know if they plan to fix it. So basically, you're screwed unless you plan on buying a GeForce 6 or newer. signature.asc Description: OpenPGP digital signature
Re: [arch-general] file system capabilities
Jan de Groot schrieb: This can be done by default, but capabilities aren't preserved when making tarballs. Every capability has to be set from post_install/post_upgrade in such cases. Maybe this is something worth to implement though. Actually, bsdtar preserves them when packing, but upon extracting they are gone. I don't know if we can force pacman to make this work. Maybe, maybe not. On another note: This [1] is something about fs caps, but "part two" didn't get finished, although it's November already. I have some code written to work with capabilities more (capchroot, capsudo), you can find the current status on http://projects.archlinux.org/. capchroot has a crappy config parser, capsudo is better but suffers from some small problems whose details I forgot. Both work though. I was going to explain those tools on "part two", but as I said, I haven't written it yet. [1] http://archlinux.me/brain0/2009/07/28/using-posix-capabilities-in-linux-part-one/ signature.asc Description: OpenPGP digital signature
Re: [arch-general] Cannot set xattr
André Ramaciotti da Silva schrieb: The problem is: I can't use them at all. I'm using the default kernel, which, according to /proc/config.gz has: CONFIG_EXT4_FS_XATTR=y and I'm using ext4, evidently. I've tried doing the following: $ echo 'asd' > test $ attr -s user.author -V andre test attr_set: Operation not supported Could not set "user.author" for test but, as you can see, it doesn't work. Running it as root doesn't work, too. I've also made a small C program, but it also fails to set the xattr, returning ENOTSUP (operation not supported), so it isn't a problem with 'attr'. That's because if you want to use user.* extended attributes on ext2/3/4, you have to mount with the user_xattr mount options. Simply add it to fstab. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Cannot set xattr
André Ramaciotti da Silva schrieb: Thank you Thomas and Xavier. I just got a little worried though. Is there any reason for user_xattr not being enabled by default? Not sure, you may ask the ext2/3/4 developers. I usually enable it on /home, but not on other partitions. IIRC, SuSE enables it by default in fstab. Arch just uses "defaults" for the options, so there is no user_xattr. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Cannot set xattr
Priit Kivisoo schrieb: I just got a little worried though. Is there any reason for user_xattr not being enabled by default? I think it's because Arch doesn't use SELinux by default, as it's mostly for ACLs. Neither selinux nor ACL have anything to do with this options. Read man 5 attr. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Cannot set xattr
André Ramaciotti da Silva schrieb: I'm sorry, I think I wasn't very clear in my question. It isn't the default in Arch Linux because it isn't the default upstream, Probably because we just set "defaults" in fstab and let the user worry about the rest. but why it isn't the default upstream? My worry is that it's somehow related to dataloss, but I couldn't find any search result about it, so I'll assume it's secure. In the worst case, I have my (daily) backups :) It is safe, these attributes just take some space. No idea why they don't want these enabled by default. There are some applications that need those attributes, I think beagle does, not sure. In any case, if you use your own user.* xattr scheme, you should prefix them by something to make sure the names are unique. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Cannot set xattr
Priit Kivisoo schrieb: Neither selinux nor ACL have anything to do with this options. Read man 5 attr. "They are often used to provide additional functionality to a filesystem - for example, additional security features such as Access Control Lists (ACLs) may be implemented using extended attributes." That's what I read. I may be wrong, of course. There are 4 different types of extended attributes, that is also details in man 5 attr. signature.asc Description: OpenPGP digital signature
[arch-general] New NVIDIA legacy drivers compatible with our latest xorg-server
NVIDIA released new prereleases of their 173.xx.xx and 96.xx.xx drivers ([1], [2]). Driver packages and kernel modules for the 2.6.31-ARCH kernel are being uploaded now, they should start to appear on mirrors soon. Please test them and report. [1] http://www.nvnews.net/vbulletin/showthread.php?p=2122688 [2] http://www.nvnews.net/vbulletin/showthread.php?p=2122691 signature.asc Description: OpenPGP digital signature
Re: [arch-general] old firewire stack?
Dieter Plaetinck schrieb: Hi, according to http://www.kdenlive.org/user-manual/troubleshooting-and-common-problems/troubleshooting-firewire-capture we are using an old firewire stack. I'm having big problems with DV-video (firewire) stuff ( see http://bbs.archlinux.org/viewtopic.php?pid=655692 ) and I was wondering if the new stack would fix it, but how can I run it? Last time we visited this topic, the new stack was incomplete and unstable, and it also said so in the kernel configuration menu. As I don't have any firewire devices, I never really cared. Should we dump the old stack and switch to the new one in the upgrade to 2.6.32? signature.asc Description: OpenPGP digital signature
Re: [arch-general] netcfg v2.5 in [testing] - auto wireless configuration has changed
James Rayner schrieb: 1. pacman -S core/wpa_actiond Still testing/wpa_actiond. About wireless: I don't think the rfkill stuff will work like that. You can specify RFKILL_NAME, but that might change over time (it may change everytime you unload/load the wireless module and is not guaranteed to be persistent). If you don't specify RFKILL_NAME, then it will look into /sys/class/net/$INTERFACE/rfkill, which doesn't exist (at least on 2.6.32). Using /sys/class/net/$INTERFACE/phy80211/rfkill*/ as rfkill path should work though. This needs to be addressed before a final release to core. signature.asc Description: OpenPGP digital signature
Re: [arch-general] stability of pbzip2 ?
Ian-Xue Li schrieb: Hi, I'm quote fond of pbzip2's ability to multitask the compression, which comes really handy when backuping large archives of server files. But just heard from my friend: pbzip2 has stability issues, sometimes leads to corruption of archive, and hence unable to recover them. I wonder if this is true (in the sense that anyone once had a problem with pbzip2), because myself had never run into one of them. If so, it really a shame to abandon such a good tool though... I used it occasionally in the past and had no problems. Although I almost never unpacked one of these files. signature.asc Description: OpenPGP digital signature
Re: [arch-general] conclusion: Another rant on arch way abuse and false promises
Arvid Picciani schrieb: Thanks to enough input i have learned two things of this thread: 1) The problem IS upstream related. Some packages do enable dbus when it is available, for the convenience of those users who do not understand what dbus is and hence need it. So every user who wants to use dbus is dumb? Needing dbus is a criterion for not understanding what it is? dbus is something very cool and useful and allows applications to conveniently interoperate, which is something that has to happen in every modern computing environment. Archs philosophy dictates, that if the upstream is retarded, so shall be the package. I used this as argument, and i shall comply to it equally. In a sense yes, but we can make it less retarded to some extent. 2) I am in fact the minority, not those who see linux as a free windows copy. Hence i should Insult number one, watch your step. 2.1) stfu and obey the will of the mass 2.2) find or found a distro that is not based on the will of the mass Arch is not based on the will of the mass, but on the will of the developers who use and develop it. Those developers happen to want cool systems instead of feature-free ones. And you know what? I don't see your problem, because my system works just fine and does everything I want it to exactly like I want it to. For me, nothing else counts. The combination of 1 and 2 invalidates everything i have said in this thread. No, some of the things you have said are invalidated by them being just rants and stupid. Jan did a great job at packaging clearly broken packages in the least harmful He did, yes. way for the majority of users, who happen to have a microsoft windows background. Insult number two. I give you one piece of advice: Apologize for being an asshole. Resorting to calling what you don't like the "Ubuntu way of doing things" and calling the majority of Arch's developers "people with Windows background" doesn't help you here. In fact, I feel personally insulted by these statements. You can either apologize to me now or STFU and get yourself another distro - preferably one whose developers like being insulted like this. It is one thing to discuss the sense and nonsense of how we do things. It is another to be an asshole about it and insult the people who do not share your opinion. And there is one thing that Arch definitely does not need: assholes. And before people start bitching about what I just said: Statements like "Arch is becoming Ubuntu" and "Arch is for users who want a free Windows replacement" (and many similar ones) are made mostly because someone is out of arguments and wants to make the other end of the discussion angry (which Arvid succeeded in). I consider such statements an insult (not because Ubuntu or Windows are evil, but because Arch is very different from either of those and I am quite proud of that) and I will not tolerate such statements. signature.asc Description: OpenPGP digital signature
Re: [arch-general] conclusion: Another rant on arch way abuse and false promises
Arvid Picciani schrieb: like what? maybe you are feeling insecure about it? Yes, I am so insecure. You are right, I am going to kill myself just now. There is a saying in my native language that goes like: "Dogs only bite if you hit their spot." Old sayings like this are usually stupid. The other devs at least managed to respond in professional and calm way, which ultimately convinced me that they are right. Until now, I was professional and managed to ignore this thread completely. But you just had to pull the Windows card. You were trying to convince people that you were right by telling them "either you agree with me or you are just another Windows user who doesn't want to pay". That is not acceptable and breaks the rules of any discussion between grown-ups. Again: Comparisons like that just mean you are out of arguments and are still trying to convince people. Tell me why you think what we do is bad without mentioning Windows or Ubuntu or any comparison to anything and we can talk professionally. but because Arch is very different from either of those and I am quite proud of that and insecure. Okay okay okay, after this e-mail I will definitely kill myself, sorry for keeping you waiting. and I will not tolerate such statements. my address is publicly available. go find me? Don't bother - all I will do is be an ass about it every time. signature.asc Description: OpenPGP digital signature
Re: [arch-general] coreutils 8.1 major problem
Lukáš Jirkovský schrieb: Hi everyone, I've just noticed coreutils 8.1 in [testing] repo and I think I should warn you. Unfortunatelly it has one quite bad regression which can break quite many scripts. There is a change in rm command (it's fixed in git repository) that when you try to remove "" it immediately exits without removing any other specified files. Unfortunately this breaks many scripts and Makefiles(IIRC there's problem with eg. libxt). I suggest NOT to upgrade to coreutils 8.1 before the old behavior is restored. more info: http://lists.gnu.org/archive/html/bug-coreutils/2009-11/msg00348.html http://lists.gnu.org/archive/html/bug-coreutils/2009-12/msg4.html You should get this to the bug tracker, an upstream fix is already available, so this should be corrected easily and quickly. signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] kernel 2.6.32-1
nez...@allurelinux.org schrieb:
On Sat, Dec 05, 2009 at 02:13:57PM +0100, Attila wrote:
At Samstag, 5. Dezember 2009 09:56 Hussam Al-Tayeb wrote:
Isn't it against Arch philosophy to split packages it binary and header
packages?
First the headers from the kernel package was even a reduced amount and if you
look in the PKGBUILD only for the cases if you build some packages for yourself.
I agree with Hussam here.
If Arch wants to be (disk)size-effective, We would end up with hundreds
of Debian-like *-{header,dev} packages.
We're not going to do that, it just seemed insane to include this stuff
in the kernel.
I just don't think splitting header packages is practical with distributions
that support a port-like system. I know the kernel might be an exception but
I still think the decision to split the headers is interesting and worth
commenting on.
The kernel IS an exception here, we will not start splitting out -dev
stuff everywhere. It is mostly done for making the PKGBUILD more readable.
signature.asc
Description: OpenPGP digital signature
Re: [arch-general] Kernel 2.6.32 and Radeon KMS
Gabriel Morrison Lima Dantas schrieb: Hi, I installed kernel26 and kernel26-firmware from testing, and I'm experiencing some problems with KMS. During system initialization, the system requests the firmware radeon/R300_cp.bin, waits a couple of seconds and then proceeds normal initialization. But when I log into X, DRI isn't enabled. Checking dmesg, I see that the kernel couldn't load R300 firmware, therefore disabling GPU acceleration. My problem is the same of this post: http://old.nabble.com/kernel-2.6.32-experiences-td26458040.html. Thomas said that mkinitcpio automatically inserts firmware listed in modinfo module in the initramfs image. When I run modinfo radeon | grep R300, it shows me 'firmware: radeon/R300_cp.bin'. So it should be available to kernel at the time of requesting it, shouldn't it? Has someone any idea to help solving that problem? Can you remove radeon from initramfs and try in the real system? I suspect that the initramfs/udev firmware loader is broken - this can't be fixed until we dump klibc, which I don't have the time for currently. signature.asc Description: OpenPGP digital signature
