Re: [arch-general] Reboot - Versioned Kernel Installs - Arch-general

newer
[arch-general] Where are kernel...

Re: [arch-general] Reboot - Versioned Kernel Installs

older
[arch-general] [netcfg] Prerelease...

Paul Gideon Dann

8 Jun 2011 8 Jun '11

4:12 p.m.

I would really like to the kernel that is being replaced kept as a backup. If the latest kernel breaks your hardware, or something else goes wrong, I'd like to have the option of using the kernel that was just replaced, because it's known to work. I wouldn't want more than one old version of the kernel, though. Also, although the -lts kernel is good for this, it isn't intended to solve this problem, and isn't always a perfect fit. For instance, my new laptop has UEFI-related issues that are only being addressed in the *very* latest kernels. I'm not sure -lts would boot for me, but I know that my *current* kernel boots; seems a pity to throw it out it straight away on upgrade, before I can test that the new kernel boots OK... Paul On Monday 06 June 2011 18:23:50 Tom Gundersen wrote:

...

On Mon, Jun 6, 2011 at 6:22 PM, Tavian Barnes wrote:

...
I have kernel26-lts installed as a backup kernel, and this is all that's really necessary for rolling back broken kernel updates. I've been bitten by a BTRFS bug once and rolled back with -lts no problem. -1 from me on keeping multiple kernel versions installed; I really like that arch doesn't keep 6 old kernels around.

I agree.

The reason I am against keeping old kernels around is that we would not be able to test user space against all the possible combinations, so it would not be a good idea to suggest that we do (we do try to support all sorts of self-compiled kernels, but at least if you compile your own kernel it is pretty obvious that it will not be as well tested as the "official" ones).

