[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?
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ț
-----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-----
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.gan@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-----
2010/7/17 Евгений Борисов <flekst@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.gan@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
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.gan@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
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ț
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.
On Sat, Jul 17, 2010 at 10:10 AM, Ng Oon-Ee <ngoonee@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.
2010/7/17 Thomas Dziedzic <gostrc@gmail.com>
On Sat, Jul 17, 2010 at 10:10 AM, Ng Oon-Ee <ngoonee@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
On Sat, 2010-07-17 at 12:23 -0300, Rafael Beraldo wrote:
2010/7/17 Thomas Dziedzic <gostrc@gmail.com>
On Sat, Jul 17, 2010 at 10:10 AM, Ng Oon-Ee <ngoonee@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.
2010/7/17 Ng Oon-Ee <ngoonee@gmail.com>
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
2010/7/17 Rafael Beraldo <rafaelluisberaldo@gmail.com>:
2010/7/17 Thomas Dziedzic <gostrc@gmail.com>
On Sat, Jul 17, 2010 at 10:10 AM, Ng Oon-Ee <ngoonee@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?
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
On Sat, Jul 17, 2010 at 12:23:48PM -0300, Rafael Beraldo wrote:
2010/7/17 Thomas Dziedzic <gostrc@gmail.com>
On Sat, Jul 17, 2010 at 10:10 AM, Ng Oon-Ee <ngoonee@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
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
On Sat, Jul 17, 2010 at 10:38 AM, Victor Lowther <victor.lowther@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 :)
On Sat, 2010-07-17 at 10:42 -0500, Thomas Dziedzic wrote:
On Sat, Jul 17, 2010 at 10:38 AM, Victor Lowther <victor.lowther@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
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.lowther@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!
On Jul 17, 2010, at 11:42 AM, Loui Chang <louipc.ist@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.lowther@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.
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
On Sat 17 Jul 2010 12:15 -0500, C Anthony Risinger wrote:
On Jul 17, 2010, at 11:42 AM, Loui Chang <louipc.ist@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.
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?
On Sat, Jul 17, 2010 at 2:08 PM, Loui Chang <louipc.ist@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.ist@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.
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
BTRFS is not marked stable by developers, so it can not used in stable arch. 2010/7/17 C Anthony Risinger <anthony@extof.me>
On Sat, Jul 17, 2010 at 2:08 PM, Loui Chang <louipc.ist@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.ist@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.
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
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, "Евгений Борисов" <flekst@gmail.com> wrote:
BTRFS is not marked stable by developers, so it can not used in stable arch.
2010/7/17 C Anthony Risinger <anthony@extof.me>
On Sat, Jul 17, 2010 at 2:08 PM, Loui Chang <louipc.ist@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.ist@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.
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
participants (11)
-
C Anthony Risinger
-
Dave Reisner
-
ganlu
-
Ionuț Bîru
-
Loui Chang
-
Madhurya Kakati
-
Ng Oon-Ee
-
Rafael Beraldo
-
Thomas Dziedzic
-
Victor Lowther
-
Евгений Борисов