[arch-general] Keep older kernel intact while upgrading to new kernel
Hi, While updating to a new kernel pacman replaces the older kernel with the new one. Is there someway to keep the older kernel in /boot and have new entries for new kernel in menu.lst while keeping old entries intact?
Re: [arch-general] Keep older kernel intact while upgrading to new kernel
http://wiki.archlinux.org/index.php/Pacman In pacman.conf: IgnorePkg=name IgnoreGroup=name Reply Header Subject:[arch-general] Keep older kernel intact while upgrading to new kernel Author: Madhurya Kakati mkakati2...@gmail.com Date: 17th July 2010 06:27 Hi, While updating to a new kernel pacman replaces the older kernel with the new one. Is there someway to keep the older kernel in /boot and have new entries for new kernel in menu.lst while keeping old entries intact?
Re: [arch-general] Keep older kernel intact while upgrading to new kernel
On Sat, Jul 17, 2010 at 3:39 AM, Legioner le_legio...@mail.ru wrote: http://wiki.archlinux.org/index.php/Pacman In pacman.conf: IgnorePkg=name IgnoreGroup=name If I interpreted correctly this will not work as OP wants. (the kernel won't be upgraded this way). Besides extracting and copying manually, I don't see any other option... Reply Header Subject: [arch-general] Keep older kernel intact while upgrading to new kernel Author: Madhurya Kakati mkakati2...@gmail.com Date: 17th July 2010 06:27 Hi, While updating to a new kernel pacman replaces the older kernel with the new one. Is there someway to keep the older kernel in /boot and have new entries for new kernel in menu.lst while keeping old entries intact? -- == Ivan Sichmann Freitas Engenharia de Computação 2009 UNICAMP http://identi.ca/ivansichmann Grupo Pró Software Livre UNICAMP - GPSL ==
[arch-general] Manager Duplicates in /var/cache/pacman/pkg
Guys, I've updated my find duplicates script to work with the .xz packages. There are actually 2 scripts involved: 'fduparch.sh' is the wrapper script that just sets the directories and options for the actual duplicate finding script 'fduppkg'. In its current configuration fduparch.sh actually calls fduppkg twice. PASS 1: it calls fduppkg to scan /var/cache/pacman/pkg and move any duplicates found to '/home/backup/pkg-old'. Packages with the same name are then checked by DATE and any older packages are moved /home/backup/pkg-old. This leaves only the current packages in /var/cache/pacman/pkg making it much easing to move your install from machine-to-machine without copying unneeded duplicates. Second, it frees up space on / by moving duplicates to the /home partition. PASS 2: it calls fduppkg a second time to scan '/home/backup/pkg-old' and move any duplicates found to '/home/backup/pkg-older'. That way you have the latest packages in the normal '/var/cache/pacman/pkg' and you have a duplicate-free set of the last packages before update in '/home/backup/pkg-old'. All older versions are kept in '/home/backup/pkg-older' The way I use the scripts is to create softlinks to the scripts in /usr/local/bin (making sure /usr/local/bin is in your PATH) as follows: ln -s /wherever/you/put/fduparch.sh /usr/local/bin/fduparch ln -s /wherever/you/put/fduppkg /usr/local/bin/fduppkg then I simply call fduparch after each update to clean the duplicates out of /var/cache/pacman/pkg. running fduppkg without arguments gives the general usage: 01:16 nirvana:/srv/http/dl/Archlinux/scripts sh fduppkg Usage: fduppkg search dir [ -d dup_dir -l logfile -s -v ] Searches search dir for duplicate pkgs and moves duplicate files to [dup_dir] or search dir/duplicates by default. -d | --dupdirUsed to specify directory to hold duplicate rpms -l | --logfile Specify the log file name (default ./duplicates.log) -s | --silentDon't output anything to stdout, just log results -v | --verbose Output information showing which files are kept and not moved However, to change the default duplicate directories, just edit the wrapper script 'fduparch' and set the directories you want there. I have used a wrapper script to keep fduppkg as flexible as possible so I can simply run it on any package directory to find and move duplicates. (the split setup was originally developed to handle suse's archane cache directory structure, but it handles Arch's simple setup as well) Grab the duplicate scripts at: http://www.3111skyline.com/dl/Archlinux/scripts/fduparch.sh http://www.3111skyline.com/dl/Archlinux/scripts/fduppkg Finally, I have developed a script for determining which packages in /var/cache/pacman/pkg are 'Installed' or not. The script is 'chkinstpkgs.sh' and is available here: http://www.3111skyline.com/dl/Archlinux/scripts/chkinstpkgs.sh Running the script without argument will check the status of all packages in /var/cache/pacman/pkg and provide you with a concise list of installed/uninstalled packages in the following format: 01:24 alchemy:~/scr/arch sh chkinstpkgs.sh Determining installed/orphaned packages in /var/cache/pacman/pkg... Initializing the package-information arrays Checking installed packages Total Number of Packages : 2713 Total Number Installed : 2225 Total Number Orphaned: 488 Updating the installed package array with installed/orphaned info ( be patient, time required is: [~30 sec/1000 pkgs] ) ORPHANS (pkg in /var/cache/pacman/pkg but not installed): Total packages orphaned: 488 PackageArch Installed a2ps-4.14-1x86_64no acct-6.5.1-1 x86_64no acpi-1.4-2 x86_64no snip INSTALLED PACKAGES: Total packages installed: 2225 Package Arch Installed a52dec-0.7.4-4 x86_64yes aalib-1.4rc5-6 x86_64yes snip I find all 3 scripts useful in managing my Arch boxes and for moving installs to new arch boxes. The chkinstpkgs.sh script is great for checking what I have forgotten to install on a new box. Enjoy! -- 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] Keep older kernel intact while upgrading to new kernel
On 07/17/2010 09:27 AM, Madhurya Kakati wrote: Hi, While updating to a new kernel pacman replaces the older kernel with the new one. Is there someway to keep the older kernel in /boot and have new entries for new kernel in menu.lst while keeping old entries intact? no -- Ionuț
Re: [arch-general] Keep older kernel intact while upgrading to new kernel
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2010年07月17日 15:46, Ionuț Bîru wrote: On 07/17/2010 09:27 AM, Madhurya Kakati wrote: Hi, While updating to a new kernel pacman replaces the older kernel with the new one. Is there someway to keep the older kernel in /boot and have new entries for new kernel in menu.lst while keeping old entries intact? no You can alway do it manually, simply copy the old kernel image as other name before you update, then modify the correspondent line in menu.1st file. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMQWwCAAoJEOaLWowX7DBTyPYH/jVEL3/YbKpw4g2YQeEDIKhN E1HHpBq0LLxHmqe5N8C79VzGV8V2RSu/B6qsmzjO3f98xd2E+ev4Etd8YGOV5vvU pkKu+UOeDEubFrX75L1/802wTIfO5DI21VaLpRKD/+JJ2R2rTa1Bk2HmTF5DWmoh mpVXOydJyIXNeu2BVUemjn4TK2t6IGs22yCI107F5uD3SV1ZtpavsZ3xZCav3e6B x2R8C2NCF/r3BnVE3BYh9AlX617/F03hCQPOKMyXjLnMylrVvfkxMM1Q9kW97pcl nGR+1YUbNgTnaylyls2dOp4UAwzALcCDVwq9oJnitTcR6f/OlIH6ELUtX0gvUUU= =t+0W -END PGP SIGNATURE-
Re: [arch-general] What broke ctrl+c ??
On Sat, Jul 17, 2010 at 07:55, David C. Rankin drankina...@suddenlinkmail.com wrote: OK I've narrowed it down to gnome-terminal. If I use konsole (kde3 or kde4) ctrl+c works just fine. Can anyone else try in gnome-terminal and see if ctrl+c is broken for you? Just type 'ping whatever' and then try to kill ping with crtl+c. I can't and that's a problem. I'm using using gnome-terminal 2.30.2-1 Create a new user, log in with it and try it again. If it works then you have messed up something in your configs. -- ijanos
Re: [arch-general] What broke ctrl+c ??
On 07/17/2010 12:52 AM, Thomas Dziedzic wrote: Can you downgrade the -lts kernel and see if it works? If not, can you try downgrading some other packages also? Yep, I'll do that as a last resort, but finding that ctrl+c is only broken in gnome-terminal and it is OK in konsole, I'm suspecting it is gtk or gnome related... -- 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] What broke ctrl+c ??
On 07/17/2010 12:58 AM, Jordan Windsor wrote: Works here, gnome-terminal 2.30.2-1 Thanks - sometimes, I think I just must be the lucky one :p -- 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] [PATCH] gdisk patches
On Sat, 17 Jul 2010, Ionuț Bîru wrote: On 07/17/2010 01:23 AM, Mark Pustjens wrote: On Fri, 16 Jul 2010, Ionuț Bîru wrote: On 07/16/2010 10:11 PM, Mark Pustjens wrote: Hi List, Below a patch wich fixes two bugs in the gdisk package. They have been submitted uptream but not yet been accepted. then we don't need them if upstream did that They didn't do anything :) Submitted only a few hours ago. post a link to the bug report or mailing list so we can follow the progress As i said in my original post: there is no place for a bug report, nor is there a mailing list. -- Ionuț Greetings/Groetjes Mark Pustjens -- 'It's a lovely morning, lads,' he said. 'I feel like a million dollars. Don't you?' There was a murmur of reluctant agreement. 'Good,' said Cohen. 'Let's go and get some.' (Interesting Times)
Re: [arch-general] [PATCH] gdisk patches
Mark Pustjens wrote: On Sat, 17 Jul 2010, Ionuț Bîru wrote: On 07/17/2010 01:23 AM, Mark Pustjens wrote: On Fri, 16 Jul 2010, Ionuț Bîru wrote: On 07/16/2010 10:11 PM, Mark Pustjens wrote: Hi List, Below a patch wich fixes two bugs in the gdisk package. They have been submitted uptream but not yet been accepted. then we don't need them if upstream did that They didn't do anything :) Submitted only a few hours ago. post a link to the bug report or mailing list so we can follow the progress As i said in my original post: there is no place for a bug report, nor is there a mailing list. http://sourceforge.net/sendmessage.php?touser=238224 But you're right, it's not easy to find and I can't guarantee that the dev will get the message or that he'll answer... Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: [arch-general] Keep older kernel intact while upgrading to new kernel
I think it's a bad idea, because the directory /lib/modules/$oldVersion$ will be removed when the package is upgraded kernel. Trivial solution not exists. 2010/7/17 ganlu rhythm@gmail.com -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2010年07月17日 15:46, Ionuț Bîru wrote: On 07/17/2010 09:27 AM, Madhurya Kakati wrote: Hi, While updating to a new kernel pacman replaces the older kernel with the new one. Is there someway to keep the older kernel in /boot and have new entries for new kernel in menu.lst while keeping old entries intact? no You can alway do it manually, simply copy the old kernel image as other name before you update, then modify the correspondent line in menu.1st file. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMQWwCAAoJEOaLWowX7DBTyPYH/jVEL3/YbKpw4g2YQeEDIKhN E1HHpBq0LLxHmqe5N8C79VzGV8V2RSu/B6qsmzjO3f98xd2E+ev4Etd8YGOV5vvU pkKu+UOeDEubFrX75L1/802wTIfO5DI21VaLpRKD/+JJ2R2rTa1Bk2HmTF5DWmoh mpVXOydJyIXNeu2BVUemjn4TK2t6IGs22yCI107F5uD3SV1ZtpavsZ3xZCav3e6B x2R8C2NCF/r3BnVE3BYh9AlX617/F03hCQPOKMyXjLnMylrVvfkxMM1Q9kW97pcl nGR+1YUbNgTnaylyls2dOp4UAwzALcCDVwq9oJnitTcR6f/OlIH6ELUtX0gvUUU= =t+0W -END PGP SIGNATURE-
Re: [arch-general] [PATCH 44/48] Save error messages to /dev/tty9.
On Fri, 2010-07-16 at 14:09 +0200, Thomas Bächler wrote:
Am 30.06.2010 23:47, schrieb Victor Lowther:
---
functions |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/functions b/functions
index 9ec8b5e..f1dce8a 100644
--- a/functions
+++ b/functions
@@ -4,6 +4,10 @@
# width:
+grep -q initdebug {
+exec 2/dev/tty9
+}
+
STAT_COL=80
if [[ ! -t 1 ]]; then
USECOLOR=
Apart from Kurt's comment:
Won't this cause errors to be omitted from the console? I'd much rather
implement a full boot logging using bootlogd, but last time I tried, it
was broken. Redirecting stderr away from the normal output seems
unhelpful, and unecessary.
The intent was to redirect the errors to be redirected to tty9 -- when I
was debugging these scripts, syntax errors kept getting nuked by the
gettys and X starting up, so putting them on a tty that was not running
a getty seemed like the easiest solution.
I'd much rather omit this in favor of a patch that adds proper boot
logging, which is a feature we really need.
No problem. The bashification-redux branch @
git://fnordovax.org/~victor/arch-initscripts has this as the last patch
to make it easy to drop.
--
Victor Lowther
LPIC2 UCP RHCE
Re: [arch-general] [PATCH 43/48] Add a PKGBUILD for building initscripts-git for testing.
On Fri, 2010-07-16 at 14:06 +0200, Thomas Bächler wrote:
Am 30.06.2010 23:47, schrieb Victor Lowther:
This builds straight out of a git checkout.
---
PKGBUILD | 23 +++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/PKGBUILD b/PKGBUILD
new file mode 100644
index 000..79b3403
--- /dev/null
+++ b/PKGBUILD
@@ -0,0 +1,23 @@
+pkgname=initscripts-git
+pkgver=$(date +%s)
+pkgrel=$(git log --pretty=format:%h |head -n 1)
+pkgdesc=System initialization/bootup scripts
+arch=('i686' 'x86_64')
+url=http://www.archlinux.org;
+license=('GPL')
+groups=('base')
+conflicts=('initscripts')
+provides=('initscripts=')
+backup=(etc/inittab etc/rc.conf etc/rc.local etc/rc.local.shutdown)
+depends=('glibc' 'bash' 'awk' 'grep' 'coreutils' 'sed' 'udev=139-1'
+ 'net-tools' 'ncurses' 'kbd' 'findutils' 'sysvinit')
+optdepends=('bridge-utils: Network bridging support'
+'dhcpcd: DHCP network configuration'
+'wireless_tools: Wireless networking')
+source=()
+sha256sums=()
+
+build() {
+ cd ..
+ DESTDIR=${pkgdir} ./install.sh
+}
Not necessary IMO, but nice to have. Should come with a .gitignore patch
that adds '*pkg.tar.*'.
It is nice to have -- being able to
makepkg sudo pacman -U inits*.tar.*
sure does make it easier to test things.
Why do you think a .gitignore patch is needed? Unless someone does
something silly like adding the tarball to the git repo git will ignore
it anyways.
--
Victor Lowther
LPIC2 UCP RHCE
Re: [arch-general] Keep older kernel intact while upgrading to new kernel
2010/7/17 Евгений Борисов fle...@gmail.com: I think it's a bad idea, because the directory /lib/modules/$oldVersion$ will be removed when the package is upgraded kernel. Trivial solution not exists. 2010/7/17 ganlu rhythm@gmail.com -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2010年07月17日 15:46, Ionuț Bîru wrote: On 07/17/2010 09:27 AM, Madhurya Kakati wrote: Hi, While updating to a new kernel pacman replaces the older kernel with the new one. Is there someway to keep the older kernel in /boot and have new entries for new kernel in menu.lst while keeping old entries intact? no You can alway do it manually, simply copy the old kernel image as other name before you update, then modify the correspondent line in menu.1st file. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMQWwCAAoJEOaLWowX7DBTyPYH/jVEL3/YbKpw4g2YQeEDIKhN E1HHpBq0LLxHmqe5N8C79VzGV8V2RSu/B6qsmzjO3f98xd2E+ev4Etd8YGOV5vvU pkKu+UOeDEubFrX75L1/802wTIfO5DI21VaLpRKD/+JJ2R2rTa1Bk2HmTF5DWmoh mpVXOydJyIXNeu2BVUemjn4TK2t6IGs22yCI107F5uD3SV1ZtpavsZ3xZCav3e6B x2R8C2NCF/r3BnVE3BYh9AlX617/F03hCQPOKMyXjLnMylrVvfkxMM1Q9kW97pcl nGR+1YUbNgTnaylyls2dOp4UAwzALcCDVwq9oJnitTcR6f/OlIH6ELUtX0gvUUU= =t+0W -END PGP SIGNATURE- If the point is to have a kernel that works, check out the -lts kernel. I on the other hand, have used kernel26-rc in the AUR as my main kernel, and kernel26 as a backup on my desktop :P
Re: [arch-general] Keep older kernel intact while upgrading to new kernel
On Sat, 2010-07-17 at 18:05 +0400, Евгений Борисов wrote: I think it's a bad idea, because the directory /lib/modules/$oldVersion$ will be removed when the package is upgraded kernel. Trivial solution not exists. My solution is to hand-roll my own kernels and initramfs'es after removing the kernel and mkinitcpio packages. The way Arch handles its kernel packages is a weak point -- Fedora and Ubuntu get this bit right. 2010/7/17 ganlu rhythm@gmail.com -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2010年07月17日 15:46, Ionuț Bîru wrote: On 07/17/2010 09:27 AM, Madhurya Kakati wrote: Hi, While updating to a new kernel pacman replaces the older kernel with the new one. Is there someway to keep the older kernel in /boot and have new entries for new kernel in menu.lst while keeping old entries intact? no You can alway do it manually, simply copy the old kernel image as other name before you update, then modify the correspondent line in menu.1st file. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMQWwCAAoJEOaLWowX7DBTyPYH/jVEL3/YbKpw4g2YQeEDIKhN E1HHpBq0LLxHmqe5N8C79VzGV8V2RSu/B6qsmzjO3f98xd2E+ev4Etd8YGOV5vvU pkKu+UOeDEubFrX75L1/802wTIfO5DI21VaLpRKD/+JJ2R2rTa1Bk2HmTF5DWmoh mpVXOydJyIXNeu2BVUemjn4TK2t6IGs22yCI107F5uD3SV1ZtpavsZ3xZCav3e6B x2R8C2NCF/r3BnVE3BYh9AlX617/F03hCQPOKMyXjLnMylrVvfkxMM1Q9kW97pcl nGR+1YUbNgTnaylyls2dOp4UAwzALcCDVwq9oJnitTcR6f/OlIH6ELUtX0gvUUU= =t+0W -END PGP SIGNATURE- -- Victor Lowther LPIC2 UCP RHCE
Re: [arch-general] Keep older kernel intact while upgrading to new kernel
On 07/17/2010 05:17 PM, Victor Lowther wrote: On Sat, 2010-07-17 at 18:05 +0400, Евгений Борисов wrote: I think it's a bad idea, because the directory /lib/modules/$oldVersion$ will be removed when the package is upgraded kernel. Trivial solution not exists. My solution is to hand-roll my own kernels and initramfs'es after removing the kernel and mkinitcpio packages. The way Arch handles its kernel packages is a weak point -- Fedora and Ubuntu get this bit right. http://bugs.archlinux.org/task/16702 -- Ionuț
Re: [arch-general] [PATCH 43/48] Add a PKGBUILD for building initscripts-git for testing.
On Sat, 2010-07-17 at 16:34 +0200, Thomas Bächler wrote: Am 17.07.2010 16:13, schrieb Victor Lowther: Why do you think a .gitignore patch is needed? Unless someone does something silly like adding the tarball to the git repo git will ignore it anyways. You want to keep git status clean, especially with __git_ps1. If there is nothing changed/to commit, I want to see a clean git status output. Huh. I guess I have never used git status before. -- Victor Lowther LPIC2 UCP RHCE
[arch-general] nfs problem
Hello, I tried to set up a nfs server and a nfs client in my network. I followed the instructions from the arch linux wiki. The server's ip address is 192.168.0.100 and the client's one is 192.168.0.101. I inserted the option --no-notify in /etc/conf.d/nfs-common.conf on the server. Here are the entries of the configuration files. --- On the server --- /etc/export: /home/user/share192.168.0.101(rw,sync,no_root_squash,no_subtree_check) /etc/hosts.allow: nfsd: 192.168.0.101/255.255.255.255 rpcbind: 192.168.0.101/255.255.255.255 mountd: 192.168.0.101/255.255.255.255 --- On the client --- /etc/hosts.allow: rpcbind: 192.168.0.100/255.255.255.255 If I try to mount the nfs share with the command mount 192.168.0.100:/home/user/share /home/user/share, I will get the error message mount.nfs: access denied by server while mounting. The directories /home/user/share on both machines are owned by the user. Maybe someone has an idea? Thanks! Bye Lars
[arch-general] Nouveau problem
Hello again, the graphics card on my old pc is a Nvidia GeForce 3 Ti 200. Before the release of the version 1.8 of X.org I used the proprietary driver. Because this is not possible anymore, I tried the nouveau driver and everything I can get is a blank screen. The vesa driver works correctly with the same configuration files. Thanks for your time! Bye Lars
Re: [arch-general] What broke ctrl+c ??
On 07/17/10 01:49, David C. Rankin wrote: On 07/17/2010 12:01 AM, Corey Johns wrote: Try a new keyboard to help isolate the problem. I would, but this is a laptop :p For the record: All laptops I've seen have USB ports, and all modern separate-keyboards I've seen have USB plugs [unless they're Bluetooth based, which might also work with your laptop] -- so why not test with an external keyboard if you have one around? They *work* on my laptop, even if I don't use them for everyday use. [since you already found Ctrl-C works in Konsole, there's probably no use to do that test anymore though] -Isaac
Re: [arch-general] Keep older kernel intact while upgrading to new kernel
On Sat, 2010-07-17 at 09:17 -0500, Victor Lowther wrote: On Sat, 2010-07-17 at 18:05 +0400, Евгений Борисов wrote: I think it's a bad idea, because the directory /lib/modules/$oldVersion$ will be removed when the package is upgraded kernel. Trivial solution not exists. My solution is to hand-roll my own kernels and initramfs'es after removing the kernel and mkinitcpio packages. The way Arch handles its kernel packages is a weak point -- Fedora and Ubuntu get this bit right. Yeah, why not keep all previous kernels and headers around. We could automatically extend menu.lst too! I'm not sure what you like about Fedora and Ubuntu handling of kernels, but I found it very annoying to have all that stuff hanging around. Would be worse with rolling release I'm sure.
Re: [arch-general] Keep older kernel intact while upgrading to new kernel
On Sat, Jul 17, 2010 at 10:10 AM, Ng Oon-Ee ngoo...@gmail.com wrote: On Sat, 2010-07-17 at 09:17 -0500, Victor Lowther wrote: On Sat, 2010-07-17 at 18:05 +0400, Евгений Борисов wrote: I think it's a bad idea, because the directory /lib/modules/$oldVersion$ will be removed when the package is upgraded kernel. Trivial solution not exists. My solution is to hand-roll my own kernels and initramfs'es after removing the kernel and mkinitcpio packages. The way Arch handles its kernel packages is a weak point -- Fedora and Ubuntu get this bit right. Yeah, why not keep all previous kernels and headers around. We could automatically extend menu.lst too! I'm not sure what you like about Fedora and Ubuntu handling of kernels, but I found it very annoying to have all that stuff hanging around. Would be worse with rolling release I'm sure. Agreed with Ng Oon-Ee on this one.
Re: [arch-general] Keep older kernel intact while upgrading to new kernel
2010/7/17 Thomas Dziedzic gos...@gmail.com On Sat, Jul 17, 2010 at 10:10 AM, Ng Oon-Ee ngoo...@gmail.com wrote: On Sat, 2010-07-17 at 09:17 -0500, Victor Lowther wrote: On Sat, 2010-07-17 at 18:05 +0400, Евгений Борисов wrote: I think it's a bad idea, because the directory /lib/modules/$oldVersion$ will be removed when the package is upgraded kernel. Trivial solution not exists. My solution is to hand-roll my own kernels and initramfs'es after removing the kernel and mkinitcpio packages. The way Arch handles its kernel packages is a weak point -- Fedora and Ubuntu get this bit right. Yeah, why not keep all previous kernels and headers around. We could automatically extend menu.lst too! I'm not sure what you like about Fedora and Ubuntu handling of kernels, but I found it very annoying to have all that stuff hanging around. Would be worse with rolling release I'm sure. Agreed with Ng Oon-Ee on this one. In this case, I think the best would be the middle ground. I mean, when upgrading the kernel, the older would be named “vmlinuz26-old” and the initramfs “kernel26-old.img”. This would be a secutiry measure --- what if a new kernel doesn't work? -- Rafael Beraldo http://cabaladada.org
Re: [arch-general] Keep older kernel intact while upgrading to new kernel
On Sat, 2010-07-17 at 12:23 -0300, Rafael Beraldo wrote: 2010/7/17 Thomas Dziedzic gos...@gmail.com On Sat, Jul 17, 2010 at 10:10 AM, Ng Oon-Ee ngoo...@gmail.com wrote: On Sat, 2010-07-17 at 09:17 -0500, Victor Lowther wrote: On Sat, 2010-07-17 at 18:05 +0400, Евгений Борисов wrote: I think it's a bad idea, because the directory /lib/modules/$oldVersion$ will be removed when the package is upgraded kernel. Trivial solution not exists. My solution is to hand-roll my own kernels and initramfs'es after removing the kernel and mkinitcpio packages. The way Arch handles its kernel packages is a weak point -- Fedora and Ubuntu get this bit right. Yeah, why not keep all previous kernels and headers around. We could automatically extend menu.lst too! I'm not sure what you like about Fedora and Ubuntu handling of kernels, but I found it very annoying to have all that stuff hanging around. Would be worse with rolling release I'm sure. Agreed with Ng Oon-Ee on this one. In this case, I think the best would be the middle ground. I mean, when upgrading the kernel, the older would be named “vmlinuz26-old” and the initramfs “kernel26-old.img”. This would be a secutiry measure --- what if a new kernel doesn't work? When a kernel is updated kernel modules are as well. For example, nvidia is pushed up one pkgrel because a new kernel is out. With your suggestion the old kernel is saved as vmlinuz26-old. Which can't get a graphical login because the old nvidia module is gone. Also, because menu.lst is not automatically edited for you, you'd still need to manually add the old kernel to grub to be able to boot from it. I submit that users who are able to do that (as all Archers are supposed to be able to do) are also able to downgrade the kernel from a live disc.
Re: [arch-general] Nouveau problem
On 17 July 2010 17:01, Lars Tennstedt o...@larstennstedt.de wrote: Hello again, the graphics card on my old pc is a Nvidia GeForce 3 Ti 200. Before the release of the version 1.8 of X.org I used the proprietary driver. Because this is not possible anymore, I tried the nouveau driver and everything I can get is a blank screen. The vesa driver works correctly with the same configuration files. Thanks for your time! Bye Lars Today new nvidia legacy drivers were released, maybe you can try them.
Re: [arch-general] Keep older kernel intact while upgrading to new kernel
On Sat, Jul 17, 2010 at 12:23:48PM -0300, Rafael Beraldo wrote: 2010/7/17 Thomas Dziedzic gos...@gmail.com On Sat, Jul 17, 2010 at 10:10 AM, Ng Oon-Ee ngoo...@gmail.com wrote: On Sat, 2010-07-17 at 09:17 -0500, Victor Lowther wrote: On Sat, 2010-07-17 at 18:05 +0400, Евгений Борисов wrote: I think it's a bad idea, because the directory /lib/modules/$oldVersion$ will be removed when the package is upgraded kernel. Trivial solution not exists. My solution is to hand-roll my own kernels and initramfs'es after removing the kernel and mkinitcpio packages. The way Arch handles its kernel packages is a weak point -- Fedora and Ubuntu get this bit right. Yeah, why not keep all previous kernels and headers around. We could automatically extend menu.lst too! I'm not sure what you like about Fedora and Ubuntu handling of kernels, but I found it very annoying to have all that stuff hanging around. Would be worse with rolling release I'm sure. Agreed with Ng Oon-Ee on this one. In this case, I think the best would be the middle ground. I mean, when upgrading the kernel, the older would be named “vmlinuz26-old” and the initramfs “kernel26-old.img”. This would be a secutiry measure --- what if a new kernel doesn't work? Then you're boned anyways because /lib/modules/$(uname -r)/ was replaced. It'll be missing in the case of a 2.6.X upgrade. d
Re: [arch-general] Keep older kernel intact while upgrading to new kernel
On Sat, 2010-07-17 at 23:10 +0800, Ng Oon-Ee wrote: On Sat, 2010-07-17 at 09:17 -0500, Victor Lowther wrote: On Sat, 2010-07-17 at 18:05 +0400, Евгений Борисов wrote: I think it's a bad idea, because the directory /lib/modules/$oldVersion$ will be removed when the package is upgraded kernel. Trivial solution not exists. My solution is to hand-roll my own kernels and initramfs'es after removing the kernel and mkinitcpio packages. The way Arch handles its kernel packages is a weak point -- Fedora and Ubuntu get this bit right. Yeah, why not keep all previous kernels and headers around. We could automatically extend menu.lst too! It wold be better than updating to a new kernel, rebooting, and having to boot to a LiveCD to get back into your system because the new kernel fscked things up. Keeping versioned header files also comes in handy -- I take it you heve never tried any sort of testing with out-of-tree drivers or kernel subsystems? Using DKMS on arch is a pointless waste of time because older kernel headers are not kept around. I'm not sure what you like about Fedora and Ubuntu handling of kernels, but I found it very annoying to have all that stuff hanging around. Would be worse with rolling release I'm sure. I like knowing that I will not have to hunt for a LiveCD or a rescue USB drive if a kernel update renders the system unbootable. -- Victor Lowther LPIC2 UCP RHCE
Re: [arch-general] Keep older kernel intact while upgrading to new kernel
On Sat, Jul 17, 2010 at 10:38 AM, Victor Lowther victor.lowt...@gmail.com wrote: On Sat, 2010-07-17 at 23:10 +0800, Ng Oon-Ee wrote: On Sat, 2010-07-17 at 09:17 -0500, Victor Lowther wrote: On Sat, 2010-07-17 at 18:05 +0400, Евгений Борисов wrote: I think it's a bad idea, because the directory /lib/modules/$oldVersion$ will be removed when the package is upgraded kernel. Trivial solution not exists. My solution is to hand-roll my own kernels and initramfs'es after removing the kernel and mkinitcpio packages. The way Arch handles its kernel packages is a weak point -- Fedora and Ubuntu get this bit right. Yeah, why not keep all previous kernels and headers around. We could automatically extend menu.lst too! It wold be better than updating to a new kernel, rebooting, and having to boot to a LiveCD to get back into your system because the new kernel fscked things up. Keeping versioned header files also comes in handy -- I take it you heve never tried any sort of testing with out-of-tree drivers or kernel subsystems? Using DKMS on arch is a pointless waste of time because older kernel headers are not kept around. I'm not sure what you like about Fedora and Ubuntu handling of kernels, but I found it very annoying to have all that stuff hanging around. Would be worse with rolling release I'm sure. I like knowing that I will not have to hunt for a LiveCD or a rescue USB drive if a kernel update renders the system unbootable. This wouldn't be a problem if you have a backup kernel :)
Re: [arch-general] Keep older kernel intact while upgrading to new kernel
On Sat, 2010-07-17 at 10:42 -0500, Thomas Dziedzic wrote: On Sat, Jul 17, 2010 at 10:38 AM, Victor Lowther victor.lowt...@gmail.com wrote: On Sat, 2010-07-17 at 23:10 +0800, Ng Oon-Ee wrote: On Sat, 2010-07-17 at 09:17 -0500, Victor Lowther wrote: On Sat, 2010-07-17 at 18:05 +0400, Евгений Борисов wrote: I think it's a bad idea, because the directory /lib/modules/$oldVersion$ will be removed when the package is upgraded kernel. Trivial solution not exists. My solution is to hand-roll my own kernels and initramfs'es after removing the kernel and mkinitcpio packages. The way Arch handles its kernel packages is a weak point -- Fedora and Ubuntu get this bit right. Yeah, why not keep all previous kernels and headers around. We could automatically extend menu.lst too! It wold be better than updating to a new kernel, rebooting, and having to boot to a LiveCD to get back into your system because the new kernel fscked things up. Keeping versioned header files also comes in handy -- I take it you heve never tried any sort of testing with out-of-tree drivers or kernel subsystems? Using DKMS on arch is a pointless waste of time because older kernel headers are not kept around. I'm not sure what you like about Fedora and Ubuntu handling of kernels, but I found it very annoying to have all that stuff hanging around. Would be worse with rolling release I'm sure. I like knowing that I will not have to hunt for a LiveCD or a rescue USB drive if a kernel update renders the system unbootable. This wouldn't be a problem if you have a backup kernel :) Oh, I do. I would just prefer to work with the package management framework, not work around it. -- Victor Lowther LPIC2 UCP RHCE
Re: [arch-general] Keep older kernel intact while upgrading to new kernel
On Sat 17 Jul 2010 11:06 -0500, Victor Lowther wrote: On Sat, 2010-07-17 at 10:42 -0500, Thomas Dziedzic wrote: On Sat, Jul 17, 2010 at 10:38 AM, Victor Lowther victor.lowt...@gmail.com wrote: On Sat, 2010-07-17 at 23:10 +0800, Ng Oon-Ee wrote: On Sat, 2010-07-17 at 09:17 -0500, Victor Lowther wrote: On Sat, 2010-07-17 at 18:05 +0400, Евгений Борисов wrote: I think it's a bad idea, because the directory /lib/modules/$oldVersion$ will be removed when the package is upgraded kernel. Trivial solution not exists. My solution is to hand-roll my own kernels and initramfs'es after removing the kernel and mkinitcpio packages. The way Arch handles its kernel packages is a weak point -- Fedora and Ubuntu get this bit right. Yeah, why not keep all previous kernels and headers around. We could automatically extend menu.lst too! It wold be better than updating to a new kernel, rebooting, and having to boot to a LiveCD to get back into your system because the new kernel fscked things up. Keeping versioned header files also comes in handy -- I take it you heve never tried any sort of testing with out-of-tree drivers or kernel subsystems? Using DKMS on arch is a pointless waste of time because older kernel headers are not kept around. I'm not sure what you like about Fedora and Ubuntu handling of kernels, but I found it very annoying to have all that stuff hanging around. Would be worse with rolling release I'm sure. I like knowing that I will not have to hunt for a LiveCD or a rescue USB drive if a kernel update renders the system unbootable. This wouldn't be a problem if you have a backup kernel :) Oh, I do. I would just prefer to work with the package management framework, not work around it. I think this is something that hooks could do. It's a feature that's in brainstorming. Maybe you could help implement it. http://wiki.archlinux.org/index.php/User:Allan/Pacman_Hooks Cheers!
Re: [arch-general] Keep older kernel intact while upgrading to new kernel
On Jul 17, 2010, at 11:42 AM, Loui Chang louipc@gmail.com wrote: On Sat 17 Jul 2010 11:06 -0500, Victor Lowther wrote: On Sat, 2010-07-17 at 10:42 -0500, Thomas Dziedzic wrote: On Sat, Jul 17, 2010 at 10:38 AM, Victor Lowther victor.lowt...@gmail.com wrote: On Sat, 2010-07-17 at 23:10 +0800, Ng Oon-Ee wrote: On Sat, 2010-07-17 at 09:17 -0500, Victor Lowther wrote: On Sat, 2010-07-17 at 18:05 +0400, Евгений Борисов wrote: I think it's a bad idea, because the directory /lib/modules/ $oldVersion$ will be removed when the package is upgraded kernel. Trivial solution not exists. My solution is to hand-roll my own kernels and initramfs'es after removing the kernel and mkinitcpio packages. The way Arch handles its kernel packages is a weak point -- Fedora and Ubuntu get this bit right. Yeah, why not keep all previous kernels and headers around. We could automatically extend menu.lst too! It wold be better than updating to a new kernel, rebooting, and having to boot to a LiveCD to get back into your system because the new kernel fscked things up. Keeping versioned header files also comes in handy -- I take it you heve never tried any sort of testing with out-of-tree drivers or kernel subsystems? Using DKMS on arch is a pointless waste of time because older kernel headers are not kept around. I'm not sure what you like about Fedora and Ubuntu handling of kernels, but I found it very annoying to have all that stuff hanging around. Would be worse with rolling release I'm sure. I like knowing that I will not have to hunt for a LiveCD or a rescue USB drive if a kernel update renders the system unbootable. This wouldn't be a problem if you have a backup kernel :) Oh, I do. I would just prefer to work with the package management framework, not work around it. I think this is something that hooks could do. It's a feature that's in brainstorming. Maybe you could help implement it. http://wiki.archlinux.org/index.php/User:Allan/Pacman_Hooks As a heads up, this (kernel rollbacks) is a planned feature of the mkinitcpio-btrfs hook in AUR. It will be implemented in one or more of about three ways: https://bbs.archlinux.org/viewtopic.php?pid=778395#p778395 and will be in the next major release; hopefully within 3 weeks or so. I'm less than 2 weeks from moving my family to a new state so free development has taken a back seat for a short while. You must be using btrfs for / of course. C Anthony
Re: [arch-general] [PATCH 43/48] Add a PKGBUILD for building initscripts-git for testing.
pkgrel=$(git rev-parse --short HEAD)
much simpler.
On Wed, Jun 30, 2010 at 11:47 PM, Victor Lowther
victor.lowt...@gmail.com wrote:
This builds straight out of a git checkout.
---
PKGBUILD | 23 +++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/PKGBUILD b/PKGBUILD
new file mode 100644
index 000..79b3403
--- /dev/null
+++ b/PKGBUILD
@@ -0,0 +1,23 @@
+pkgname=initscripts-git
+pkgver=$(date +%s)
+pkgrel=$(git log --pretty=format:%h |head -n 1)
+pkgdesc=System initialization/bootup scripts
+arch=('i686' 'x86_64')
+url=http://www.archlinux.org;
+license=('GPL')
+groups=('base')
+conflicts=('initscripts')
+provides=('initscripts=')
+backup=(etc/inittab etc/rc.conf etc/rc.local etc/rc.local.shutdown)
+depends=('glibc' 'bash' 'awk' 'grep' 'coreutils' 'sed' 'udev=139-1'
+ 'net-tools' 'ncurses' 'kbd' 'findutils' 'sysvinit')
+optdepends=('bridge-utils: Network bridging support'
+ 'dhcpcd: DHCP network configuration'
+ 'wireless_tools: Wireless networking')
+source=()
+sha256sums=()
+
+build() {
+ cd ..
+ DESTDIR=${pkgdir} ./install.sh
+}
--
1.7.1
Re: [arch-general] Keep older kernel intact while upgrading to new kernel
On Sat 17 Jul 2010 12:15 -0500, C Anthony Risinger wrote: On Jul 17, 2010, at 11:42 AM, Loui Chang louipc@gmail.com wrote: On Sat 17 Jul 2010 11:06 -0500, Victor Lowther wrote: Oh, I do. I would just prefer to work with the package management framework, not work around it. I think this is something that hooks could do. It's a feature that's in brainstorming. Maybe you could help implement it. http://wiki.archlinux.org/index.php/User:Allan/Pacman_Hooks As a heads up, this (kernel rollbacks) is a planned feature of the mkinitcpio-btrfs hook in AUR. It will be implemented in one or more of about three ways: https://bbs.archlinux.org/viewtopic.php?pid=778395#p778395 You must be using btrfs for / of course. So, that's not something that would work within the package management framework, is it?
Re: [arch-general] Keep older kernel intact while upgrading to new kernel
On Sat, Jul 17, 2010 at 2:08 PM, Loui Chang louipc@gmail.com wrote: On Sat 17 Jul 2010 12:15 -0500, C Anthony Risinger wrote: On Jul 17, 2010, at 11:42 AM, Loui Chang louipc@gmail.com wrote: On Sat 17 Jul 2010 11:06 -0500, Victor Lowther wrote: Oh, I do. I would just prefer to work with the package management framework, not work around it. I think this is something that hooks could do. It's a feature that's in brainstorming. Maybe you could help implement it. http://wiki.archlinux.org/index.php/User:Allan/Pacman_Hooks As a heads up, this (kernel rollbacks) is a planned feature of the mkinitcpio-btrfs hook in AUR. It will be implemented in one or more of about three ways: https://bbs.archlinux.org/viewtopic.php?pid=778395#p778395 You must be using btrfs for / of course. So, that's not something that would work within the package management framework, is it? no, it would not. it requires you to manually run the proper command prior to upgrading. it could be automated by either a pacman hook, or putting the command in a wrapper script around pacman. there has been some big interest in rollback from a couple devs, so maybe it will make its way into pacman/libalpm official, but idk. at any rate, it will be a solution to the kernel rollback problem, and will suffice for some; it's just that it requires a btrfs root. the next release will include this functionality, along with a tool to work with/create system snapshots (and for use in said wrapper). C Anthony
Re: [arch-general] Keep older kernel intact while upgrading to new kernel
BTRFS is not marked stable by developers, so it can not used in stable arch. 2010/7/17 C Anthony Risinger anth...@extof.me On Sat, Jul 17, 2010 at 2:08 PM, Loui Chang louipc@gmail.com wrote: On Sat 17 Jul 2010 12:15 -0500, C Anthony Risinger wrote: On Jul 17, 2010, at 11:42 AM, Loui Chang louipc@gmail.com wrote: On Sat 17 Jul 2010 11:06 -0500, Victor Lowther wrote: Oh, I do. I would just prefer to work with the package management framework, not work around it. I think this is something that hooks could do. It's a feature that's in brainstorming. Maybe you could help implement it. http://wiki.archlinux.org/index.php/User:Allan/Pacman_Hooks As a heads up, this (kernel rollbacks) is a planned feature of the mkinitcpio-btrfs hook in AUR. It will be implemented in one or more of about three ways: https://bbs.archlinux.org/viewtopic.php?pid=778395#p778395 You must be using btrfs for / of course. So, that's not something that would work within the package management framework, is it? no, it would not. it requires you to manually run the proper command prior to upgrading. it could be automated by either a pacman hook, or putting the command in a wrapper script around pacman. there has been some big interest in rollback from a couple devs, so maybe it will make its way into pacman/libalpm official, but idk. at any rate, it will be a solution to the kernel rollback problem, and will suffice for some; it's just that it requires a btrfs root. the next release will include this functionality, along with a tool to work with/create system snapshots (and for use in said wrapper). C Anthony
Re: [arch-general] Keep older kernel intact while upgrading to new kernel
IIRC it is being marked stable in 2.6.35. Stable schmable... works like a treat for me and many others; it's just a possible solution. C Anthony [mobile] On Jul 17, 2010, at 3:46 PM, Евгений Борисов fle...@gmail.com wrote: BTRFS is not marked stable by developers, so it can not used in stable arch. 2010/7/17 C Anthony Risinger anth...@extof.me On Sat, Jul 17, 2010 at 2:08 PM, Loui Chang louipc@gmail.com wrote: On Sat 17 Jul 2010 12:15 -0500, C Anthony Risinger wrote: On Jul 17, 2010, at 11:42 AM, Loui Chang louipc@gmail.com wrote: On Sat 17 Jul 2010 11:06 -0500, Victor Lowther wrote: Oh, I do. I would just prefer to work with the package management framework, not work around it. I think this is something that hooks could do. It's a feature that's in brainstorming. Maybe you could help implement it. http://wiki.archlinux.org/index.php/User:Allan/Pacman_Hooks As a heads up, this (kernel rollbacks) is a planned feature of the mkinitcpio-btrfs hook in AUR. It will be implemented in one or more of about three ways: https://bbs.archlinux.org/viewtopic.php?pid=778395#p778395 You must be using btrfs for / of course. So, that's not something that would work within the package management framework, is it? no, it would not. it requires you to manually run the proper command prior to upgrading. it could be automated by either a pacman hook, or putting the command in a wrapper script around pacman. there has been some big interest in rollback from a couple devs, so maybe it will make its way into pacman/libalpm official, but idk. at any rate, it will be a solution to the kernel rollback problem, and will suffice for some; it's just that it requires a btrfs root. the next release will include this functionality, along with a tool to work with/create system snapshots (and for use in said wrapper). C Anthony
Re: [arch-general] What broke ctrl+c ??
2010/7/17 David C. Rankin drankina...@suddenlinkmail.com On 07/16/2010 09:52 PM, David C. Rankin wrote: Guys, I have a strange problem. ctrl+c is completely broken on my system. It won't cancel Jack Schit. It is the strangest thing I've seen. I apologize if there is some archain Arch notice on this I apologize, I've missed it. This is easy to test. Just to 'ping anywhere' and then try and kill it with ctrl+c. I have to open another terminal and either 'killall ping' or kill the pid to get the thing to stop. Same thing happens if I mistype a cli and need to cancel the execution (like if I mistype a ' instead of a and the script continues on a new line) What's up with this? OK I've narrowed it down to gnome-terminal. If I use konsole (kde3 or kde4) ctrl+c works just fine. Can anyone else try in gnome-terminal and see if ctrl+c is broken for you? Just type 'ping whatever' and then try to kill ping with crtl+c. I can't and that's a problem. I'm using using gnome-terminal 2.30.2-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 Does Xterm and the VT's works? if so, it must be something with the gnome terminal :)
Re: [arch-general] What broke ctrl+c ??
I had this problem a while back. In my case, I had compiled a random git checkout from awesomewm and that had a bug that was the cause of the failure. If you're using any beta or development branches of your window manager, you might want to try stable. Also, try removing any .xmodmap or other such configurations. On Sat, Jul 17, 2010 at 2:58 PM, Adriano Moura adriano.l...@gmail.comwrote: 2010/7/17 David C. Rankin drankina...@suddenlinkmail.com On 07/16/2010 09:52 PM, David C. Rankin wrote: Guys, I have a strange problem. ctrl+c is completely broken on my system. It won't cancel Jack Schit. It is the strangest thing I've seen. I apologize if there is some archain Arch notice on this I apologize, I've missed it. This is easy to test. Just to 'ping anywhere' and then try and kill it with ctrl+c. I have to open another terminal and either 'killall ping' or kill the pid to get the thing to stop. Same thing happens if I mistype a cli and need to cancel the execution (like if I mistype a ' instead of a and the script continues on a new line) What's up with this? OK I've narrowed it down to gnome-terminal. If I use konsole (kde3 or kde4) ctrl+c works just fine. Can anyone else try in gnome-terminal and see if ctrl+c is broken for you? Just type 'ping whatever' and then try to kill ping with crtl+c. I can't and that's a problem. I'm using using gnome-terminal 2.30.2-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 Does Xterm and the VT's works? if so, it must be something with the gnome terminal :)
Re: [arch-general] Nouveau problem
Try following the nouveau page on ArchWiki and asking in some nouveau-specific support channels, like #nouveau on freenode. 2010/7/17 Lukáš Jirkovský l.jirkov...@gmail.com On 17 July 2010 17:01, Lars Tennstedt o...@larstennstedt.de wrote: Hello again, the graphics card on my old pc is a Nvidia GeForce 3 Ti 200. Before the release of the version 1.8 of X.org I used the proprietary driver. Because this is not possible anymore, I tried the nouveau driver and everything I can get is a blank screen. The vesa driver works correctly with the same configuration files. Thanks for your time! Bye Lars Today new nvidia legacy drivers were released, maybe you can try them.
[arch-general] donate for the improvement and development
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Is there any site which listed the current Arch Linux project objectives, on which user can donate development or improvement of this tasks? - -- Best regards, Dmitry Korzhevin Tel: +38 (039) 295- Office Phone: +38 (044) 383-14-12 E-mail: dkorzhe...@lsupport.net Jabber ID: dkorzhe...@lsupport.net Skype: dkorzhevin URL: http://lsupport.net Linux Support LLC -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMQj6GAAoJEGuRMpfwJUbRnksH/jJwCFrHZiu5wfBhAYKYtcN2 6JBe+6EIVfmKmJGzvUhD2MVTwcjajIGC3oXq8ekVrxV+sH/QheGxGX+QRleJvfxb 1aK0n0zyiYnz8OXEleGgNYqqwsy/ccFiPndH/4rv4YX3Ttm5EZODwq/dVJ9/O6qg Zp32Yn1UbNkHiwnendRTS1Ig5vcbWXuPFr/obST2jPViK1Yj4EMk6nfjN2sQouRd yJQEJLqOSvlu7pCWckewANGQ7pYQbB1OSGAdEMs5kC9+Ludt5zTlJs0bxj1cD7/g /7M0bc4lSU1gqykcLetCuWXbMkbXQC9bhBrhwbnA/q05s66NFgxpSDbhHSzk7pk= =tSai -END PGP SIGNATURE-
Re: [arch-general] donate for the improvement and development
On Sat, Jul 17, 2010 at 6:36 PM, Dmitry Korzhevin dkorzhe...@lsupport.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Is there any site which listed the current Arch Linux project objectives, on which user can donate development or improvement of this tasks? - -- Best regards, Dmitry Korzhevin Tel: +38 (039) 295- Office Phone: +38 (044) 383-14-12 E-mail: dkorzhe...@lsupport.net Jabber ID: dkorzhe...@lsupport.net Skype: dkorzhevin URL: http://lsupport.net Linux Support LLC -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMQj6GAAoJEGuRMpfwJUbRnksH/jJwCFrHZiu5wfBhAYKYtcN2 6JBe+6EIVfmKmJGzvUhD2MVTwcjajIGC3oXq8ekVrxV+sH/QheGxGX+QRleJvfxb 1aK0n0zyiYnz8OXEleGgNYqqwsy/ccFiPndH/4rv4YX3Ttm5EZODwq/dVJ9/O6qg Zp32Yn1UbNkHiwnendRTS1Ig5vcbWXuPFr/obST2jPViK1Yj4EMk6nfjN2sQouRd yJQEJLqOSvlu7pCWckewANGQ7pYQbB1OSGAdEMs5kC9+Ludt5zTlJs0bxj1cD7/g /7M0bc4lSU1gqykcLetCuWXbMkbXQC9bhBrhwbnA/q05s66NFgxpSDbhHSzk7pk= =tSai -END PGP SIGNATURE- Always check the wiki :) http://wiki.archlinux.org/index.php/Getting_Involved
[arch-general] Need Help working on radeon/kernel bug - Where can I get .35rc kernel
Guys, On the kernel/radeon, Andreas suggested: try a .35rc kernel if it's fixed meanwhile. if not ask on the upstream radeon list and then probably file the issue to the Xorg tracker for radeon. My question: (1) where would I look to find the Arch .35rc kernel? I got the rest :p -- 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] What broke ctrl+c ??
On 07/17/2010 03:58 PM, Adriano Moura wrote: Does Xterm and the VT's works? if so, it must be something with the gnome terminal :) Yep, x-term and all other vt's work fine, gnome-terminal is the only one with the un-terminable illness :p -- 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] Need Help working on radeon/kernel bug - Where can I get .35rc kernel
On Sat, Jul 17, 2010 at 7:36 PM, David C. Rankin drankina...@suddenlinkmail.com wrote: Guys, On the kernel/radeon, Andreas suggested: try a .35rc kernel if it's fixed meanwhile. if not ask on the upstream radeon list and then probably file the issue to the Xorg tracker for radeon. My question: (1) where would I look to find the Arch .35rc kernel? I got the rest :p http://aur.archlinux.org/packages.php?ID=31932 kernel26-rc