One possibility would be to do like upstream does and always rename the previous kernel to .old. That should keep the last known working kernel around while making it clear that it should not be relied on for day-to-day use (and that it will get overwritten on the next kernel upgrade so these things won't get old).

That said, I'm not involved with packaging the kernel, so if you want anything to change with how it is packaged (maybe after this discussion is over), it would be best to file a feature request on FS.

Cheers,

Tom

Show replies by date

Jelle van der Waa

8 Jun 8 Jun

4:41 p.m.

New subject: [arch-general] Reboot - Versioned Kernel Installs

On 06/08/2011 04:12 PM, Paul Gideon Dann wrote:

...

I would really like to the kernel that is being replaced kept as a backup. If the latest kernel breaks your hardware, or something else goes wrong, I'd like to have the option of using the kernel that was just replaced, because it's known to work.

I wouldn't want more than one old version of the kernel, though.

Also, although the -lts kernel is good for this, it isn't intended to solve this problem, and isn't always a perfect fit. For instance, my new laptop has UEFI-related issues that are only being addressed in the *very* latest kernels. I'm not sure -lts would boot for me, but I know that my *current* kernel boots; seems a pity to throw it out it straight away on upgrade, before I can test that the new kernel boots OK...

Paul

If you want this, implement it! I have seen some discussions about it and it always tend to users wanting feature X or Y, but didn't commit to it. protip: iirc there are some threads about this on the mailing list, the forums and the bugtracker, start gathering info there. good luck!

...

On Monday 06 June 2011 18:23:50 Tom Gundersen wrote:

...
On Mon, Jun 6, 2011 at 6:22 PM, Tavian Barnes wrote:

...
I have kernel26-lts installed as a backup kernel, and this is all that's really necessary for rolling back broken kernel updates. I've been bitten by a BTRFS bug once and rolled back with -lts no problem. -1 from me on keeping multiple kernel versions installed; I really like that arch doesn't keep 6 old kernels around. I agree.

The reason I am against keeping old kernels around is that we would not be able to test user space against all the possible combinations, so it would not be a good idea to suggest that we do (we do try to support all sorts of self-compiled kernels, but at least if you compile your own kernel it is pretty obvious that it will not be as well tested as the "official" ones).

One possibility would be to do like upstream does and always rename the previous kernel to .old. That should keep the last known working kernel around while making it clear that it should not be relied on for day-to-day use (and that it will get overwritten on the next kernel upgrade so these things won't get old).

That said, I'm not involved with packaging the kernel, so if you want anything to change with how it is packaged (maybe after this discussion is over), it would be best to file a feature request on FS.

Cheers,

Tom

-- Jelle van der Waa

Tom Gundersen

4:45 p.m.

New subject: [arch-general] Reboot - Versioned Kernel Installs

On Wed, Jun 8, 2011 at 4:41 PM, Jelle van der Waa wrote:

...

On 06/08/2011 04:12 PM, Paul Gideon Dann wrote:

...
I would really like to the kernel that is being replaced kept as a backup. If the latest kernel breaks your hardware, or something else goes wrong, I'd like to have the option of using the kernel that was just replaced, because it's known to work.

I wouldn't want more than one old version of the kernel, though.

Also, although the -lts kernel is good for this, it isn't intended to solve this problem, and isn't always a perfect fit. For instance, my new laptop has UEFI-related issues that are only being addressed in the *very* latest kernels. I'm not sure -lts would boot for me, but I know that my *current* kernel boots; seems a pity to throw it out it straight away on upgrade, before I can test that the new kernel boots OK...

Paul

If you want this, implement it! I have seen some discussions about it and it always tend to users wanting feature X or Y, but didn't commit to it. protip: iirc there are some threads about this on the mailing list, the forums and the bugtracker, start gathering info there.

Implementing this should be almost trivial, it's just a patch to kernel26.install. I think if someone wants to see this feature, the best way would be to post a patch to arch-projects@archlinux.org. -t

Paul Gideon Dann

4:54 p.m.

New subject: [arch-general] Reboot - Versioned Kernel Installs

On Wednesday 08 June 2011 15:45:21 Tom Gundersen wrote:

...

On Wed, Jun 8, 2011 at 4:41 PM, Jelle van der Waa wrote:

...
If you want this, implement it! I have seen some discussions about it and it always tend to users wanting feature X or Y, but didn't commit to it. protip: iirc there are some threads about this on the mailing list, the forums and the bugtracker, start gathering info there.

Implementing this should be almost trivial, it's just a patch to kernel26.install. I think if someone wants to see this feature, the best way would be to post a patch to arch-projects@archlinux.org.

That's true; I'll try to find some time to do this in the next week or so, if someone doesn't beat me to it. I was just expecting to contribute to the discussion regarding the best way to deal with kernel upgrades, but if you think this patch would be accepted, I'd be happy to provide it. Paul

Tom Gundersen

5 p.m.

New subject: [arch-general] Reboot - Versioned Kernel Installs

On Wed, Jun 8, 2011 at 4:54 PM, Paul Gideon Dann wrote:

...

On Wednesday 08 June 2011 15:45:21 Tom Gundersen wrote:

...
On Wed, Jun 8, 2011 at 4:41 PM, Jelle van der Waa wrote:

...
If you want this, implement it! I have seen some discussions about it and it always tend to users wanting feature X or Y, but didn't commit to it. protip: iirc there are some threads about this on the mailing list, the forums and the bugtracker, start gathering info there.

Implementing this should be almost trivial, it's just a patch to kernel26.install. I think if someone wants to see this feature, the best way would be to post a patch to arch-projects@archlinux.org.

That's true; I'll try to find some time to do this in the next week or so, if someone doesn't beat me to it.

I was just expecting to contribute to the discussion regarding the best way to deal with kernel upgrades, but if you think this patch would be accepted, I'd be happy to provide it.

Cool! I'd be in favor of the patch, but I don't know if it will be accepted (I'm not the maintainer). At least you'll get the attention of the right people :) -t

Oon-Ee Ng

9 Jun 9 Jun

12:36 a.m.

New subject: [arch-general] Reboot - Versioned Kernel Installs

On Wed, Jun 8, 2011 at 11:00 PM, Tom Gundersen wrote:

...

On Wed, Jun 8, 2011 at 4:54 PM, Paul Gideon Dann wrote:

...
On Wednesday 08 June 2011 15:45:21 Tom Gundersen wrote:

...
On Wed, Jun 8, 2011 at 4:41 PM, Jelle van der Waa wrote:

...
If you want this, implement it! I have seen some discussions about it and it always tend to users wanting feature X or Y, but didn't commit to it. protip: iirc there are some threads about this on the mailing list, the forums and the bugtracker, start gathering info there.

Implementing this should be almost trivial, it's just a patch to kernel26.install. I think if someone wants to see this feature, the best way would be to post a patch to arch-projects@archlinux.org.

That's true; I'll try to find some time to do this in the next week or so, if someone doesn't beat me to it.

I was just expecting to contribute to the discussion regarding the best way to deal with kernel upgrades, but if you think this patch would be accepted, I'd be happy to provide it.

Cool! I'd be in favor of the patch, but I don't know if it will be accepted (I'm not the maintainer). At least you'll get the attention of the right people :)

-t

Such a patch would also have to copy the modules (which aren't under kernel26's 'purview'). For example, nvidia gets upgraded on a major version kernel update, the old kernel which has been renamed doesn't 'work' graphically anymore.

Heiko Baums

1:04 a.m.

New subject: [arch-general] Reboot - Versioned Kernel Installs

Am Thu, 9 Jun 2011 06:36:08 +0800 schrieb Oon-Ee Ng :

...

Such a patch would also have to copy the modules (which aren't under kernel26's 'purview'). For example, nvidia gets upgraded on a major version kernel update, the old kernel which has been renamed doesn't 'work' graphically anymore.

Just for keeping an old kernel image as a fallback keeping the modules, too, isn't necessary. The old kernel image is just to get the system booted to being able to repair the system (downgrading the kernel package again or whatever). The modules shouldn't be necessary for this. Nevertheless I would suggest not to keeping an old kernel version when upgrading the kernel. I'm using Arch Linux for about 4 years now and before then I was using Gentoo for about 6 years. I never had one single issue with a kernel upgrade particularly not such an issue which caused a boot failure. If this really happens - in the very rare cases - then it's always possible to boot from a LiveCD. If someone is really so afraid he can easily install kernel26-lts or another kernel package and, of course, he definitely shouldn't use the [testing] repo. I don't see a real reason for keeping an old kernel image after an update. Just KISS. Heiko

Paul Gideon Dann

12:31 p.m.

New subject: [arch-general] Reboot - Versioned Kernel Installs

On Thursday 09 June 2011 00:04:09 Heiko Baums wrote:

...

schrieb Oon-Ee Ng :

...
Such a patch would also have to copy the modules (which aren't under kernel26's 'purview'). For example, nvidia gets upgraded on a major version kernel update, the old kernel which has been renamed doesn't 'work' graphically anymore.

Yeah, I think this is starting to go beyond what can sensibly be implemented in the install script. I'm putting my voice behind versioned kernels. If we can define the number of old kernels to keep in rc.conf, that idea is actually a superset of my desire to keep a pre-upgrade kernel, without cluttering /boot too much.

...

The old kernel image is just to get the system booted to being able to repair the system (downgrading the kernel package again or whatever). The modules shouldn't be necessary for this.

I'm afraid I don't agree with this; I'd like to be able to boot to a fully- usable system from the pre-upgrade kernel, in case the new kernel is broken.

...

I'm using Arch Linux for about 4 years now and before then I was using Gentoo for about 6 years. I never had one single issue with a kernel upgrade particularly not such an issue which caused a boot failure.

Well, it's happened to me, and it *could* happen to you. Better to prevent the situation, don't you think?

...

If this really happens - in the very rare cases - then it's always possible to boot from a LiveCD.

This is what I've always had to do, but I don't like the idea of relying on always having my LiveCD handy. LTS gets around this, but it doesn't feel like the "correct" solution to a failed upgrade; more of a workaround.

...

If someone is really so afraid he can easily install kernel26-lts or another kernel package and, of course, he definitely shouldn't use the [testing] repo.

Unfortunately, my new laptop has a buggy UEFI implementation and will only boot 3.0.rc1 or newer. Who knows if my hardware will fail to boot with the next release? This worries me, so I'd like to have known-to-work kernels lying around just in case. Paul

Yaro Kasear

3:07 p.m.

New subject: [arch-general] Reboot - Versioned Kernel Installs

On Thursday, June 09, 2011 05:31:06 Paul Gideon Dann wrote:

...

On Thursday 09 June 2011 00:04:09 Heiko Baums wrote:

...
schrieb Oon-Ee Ng :

...
Such a patch would also have to copy the modules (which aren't under kernel26's 'purview'). For example, nvidia gets upgraded on a major version kernel update, the old kernel which has been renamed doesn't 'work' graphically anymore.

Yeah, I think this is starting to go beyond what can sensibly be implemented in the install script. I'm putting my voice behind versioned kernels. If we can define the number of old kernels to keep in rc.conf, that idea is actually a superset of my desire to keep a pre-upgrade kernel, without cluttering /boot too much.

Keeping a single old kernel non-lts, clutters /boot in my opinion.

...

...
The old kernel image is just to get the system booted to being able to repair the system (downgrading the kernel package again or whatever). The modules shouldn't be necessary for this.

I'm afraid I don't agree with this; I'd like to be able to boot to a fully- usable system from the pre-upgrade kernel, in case the new kernel is broken.

The fallback image and LTS kernels cover this base well enough that we don't need 'pre-upgrade' anything.

...

...
I'm using Arch Linux for about 4 years now and before then I was using Gentoo for about 6 years. I never had one single issue with a kernel upgrade particularly not such an issue which caused a boot failure.

Well, it's happened to me, and it *could* happen to you. Better to prevent the situation, don't you think?

Again: Purpose of fallback image and lts kernel. Jacking up /boot with dozens of old kernels is not a needed or desirable solution.

...

...
If this really happens - in the very rare cases - then it's always possible to boot from a LiveCD.

This is what I've always had to do, but I don't like the idea of relying on always having my LiveCD handy. LTS gets around this, but it doesn't feel like the "correct" solution to a failed upgrade; more of a workaround.

Keeping old kernels is more of a workaround than officially supported lts kernels or using a LiveCD.

...

...
If someone is really so afraid he can easily install kernel26-lts or another kernel package and, of course, he definitely shouldn't use the [testing] repo.

Unfortunately, my new laptop has a buggy UEFI implementation and will only boot 3.0.rc1 or newer. Who knows if my hardware will fail to boot with the next release? This worries me, so I'd like to have known-to-work kernels lying around just in case.

Paul

Arch development should never be centered around compensating for users' crappy hardware. There are ways to "fix" UEFI without annoying the other users of Arch with cluttered boot partitions. If you want old kernels that badly, use lts or go to a distribution that implements this bad feature.

Paul Gideon Dann

3:37 p.m.

New subject: [arch-general] Reboot - Versioned Kernel Installs

On Thursday 09 June 2011 14:07:45 Yaro Kasear wrote:

...

On Thursday, June 09, 2011 05:31:06 Paul Gideon Dann wrote:

...
Well, it's happened to me, and it *could* happen to you. Better to prevent the situation, don't you think?

Again: Purpose of fallback image and lts kernel. Jacking up /boot with dozens of old kernels is not a needed or desirable solution.

I don't think that's the case; the purpose of LTS is to provide an extra- stable kernel that is less likely to break between upgrades (hence "long-term support"). It might be good to have around for rescue, but that's not the same as having a last-known-working-configuration kernel. The fallback initrd is completely irrelevant, because as far as I'm aware, that only protects against initrd configuration mistakes and unplanned hardware alterations (e.g. after hardware malfunction).

...

Arch development should never be centered around compensating for users' crappy hardware. There are ways to "fix" UEFI without annoying the other users of Arch with cluttered boot partitions. If you want old kernels that badly, use lts or go to a distribution that implements this bad feature.

It's not as though /boot needs to fulfill many other roles... And would you really label all new hardware "crappy" until it's well supported? Paul

Joe(theWordy)Philbrook

10:48 p.m.

New subject: [arch-general] Reboot - Versioned Kernel Installs

It would appear that on Jun 9, Yaro Kasear did say:

...

On Thursday, June 09, 2011 05:31:06 Paul Gideon Dann wrote:

...
On Thursday 09 June 2011 00:04:09 Heiko Baums wrote:

...
schrieb Oon-Ee Ng :

...
Such a patch would also have to copy the modules (which aren't under kernel26's 'purview'). For example, nvidia gets upgraded on a major version kernel update, the old kernel which has been renamed doesn't 'work' graphically anymore.

Yeah, I think this is starting to go beyond what can sensibly be implemented in the install script. I'm putting my voice behind versioned kernels. If we can define the number of old kernels to keep in rc.conf, that idea is actually a superset of my desire to keep a pre-upgrade kernel, without cluttering /boot too much.

Keeping a single old kernel non-lts, clutters /boot in my opinion.

...
...
The old kernel image is just to get the system booted to being able to repair the system (downgrading the kernel package again or whatever). The modules shouldn't be necessary for this.

I'm afraid I don't agree with this; I'd like to be able to boot to a fully- usable system from the pre-upgrade kernel, in case the new kernel is broken.

I have to agree with Paul here... *_IF_* that is a last known good kernel is to be kept, then including the modulus so that it can function fully is exactly what I'd want if the new kernel didn't work on my system...

...

The fallback image and LTS kernels cover this base well enough that we don't need 'pre-upgrade' anything.

...
...
I'm using Arch Linux for about 4 years now and before then I was using Gentoo for about 6 years. I never had one single issue with a kernel upgrade particularly not such an issue which caused a boot failure.

Well, it's happened to me, and it *could* happen to you. Better to prevent the situation, don't you think?

Again: Purpose of fallback image and lts kernel. Jacking up /boot with dozens of old kernels is not a needed or desirable solution.

...
...
If this really happens - in the very rare cases - then it's always possible to boot from a LiveCD.

This is what I've always had to do, but I don't like the idea of relying on always having my LiveCD handy. LTS gets around this, but it doesn't feel like the "correct" solution to a failed upgrade; more of a workaround.

Keeping old kernels is more of a workaround than officially supported lts kernels or using a LiveCD.

...
...
If someone is really so afraid he can easily install kernel26-lts or another kernel package and, of course, he definitely shouldn't use the [testing] repo.

Unfortunately, my new laptop has a buggy UEFI implementation and will only boot 3.0.rc1 or newer. Who knows if my hardware will fail to boot with the next release? This worries me, so I'd like to have known-to-work kernels lying around just in case.

Paul

Arch development should never be centered around compensating for users' crappy hardware. There are ways to "fix" UEFI without annoying the other users of Arch with cluttered boot partitions. If you want old kernels that badly, use lts or go to a distribution that implements this bad feature.

- - - - - - - - -< s n i p | PASTE | s n i p>- - - - - - - - - - It would appear that on Jun 9, Paul Gideon Dann did say:

...

On Thursday 09 June 2011 14:07:45 Yaro Kasear wrote:

...
On Thursday, June 09, 2011 05:31:06 Paul Gideon Dann wrote:

...
Well, it's happened to me, and it *could* happen to you. Better to prevent the situation, don't you think?

Again: Purpose of fallback image and lts kernel. Jacking up /boot with dozens of old kernels is not a needed or desirable solution.

On that I agree with Yaro, keeping dozens of them would be a terrible idea. But I don't think that is what's being asked for here. certainly not by Paul. He only wants the *_ONE_* "last known good" to be kept in a fully functional way. If only the currently running kernel at the time of a kernel upgrade was kept and all other old kernels were removed it would never escalate to "dozens"...

...

I don't think that's the case; the purpose of LTS is to provide an extra- stable kernel that is less likely to break between upgrades (hence "long-term support"). It might be good to have around for rescue, but that's not the same as having a last-known-working-configuration kernel.

The fallback initrd is completely irrelevant, because as far as I'm aware, that only protects against initrd configuration mistakes and unplanned hardware alterations (e.g. after hardware malfunction).

...
Arch development should never be centered around compensating for users' crappy hardware. There are ways to "fix" UEFI without annoying the other users of Arch with cluttered boot partitions. If you want old kernels that badly, use lts or go to a distribution that implements this bad feature.

It's not as though /boot needs to fulfill many other roles...

And would you really label all new hardware "crappy" until it's well supported?

This is the kind of thing that caused me to become a ‘multi-Linux distribution’, ‘multi-boot’ kind of guy in the first place. When an upgrade «or my own dumb mistakes» break my system I like being able to simply reboot something else and finish anything I'm working on before I spend hours, or days, or even weeks just trying to figure out what broke... It's not likely that anything other than a hardware failure will shut down Arch AND Ubuntu AND PCLinuxOS AND OpenSuSE all at the same time... And for that I still have a laptop... But it would sure be nice to be able to keep using my favorite distro with a fallback kernel instead of having to boot one of the others. But I do have to agree that more than one fully functional old kernel is a bad idea. Though I don't have much trouble manually deleting the really old ones from Ubuntu's /boot dir... -- | ~^~ ~^~ | <*> <*> Joe (theWordy) Philbrook | ^ J(tWdy)P | \___/ <>

C Anthony Risinger

10 Jun 10 Jun

12:36 a.m.

New subject: [arch-general] Reboot - Versioned Kernel Installs

2011/6/9 Joe(theWordy)Philbrook :

...

This is the kind of thing that caused me to become a ‘multi-Linux distribution’, ‘multi-boot’ kind of guy in the first place. When an upgrade «or my own dumb mistakes» break my system I like being able to simply reboot something else and finish anything I'm working on before I spend hours, or days, or even weeks just trying to figure out what broke...

It's not likely that anything other than a hardware failure will shut down Arch AND Ubuntu AND PCLinuxOS AND OpenSuSE all at the same time... And for that I still have a laptop...

But it would sure be nice to be able to keep using my favorite distro with a fallback kernel instead of having to boot one of the others. But I do have to agree that more than one fully functional old kernel is a bad idea. Though I don't have much trouble manually deleting the really old ones from Ubuntu's /boot dir...

what if we (optionally) stored the original images _inside_ the new one? the new/bad kernel would boot, and via some bootloader entry eg. kernel param the new initcpio script would kexec the old kernel, with another (different) kernel param ... when the old kernel booted it would load the exact same initramfs image, except it would use an alternate tree, ie. instead of /init it would chroot to /previous and run /previous/init ... you could store as many of these "old" images as you liked, but it would look like one -- i don't see any technical problems off-hand at least, and i *think* it would only require minor changes to mkinitcpio, and would be unobtrusive to other tools. does this sound genius or completely insane? some insanely genius guy once said they are only separated by a fine line ... C Anthony

C Anthony Risinger

12:38 a.m.

New subject: [arch-general] Reboot - Versioned Kernel Installs

On Thu, Jun 9, 2011 at 5:36 PM, C Anthony Risinger wrote:

...

2011/6/9 Joe(theWordy)Philbrook :

...
This is the kind of thing that caused me to become a ‘multi-Linux distribution’, ‘multi-boot’ kind of guy in the first place. When an upgrade «or my own dumb mistakes» break my system I like being able to simply reboot something else and finish anything I'm working on before I spend hours, or days, or even weeks just trying to figure out what broke...

It's not likely that anything other than a hardware failure will shut down Arch AND Ubuntu AND PCLinuxOS AND OpenSuSE all at the same time... And for that I still have a laptop...

But it would sure be nice to be able to keep using my favorite distro with a fallback kernel instead of having to boot one of the others. But I do have to agree that more than one fully functional old kernel is a bad idea. Though I don't have much trouble manually deleting the really old ones from Ubuntu's /boot dir...

what if we (optionally) stored the original images _inside_ the new one? the new/bad kernel would boot, and via some bootloader entry eg. kernel param the new initcpio script would kexec the old kernel, with another (different) kernel param ... when the old kernel booted it would load the exact same initramfs image, except it would use an alternate tree, ie. instead of /init it would chroot to /previous and run /previous/init ...

you could store as many of these "old" images as you liked, but it would look like one -- i don't see any technical problems off-hand at least, and i *think* it would only require minor changes to mkinitcpio, and would be unobtrusive to other tools.

does this sound genius or completely insane? some insanely genius guy once said they are only separated by a fine line ...

oops, forgot to mention one caveat -- if the new kernel was totally borked and didn't boot at *all* and couldnt even get to the initramfs, then it wouldn't work ... but i dont think thats ever happened to me and seems pretty rare. C Anthony

Heiko Baums

12:50 a.m.

New subject: [arch-general] Reboot - Versioned Kernel Installs

Am Thu, 9 Jun 2011 17:36:21 -0500 schrieb C Anthony Risinger :

...

does this sound genius or completely insane? some insanely genius guy once said they are only separated by a fine line ...

Sounds completely insane. Heiko

C Anthony Risinger

3:25 a.m.

New subject: [arch-general] Reboot - Versioned Kernel Installs

On Jun 9, 2011 5:50 PM, "Heiko Baums" wrote:

...

Am Thu, 9 Jun 2011 17:36:21 -0500 schrieb C Anthony Risinger :

...
does this sound genius or completely insane? some insanely genius guy once said they are only separated by a fine line ...

Sounds completely insane.

ooooook ... and ... why? ) initramfs is not very big (fallback on my sys is only 13MB + 2MB kern) ) keeps the whole thing in mkinitcpio ) does not affect any current images and is even backward compat ) small chance of absolute failure (i think :-) ) only small changes to mkinitcpio, if any at all ) ... ) ... KISS BABY! ) oh yeah and ... PROFIT! im pretty sure it could be implemented as a hook (possibly 2) to the current system ... this might even be the best way. `install` hook would unpack the current image to a known location (prob `/lib/initcpio` somewhere), copy the kernel to the same place, and then add the directory to the image (after removing the old-old image if existed :-). the real `hook` would then check for one of two flags: ) kexec.flag ... kexec the old kernel with the boot.flag ) boot.flag ... chroot to "previous", run old hooks/mods/etc, exit chroot, switch_root like normal i thought it was pretty succinct ... elegant even :-) ... with some sprinkles of insanity that give it the funny but mildly enjoyable aftertaste. i don't have any free time for a couple days, but i'm *pretty* sure this could be done as a hook to the current mkinitcpio in a couple hours -- might take a whack at it this weekend, would be useful, as i've personally mucked my boot more than once, and though i can recover easily enough, i'm liking this more and more ... ... though i could very well be missing something obvious, certainly wouldn't be the first time ... surely someone out there reads this and thinks "why not?" C Anthony

