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? Thomas, I'm going to work through the .xmodmap thoughts Jeff Cook had and then I'll downgrade LTS and see if that cures it. I'll report back on both. Thanks. -- 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 07/17/2010 07:39 PM, Thomas Dziedzic wrote: http://aur.archlinux.org/packages.php?ID=31932 kernel26-rc Thanks Thomas :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 05:38 PM, Jeff Cook wrote: 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. Oh..Oh... This is good information concerning I am experiencing a bug with the 2.6.34 kernel and the radeon driver as we speak (Arch Bug #20200). So this may very well be part of the solution I'm trying to find. I'll give it a go and report back. -- 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 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
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
[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] donate for the improvement and development
On Sat, Jul 17, 2010 at 6:36 PM, Dmitry Korzhevin 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] 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] 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ý > On 17 July 2010 17:01, Lars Tennstedt 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] 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 wrote: > 2010/7/17 David C. Rankin > > > 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 ??
2010/7/17 David C. Rankin > 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] 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, "Евгений Борисов" wrote: > BTRFS is not marked stable by developers, so it can not used in > stable > arch. > > 2010/7/17 C Anthony Risinger > >> On Sat, Jul 17, 2010 at 2:08 PM, Loui Chang >> wrote: >>> On Sat 17 Jul 2010 12:15 -0500, C Anthony Risinger wrote: On Jul 17, 2010, at 11:42 AM, Loui Chang 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 > On Sat, Jul 17, 2010 at 2:08 PM, Loui Chang wrote: > > On Sat 17 Jul 2010 12:15 -0500, C Anthony Risinger wrote: > >> On Jul 17, 2010, at 11:42 AM, Loui Chang 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
On Sat, Jul 17, 2010 at 2:08 PM, Loui Chang wrote: > On Sat 17 Jul 2010 12:15 -0500, C Anthony Risinger wrote: >> On Jul 17, 2010, at 11:42 AM, Loui Chang 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
On Sat 17 Jul 2010 12:15 -0500, C Anthony Risinger wrote: > On Jul 17, 2010, at 11:42 AM, Loui Chang 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] [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
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 Jul 17, 2010, at 11:42 AM, Loui Chang 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 >>> 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] 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 > > 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 Sat, 2010-07-17 at 10:42 -0500, Thomas Dziedzic wrote: > On Sat, Jul 17, 2010 at 10:38 AM, Victor Lowther > 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, Jul 17, 2010 at 10:38 AM, Victor Lowther 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 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
2010/7/17 Ng Oon-Ee > 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. > > I didn't know that. > 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. > > If not for the problem above-mentioned, creating a permanent entry for vmlinuz26-old wouldn't be a problem. One could even edit the entry in the grub menu itself. -- Rafael Beraldo http://cabaladada.org
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 > > > On Sat, Jul 17, 2010 at 10:10 AM, 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! > > > > > > 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
2010/7/17 Rafael Beraldo : > 2010/7/17 Thomas Dziedzic > >> On Sat, Jul 17, 2010 at 10:10 AM, 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! >> > >> > 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? > > As I have said, I keep a backup kernel which I know works. (I don't upgrade both of them without testing the other). You could just install a kernel that works and never upgrade it to be safe :P
Re: [arch-general] Nouveau problem
On 17 July 2010 17:01, Lars Tennstedt 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, 2010-07-17 at 12:23 -0300, Rafael Beraldo wrote: > 2010/7/17 Thomas Dziedzic > > > On Sat, Jul 17, 2010 at 10:10 AM, 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! > > > > > > 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] Keep older kernel intact while upgrading to new kernel
2010/7/17 Thomas Dziedzic > On Sat, Jul 17, 2010 at 10:10 AM, 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! > > > > 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, Jul 17, 2010 at 10:10 AM, 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! > > 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
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] 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
[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
[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
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
Re: [arch-general] [PATCH 43/48] Add a PKGBUILD for building initscripts-git for testing.
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. signature.asc Description: OpenPGP digital signature
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] 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 > > > -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
2010/7/17 Евгений Борисов : > 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 > >> -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] [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] [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] 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 > -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] 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] [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] 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] 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 Sat, Jul 17, 2010 at 07:55, David C. Rankin 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] 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] 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ț
