Re: [arch-general] Why not create a new repo specified for games ?
On Tue, Nov 1, 2011 at 12:34 PM, Leonid Isaev wrote: > On (11/01/11 16:40), Matej Ľach wrote: > -~> I support this idea. > -~> Keep most games in AUR and the more popular ones can have their > -~> own repo [games] on a separate server. > -~> This server could be community financed using donations and if not > -~> enough interest will be raised for new repo, all these huge games > -~> can be moved to AUR and the smaller ones can stay in [community]. > -~> > -~> That's my view at it. > -~> > > +1, but what I can't understand is why the MiB size is a figure of merit? > Instead a more relevant question, imho, is why waste server resources and time > on bad software? > > Most of these games are either from 1990 era or developed simply for fun and > have poor quality, especially compared to multi-million budgeted Windows > games. > And look at the number of game pkgs per TU in community. Most likely these > packages are simply being routinely rebuilt without seeing much usage. I would like this too. Maybe community-extra. I would not sync it, and I would even considering publically mirroring core/extra/community/testing/community-testing if all the games (it is the nany game data packages that are huge and not worth mirroing for me). Sincerely, Dwight Schauer
Re: [arch-general] coping with damaging updates
On Thu, Oct 27, 2011 at 10:36 AM, Mick wrote: > ... > made the change but it didn't work, if I can't find what they butchered > this time before the night freight train to Cairns grinds past in half > an hour I'll give up and re-install tomorrow. If you can't fix it in the current install, how is a re-install going to just "magically" fix things? Did you check .pacnew files? Have you messed up files that are changing the behavior of your system? You likely did not. The default behavior of stuff does often change. This is often due to upstream changes of packages. Many other distros try hard to shield you from those changes by over tweaking the defaults and always finding alternatives to upstream changes. They can become distanced with where the upstream really is. Arch is a lot more transparent in that regard, the end user is less shielded by the continual change within the free software community that provides the upstream for GNU/Linux and BSD systems. If you can't deal with being so exposed to upstream changes and are willing to adapt (like by learning udev rules to automatically let you use common usb media as a regular use) then Arch is likely not for you. If a re-install to fix your system you are doing it wrong. Fix the problems in your existing install or they will just come right back. Ok, if you have tweaked all your settings to no avail and have broken the system yourself, then yes, a re-install would give you a clean slate. Arch is not like windows was 10 years ago where you had to reinstall every 6 months just to get a stable system again. There is no "registry" in arch that one has to continually clean. With Arch you research problems and get to the bottom of what is causing it, and fix it, and learn a lot in the process. In the past year I can only think of only two updated packages that made me have to intervene BEFORE things broke: 1) changes in network configuration 2) changes in kernel naming There were other changes, but they were easy enough to just deal with as they happened. USB stuff did change, but since I'd already been writing udev rules for other stuff, it did not really affect me. Arch Linux should not be promoted as a system that will just work for you if you are not willing to get your hands dirty and research things to fix them. In my opinion Arch Linux is really for those who really would be better off running Linux From Scratch http://www.linuxfromscratch.org/ if they had the time and energy to do so, but want to use a distribution that takes care of all the laborious stuff so they can other stuff with their system(s). Arch is for experienced Linux users alreeady proficient at a nitty gritty configuration level, or those who want to become that type of user, and Arch goes out of it way to cater towards that type of user, and help you become that type of user.
Re: [arch-general] coping with damaging updates
On Fri, Oct 28, 2011 at 12:14 AM, Mick wrote: > I did make a mistake when I chose Arch. I asked friends on yahoo chat > for suggestions for a replacement my then distro when it focused on > eye-candy to the detriment of function and several suggested Arch. It > was only when the problems I raised here struck the first time that I > found Arch made no pretensions to being fit for production. By that > time I had come to like most of what Arch is. I run Arch on production systems. Yikes you might think. However, I run Arch Linux on more than 10 systems, and about 6 or 7 of those are at work. I've been running Arch since 2007 and used it for several months at home before using it at work. I update non-critical systems first, but since I update them daily, any breakage is easy to fix, and usually I've gotten a heads up as I track arch-general, arch-announce, arch-releng, and arch-dev-public. I have cron set to automatically download all updates so when I get around to updating, it is fast. The installs I've set up for others they typcially never update, but when I get back with them to help them on something (might even be a few months) I go ahead and update and while the update is taking place I open another terminal and pre-fix any issues. I've not had downtime with Arch, and it is a breeze to update compared to Gentoo, which I ran for a many years before I found Arch. And yes, I'll even update while working on a critical job related issue with a co-worker. I run a very custom installer, and use it to create cookie cutter installs that I already have everything set up the way we need to for our work environment, but of course adding a needing tool or two later is fairly easy. I've not had much success with the official provided installers, I think my pre partitioning and other choices mess it up. I had to fix the boot loader on my first few installs of Arch so I ended up just installing arch gentoo style on subsequent systems. I don't install base anymore, it has several packages I never use. Since the provided installer has only worked for me maybe once or twice, I just use my custom installer, which is much easier anyways for me, as I just change the hostname and default username/pass, change the architecture if need be, and do a make all. I try out he installs first in qemu-kvm for a quick sanity check, then transfer the filesystem images to the target system. Using a custom installer is fast, as I use the cached packages on my host. I have a custom xfce4 desktop setup in /etc/skel, so the install is ready to use. I've run Debian and Ubuntu but fought with package management and custom kernel deployment too much on them so I found Arch much easier to manage. Arch is much simpler than those and so much easier for me to wrap my head around it and fix issues. When I do have a question about something a quick email here about it and it is answered quickly. Most of the time there is no need to ask. All the relevant issues are already being discussed here or in arch-dev-public. All that being said, Arch is certainly not for everyone. But I disagree about it not being production worthy. I have the lts kernel installed on every system, but only the most critical ones use it by default. For any system to be production worthy, you have to be able to maintain it and fix any issues fast that come up. The only real mess up I've had was my fault, not a damaging update from an Arch developer. I mistakenly put an x86_64 bit repo path at the top of the mirrorlists of two i686 boxes and updated them. Yikes. I've since switched to using $arch in the mirrorlists rather than hardcoding the architecture. They were not out of commission long, a boot of the livecd, a quick $(awking) of /var/log/pacman.log in a pacman command line reinstalled the invalid packages and I had working systems back. Ok, the updated networking setup broke some of my systems earlier this year, but it was easy enough to fix. Arch is easy to manage if you insist on having the system set up the way you want it and you want to be on top of every issue. Distros like OpenSUSE, Fedora, Ubuntu, and to a lesser extent Debian are too daunting and confusing to me. Most Linux users I know would not tolerate Arch Linux if they had to install and setup it up themselves. But at the same time I have no real like for the distros they prefer to install and manage for themselves. A rolling update based distro that is mostly minimal and lightweight is not without it's issues and problems. All distros have serious issues and problems, it is mainly a matter of which have the issues/problems that are easiest for you to manage. I may not be the typical Arch user, dunno. Especially since I use joe instead if vi, and was a not amused when joe went to the AUR. But I have a repo for work stuff, so I just put it there so it is ready on new systems. You may have made a mistake when you chose Arch, and I'm not going to disagree with on your reasoning. Arch does have major/
Re: [arch-general] /usr is not mounted. This is not supported.
On Thu, Oct 27, 2011 at 3:38 AM, clemens fischer wrote: > Dwight Schauer wrote: > >> My root= on my kernel boot line is using /dev/by-uuid/ so if the >> initramfs can find the root device, I'm sure it can find the /usr >> device from the rootfs /etc/fstab. >> >> I've not noticed any breakage on all my system's that have a seperate >> /usr, apart from the message doing boot. > > Don't you have a boot message saying "minilogd not found" or somesuch? > I don't see that in /var/log/boot. I do see the "/usr is not mounted. This is not supported." in /var/log/boot. > On the other hand, rc.sysinit also invokes /sbin/bootlogd, which leaves > most of the interesting stuff in var/log/boot, so this would be an > academic exercise ... And this works even with a separate /var, but that is beside the point.
Re: [arch-general] /usr is not mounted. This is not supported.
On Wed, Oct 26, 2011 at 3:13 PM, Tom Gundersen wrote: > On Wed, Oct 26, 2011 at 12:57 PM, clemens fischer wrote: >> Lucky you, I have a way to explain it: There are udev rules referencing >> stuff in /usr. If people mount /usr by-label or by-uuid, udev must have >> completed to setup those symlinks. Catch-22. > > If you want to understand this I suggest you look at the udev hook in > initramfs. There is no problem. Well, when I started this thread I did not know it get so much discussion. Anyways, I'm not worried about it any more. My root= on my kernel boot line is using /dev/by-uuid/ so if the initramfs can find the root device, I'm sure it can find the /usr device from the rootfs /etc/fstab. I've not noticed any breakage on all my system's that have a seperate /usr, apart from the message doing boot. As long as the message and any potential problems from a seperate /usr go away when the initramfs hook is completed, I'll be happy. -das
Re: [arch-general] /usr is not mounted. This is not supported.
On Tue, Oct 25, 2011 at 8:59 AM, Thomas Bächler wrote: > Mounting /usr needs to go to the initramfs. It is possible to implement > a mount handler for this. At this stage, the by-label symlinks exist > already. Would the /usr location be determined when the initramfs is created, or would it determine the location at runtime via /etc/fstab? Just wanted to make sure it is the latter. By label? Is that assuming /usr location can be guessed by the label? That would not work on a lot of setups. Even if a mountpoint in label was used, that does not account for multiple disks attached, all with Linux installs on them. Or by by-label do you mean because /etc/fstab is being used, possibly with a label in the entries (I use by-uuid entries) that the correct one will be chosen?
Re: [arch-general] /usr is not mounted. This is not supported.
On Mon, Oct 24, 2011 at 1:18 PM, Tom Gundersen wrote: > There are two ways to solve this: either merge your / and your /usr > partitions, or make your initramfs mount /usr so init won't even know > that /usr is separate. > > We are currently working on adding support for the second approach, > but we are not there yet (I have some patches against mkinitcpio to > add this, but they rely on a patch by Thomas against busybox that has > not yet landed upstream). > Ok, so it is not as much of a problem as I initially thought it would be. On new large media installs I'll try to not use /usr until this gets resolved. On current installs they all seem to be working fine (I've not noticed any lack of functionality) I'll just wait until the mkinitcpio patches are completed and mkinitcpio is released with /usr mount support. Thanks, Dwight Schauer
[arch-general] /usr is not mounted. This is not supported.
I've been using Arch Linux for about 4 years now. I have it on a few important systems at work and it has been doing very well. This morning I saw "/usr is not mounted. This is not supported." in my boot up after a recent rc.sysinit update. What is this, bait and switch? I've been running Linux and BSD systems since 1996 and typically always have /usr in a separate partition (as well as /var, /home/ and /tmp, but lately been using a ram /tmp). Why does /usr even exist if it can't be on a separate partition? Why not just combine /usr/lib and /lib? And /usr/bin and /bin? And /usr/sbin and /sbin? Why have the distinction at all if it can't be on separate partition? I understand that historically that /usr often use to be on different drive, and that is not really an issue nowadays. Only this year have I started not putting /usr into separate partitions because I've been making thumbdrive installs, and did not really see any benefit to making so many partitions (automatically created anyways, with a custom install script). Does this "/usr is not mounted. This is not supported." mean I'm going to have to eventually fix (dump/fix/restore) all my systems that are now currently running fine (and that I and others are depending on at my work) because Arch Linux no longer supports /usr on a different partition (due to rc.sysinit failing, not just printing an error message)? I run Arch Linux on more than 10 systems, and about 6 or 7 of those are at work (where Arch has been working out very well). I'm not looking forward to redoing all these systems that are running fine if this is where Arch is headed and rc.sysinit is not fixed to take out this new requirement. I know this a bit of a rant, but this "/usr is not mounted. This is not supported." error message is definitely not getting this day off to a good start... Definitely not wanting to give up Arch for such a simple issue Dwight
Re: [arch-general] Wiki & forum down?
On Mon, Oct 24, 2011 at 9:35 AM, Paul Gideon Dann wrote: > On Monday 24 Oct 2011 10:30:26 Taylor Hedberg wrote: >> Apologies if I've missed something obvious, but both the wiki and forum >> seem to have been down for at least a few hours now (I think they are >> located on the same host). Does anyone know what the situation is? > > They both look fine to me. Maybe an issue with your local DNS? > > Paul > It is down for me to.
Re: [arch-general] bash variable PS1 confuses the terminal somehow
On Wed, Sep 28, 2011 at 9:46 AM, 清显 wrote:
> 13 PROMPT_COMMAND='
> 14 if (($?)); then
> 15 warn="^[[31mWARNING^[[m"
> 16 else
> 17 warn=
> 18 fi
> 19 date=`date`
> 20
> PS1="\[^[[s\]\[^[[$(($COLUMNS-28))C\]\[^[[0;33m$date\]\[^[[u\]\[^[[0;31m$warn\]\[^[[0;32m[\]\[^[[1;33m\u\]\[^[[0;32m@\]\[^[[1;36m\w\]\[^[[0;32m]\$\]
> 21 '
>
> i changed PROMPT_COMMAND to this as you said, it fixes what i mentioned
> earlier, but produces more problem, like when i type one character and then
> use BACKSPACE to delete it, the entire promt is gone, and again bring me to
> the begining of the line, also when i use ^R to search for history command,
> the prompt is destroyed too...
>
I do something similar, but I don't change PS1 in the prompt command.
My prompt does end up on two lines, but when I'm in a long path at
least the command edit area stays large.
PS1='\[\e[1;32m\]\u\[\e[1;33m\]@\h\[\e[0m\] \$ '
PROMPT_COMMAND='echo -e "\e[1;36m$(date "+%a %d%b%y %H:%M:%S")
\e[1;33m${PWD/${HOME}/~}\e[0m"
Re: [arch-general] [arch-dev-public] [signoff] linux-3.0.2-1
On Tue, Aug 16, 2011 at 7:02 AM, Matias Serer wrote: > Sorry about my ignorance and bad english, but could anyone explain what do i > have to do? > Matias, It is optional, you only do this if you want to or have the time to do so. Install the latest linux kernel package (currently linux-3.0.2-1) from the testing repository. If all works well when you use the new kernel, you can report back that all is well with it (indicate you are signing off on it). If there is a problem, then report back with what the problem is (which would mean you are not signing off on it). https://wiki.archlinux.org/index.php/Pacman#Repositories https://wiki.archlinux.org/index.php/Official_Repositories#.5Btesting.5D > Thanks, i hope i do not disturb. No problem. Dwight
Re: [arch-general] mpop & msmtp
On Tue, Aug 2, 2011 at 4:52 AM, Allan McRae wrote: > On 02/08/11 18:52, Bastien Dejean wrote: >> >> Hello, >> >> Why is there an official arch pkg for msmtp but not for mpop? >> > > Because... > Because something like fetchmail does the same thing as mpop?
Re: [arch-general] iniitcpio root device check [SOLVED]
On Sun, Jul 31, 2011 at 5:26 PM, Dave Reisner wrote:
>>Ok, I renamed "9p_mount_handler" to "ninep_mount_handler" and updated
>>mount_handler= accordingly, and rebuild the initcpio images.
>>
>>Still no joy... :)
>>
>>I went so far as to rename 9p to ninep in
>>/lib/initcpio/{install,hooks} and the HOOKS string, and rebuilt the
>>initcpio images, but that did not help.
>>
>>Dwight
>
> Let's try this one more time. You're missing a pointer to your install
> script. Part of the build function needs:
> SCRIPT=ninep
>
> or whatever you're calling it...
>
> d
>
That did it! Thanks. Now I can start the session automatically without
intervention.
Dwight
Re: [arch-general] iniitcpio root device check
On Sun, Jul 31, 2011 at 3:56 PM, Dave Reisner wrote:
>> Alright, I did that, but it is still doing the root device check and
>> dropping into the recovery shell, so I have to press Ctrl-D to
>> continue.
>>
>> >From /etc/mkinitcpio.conf:
>> MODULES="" # I was putting the modules here, now they are in install/9p
>> HOOKS="base udev autodetect 9p filesystems"
>>
>> < start /lib/initcpio/hooks/9p >
>> run_hook () {
>> modprobe 9p
>> modprobe 9pnet
>> modprobe fscache
>> modprobe virtio
>> modprobe virtio_ring
>> modprobe virtio_pci
>> modprobe 9pnet_virtio
>> }
>
> FYI, you can run:
>
> modprobe -a 9p 9pnet fscache ..
>
> and save yourself some forks.
Thanks.
>> 9p_mount_handler() {
>> mount -t 9p -o ro,${rootflags} "$root" "$1"
>> }
>>
>> mount_handler=9p_mount_handler
>> < end /lib/initcpio/hooks/9p >
>>
>> < start /lib/initcpio/install/9p >
>> #!/bin/bash
>>
>> build() {
>> MODULES+=" 9p 9pnet fscache virtio virtio_ring virtio_pci 9pnet_virtio"
>> }
>>
>> help() {
>> cat<> This hook allows a 9p virtual filesystem passthrough to be used
>> as the root filesystem when run qemu KVM.
>> HELPEOF
>> }
>> < end /lib/initcpio/install/9p >
>>
>> It does not seem to matter where I put the 9p hook in the HOOKS string
>> before rebuilding the initcpio images.
>>
>> Dwight
>
> My fault for suggesting a rotten name. You can't start a function name
> with a number.
>
> $ 9p() { echo hi; }
> ash: syntax error: bad function name
>
> Parsing failed on sourcing the hook, and mount_handler was never
> declared. Rename the function to something that ash plays nicely with
> and you should get some joy.
>
> dave
Ok, I renamed "9p_mount_handler" to "ninep_mount_handler" and updated
mount_handler= accordingly, and rebuild the initcpio images.
Still no joy... :)
I went so far as to rename 9p to ninep in
/lib/initcpio/{install,hooks} and the HOOKS string, and rebuilt the
initcpio images, but that did not help.
Dwight
Re: [arch-general] iniitcpio root device check
On Sun, Jul 31, 2011 at 10:26 AM, Dave Reisner wrote:
>> I have an arch linux install running in qemu using a 9p virtual root
>> filesystem (root filesystem is just a sub directory on the host).
>>
>> This is the line I use to launch it:
>>
>> qemu-system-x86_64 -enable-kvm -virtfs
>> local,path=$(pwd)/wn-root,security_model=mapped,mount_tag=wn-root -smp
>> 2 -m 1024 -kernel ./wn-root/boot/vmlinuz26 -append 'rootfstype=9p
>> rootflags="trans=virtio,version=9p2000.L" root=wn-root ro
>> rootdelay=10' --initrd ./wn-root/boot/kernel26-fallback.img -net vde
>> -net nic,vlan=0,macaddr=52:54:00:00:EE:03
>>
>> Immediately after "::Running Hook [resume]" though I get:
>>
>> Root device 'wn-root' does'nt exist. Attempting to create it.
>> ERROR: Unable to determine major/minor number of root device 'wn-root'.
>>
>> At that point I'm dropped into the recovery shell, I exit that, it
>> complains, but continues to boot fine as it the existence in /dev/ of
>> a 9p filesystem source is not needed.
>>
>> I did not find anything in mkinitcpio.conf to disable this check,
>> which in this case is not needed, as the root filesystem is mounted
>> without any problem.
>>
>> Using 9p for a kvm root filesystem is useful for cases where something
>> like Linux containers (LXC) is not sufficient to accomplish some task.
>>
>> For the most part this is working fine, still have some 9p filesystem
>> oddities to work through. For instance, syslog-ng won't start and
>> using makepkg on some packages results in "cat: -: No such file or
>> directory" (that error does not occur when that arch install is
>> chrooted into and build run from inside the chroot). The 9p issues are
>> not relevant to the initcpio workaround I'm looking for though.
>>
>> Dwight
>
> You'll likely want to create your own mount handler as this is a bit of
> an edge case. Doesn't need to be anything complex..
>
> 9p_mount_handler() {
> mount -t 9p -o ro,${rootflags} "$root" "$1"
> }
> mount_handler=9p_mount_handler
>
> This gets added to /lib/initcpio/hooks (call it 9p?) and then wrapped up
> in a build script which is added to /lib/initcpio/install. After that,
> add '9p' to your HOOKS in the config. Note that while the install
> scripts are interpreted by /bin/bash, hooks that run on the initcpio are
> interpreted by /bin/busybox ash.
>
> dave
>
Alright, I did that, but it is still doing the root device check and
dropping into the recovery shell, so I have to press Ctrl-D to
continue.
>From /etc/mkinitcpio.conf:
MODULES="" # I was putting the modules here, now they are in install/9p
HOOKS="base udev autodetect 9p filesystems"
< start /lib/initcpio/hooks/9p >
run_hook () {
modprobe 9p
modprobe 9pnet
modprobe fscache
modprobe virtio
modprobe virtio_ring
modprobe virtio_pci
modprobe 9pnet_virtio
}
9p_mount_handler() {
mount -t 9p -o ro,${rootflags} "$root" "$1"
}
mount_handler=9p_mount_handler
< end /lib/initcpio/hooks/9p >
< start /lib/initcpio/install/9p >
#!/bin/bash
build() {
MODULES+=" 9p 9pnet fscache virtio virtio_ring virtio_pci 9pnet_virtio"
}
help() {
cat<
It does not seem to matter where I put the 9p hook in the HOOKS string
before rebuilding the initcpio images.
Dwight
[arch-general] iniitcpio root device check
I have an arch linux install running in qemu using a 9p virtual root filesystem (root filesystem is just a sub directory on the host). This is the line I use to launch it: qemu-system-x86_64 -enable-kvm -virtfs local,path=$(pwd)/wn-root,security_model=mapped,mount_tag=wn-root -smp 2 -m 1024 -kernel ./wn-root/boot/vmlinuz26 -append 'rootfstype=9p rootflags="trans=virtio,version=9p2000.L" root=wn-root ro rootdelay=10' --initrd ./wn-root/boot/kernel26-fallback.img -net vde -net nic,vlan=0,macaddr=52:54:00:00:EE:03 Immediately after "::Running Hook [resume]" though I get: Root device 'wn-root' does'nt exist. Attempting to create it. ERROR: Unable to determine major/minor number of root device 'wn-root'. At that point I'm dropped into the recovery shell, I exit that, it complains, but continues to boot fine as it the existence in /dev/ of a 9p filesystem source is not needed. I did not find anything in mkinitcpio.conf to disable this check, which in this case is not needed, as the root filesystem is mounted without any problem. Using 9p for a kvm root filesystem is useful for cases where something like Linux containers (LXC) is not sufficient to accomplish some task. For the most part this is working fine, still have some 9p filesystem oddities to work through. For instance, syslog-ng won't start and using makepkg on some packages results in "cat: -: No such file or directory" (that error does not occur when that arch install is chrooted into and build run from inside the chroot). The 9p issues are not relevant to the initcpio workaround I'm looking for though. Dwight
Re: [arch-general] Trinity Running on Arch Linux!
On 02/16/2011 08:28 PM, David C. Rankin wrote: On 02/16/2011 02:24 PM, Bernardo Barros wrote: is your build already with qt4? if not, any idea when this could happen? Trinity has been designed with a custom Qt interface (tqtinterface) that will allow it to be built with Qt4. Currently the build is with Qt3 (patched for the tqtinterface). I don't know the exact timetable for completing the Qt4 interface, but the groundwork has already been done. I'll try and find out if there is a timetable for that. The current push the Trinity SVN code is to finish the port to CMake before release of KDE 3.5.13. I'll find out if that will also include the ability to build against Qt4. http://trinity.pearsoncomputing.net/wiki/bin/view/Developers/TrinityTQtforQt4Conversion They have status, I've not seen a time table. --DAS
Re: [arch-general] Testing kills shm and pts
On 12/12/2010 12:37 PM, jesse jaara wrote: So I enabled testing, community-testing and kde-unstable updated yaourt -Syu and reebooted. Now when ever I boot the machine the /dev/shm and /dev/pts get mounted so that only root can write into them. So I cannot use shm as a normal user and no terminal emulator can create a /dev/pts/0 node. 2010/12/12 Kaiting Chen Um what? You're going to need to be a little more specific. --Kaiting. This is still very broad and not very specific. You updated to a lot of packages from testing and unstable repositories. Since you updated so many, it is difficult to track down which package caused this problem. It would be good if you could say specifically what package you updated to caused this problem. Unless this is scratch system you are going to blow away, my advice is that you boot with some other medium, mount this install, and use pacman from the other medium to downgrade the install (after you have fixed /etc/pacman.conf on the broken system). If you want to continue down this path, once you are back to a normal system, one at a time you could make these repositories higher priority, update and reboot until it breaks, then fix again, then you'd have a better idea what package it was that caused this problem.
Re: [arch-general] dmraid boot fail (grub errors 5 & 24) - follow up
On 11/09/2010 12:45 PM, Thomas Bächler wrote: Am 09.11.2010 19:25, schrieb David C. Rankin: Guys, As a follow up, the post to kernel.org did not elicit any response. The folks at dm-devel suggested it may be a grub bug. So that leave me with two more avenues to try (1) the grub list, and (2) lilo test. https://wiki.archlinux.org/index.php/Syslinux Always worth a try. I was going to suggest the same thing. Since May of this year I've been using Syslinux rather than grub. Apart from installation and config being a bit different, I found Syslinux easy to migrate to from grub 1, as I have no desire to move to grub 2. (and no desire to move back to lilo).
Re: [arch-general] Debootstrap for Arch?
On Wed, Mar 31, 2010 at 7:20 PM, Daenyth Blank wrote: > On Wed, Mar 31, 2010 at 21:17, Piyush P Kurur wrote: >> You can install packages under a particular directroy using the command >> >> pacman -S pkgname -r /gateway/to/hell >> >> So using that you can actually build a chrooted environment and work >> your way up. > Duh, now why didn't I think of that? There's a wiki page for how to > install arch inside a chroot, use that. > http://wiki.archlinux.org/index.php?title=Special:Search&search=mkarchroot&go=Go There is also mkarchroot which is similar to debootstrap. You need to install devtools to get mkarchroot.
Re: [arch-general] Software RAID w/ 4 Drives Fails
Can you add a drive to an array after it has been built? I know you can add a hot spare, or remove a drive and add another, but I did not think you could increase N, where the size of the array is N-1 * size of each drive. How is the raid going to know which is data and which is parity? Of course I could be wrong. On Fri, Jan 22, 2010 at 12:03 PM, Louis Brazeau wrote: > On Fri, Jan 22, 2010 at 11:13 AM, Carlos Williams > wrote: > > snip > > > When I reboot the system I lose > > keyboard and it asks me to enter a run level. Obviously I can't > > troubleshoot more because I have no keyboard. > > snip > > > > > Any tips? > > > > Sorry I can't help you with your RAID. I have a RAID 5 with 3 drives > and like you said, that works. > > About loosing your keyboard. Do you have a USB keyboard ? > If so, do you have "usbinput" in your /etc/mkinitcpio.conf ? > > -- > Louis Brazeau > Informaticien >
Re: [arch-general] libglew
Won't extra/glew work? $ pacman -Ss glew extra/glew 1.5.1-1 A cross-platform C/C++ extension loading library $ pacman -Ql glew glew /usr/ glew /usr/bin/ glew /usr/bin/glewinfo glew /usr/bin/visualinfo glew /usr/include/ glew /usr/include/GL/ glew /usr/include/GL/glew.h glew /usr/include/GL/glxew.h glew /usr/include/GL/wglew.h glew /usr/lib/ glew /usr/lib/libGLEW.a glew /usr/lib/libGLEW.so glew /usr/lib/libGLEW.so.1.5 glew /usr/lib/libGLEW.so.1.5.1 glew /usr/share/ glew /usr/share/licenses/ glew /usr/share/licenses/glew/ glew /usr/share/licenses/glew/LICENSE.txt On Sat, Dec 26, 2009 at 4:16 PM, richard terry wrote: > Posted this to the gambas list as my current svn won't compile - they said I > needed libglew but can't find it in the repos ?under another name? > >> Le samedi 26 décembre 2009 22:58:38, richard terry a écrit : >> > Making all in opengl >> > make[5]: Entering directory `/home/richard/gambas3- >> > svn/src/trunk/gb.qt4/src/opengl' >> > /bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. >> > - I../.. -DQT3_SUPPORT -DQT_SHARED -DQT3_SUPPORT -I/usr/include/QtCore - >> > I/usr/include/QtGui -I/usr/include/Qt3Support -I/usr/include/QtNetwork - >> > I/usr/include/QtSql -I/usr/include/GL/ -DQT_SHARED >> > -I/usr/include/QtCore - I/usr/include/QtGui -I/usr/include/QtOpenGL >> > -pipe -Wall >> > -fno-exceptions - Wno-unused-value -fsigned-char -fvisibility=hidden -g >> > -Os -fno-omit-frame- pointer -MT main.lo -MD -MP -MF .deps/main.Tpo -c >> > -o main.lo main.cpp libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. >> > -DQT3_SUPPORT -DQT_SHARED - DQT3_SUPPORT -I/usr/include/QtCore >> > -I/usr/include/QtGui - >> > I/usr/include/Qt3Support -I/usr/include/QtNetwork -I/usr/include/QtSql - >> > I/usr/include/GL/ -DQT_SHARED -I/usr/include/QtCore -I/usr/include/QtGui >> > - I/usr/include/QtOpenGL -pipe -Wall -fno-exceptions -Wno-unused-value >> > -fsigned- char -fvisibility=hidden -g -Os -fno-omit-frame-pointer -MT >> > main.lo -MD -MP - MF .deps/main.Tpo -c main.cpp -fPIC -DPIC -o >> > .libs/main.o >> > In file included from main.cpp:29: >> > CGLarea.h:30:21: error: GL/glew.h: No such file or directory >> > make[5]: *** [main.lo] Error 1 >> > *** >> Yes, now you need libglew package (and devel files of course) > *** > > regards > > richard >
Re: [arch-general] [OT] What is wrong with DBus anyway?
gedit --help shows --new-window. I don't see what issue is Dwight On Fri, Dec 4, 2009 at 5:07 PM, Heiko Baums wrote: > Am Fri, 4 Dec 2009 23:38:02 +0100 > schrieb f...@kokkinizita.net: > >> THAT is completely irrelevant. I never claimed >> to be forced to use it. > > THAT is completely relevant. You don't want a text editor which uses > IPC so don't use one. > >> The point is that you can allow a user to have multiple >> tabs by providing an interface to request a new tab. >> This still leaves the user the choice not to have new >> tab by starting a new instance instead of using the >> new tab option. Providing this does not require IPC. > > And what? The gedit devs want to use IPC and they likely have reasons > for this. If you don't like this don't use gedit or file a bug report > to gedit upstream. > >> Instead of this, you prefer to limit the user's choice >> by creating a new tab even if the user starts a new >> instance. This removes a valuable choice. > > This is indeed a valuable choice, choosing between opening a new > instance which requires more resources than opening a new tab which > requires less resources. I bet you can configure if a text file should > be opened in a new instance or in a new tab. Otherwise don't click on > the new tab but start a new instance. > > Other option: Use mousepad. It can only handle one file at a time. > Every file is opened in a separate instance. > > Or use nano, also no multi-file editor. And there's still echo. > > Which choice is removed by gedit? > > Heiko >
Re: [arch-general] peaceful suggestion to clarify "the arch way" to avoid this to happen AGAIN
2009/12/3 Arvid Picciani : > Ng Oon-Ee wrote: > >> I actually think the you've been over-focusing on a single part of the >> 'arch way', that its 'all about' minimalism. > > then i suggest we remove the statement that it is all about minimalism. > >> Throughout this thread the vibe I've been getting for you is that you >> somehow feel disadvantaged and biased-against because dbus/hal exist and >> are selected as options in building general-purpose binaries. > > I feel in fact like wasting my time. > > I am a very simple person. I understand "fuck you" very well and can handle > it, other things like blurry project goals make me act stupid. > >> Why is Arch not for the minimalist user? > > Because it was officially stated by two arch devs that it is not. > >> Because dbus/hal are enabled in >> some packages in binary? > > Because its philosophy does not match. That goes way deeper then > arguing vim vs emacs. > > > Please, can we stop beating it now, and just officialy tell minimalists to > fuck off so everyone can stop wasting their time? > > -- > Arvid > Asgaard Technologies > It all just depends on the degree of minimalism one is after. I went from Gentoo to Ubuntu to Arch Linux (With a whole lot of other distros before and in between, including Crux, Slackware, and the BSDs). For me, Arch is far more minimal than Gentoo and Ubuntu. (More minimal than Gentoo because package building is minimized, and more minimal than Ubuntu as far as package dependencies/complexities and also configuration/runlevels/etc). For me Arch is the best balance of minimalism and overall functionality that I've found in any Linux distro. Yes, compared to slackware, Arch Linux might not be minimal, but compared to the desktop distros Fedora, Ubuntu, Mandriva, OpenSUSE, and the likes, ArchLinux is very lightweight and minimal. Arch can't be the ideal distro for everybody. Like others have said, it is what you make it, and being able to easily add your own packages and repositories makes Arch far flexible than the non minimal desktop distros. Yeah, maybe I should not add to this discussion. It has gone on long enough. Dwight
Re: [arch-general] archlinuxfr bad virtualbox_bin-3.0.10-1 package
No, it is not actually... 2009/11/17 Ng Oon-Ee : > On Tue, 2009-11-17 at 07:57 -0600, Dwight Schauer wrote: >> Yeah, as soon as I saw this redistribution discussion updated right >> away as I assumed it would soon be deleted. > > Honestly, is it THAT hard to compile it from the AUR? > >
Re: [arch-general] archlinuxfr bad virtualbox_bin-3.0.10-1 package
Yeah, as soon as I saw this redistribution discussion updated right away as I assumed it would soon be deleted. On Tue, Nov 17, 2009 at 7:53 AM, tuxce wrote: > 2009/11/17 Pierre Schmitz >> >> Am Dienstag 17 November 2009 12:22:35 schrieb tuxce: >> > I'm uploading it right now, thanks for the information. >> > >> >> You know that redistribution of the binary package is not legal? (except you >> have got the permission from Sun of course) >> >> -- >> >> Pierre Schmitz, https://users.archlinux.de/~pierre > > I just read the FAQ, actually, you are right, I don't know if the > maintainer has permissions. > I uploaded it because I saw this thread and have rights to do it, but > I will see if he has asked for permission. (I don't think this is the > case, so it will surely be deleted :/) >
[arch-general] Linux containers HOWTO for Arch Linux
For anyone that might be interested in Linux Containers on Arch Linux, I've created an LXC HOWTO that is somewhat Arch Linux specific. http://lxc.teegra.net/ -- Dwight
Re: [arch-general] Maximum JFS file (not filesytem) size
On Tue, Sep 8, 2009 at 3:49 PM, Dwight Schauer wrote: > Thanks, I'm trying ddrescue on it right now. > Well, I recovered the file, but neither star or tar can find a valid tar header in the remaining 83 GB of data.
Re: [arch-general] Maximum JFS file (not filesytem) size
Thanks Guus.
[Guus wrote: Also, is there anything in the kernel messages (dmesg)
that gives a clue?]
This is looking like a hard drive (most likely), ata controller, or
ata driver issue as:
dd if=a4b4.tar skip=123166576 of=/dev/null
dd: reading `a4b4.tar': Input/output error
0+0 records in
0+0 records out
0 bytes (0 B) copied, 13.7423 s, 0.0 kB/s
produces the following dmesg output:
--< start clip >--
ata3.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x0
ata3.00: irq_stat 0x4008
ata3.00: cmd 60/08:00:88:fe:28/00:00:23:00:00/40 tag 0 ncq 4096 in
res 41/40:00:8f:fe:28/54:00:23:00:00/40 Emask 0x409 (media error)
ata3.00: status: { DRDY ERR }
ata3.00: error: { UNC }
ata3.00: configured for UDMA/133
ata3: EH complete
sd 2:0:0:0: [sda] 976773168 512-byte hardware sectors (500108 MB)
sd 2:0:0:0: [sda] Write Protect is off
sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
ata3.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x0
ata3.00: irq_stat 0x4008
ata3.00: cmd 60/08:00:88:fe:28/00:00:23:00:00/40 tag 0 ncq 4096 in
res 41/40:00:8f:fe:28/06:00:23:00:00/40 Emask 0x409 (media error)
ata3.00: status: { DRDY ERR }
ata3.00: error: { UNC }
ata3.00: configured for UDMA/133
ata3: EH complete
sd 2:0:0:0: [sda] 976773168 512-byte hardware sectors (500108 MB)
sd 2:0:0:0: [sda] Write Protect is off
sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
ata3.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x0
ata3.00: irq_stat 0x4008
ata3.00: cmd 60/08:00:88:fe:28/00:00:23:00:00/40 tag 0 ncq 4096 in
res 41/40:00:8f:fe:28/06:00:23:00:00/40 Emask 0x409 (media error)
ata3.00: status: { DRDY ERR }
ata3.00: error: { UNC }
ata3.00: configured for UDMA/133
ata3: EH complete
sd 2:0:0:0: [sda] 976773168 512-byte hardware sectors (500108 MB)
sd 2:0:0:0: [sda] Write Protect is off
sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
ata3.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x0
ata3.00: irq_stat 0x4008
ata3.00: cmd 60/08:00:88:fe:28/00:00:23:00:00/40 tag 0 ncq 4096 in
res 41/40:00:8f:fe:28/06:00:23:00:00/40 Emask 0x409 (media error)
ata3.00: status: { DRDY ERR }
ata3.00: error: { UNC }
ata3.00: configured for UDMA/133
ata3: EH complete
sd 2:0:0:0: [sda] 976773168 512-byte hardware sectors (500108 MB)
sd 2:0:0:0: [sda] Write Protect is off
sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
ata3.00: exception Emask 0x0 SAct 0x3 SErr 0x0 action 0x0
ata3.00: irq_stat 0x4008
ata3.00: cmd 60/08:00:88:fe:28/00:00:23:00:00/40 tag 0 ncq 4096 in
res 41/40:00:8f:fe:28/06:00:23:00:00/40 Emask 0x409 (media error)
ata3.00: status: { DRDY ERR }
ata3.00: error: { UNC }
ata3.00: configured for UDMA/133
ata3: EH complete
sd 2:0:0:0: [sda] 976773168 512-byte hardware sectors (500108 MB)
sd 2:0:0:0: [sda] Write Protect is off
sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
ata3.00: exception Emask 0x0 SAct 0x2 SErr 0x0 action 0x0
ata3.00: irq_stat 0x4008
ata3.00: cmd 60/08:08:88:fe:28/00:00:23:00:00/40 tag 1 ncq 4096 in
res 41/40:00:8f:fe:28/06:00:23:00:00/40 Emask 0x409 (media error)
ata3.00: status: { DRDY ERR }
ata3.00: error: { UNC }
ata3.00: configured for UDMA/133
sd 2:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
sd 2:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
Descriptor sense data with sense descriptors (in hex):
72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00
23 28 fe 8f
sd 2:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
end_request: I/O error, dev sda, sector 589889167
ata3: EH complete
sd 2:0:0:0: [sda] 976773168 512-byte hardware sectors (500108 MB)
sd 2:0:0:0: [sda] Write Protect is off
sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
--< end clip >--
On Tue, Sep 8, 2009 at 3:10 PM, Guus Snijders wrote:
> Something else you could try is using ddrescue on the file; whereas
> "dd" stops when it encounters an error, ddrescue
> will keep trying to read as much as possible.
> It feels a bit like the disk (on which the image is stored) is giving
> a read error, causing dd to stop.
Thanks, I'm trying ddrescue on it right now.
[arch-general] Maximum JFS file (not filesytem) size
Dear fellow Archers, I tarred up a couple filesystems and piped the tar stream through ssh to a remote computer where I dd'ed it to a file. This a common backup method I've been using for a few years now if I'm going to wipe a system and start over. I'm using JFS on the arch linux system that was being copied to. The resulting file ended up being 137G (which is about right based on the source filesystem usage). du --human --total a4b4.tar 137Ga4b4.tar 137Gtotal However, I can only restore from 63G of the tar ball, so I attempted to see how much could be read. dd if=a4b4.tar of=/dev/null dd: reading `a4b4.tar': Input/output error 123166576+0 records in 123166576+0 records out 63061286912 bytes (63 GB) copied, 1193.69 s, 52.8 MB/s There were no critical files in that tar ball that are not kept elsewhere, that is not the issue. At this point I can consider what is past the 63G point in the tarball to unrecoverable, which is fine. I tried skipping the first 63GB, but that does not work. dd if=a4b4.tar skip=123166576 of=/dev/null dd: reading `a4b4.tar': Input/output error 0+0 records in 0+0 records out 0 bytes (0 B) copied, 27.2438 s, 0.0 kB/s It seems like it took a while to figure out that it could not perform this operation. The box in question is running an OpenVZ patched 2.6.27 kernel, but that might not have anything to do with it. Yeah, I know, I could have used bzip and made 2 separate files, I could have used rsync -av, I could have checked tarball before wiping the source files systems, etc, that is not the point here. Now that I know that JFS on my setup has a 63GB file size limit, I know now to accommodate for that in the future. I'm mainly just curious on how the system could write a larger file than it can read. Dwight
Re: [arch-general] Where can I find the "boot" log to find out what failed on boot?
On Sat, Jul 25, 2009 at 5:37 PM, Randy Morris wrote: > On Sat, Jul 25, 2009 at 05:29:31PM -0500, Dan McGee wrote: >> On Sat, Jul 25, 2009 at 4:49 PM, David C. >> Rankin wrote: >> > Listmates, >> > >> > Seems like a simple question, but I've searched /var/log and >> > can't find a file that contains the boot history showing all the >> > "fail" messages during boot. For some reason after the latest >> > update, my i686 box showed a half dozen or so "fail" messages. I >> > need to find the log of what died. >> > >> > The upside to this? This was my i686 box that would no longer >> > start kde after the next-previous set of updates. Now kde4 starts >> > fine again. >> > >> > Whatever failed can't be that critical because the box is >> > functioning fine, but I still want to find out what failed. If the >> > file is in /var/log, then I just flat missed it. I thought it would >> > be daemons.log, but I found no fail messages. >> >> This might not actually be logged anywhere now that I think about it. >> To devs- am I wrong, or maybe we should add some syslog foo in here so >> this stuff is more easily traceable? >> >> I personally disable the VC on tty1 in inittab on all machines so that >> no console overwrites the boot screen. >> >> -Dan > > That's an interesting way to handle that Dan. Personally if I'm > troubleshooting this, I add something like "read KEY" to the end of > /etc/rc.local so that the boot pauses for a keypress. After I see what > I want, I just comment out or remove that line from /etc/rc.local. > > Another way would be to remove the string escape that clears the screen > from /etc/issue, but IMHO that is quite ugly. > I disable vc/1 on all my machines in inittab as well, and have been doing for over a year now on all my arch installs. It is one of the first things I do after installing, and I just leave it disabled.
Re: [arch-general] New 64 bit computer
Did you read the whole article? It may have been working, but not without some issues. It other words, it was not working 100%, it still had some things lacking. >From the article: "Once installing the patched Radeon driver, it immediately began working with our Diamond Radeon HD 4850 (identified as a Wekiva RV770 B50102 Board through AtomBIOS). Granted, of course, there is no 2D or 3D acceleration yet for the Radeon HD 4800 series. Once the R600 series has 2D/3D support, it should be easily ported to the RV770. The only other issue we have run into is the driver not being able to read the EDID information from the monitor. We have tried with multiple monitors and with all of them reading the EDID had failed, which resulted in the X server defaulting to 1280 x 768." Also see: http://xorg.freedesktop.org/wiki/RadeonFeature My workstation at where I work had a newer ATI card in it. I could not use with the free driver in any combination due to the card having Display Port instead of DVI, so I had to go with the proprietary driver. Once support for the proprietary driver was dropped and having the old one stop working due to kernel and Xorg updates I finally just pulled it out and put in and Nvidia card. Every computer I've worked with over the past several years that had an ATI card it in I ended up replacing with an Nvidia card due to one issue or another (not being able to realiable watch movies, run compiz, connect more than one monitor, whatever). With ATI I'd have the setup working for a while, the some other update would come along and break it. I wish it were not that way. I'd rather have all opensoruce drivers in the the computers I use. When it comes to video cards, that just is not a reality yet for me. Well, 1 current exception. My laptop has an intel video chipset and I've had not any major problems with it using the free Xorg drivers, even with 3D stuff or compiz. On Tue, Jun 16, 2009 at 4:37 PM, Antony Jepson wrote: > On 2009-06-17, Ricardo Hernandez wrote: >> ATI noo!!! hehe. As commented above i'm almost 100% sure you'll have >> troubles. At least in my case, ATI 4850, i cannot use X at all. ATI has no >> support for kernel 2.6.29 yet and arch have a patch for that but it does not >> work for some card, for example my card. Xorg didn't recognize mi card even >> with the fglrx driver. > > According to Phoronix[1] the ATI 4850 has worked with xf86-video-ati > driver since day one. > > [1]: > http://www.phoronix.com/scan.php?page=article&item=amd_rv770_oss&num=1 > > -- > Sincerely, > > Antony Jepson / / GPG Key: 0xFA10ED80 >
Re: [arch-general] New 64 bit computer
Well, a few issues here. 1) Video card drivers for X for mostly user mode with a couple exceptions, the proprietary ATI and Nvidia drivers needs proprieteray closed source kernel module in order to make full use of the card. 2) If one does not care that their card is being fully utilized (both outputs working correctly, 3D animation working satisfactorily or even properly, etc), then one can use the free drivers included with Xorg. 3) ATI did release specs for some of their cards so that free drivers can be written, but that effort is slow going, and even many of the cards that the specs have been released for still have have a lot of driver issues, so situation #2 above for many people is still not an option. There are other issues as well, but these are the major ones. Intel does release specs and free drivers (including source) for Linux. Unfortunately Intel does not make PCI or PCI express video cards, in any configuration, that are available in mainstream retail. On Tue, Jun 16, 2009 at 12:12 PM, David Rosenstrauch wrote: > David C. Rankin wrote: >> >> What I am pissed at AMD/ATI for is dropping all Linux driver support >> for all cards sold before 2007 (Everything before the 2400 series). This >> screwed a lot of loyal ATI users over and left a real bad taste in my mouth. > > Forgive me if I'm ignorant on the specifics of the topic. But in theory > shouldn't older model hardware drivers already be fully integrated into the > kernel (and supported by kernel developers), thereby making such a move a > non-issue? > > DR >
Re: [arch-general] New 64 bit computer
Both old and new ones. Most of the problems I've ran into are with dual monitor setups that use compiz. I've so much wanted to go with and opensource driver solution, but I've wasted too much time/money researching trying. So no more. Maybe in a year of two the nouveau drivers will have matured. Last I checked on my setups I still had issues. If I was content with one monitor and no compiz, then an ATI card "might" be alright using an opensource driver, as the proprietry ones are too buggy in my opinion. But I've been been too much at this proint by time/money wasted on trying to go the ATI route. On Tue, Jun 16, 2009 at 10:22 AM, David Rosenstrauch wrote: > Are you referring to old ATI cards? Or new ones? > > Dunno ... I've used a number of ATI cards, and haven't had problems. I'm > currently using a laptop with a ATI Mobility Radeon 9000, and a > desktop/server with a ATI Radeon 9200 SE - both without incident. > > DR > > Dwight Schauer wrote: >> >> I have to agree, ATI is big no no if you want a decent workstation >> setup. I've tried a whole lot to use ATI instead of Nvidia but it just >> never pans out. I've wasted a lot of money and a whole lot of time on >> ATI cards and just end up ripping the card out and putting in an >> Nvidia one. I don't even use my computers for gaming, that is not the >> issue at all with the video card. I just want something stable that >> just works. I've researched what to buy as far as what is well >> supported, tried both the free radeon and radeonhd drivers, and tried >> the proprietery fglrx ones many times and really tried to come up with >> working solutions. If you don't need X, than an ATI card will be fine. >> Going Nvidia might not be the most "idealistic" route, but it is by >> far the least amount of hassle in my opinion. >> >> >> On Tue, Jun 16, 2009 at 9:53 AM, Ricardo Hernandez >> wrote: >>> >>> ATI noo!!! hehe. As commented above i'm almost 100% sure you'll have >>> troubles. At least in my case, ATI 4850, i cannot use X at all. ATI has >>> no >>> support for kernel 2.6.29 yet and arch have a patch for that but it does >>> not >>> work for some card, for example my card. Xorg didn't recognize mi card >>> even >>> with the fglrx driver. >>> >>> Sooo...my recomendation, again as above, buy nvidia. I read you don't >>> like >>> nvidia but is a more serious company at least in support and driver >>> updates. >>> >>> I sell mi ati card and buy a XFX 9800 GT. Is a little less power but it >>> works a lot better and have no problem. >>> >>> However if you don't mind 3d acceleration for the moment, the radeonhd >>> drivers is a good alternative, and it seems that in kernel 2.6.31 i'll >>> have >>> KMS support. >>> >>> -- >>> Ricardo Hernández ( richerVE ) >>> > >
Re: [arch-general] New 64 bit computer
I have to agree, ATI is big no no if you want a decent workstation setup. I've tried a whole lot to use ATI instead of Nvidia but it just never pans out. I've wasted a lot of money and a whole lot of time on ATI cards and just end up ripping the card out and putting in an Nvidia one. I don't even use my computers for gaming, that is not the issue at all with the video card. I just want something stable that just works. I've researched what to buy as far as what is well supported, tried both the free radeon and radeonhd drivers, and tried the proprietery fglrx ones many times and really tried to come up with working solutions. If you don't need X, than an ATI card will be fine. Going Nvidia might not be the most "idealistic" route, but it is by far the least amount of hassle in my opinion. On Tue, Jun 16, 2009 at 9:53 AM, Ricardo Hernandez wrote: > ATI noo!!! hehe. As commented above i'm almost 100% sure you'll have > troubles. At least in my case, ATI 4850, i cannot use X at all. ATI has no > support for kernel 2.6.29 yet and arch have a patch for that but it does not > work for some card, for example my card. Xorg didn't recognize mi card even > with the fglrx driver. > > Sooo...my recomendation, again as above, buy nvidia. I read you don't like > nvidia but is a more serious company at least in support and driver updates. > > I sell mi ati card and buy a XFX 9800 GT. Is a little less power but it > works a lot better and have no problem. > > However if you don't mind 3d acceleration for the moment, the radeonhd > drivers is a good alternative, and it seems that in kernel 2.6.31 i'll have > KMS support. > > -- > Ricardo Hernández ( richerVE ) >
Re: [arch-general] [arch-dev-public] Kill old gcc versions
I'd have to agree with Jan on this one. The reason why packages don't compile on the with newer compilers is generally because the code is not standards compliant and needs fixing anyways. So the right thing to do is fix the broken packages in extra and move on. Then again, I'm not an Arch Linux developer, so that is easy for me to say. When I download some source tarball and try to compile it and it fails, I never go try it with and older compiler. If it is a application/library I really need, I patch it until it compiles. On Sun, Jun 14, 2009 at 6:17 PM, Baho Utot wrote: > On Mon, 2009-06-15 at 00:51 +0200, Jan de Groot wrote: >> On Sun, 2009-06-14 at 18:46 -0400, Baho Utot wrote: >> >> > I have encountered many packages in extra that don't compile with >> > gcc-4.4.0. The easy way to fix them is to compile them with gcc-3.4 >> >> The easy way to fix them is by reporting bugs. Bugfixing most of these >> packages is very easy and takes us only a few minutes to fix, so why >> bother supporting an old outdated compiler that hasn't been supported >> upstream for a long while? >> > Do you really want a list of all the packages in extra that are broke? > > There are lots of them > >
Re: [arch-general] Firefox bug that may be Arch specific
On Tue, May 19, 2009 at 1:07 PM, Matthew wrote: > Emmanuel Benisty wrote: >> >> Hi List, >> >> Just for information, there has been already two bug reports in >> Bugzilla that mention a bug in the display size of textboxes. Until >> now, only Archers seems to suffer from this bug and one of the mozilla >> developers has marked this issue as specific to Arch. Therefore, I >> thought it could be interesting to let Arch developers and users to be >> informed about this. >> >> https://bugzilla.mozilla.org/show_bug.cgi?id=491114 >> >> Thanks+regards. >> > > I'm using firefox 3.5beta4 here with no problems. My system is fully > up-to-date, however I am running testing. > > ~pyther > I'm not running testing, but I'm fully up to date. No problems regarding textboxes with epiphany, firefox, or swift weasel.
Re: [arch-general] Laptop Install - 2 questions remain, WPA and Compiz with Radeon Driver
http://wiki.archlinux.org/index.php/Networkmanager
or
http://wiki.archlinux.org/index.php/Wicd
Both explain how depending on what you are running.
On Mon, May 4, 2009 at 11:54 AM, David C. Rankin, J.D.,P.E.
wrote:
> On Sunday 03 May 2009 05:21:05 Jan Spakula wrote:
>> Excerpts from David C. Rankin, J.D.,P.E.'s message of So Mai 03 12:11:04
> +0200 2009:
>> > (1) My laptop has an Atheros card and is happily using the madwifi
>> > driver. The only problem is that I'm starting it manually and need to
>> > know where to put the pieces to have it start automatically. Basically,
>> > it takes 3 commands to get my wifi going:
>> >
>> > ESSID=${1:-skyline}
>> > IFACE=${2:-wlan0}
>> >
>> > iwconfig ${IFACE} essid "${ESSID}"
>> >
>> > wpa_supplicant -i${IFACE} -Dwext -c/etc/wpa_supplicant.conf -d -B
>> >
>> > >> /var/log/wpa_start.log 2>&1
>> >
>> > sleep 2 # This doesn't count as a command
>> >
>> > dhcpcd wlan0
>> >
>> > My question is "Where do I put this stuff to make it happen when I
>> > start Arch??
>>
>> Install the netcfg package, create a profile under /etc/network.d (there
>> are some examples, so you shouldn't have any problem), and edit
>> /etc/rc.conf: add the name of your profile into "NETWORKS=(...)" and add
>> 'net-profiles' to your DAEMONS.
>>
>> -- Jan
>
> Jan,
>
> While I'm at it, where can I turn the default attempt to start 'eth0'
> off.
> All I care about is wireless on my laptop. If I need the wired connection I
> can go start it manually, but I'd like to get rid of the ... waiting and the
> [Fail] on boot. I thought about removing 'main' from the NETWORK section,
> but I didn't want to kill the loopback setup (if that's where it is done).
> What say the gurus? Where do I turn off the attempt to start eth0?
>
> --
> David C. Rankin, J.D.,P.E.
> Rankin Law Firm, PLLC
> 510 Ochiltree Street
> Nacogdoches, Texas 75961
> Telephone: (936) 715-9333
> Facsimile: (936) 715-9339
> www.rankinlawfirm.com
>
Re: [arch-general] 3rd Arch install -- on my laptop -- a bit more of a challenge - ATI is the problem
David, You might also want to look at the catalyst package on AUR catalyst 9.4-1 AMD/ATI kernel drivers for Radeon brand cards. Stock kernel http://aur.archlinux.org/packages.php?ID=22899 Not sure if it will do any better for you than the crippled 9.3 driver you mention. Dwight On Sat, May 2, 2009 at 8:00 PM, David C. Rankin wrote: > Listmates, > > My 3rd install of Arch is on my x86_64 laptop (Toshiba 205D). > Unfortunately I > have an ATI Radeon 1200 in it and ATI - SUCKS. > > (Not to mention they have just royally screwed Linux over by dropping all > support for the R300-R500 series cards while the last driver ATI released [the > 9.3 driver] is crippled as hell for many cards) > > I'm currently working to get the radeon driver up and going and when > I'm done > I'll look into compiling the last good fglrx driver (8-9 release) for Arch. > I'm > not that great of a programmer, so if there are any Arch programmers here that > want to take a look, I could sure use the help. > > The package I will work with is the September '08 driver package you > can > obtain at the ati site under previous releases: > > ati-driver-installer-8-9-x86.x86_64.run > > You can extract the files with: > > ati-driver-installer-8-9-x86.x86_64.run --extract > > If anyone wants to take a look, 2 sets of eyes are always better than > 1. > > > -- > David C. Rankin, J.D.,P.E. > Rankin Law Firm, PLLC > 510 Ochiltree Street > Nacogdoches, Texas 75961 > Telephone: (936) 715-9333 > Facsimile: (936) 715-9339 > www.rankinlawfirm.com >
Re: [arch-general] Done! Website move to 1st Archlinux Box
Troll? Hmmm No, you are not a troll. (Not that I participate on these lists all that much myself). It is interesting though seeing that is someone migrating from OpenSuse to Arch Linux, as they are almost polar opposites as far as Linux distros go. I use OpenSuse a lot at work (not my choice), but I prefer Arch (which I use on my own workstation and servers I maintain, and Arch is currently the only Linux distro I use at home). On Sat, Apr 25, 2009 at 11:41 PM, David C. Rankin wrote: > Andrei Thorp wrote: >> I like this guy :) >> >> You've shown yourself to be indeed an awesome community member. >> Thanks, and I hope that Arch continues to make you happy. And I agree, >> I always thought Arch would do well for a server if you take >> precautions around updates. >> >> :) >> >> -Andrei "Garoth" Thorp >> > > Thanks Andrei, that means I batting 50%. The others just call me a > Troll:-) > > (Note, I had to boot back to suse for a bit so I can export the rest of the > mysql databases and web apps. I moved the Arch files apache file over to > another server so they are accessible while I finish up.) > > Thanks again. Look forward to working with you all while I learn Arch; > I > really like this distro. > > -- > David C. Rankin, J.D.,P.E. > Rankin Law Firm, PLLC > 510 Ochiltree Street > Nacogdoches, Texas 75961 > Telephone: (936) 715-9333 > Facsimile: (936) 715-9339 > www.rankinlawfirm.com >
Re: [arch-general] how to mount external hdd
and login $ cat /proc/partitions #idenitfy the partition, is usually one of the last ones, lets assume it is /dev/sdXY $ sudo mount /dev/sdXY /path/to/mount/point $ exit to go back to your login manager Not sure what kind of answer you were looking for. On Tue, Feb 17, 2009 at 9:55 PM, Preston C. wrote: > I think that this is a simple question. How do I mount an external > hard drive before I log into my desktop? Thanks >
Re: [arch-general] Pushing Updates
Not exactly a push, but I have my servers "remind" me daily when there are updates available. I have a script called 00pacman-update in my /etc/cron.daily < start clip > #!/bin/sh /usr/bin/pacman -Sy --noprogressbar /usr/bin/pacman -Qu < end clip > That way I get a daily reminder via email of what updates are available. Looking at the pacman options again though I think I'm going to change the first pacman options, from: "-Sy --noprogressbar" to "-Syuw --noconfirm --noprogressbar" # sync and download, but don't do the actual update I know that is not a push, but it does save you some time and you get reminded where there are waiting packages. You could script a push via ssh. On Tue, Nov 4, 2008 at 7:54 PM, Sujith <[EMAIL PROTECTED]> wrote: > Hi, > > I maintain a few machines and a server in my office and I periodically > update them manually ( -Syu ). > > Is there a way to push package updates to them ? > Any project out there which does this ? > > Thanks. > > Sujith > -- > http://sujith-m.blogspot.com >
Re: [arch-general] [English] New Distro - Can't Read German
Of course German is more useful than Ruby! Phffftt... Who could possibly not think that? Just consider the number of German users versus Ruby users come on now... -- Dwight Schauer On Tue, Apr 1, 2008 at 12:27 PM, Johannes Held <[EMAIL PROTECTED]> wrote: > "Aaron Griffin" <[EMAIL PROTECTED]>: > > > Nominated for quote of the year: > > > > On Tue, Apr 1, 2008 at 9:38 AM, David Rosenstrauch <[EMAIL PROTECTED]> > wrote: > > > German is way more useful than Ruby! :-) > > > +2 > > > > -- > Gruß, Johannes > Täglich http://blog.hehejo.de und du fühlst dich gut. > > http://cryptocd.eduforge.org/online_version >
Re: [arch-general] signoff kernel26-2.6.24.3-6
On Tue, Mar 25, 2008 at 7:21 PM, Aaron Griffin <[EMAIL PROTECTED]> wrote: > Suffice to say: for all the "old timers" out there, I am on your side. > I *am* an "old timer", and I will do everything in my power to make > arch what it was. I switched to arch only recently, but I've been using linux 10+ years. So, as far as linux goes, I *am* an "old timer" as well, and as others have stated do not wish to be babied and I need to know exactly what is going with service starting/stopping, etc, and be able to control it myself. I switched to arch from ubuntu (after trying half a dozen or so other distros in between) and do not want arch to become an ubuntu clone with only a different but similar package manager.