Timothy L.

4:22 a.m.

New subject: [arch-general] Reboot - Versioned Kernel Installs

On Thu, Jun 9, 2011 at 9:25 PM, C Anthony Risinger wrote:

...

On Jun 9, 2011 5:50 PM, "Heiko Baums" wrote:

...
Am Thu, 9 Jun 2011 17:36:21 -0500 schrieb C Anthony Risinger :

...
does this sound genius or completely insane? some insanely genius guy once said they are only separated by a fine line ...

Sounds completely insane.

ooooook ... and ... why?

) initramfs is not very big (fallback on my sys is only 13MB + 2MB kern) ) keeps the whole thing in mkinitcpio ) does not affect any current images and is even backward compat ) small chance of absolute failure (i think :-) ) only small changes to mkinitcpio, if any at all ) ... ) ... KISS BABY! ) oh yeah and ... PROFIT!

im pretty sure it could be implemented as a hook (possibly 2) to the current system ... this might even be the best way. `install` hook would unpack the current image to a known location (prob `/lib/initcpio` somewhere), copy the kernel to the same place, and then add the directory to the image (after removing the old-old image if existed :-). the real `hook` would then check for one of two flags:

) kexec.flag ... kexec the old kernel with the boot.flag ) boot.flag ... chroot to "previous", run old hooks/mods/etc, exit chroot, switch_root like normal

i thought it was pretty succinct ... elegant even :-) ... with some sprinkles of insanity that give it the funny but mildly enjoyable aftertaste. i don't have any free time for a couple days, but i'm *pretty* sure this could be done as a hook to the current mkinitcpio in a couple hours -- might take a whack at it this weekend, would be useful, as i've personally mucked my boot more than once, and though i can recover easily enough, i'm liking this more and more ...

... though i could very well be missing something obvious, certainly wouldn't be the first time ... surely someone out there reads this and thinks "why not?"

C Anthony

Keeping the previous kernel after upgrading sounds sane to me. For the apprehensive, couldn't we just include a simple configuration option/check somewhere? /etc/mkinitcpio.conf KEEP_PREVIOUS_KERNEL="yes" I've read most of this thread but please excuse me if this has already been mentioned.

Yaro Kasear

3:01 p.m.

New subject: [arch-general] Reboot - Versioned Kernel Installs

On Thursday, June 09, 2011 21:22:50 Timothy L. wrote:

...

On Thu, Jun 9, 2011 at 9:25 PM, C Anthony Risinger wrote:

...
On Jun 9, 2011 5:50 PM, "Heiko Baums" wrote:

...
Am Thu, 9 Jun 2011 17:36:21 -0500

schrieb C Anthony Risinger :

...
does this sound genius or completely insane? some insanely genius guy once said they are only separated by a fine line ...

Sounds completely insane.

ooooook ... and ... why?

) initramfs is not very big (fallback on my sys is only 13MB + 2MB kern) ) keeps the whole thing in mkinitcpio ) does not affect any current images and is even backward compat ) small chance of absolute failure (i think :-) ) only small changes to mkinitcpio, if any at all ) ... ) ... KISS BABY! ) oh yeah and ... PROFIT!

im pretty sure it could be implemented as a hook (possibly 2) to the current system ... this might even be the best way. `install` hook would unpack the current image to a known location (prob `/lib/initcpio` somewhere), copy the kernel to the same place, and then add the directory to the image (after removing the old-old image if existed :-). the real `hook` would then check for one of two flags:

) kexec.flag ... kexec the old kernel with the boot.flag ) boot.flag ... chroot to "previous", run old hooks/mods/etc, exit chroot, switch_root like normal

i thought it was pretty succinct ... elegant even :-) ... with some sprinkles of insanity that give it the funny but mildly enjoyable aftertaste. i don't have any free time for a couple days, but i'm *pretty* sure this could be done as a hook to the current mkinitcpio in a couple hours -- might take a whack at it this weekend, would be useful, as i've personally mucked my boot more than once, and though i can recover easily enough, i'm liking this more and more ...

... though i could very well be missing something obvious, certainly wouldn't be the first time ... surely someone out there reads this and thinks "why not?"

C Anthony

Keeping the previous kernel after upgrading sounds sane to me. For the apprehensive, couldn't we just include a simple configuration option/check somewhere?

/etc/mkinitcpio.conf KEEP_PREVIOUS_KERNEL="yes"

I've read most of this thread but please excuse me if this has already been mentioned.

I'd accept that solution just so long as the default is set to "no" and not "yes." Most Arch people don't want old kernels.

C Anthony Risinger

10:17 a.m.

New subject: [arch-general] Reboot - Versioned Kernel Installs

On Thu, Jun 9, 2011 at 8:25 PM, C Anthony Risinger wrote:

...

... though i could very well be missing something obvious, certainly wouldn't be the first time ...

... after 1/2 implementing this i suddenly realized a painful truth that's probably already been voiced ... the kernel is *long-since upgraded* by the time _any_ hooks run ... the original image is gone, the package is gone, all hope is gone, fml. the hook saves the images just fine because they are in the process of being created ... but the original kernel image ... not so much :-( i don't know how this can work without hooks into pacman, anything else i think of is too hacky ... even for me. sorry guys, i tried :-( i finished the `install` script and realized it soon after. my work follows for the benefit of children everywhere. C Anthony ---------------------------------------------------------------- # vim:set ft=sh: install () { SCRIPT="oldkernel" local src dst obase fdesc fmode fgid fuid fmaj fmin local okdir=".oldkernel-$(basename "${GENIMG%.img}")-${KERNELVERSION}" mkdir -p "${TMPDIR}/${okdir}" bsdtar -xf "${GENIMG}" -C "${TMPDIR}/${okdir}" --exclude /.oldkernel --strip-components 1 cp -a /boot/vmlinuz26 "${TMPDIR}/${okdir}" #FIXME: we should just keep the old file list around ... # hack BASEDIR to build links correctly obase="${BASEDIR}" BASEDIR="${TMPDIR}" while read -r src dst; do IFS=$'\t' read -r fdesc fmode fgid fuid fmaj fmin <<<"$(stat -c $'%F\t%a\t%g\t%u\t%t\t%T' "${src}")" case "${fdesc}" in 'regular file'|'symbolic link') add_file "${src}" "${dst}";; 'directory') add_dir "${dst}";; 'fifo') echo "pipe ${dst} ${fmode} ${fgid} ${fuid}" >> "${FILELIST}";; 'socket') echo "sock ${dst} ${fmode} ${fgid} ${fuid}" >> "${FILELIST}";; 'character special file') echo "nod ${dst} ${fmode} ${fgid} ${fuid} c ${fmaj} ${fmin}" >> "${FILELIST}";; 'block special file') echo "nod ${dst} ${fmode} ${fgid} ${fuid} b ${fmaj} ${fmin}" >> "${FILELIST}";; *) echo "UNKNOWN FILE: ${src}";; esac done < <(bsdtar -tf "${GENIMG}" --exclude /.oldkernel | sed "s,.*,${TMPDIR}/${okdir}\0 /${okdir}\0,g") add_file /boot/vmlinuz26 "/${okdir}/vmlinuz26" BASEDIR="${obase}" } help () { cat <

C Anthony Risinger

10:24 a.m.

New subject: [arch-general] Reboot - Versioned Kernel Installs

On Fri, Jun 10, 2011 at 3:17 AM, C Anthony Risinger wrote:

...

On Thu, Jun 9, 2011 at 8:25 PM, C Anthony Risinger wrote:

...
... though i could very well be missing something obvious, certainly wouldn't be the first time ...

... after 1/2 implementing this i suddenly realized a painful truth that's probably already been voiced ...

the kernel is *long-since upgraded* by the time _any_ hooks run ... the original image is gone, the package is gone, all hope is gone, fml. the hook saves the images just fine because they are in the process of being created ... but the original kernel image ... not so much :-(

... though with the help of the .install script as mentioned earlier, this could be remedied. what would be even better is if some kind of generic hook was added to the install points for the kernel only. not the same as full blown pacman hooks, but since kernel is a bit unique anyway i don't think it would hurt ... if the .install script sourced a known location, eg. /etc/pacman/kernel26.hook or something similar, then any of us would be free to implement backups however we wished. C Anthony

Robert Howard

11:26 a.m.

New subject: [arch-general] Reboot - Versioned Kernel Installs

Why not just copy the old kernel image, modules and initrd image somewhere by hand before you upgrade kernels. If we try to make this automated it isn't going to be kiss. I used to do this way back in the day by including the entire kernel version in the pkgver and giving the images longer names. It was possible to have concurrently installed kernels. Check out how some of the AUR kernels manage to be the same kernel version as the official without causing issues.

Yaro Kasear

3:03 p.m.

New subject: [arch-general] Reboot - Versioned Kernel Installs

On Friday, June 10, 2011 04:26:21 Robert Howard wrote:

...

Why not just copy the old kernel image, modules and initrd image somewhere by hand before you upgrade kernels. If we try to make this automated it isn't going to be kiss. I used to do this way back in the day by including the entire kernel version in the pkgver and giving the images longer names. It was possible to have concurrently installed kernels. Check out how some of the AUR kernels manage to be the same kernel version as the official without causing issues.

+1 on this. If you really need the old kernel, why not make sure you back up the old one and its image before upgrading instead of inconveniencing other users and the developers for a feature only a minority even wants?

Paul Gideon Dann

3:25 p.m.

New subject: [arch-general] Reboot - Versioned Kernel Installs

On Friday 10 June 2011 14:03:32 Yaro Kasear wrote:

...

On Friday, June 10, 2011 04:26:21 Robert Howard wrote:

...
Why not just copy the old kernel image, modules and initrd image somewhere by hand before you upgrade kernels. If we try to make this automated it isn't going to be kiss. I used to do this way back in the day by including the entire kernel version in the pkgver and giving the images longer names. It was possible to have concurrently installed kernels. Check out how some of the AUR kernels manage to be the same kernel version as the official without causing issues.

+1 on this. If you really need the old kernel, why not make sure you back up the old one and its image before upgrading instead of inconveniencing other users and the developers for a feature only a minority even wants?

Because it's painful to go through that every time a new kernel update comes along. Also, I think you're underestimating the interest in this. This list will typically contain the most advanced Arch users, who are confident rescuing their system from a bad kernel upgrade. I'm sure there are plenty of Arch users out there that aren't reading this list, but for whom this feature could save them a lot of time and effort. Just because most of *us* can probably fix this in our sleep, doesn't mean it's right for Arch users in general. Also, I wonder what happens if power is lost whilst pacman is installing a new kernel? I haven't tried this, but it wouldn't surprise me if the system ended up with a truncated kernel that wouldn't boot. That's a bug right there, although it's a pretty tiny corner case, granted :) Paul

Vic Demuzere

3:29 p.m.

New subject: [arch-general] Reboot - Versioned Kernel Installs

On 10 June 2011 15:25, Paul Gideon Dann wrote:

...

Also, I wonder what happens if power is lost whilst pacman is installing a new kernel? I haven't tried this, but it wouldn't surprise me if the system ended up with a truncated kernel that wouldn't boot. That's a bug right there, although it's a pretty tiny corner case, granted :)

Paul

Is that the case? The kernel should be replaced only after the new one is ready, else it would fail if you pushed CTRL+C while updating the kernel as well. Vic

Thomas Dziedzic

5:54 p.m.

New subject: [arch-general] Reboot - Versioned Kernel Installs

On Fri, Jun 10, 2011 at 8:29 AM, Vic Demuzere wrote:

...

On 10 June 2011 15:25, Paul Gideon Dann wrote:

...
Also, I wonder what happens if power is lost whilst pacman is installing a new kernel? I haven't tried this, but it wouldn't surprise me if the system ended up with a truncated kernel that wouldn't boot. That's a bug right there, although it's a pretty tiny corner case, granted :)

Paul

Is that the case? The kernel should be replaced only after the new one is ready, else it would fail if you pushed CTRL+C while updating the kernel as well.

Vic

paul, please check out https://bugs.archlinux.org/task/8585 for the power issue I really don't see how implementing this feature would give any more benefits to say installing an -lts kernel or some other kernel you know just works. On the other hand, I do see versioned kernels increasing the complexity of the system.

Joe(theWordy)Philbrook

11 Jun 11 Jun

3:06 a.m.

New subject: [arch-general] Reboot - Versioned Kernel Installs

It would appear that on Jun 10, Robert Howard did say:

...

Why not just copy the old kernel image, modules and initrd image somewhere by hand before you upgrade kernels. If we try to make this automated it isn't going to be kiss. I used to do this way back in the day by including the entire kernel version in the pkgver and giving the images longer names. It was possible to have concurrently installed kernels. Check out how some of the AUR kernels manage to be the same kernel version as the official without causing issues.

That wouldn't be such a bad idea. And in fact I already do that with the kernel and initrd image. But I'm almost ashamed to admit that I don't have enough understanding of the modules to know how to preserve and when needed restore them. And as was I think mentioned in this thread, without the modules, the gui wouldn't work... «I blame CRS {see below}» I've tried to learn stuff like that but the knowledge didn't stick. Is there a step by step how-to or wiki I could bookmark??? -- | ~^~ ~^~ | <?> <?> Joe (theWordy) Philbrook | ^ J(tWdy)P | \___/ <> * CRS : "Can't Remember Sh^Htuff" : In my case this means that unless I * do something the same way every day for a LONG time, or have examples * of how I did it before (where I can still find them), I usually wind up * scratching my head the next time I need to do a non-daily task. Or for * that matter, to remember what I was doing before the durned phone rang etc...

Heiko Baums

3:29 a.m.

New subject: [arch-general] Reboot - Versioned Kernel Installs

Am Fri, 10 Jun 2011 21:06:21 -0400 schrieb "Joe(theWordy)Philbrook" :

...

That wouldn't be such a bad idea. And in fact I already do that with the kernel and initrd image. But I'm almost ashamed to admit that I don't have enough understanding of the modules to know how to preserve and when needed restore them. And as was I think mentioned in this thread, without the modules, the gui wouldn't work...

You don't need the modules and the GUI to downgrade the kernel package if the updated kernel should be broken.

...

Is there a step by step how-to or wiki I could bookmark???

1. Boot the old kernel 2. Login on the text console 3. pacman -U /var/cache/pacman/pkg/kernel26-<lastworkingversion>-<arch>.pkg.tar.xz 4. reboot Old kernel and its modules are back. But before you do this, you should write down or copy the necessary error messages and details to file a bug report about the kernel issue. Heiko

Joe(theWordy)Philbrook

2:45 a.m.

New subject: [arch-general] Reboot - Versioned Kernel Installs

It would appear that on Jun 9, C Anthony Risinger did say:

...

On Jun 9, 2011 5:50 PM, "Heiko Baums" wrote:

...
Am Thu, 9 Jun 2011 17:36:21 -0500 schrieb C Anthony Risinger :

...
does this sound genius or completely insane? some insanely genius guy once said they are only separated by a fine line ...

Sounds completely insane.

ooooook ... and ... why?

-snipped. . . . . . . . . .stuff The only reason to even consider keeping an old kernel around with Arch was just in case the new kernel is effectively borked... (possibly due to a hardware incompatibility...) And if I remember right, you said something about this not working if the new kernel can't boot... -- | ~^~ ~^~ | <*> <*> Joe (theWordy) Philbrook | ^ J(tWdy)P | \___/ <>

Martti Kühne

10 Jun 10 Jun

12:42 p.m.

New subject: [arch-general] Reboot - Versioned Kernel Installs

On Fri, Jun 10, 2011 at 12:36 AM, C Anthony Risinger wrote: <snip>

...

what if we (optionally) stored the original images _inside_ the new one? the new/bad kernel would boot, and via some bootloader entry eg. kernel param the new initcpio script would kexec the old kernel, with another (different) kernel param ... when the old kernel booted it would load the exact same initramfs image, except it would use an alternate tree, ie. instead of /init it would chroot to /previous and run /previous/init ...

eh, for the priority of known sources of error: an UPDATE image could contain the NEW kernel in an alternate tree /new/init, because the OLD kernel is KNOWN to boot that far... Anything else would be insane.

Vic Demuzere

12:48 p.m.

New subject: [arch-general] Reboot - Versioned Kernel Installs

On Jun 10, 2011 12:43 PM, "Martti Kühne" wrote:

...

On Fri, Jun 10, 2011 at 12:36 AM, C Anthony Risinger

wrote:

...

<snip>

...
what if we (optionally) stored the original images _inside_ the new one? the new/bad kernel would boot, and via some bootloader entry eg. kernel param the new initcpio script would kexec the old kernel, with another (different) kernel param ... when the old kernel booted it would load the exact same initramfs image, except it would use an alternate tree, ie. instead of /init it would chroot to /previous and run /previous/init ...

eh, for the priority of known sources of error: an UPDATE image could contain the NEW kernel in an alternate tree /new/init, because the OLD kernel is KNOWN to boot that far...

Anything else would be insane.

Having multiple kernels is insane. I don't get why it's needed. There is a live cd to rescue your system if needed. Vic

Heiko Baums

1:14 p.m.

New subject: [arch-general] Reboot - Versioned Kernel Installs

Am Fri, 10 Jun 2011 12:48:57 +0200 schrieb Vic Demuzere :

...

Having multiple kernels is insane. I don't get why it's needed. There is a live cd to rescue your system if needed.

And the old kernel packages (every package) are saved in pacman's cache (usually /var/cache/pacman/pkg) anyway until pacman -Sc or pacman -Scc is run. So every package can easily be downgraded by running pacman -U /var/cache/pacman/pkg/<package-file-name>. Of course, the pacman cache should only be flushed if the updated software is working correctly. There's no need for keeping old kernel images, even less included in a new and updated kernel image or initrd, however this would be possible anyway. Maybe there could be made an option in /etc/pacman.conf for the kernel package (a hook isn't needed) which tells pacman if it shall first copy /boot/vmlinuz26 to /boot/vmlinuz26.old. But this should definitely not be done by default for every user. And it's really not necessary to backup all old modules for being able to boot an old kernel for fixing the new one (see pacman -U above). The better and much cleaner solution is to first try the fallback initrd or to install a different kernel package like kernel26-lts parallel to kernel26. Keep in mind, those cases in which an updated kernel is unbootable are very, very rare. And people who need a reliable system and are so afraid of broken kernels, of course, shouldn't use [testing]. They should better install a multiboot system with one stable system and one test system. This way they can test kernel updates from [testing] on their test system and update the kernel on their stable system only if the test system is working correctly. This would, btw., help to filing bug reports for the kernels on esoteric hardware before they get into [core]. Heiko

Joe(theWordy)Philbrook

11 Jun 11 Jun

3:21 a.m.

New subject: [arch-general] Reboot - Versioned Kernel Installs

It would appear that on Jun 10, Heiko Baums did say:

...

Am Fri, 10 Jun 2011 12:48:57 +0200 schrieb Vic Demuzere :

...
Having multiple kernels is insane. I don't get why it's needed. There is a live cd to rescue your system if needed.

And the old kernel packages (every package) are saved in pacman's cache (usually /var/cache/pacman/pkg) anyway until pacman -Sc or pacman -Scc is run. So every package can easily be downgraded by running pacman -U /var/cache/pacman/pkg/<package-file-name>.

Mind specifying for an idiot like me just which package-file-names I'd need to use with pacman -U to restore the previous kernel, complete with it's modules? -snipped. . . . . . . . . .stuff

...

The better and much cleaner solution is to first try the fallback initrd or to install a different kernel package like kernel26-lts parallel to kernel26.

Keep in mind, those cases in which an updated kernel is unbootable are very, very rare.

And people who need a reliable system and are so afraid of broken kernels, of course, shouldn't use [testing]. They should better install a multiboot system with one stable system and one test system. This way they can test kernel updates from [testing] on their test system and update the kernel on their stable system only if the test system is working correctly. This would, btw., help to filing bug reports for the kernels on esoteric hardware before they get into [core].

Now that, Heiko, is a good idea. And one that I could actually do. I'd just have to decide which of my other Linux distributions to sacrifice to make room for it... Keeping in mind that as you say: "those cases in which an updated kernel is unbootable are very, very rare." I think I'd rather learn how to use the "pacman -U" method... -- | ~^~ ~^~ | <*> <*> Joe (theWordy) Philbrook | ^ J(tWdy)P | \___/ <>

Heiko Baums

3:33 a.m.

New subject: [arch-general] Reboot - Versioned Kernel Installs

Am Fri, 10 Jun 2011 21:21:17 -0400 schrieb "Joe(theWordy)Philbrook" :

...

Mind specifying for an idiot like me just which package-file-names I'd need to use with pacman -U to restore the previous kernel, complete with it's modules?

Try `ls /var/cache/pacman/pkg/kernel26*` and I guess you will find it.

...

Now that, Heiko, is a good idea. And one that I could actually do. I'd just have to decide which of my other Linux distributions to sacrifice to make room for it... Keeping in mind that as you say: "those cases in which an updated kernel is unbootable are very, very rare." I think I'd rather learn how to use the "pacman -U" method...

Would at least be less work. Heiko

Joe(theWordy)Philbrook

6:40 p.m.

New subject: [arch-general] Reboot - Versioned Kernel Installs

It would appear that on Jun 11, Heiko Baums did say:

...

Am Fri, 10 Jun 2011 21:21:17 -0400 schrieb "Joe(theWordy)Philbrook" :

...
Mind specifying for an idiot like me just which package-file-names I'd need to use with pacman -U to restore the previous kernel, complete with it's modules?

Try `ls /var/cache/pacman/pkg/kernel26*` and I guess you will find it.

OK so lets see if I understand... I already maintain a manually configured grub legacy partition where each of my installed Linux have both a chainloader menu entry to whichever grub that Linux has installed to /boot on it's root partition, AND a regular menu entry that specified the initrd & vmlinuz that I routinely copy to MY grub partition shortly after any kernel upgrade... So in the event that the new kernel was effectively broken that on MY hardware neither the chainloaded Arch nor the arch fallback menu entries were able to boot, I could then boot the not yet replaced last known good kernel and initrd directly from MY grub and then from a console root prompt: «assuming that the following tar.xz file is still there» pacman -U /var/cache/pacman/pkg/kernel26-2.6.38.6-2-x86_64.pkg.tar.xz And when I next reboot using the chainloader to where arch has it's grub installed, and selected "Arch Linux" it should boot that kernel with it's initrd AND it's modules would be where it expects them with the result that it should be as fully functioning as it was before pacman upgraded from it??? -- | ~^~ ~^~ | <?> <?> Joe (theWordy) Philbrook | ^ J(tWdy)P | \___/ <>

Heiko Baums

8:13 p.m.

New subject: [arch-general] Reboot - Versioned Kernel Installs

Am Sat, 11 Jun 2011 12:40:36 -0400 schrieb "Joe(theWordy)Philbrook" :

...

OK so lets see if I understand... I already maintain a manually configured grub legacy partition where each of my installed Linux have both a chainloader menu entry to whichever grub that Linux has installed to /boot on it's root partition, AND a regular menu entry that specified the initrd & vmlinuz that I routinely copy to MY grub partition shortly after any kernel upgrade...

So in the event that the new kernel was effectively broken that on MY hardware neither the chainloaded Arch nor the arch fallback menu entries were able to boot, I could then boot the not yet replaced last known good kernel and initrd directly from MY grub and then from a console root prompt:

«assuming that the following tar.xz file is still there»

pacman -U /var/cache/pacman/pkg/kernel26-2.6.38.6-2-x86_64.pkg.tar.xz

And when I next reboot using the chainloader to where arch has it's grub installed, and selected "Arch Linux" it should boot that kernel with it's initrd AND it's modules would be where it expects them with the result that it should be as fully functioning as it was before pacman upgraded from it???

Principally, yes. But are you really sure that it is the updated kernel package and not your grub installation or config which causes your boot failures? Your description sounds pretty weird to me. Above all, what is a grub legacy partition and why do you need chainload in grub legacy for booting a Linux kernel? And are you sure that grub legacy is the right bootloader for your uefi mainboard? Heiko

Joe(theWordy)Philbrook

12 Jun 12 Jun

5:07 a.m.

New subject: [arch-general] Reboot - Versioned Kernel Installs

It would appear that on Jun 11, Heiko Baums did say:

...

Am Sat, 11 Jun 2011 12:40:36 -0400 schrieb "Joe(theWordy)Philbrook" :

...
OK so lets see if I understand... I already maintain a manually configured grub legacy partition where each of my installed Linux have both a chainloader menu entry to whichever grub that Linux has installed to /boot on it's root partition, AND a regular menu entry that specified the initrd & vmlinuz that I routinely copy to MY grub partition shortly after any kernel upgrade...

So in the event that the new kernel was effectively broken that on MY hardware neither the chainloaded Arch nor the arch fallback menu entries were able to boot, I could then boot the not yet replaced last known good kernel and initrd directly from MY grub and then from a console root prompt:

«assuming that the following tar.xz file is still there»

pacman -U /var/cache/pacman/pkg/kernel26-2.6.38.6-2-x86_64.pkg.tar.xz

And when I next reboot using the chainloader to where arch has it's grub installed, and selected "Arch Linux" it should boot that kernel with it's initrd AND it's modules would be where it expects them with the result that it should be as fully functioning as it was before pacman upgraded from it???

Principally, yes.

Thanks!

...

But are you really sure that it is the updated kernel package and not your grub installation or config which causes your boot failures?

Actually It's been a long time since I had actual boot failures with Arch... And if memory serves it wasn't the updated kernels fault, though I no longer remember what I'd done... However I have experienced other Linux that no longer booted properly upon kernel upgrades... When my grub installation fails to properly boot one of my Linux, I immediately use the chainloader entry to get that distro's own grub. Having a back-up in case a new kernel doesn't work for me just feels like the right thing to do. And now I know (and will have notes) how to resolve that problem in the event that an Arch kernel upgrade ever does fail me. Thanks again!

...

Your description sounds pretty weird to me. Above all, what is a grub legacy partition and why do you need chainload in grub legacy for booting a Linux kernel? And are you sure that grub legacy is the right bootloader for your uefi mainboard?

Well I call it grub legacy because that's what gnu.org is calling it now... http://www.gnu.org/software/grub/grub-legacy.en.html http://www.gnu.org/software/grub/manual/html_node/Changes-from-GRUB-Legacy.h... «Which incidentally is the kind of grub that Arch is using on my PC» According to them the old grub has been replaced with a new version. Though I don't see it as an improvement. I think the only Distro I've got installed that really likes "grub 2" is Ubuntu, But since I didn't let it use ext4, I can still even boot that with the classic grub. ☻ I guess you would either call it just a "grub partition" Or perhaps you would have said "boot partition" without specifying which boot loader is installed there. It is not that uncommon among multi-Linux-Distro, multi-booters to have a separate bootloader installed to the MBR from the ones each distro installed to their root partitions. Though the others I've heard about usually just select the appropriate chainloader entry for the Linux they want to boot, which in turn usually has a very short timeout before it automatically boots it's default entry. I myself rarely bother with the chainloader entries. They are mostly only there in case I goof when I edit the entries I normally boot from. This configuration also makes it easy to use a supergrub disc in the event that my normal boot partition gets corrupted as each installed Linux has it's own boot loader so all I'd need to tell supergrub is to boot the appropriate partition... -- | --- ___ | <0> <-> Joe (theWordy) Philbrook | ^ J(tWdy)P | ~\___/~ <>

Heiko Baums

6:37 a.m.

New subject: [arch-general] Reboot - Versioned Kernel Installs

Am Sat, 11 Jun 2011 23:07:00 -0400 schrieb "Joe(theWordy)Philbrook" :

...

Actually It's been a long time since I had actual boot failures with Arch... And if memory serves it wasn't the updated kernels fault, though I no longer remember what I'd done...

You see, those cases in which a kernel update leads to a boot failure are very rare. ;-) And Arch Linux kernels are usually tested in [testing] and are only moved to [core] if there are no bigger issues found.

...

However I have experienced other Linux that no longer booted properly upon kernel upgrades... When my grub installation fails to properly boot one of my Linux, I immediately use the chainloader entry to get that distro's own grub. Having a back-up in case a new kernel doesn't work for me just feels like the right thing to do. And now I know (and will have notes) how to resolve that problem in the event that an Arch kernel upgrade ever does fail me. Thanks again! ... Well I call it grub legacy because that's what gnu.org is calling it now...

That's what it's called.

...

According to them the old grub has been replaced with a new version. Though I don't see it as an improvement. I think the only Distro I've got installed that really likes "grub 2" is Ubuntu, But since I didn't let it use ext4, I can still even boot that with the classic grub. ☻

Which bootloader you need depends on your installation and hardware, not on the distro. There are at least 3 bootloaders (grub legacy, grub2 and syslinux) which have different capabilities and can't easily be replaced in any case. But all of them can handle ext4.

...

I guess you would either call it just a "grub partition" Or perhaps you would have said "boot partition" without specifying which boot loader is installed there.

I guess you meant the /boot partition. ;-)

...

It is not that uncommon among multi-Linux-Distro, multi-booters to have a separate bootloader installed to the MBR from the ones each distro installed to their root partitions. Though the others I've heard about usually just select the appropriate chainloader entry for the Linux they want to boot, which in turn usually has a very short timeout before it automatically boots it's default entry.

I myself rarely bother with the chainloader entries. They are mostly only there in case I goof when I edit the entries I normally boot from. This configuration also makes it easy to use a supergrub disc in the event that my normal boot partition gets corrupted as each installed Linux has it's own boot loader so all I'd need to tell supergrub is to boot the appropriate partition...

I would completely remove the chainloaders. Make one /boot parition for every distro, but only install one bootloader from your main distro into the MBR. Don't let the other distros install a bootloader and just configure the one bootloader to boot the other distros, too. That's the easiest way which should always work. Btw., if you let every distro install a bootloader into the MBR, the previously installed one will be overwritten. There won't be two different bootloaders in the MBR. Depending on what you are doing with your multi-boot system, you probably should consider using virtualization. Heiko

Joe(theWordy)Philbrook

8:24 p.m.

New subject: [arch-general] boot loaders and the /boot partition. [was: Reboot - Versioned Kernel Installs]

It would appear that on Jun 12, Heiko Baums did say:

...

Am Sat, 11 Jun 2011 23:07:00 -0400 schrieb "Joe(theWordy)Philbrook" :

...
Actually It's been a long time since I had actual boot failures with Arch... And if memory serves it wasn't the updated kernels fault, though I no longer remember what I'd done...

You see, those cases in which a kernel update leads to a boot failure are very rare. ;-)

I myself never doubted that. It's one of the reasons why it's currently my default boot choice. But as I've long been on a shoe string budget that does not allow me to be very selective with my hardware, I can't always be sure that my hardware won't be incompatible with some future change. Sometimes I manage to find a deal on used equipment. But I can rarely afford to be choosy. My current desktop was a gift from my brother in law who had just upgraded to something newer.

...

And Arch Linux kernels are usually tested in [testing] and are only moved to [core] if there are no bigger issues found.

And I think they do a pretty durned good job of it too...

...

...
Well I call it grub legacy because that's what gnu.org is calling it now...

That's what it's called.

...
According to them the old grub has been replaced with a new version. Though I don't see it as an improvement. I think the only Distro I've got installed that really likes "grub 2" is Ubuntu, But since I didn't let it use ext4, I can still even boot that with the classic grub. ☻

Which bootloader you need depends on your installation and hardware, not on the distro. There are at least 3 bootloaders (grub legacy, grub2 and syslinux) which have different capabilities and can't easily be replaced in any case. But all of them can handle ext4.

Hmmnnn... Ah yes I see now, there have been patches etc... since I last looked at it. I notice that the instructions to use the patched ubuntu grub to boot an ext4 system seems to require adding the kernel option: rootfstype=ext4 Would that be required with the grub installed to Arch as well? I also note that: https://ext4.wiki.kernel.org/index.php/Ext4_Howto Says something about a Google Summer of Code project (from opensuse) under the topic of "Booting from an ext4 filesystem" and that it also mentioned that "Ubuntu 9.04 and later includes a patch" So I'm thinking that I might which version of grub I use might make a difference...

...

...
I guess you would either call it just a "grub partition" Or perhaps you would have said "boot partition" without specifying which boot loader is installed there.

I guess you meant the /boot partition. ;-)

...
It is not that uncommon among multi-Linux-Distro, multi-booters to have a separate bootloader installed to the MBR from the ones each distro installed to their root partitions. Though the others I've heard about usually just select the appropriate chainloader entry for the Linux they want to boot, which in turn usually has a very short timeout before it automatically boots it's default entry.

I myself rarely bother with the chainloader entries. They are mostly only there in case I goof when I edit the entries I normally boot from. This configuration also makes it easy to use a supergrub disc in the event that my normal boot partition gets corrupted as each installed Linux has it's own boot loader so all I'd need to tell supergrub is to boot the appropriate partition...

I would completely remove the chainloaders.

Make one /boot parition for every distro, but only install one bootloader from your main distro into the MBR. Don't let the other distros install a bootloader and just configure the one bootloader to boot the other distros, too. That's the easiest way which should always work.

Yeah, if I wanted any distro to have control over the booting of the others. I let each distro maintain it's own (root partition based) grub installation so that I can simply (and easily) see what they think is the best way to boot their Linux. Sometimes they auto detect the other Linux. and sometimes the grub entries they add for the other Linux even work. But I like to keep control over the primary boot loader that I like to be able to chain load their boot loaders in case I want to confirm that some issue I'm having with one isn't a goof in my menu.lst configuration. Also,this way I don't need to bother maintaining fallback/recovery/nurse/etc... entries, If I need them I just use the ones their package manager installed to their chainloaded bootloader...

...

Btw., if you let every distro install a bootloader into the MBR, the previously installed one will be overwritten. There won't be two different bootloaders in the MBR.

It's been a long time since I had to set up my /boot partition. I'm not even sure which distro I used to do so. But basically I started with all the distro's using the /boot of their root partition, and all but one configured to install it to the first superblock of that partition. Then I tweaked the one I let install to the mbr until I was happy with how it worked for all the distros... Then I mounted the intended /boot partition on /mnt. Next I did: "cd /mnt" then a: "ln -s . boot, and copied everything from /boot to /mnt, edited the /mnt/grub/menu.lst so that where there were lines that said things like: root (hd0,6) it now said: root (hd0,1) next I unmounted the intended /boot from /mnt and mounted it on top of /boot and reinstalled grub to the MBR. after which I unmounted it which exposed the original contents of /boot, and reinstalled that one to the superblock. From them on I had a seemingly stand alone /boot partition that none of my Linux mess with even when there is a kernel upgrade, And all of my Linux have their own functional bootloader installed to their superblocks... I'm not sure, But I think that I might have to redo this if I should ever uninstall whichever Distro it was I used to do this. But other than that it seams to work great...

...

Depending on what you are doing with your multi-boot system, you probably should consider using virtualization.

Then what happens if I hose the system hosting the others??? My, time flies... Gotta go. SeeYa -- | ~^~ ~^~ | <*> <*> Joe (theWordy) Philbrook | ^ J(tWdy)P | \___/ <>

Yaro Kasear

10 Jun 10 Jun

3:05 p.m.

New subject: [arch-general] Reboot - Versioned Kernel Installs

On Friday, June 10, 2011 05:48:57 Vic Demuzere wrote:

...

On Jun 10, 2011 12:43 PM, "Martti Kühne" wrote:

...
On Fri, Jun 10, 2011 at 12:36 AM, C Anthony Risinger

wrote:

...
<snip>

...
what if we (optionally) stored the original images _inside_ the new one? the new/bad kernel would boot, and via some bootloader entry eg. kernel param the new initcpio script would kexec the old kernel, with another (different) kernel param ... when the old kernel booted it would load the exact same initramfs image, except it would use an alternate tree, ie. instead of /init it would chroot to /previous and run /previous/init ...

eh, for the priority of known sources of error: an UPDATE image could contain the NEW kernel in an alternate tree /new/init, because the OLD kernel is KNOWN to boot that far...

Anything else would be insane.

Having multiple kernels is insane. I don't get why it's needed. There is a live cd to rescue your system if needed.

Vic

Another agreement from me here. Also, may I also add that a great deal of Arch users have /boot in a (tiny) partition to start with and can't really KEEP that much stuff in there? Keeping old kernels would definitely screw their systems up and keep them from upgrading with any ease.

Paul Gideon Dann

3:18 p.m.

New subject: [arch-general] Reboot - Versioned Kernel Installs

On Friday 10 June 2011 14:05:14 Yaro Kasear wrote:

...

Another agreement from me here. Also, may I also add that a great deal of Arch users have /boot in a (tiny) partition to start with and can't really KEEP that much stuff in there? Keeping old kernels would definitely screw their systems up and keep them from upgrading with any ease.

I have two kernels in /boot at the moment, and that takes 32MiB. My /boot partition is 200MiB, which is pretty generous as far as separate /boots go. That gives me room for 12 kernels. I'm not sure many would have a /boot smaller than 100MiB, and can't see *anyone* partitioning a /boot to less than 32MiB. I don't think space is a concern when we're talking about 2-3 kernels (current, previous, and possibly a custom build.) Paul

C Anthony Risinger

6:05 p.m.

New subject: [arch-general] Reboot - Versioned Kernel Installs

On Fri, Jun 10, 2011 at 5:42 AM, Martti Kühne wrote:

...

On Fri, Jun 10, 2011 at 12:36 AM, C Anthony Risinger wrote: <snip>

...
what if we (optionally) stored the original images _inside_ the new one? the new/bad kernel would boot, and via some bootloader entry eg. kernel param the new initcpio script would kexec the old kernel, with another (different) kernel param ... when the old kernel booted it would load the exact same initramfs image, except it would use an alternate tree, ie. instead of /init it would chroot to /previous and run /previous/init ...

eh, for the priority of known sources of error: an UPDATE image could contain the NEW kernel in an alternate tree /new/init, because the OLD kernel is KNOWN to boot that far...

yeah but when i update then kernel, i expect it to be updated ... not boot the old one next time i restart. i'm pretty sure you'd get all sorts of confusion over that. ... and the machine probably wouldn't work anyway because the module tree would be incorrect, though the ones in the initramfs would still be ok. since it's not really practical to actually boot the previous kernel (unless your using some kind of _system_ recovery mechanism like *cough* btrfs rollback), we're really just talking about a small recovery environment. lts kernel kind of works for this, but the last known good kernel is better ... i still think the best solution is to just drop some externalized hooks into the .install file for kernel package and let to community run with it. this eliminated developer burden/responsibility and allows flexibility for different implementations and different needs. maybe if we like some they can be added to standard repos in time. for example, a couple months back i was working on trying to get kernel rollbacks working with the mkinicpio-btrfs hook ... i needed a two-stage boot via kexec because the real kernel was inside a btrfs subvolume -- which bootloaders cannot yet access -- and it needed to be rebuilt with the real kernel. a simple drop in hook for this would have made things much much easier. so i say forget about versioned kernels and all that jazz because that's just one possible use. create something like: /etc/pacman/hooks.d/kernel26/<hookname> ... where kernel26 matches the package name. i haven't looked at the proposition for pacman hooks but this seems like it could serve as a small pilot to a more generic mechanism. ultimately this thread is not about "versioned kernels" but rather providing a way to link into the system management procedures performed by pacman, and do custom stuff. C Anthony

Mauro Santos

9:44 p.m.

New subject: [arch-general] Reboot - Versioned Kernel Installs

Arch users have lived without the last good known kernel so far and without an -lts kernel until recently. IMHO it is a lot more advisable to have an install cd/usb, or even better, a custom install in some external media that can be used to boot the system in case something goes wrong or in case of emergency. Then you can just chroot into the broken install and fix the problem or tell pacman where the root and cache are located and fix things. -- Mauro Santos

Paul Gideon Dann

12 Jun 12 Jun

12:41 a.m.

New subject: [arch-general] Reboot - Versioned Kernel Installs

On Friday 10 June 2011 20:44:16 Mauro Santos wrote:

...

Arch users have lived without the last good known kernel so far and without an -lts kernel until recently. IMHO it is a lot more advisable to have an install cd/usb, or even better, a custom install in some external media that can be used to boot the system in case something goes wrong or in case of emergency. Then you can just chroot into the broken install and fix the problem or tell pacman where the root and cache are located and fix things.

To me, that just doesn't sound like a sensible rescue plan for a modern OS. I like tinkering and learning, but being forced to boot a CD, load dm-mod, bring up my LVM volumes, mount the root, bind proc, sys, and dev, chroot, and finally get pacman to install the last kernel? That's something I'd like to avoid unless I'm doing it for fun :) Paul

4725

Age (days ago)

4729

Last active (days ago)

List overview

Download

41 comments

14 participants

participants (14)

C Anthony Risinger
Heiko Baums
Jelle van der Waa
Joe(theWordy)Philbrook
Martti Kühne
Mauro Santos
Oon-Ee Ng
Paul Gideon Dann
Robert Howard
Thomas Dziedzic
Timothy L.
Tom Gundersen
Vic Demuzere
Yaro Kasear