Reboot - Versioned Kernel Installs

[KESHAV P.R.]

Hi all,
Since the next kernel will be 3.0 , the kernel26 naming is
meaningless from the next kernel. I think this is also a good time to
consider implementing versioned kernel install. Agreed arch has a
policy of 1 package per software in the official repos. While this
attitude is acceptable for Xorg or windows managers or even some low
level utilities, problems with those can be corrected if the system
can boot to a shell atleast (init 1 or 3). But if the kernel fails to
boot and under the assumption that the user hdoes not have any rescue
system/distro handy he/she cannot boot into the system (atleast not at
that moment). Without a working kernel it is not possible to boot to a
shell to run any damn command.
While this topic has already been discussed at [1] the
discussion was slow and has not lead to any fruitful result. This post
is mainly to reach out to a larger audience and decide on how to go
about since the upsteam version change provides the right time for
Arch to reconsider the same. Another discussion at [2] is about
removing the word kernel from the initramfs image. If in case
versioned kernel proposal is accepted then the initramfs also
(automatically) becomes versioned to match the kernel. Atleast Dave
Reisner (falconindy) took the first step by making the change in his
geninit program. I understand this might require changes in the way
mkinitcpio (or geninit if at all it becomes default) and the way
pacman handles different versions of same packages. Please join in.

[1] https://bugs.archlinux.org/task/16702
[2] https://bugs.archlinux.org/task/18719

Regards.

keshav

[Tavian Barnes]

Post by KESHAV P.R.
Hi all,
        Since the next kernel will be 3.0 , the kernel26 naming is
meaningless from the next kernel. I think this is also a good time to
consider implementing versioned kernel install. Agreed arch has a
policy of 1 package per software in the official repos. While this
attitude is acceptable for Xorg or windows managers or even some low
level utilities, problems with those can be corrected if the system
can boot to a shell atleast (init 1 or 3). But if the kernel fails to
boot and under the assumption that the user hdoes not have any rescue
system/distro handy he/she cannot boot into the system (atleast not at
that moment). Without a working kernel it is not possible to boot to a
shell to run any damn command.
       While this topic has already been discussed at [1] the
discussion was slow and has not lead to any fruitful result. This post
is mainly to reach out to a larger audience and decide on how to go
about since the upsteam version change provides the right time for
Arch to reconsider the same. Another discussion at [2] is about
removing the word kernel from the initramfs image. If in case
versioned kernel proposal is accepted then the initramfs also
(automatically) becomes versioned to match the kernel. Atleast Dave
Reisner (falconindy) took the first step by making the change in his
geninit program. I understand this might require changes in the way
mkinitcpio (or geninit if at all it becomes default) and the way
pacman handles different versions of same packages. Please join in.
[1] https://bugs.archlinux.org/task/16702
[2] https://bugs.archlinux.org/task/18719
Regards.
keshav

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.

While we're at it, +1 for calling the kernel package "linux" for version 3.0.

[Thomas Dziedzic]

On Mon, Jun 6, 2011 at 11:22 AM, Tavian Barnes

Post by Tavian Barnes

Post by KESHAV P.R.
Hi all,
        Since the next kernel will be 3.0 , the kernel26 naming is
meaningless from the next kernel. I think this is also a good time to
consider implementing versioned kernel install. Agreed arch has a
policy of 1 package per software in the official repos. While this
attitude is acceptable for Xorg or windows managers or even some low
level utilities, problems with those can be corrected if the system
can boot to a shell atleast (init 1 or 3). But if the kernel fails to
boot and under the assumption that the user hdoes not have any rescue
system/distro handy he/she cannot boot into the system (atleast not at
that moment). Without a working kernel it is not possible to boot to a
shell to run any damn command.
       While this topic has already been discussed at [1] the
discussion was slow and has not lead to any fruitful result. This post
is mainly to reach out to a larger audience and decide on how to go
about since the upsteam version change provides the right time for
Arch to reconsider the same. Another discussion at [2] is about
removing the word kernel from the initramfs image. If in case
versioned kernel proposal is accepted then the initramfs also
(automatically) becomes versioned to match the kernel. Atleast Dave
Reisner (falconindy) took the first step by making the change in his
geninit program. I understand this might require changes in the way
mkinitcpio (or geninit if at all it becomes default) and the way
pacman handles different versions of same packages. Please join in.
[1] https://bugs.archlinux.org/task/16702
[2] https://bugs.archlinux.org/task/18719
Regards.
keshav

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.
While we're at it, +1 for calling the kernel package "linux" for version 3.0.
--
Tavian Barnes

Agreed with Tavian Barnes.
Also, don't call it "linux30" just call it "linux"

[Yaro Kasear]

Post by Thomas Dziedzic
On Mon, Jun 6, 2011 at 11:22 AM, Tavian Barnes

Post by Tavian Barnes

Post by KESHAV P.R.
Hi all,
Since the next kernel will be 3.0 , the kernel26 naming is
meaningless from the next kernel. I think this is also a good time to
consider implementing versioned kernel install. Agreed arch has a
policy of 1 package per software in the official repos. While this
attitude is acceptable for Xorg or windows managers or even some low
level utilities, problems with those can be corrected if the system
can boot to a shell atleast (init 1 or 3). But if the kernel fails to
boot and under the assumption that the user hdoes not have any rescue
system/distro handy he/she cannot boot into the system (atleast not at
that moment). Without a working kernel it is not possible to boot to a
shell to run any damn command.
While this topic has already been discussed at [1] the
discussion was slow and has not lead to any fruitful result. This post
is mainly to reach out to a larger audience and decide on how to go
about since the upsteam version change provides the right time for
Arch to reconsider the same. Another discussion at [2] is about
removing the word kernel from the initramfs image. If in case
versioned kernel proposal is accepted then the initramfs also
(automatically) becomes versioned to match the kernel. Atleast Dave
Reisner (falconindy) took the first step by making the change in his
geninit program. I understand this might require changes in the way
mkinitcpio (or geninit if at all it becomes default) and the way
pacman handles different versions of same packages. Please join in.
[1] https://bugs.archlinux.org/task/16702
[2] https://bugs.archlinux.org/task/18719
Regards.
keshav

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.
While we're at it, +1 for calling the kernel package "linux" for version 3.0.
--
Tavian Barnes

Agreed with Tavian Barnes.
Also, don't call it "linux30" just call it "linux"

Or just 'kernel.'

And yes, -1 on multiple kernels. That was one of the more idiotic brain-
damaged practices of Ubuntu that drove me away in the first place.

[Jelle van der Waa]

Post by Yaro Kasear

Post by Thomas Dziedzic
On Mon, Jun 6, 2011 at 11:22 AM, Tavian Barnes

Post by Tavian Barnes

Post by KESHAV P.R.
Hi all,
Since the next kernel will be 3.0 , the kernel26 naming is
meaningless from the next kernel. I think this is also a good time to
consider implementing versioned kernel install. Agreed arch has a
policy of 1 package per software in the official repos. While this
attitude is acceptable for Xorg or windows managers or even some low
level utilities, problems with those can be corrected if the system
can boot to a shell atleast (init 1 or 3). But if the kernel fails to
boot and under the assumption that the user hdoes not have any rescue
system/distro handy he/she cannot boot into the system (atleast not at
that moment). Without a working kernel it is not possible to boot to a
shell to run any damn command.
While this topic has already been discussed at [1] the
discussion was slow and has not lead to any fruitful result. This post
is mainly to reach out to a larger audience and decide on how to go
about since the upsteam version change provides the right time for
Arch to reconsider the same. Another discussion at [2] is about
removing the word kernel from the initramfs image. If in case
versioned kernel proposal is accepted then the initramfs also
(automatically) becomes versioned to match the kernel. Atleast Dave
Reisner (falconindy) took the first step by making the change in his
geninit program. I understand this might require changes in the way
mkinitcpio (or geninit if at all it becomes default) and the way
pacman handles different versions of same packages. Please join in.
[1] https://bugs.archlinux.org/task/16702
[2] https://bugs.archlinux.org/task/18719
Regards.
keshav

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.
While we're at it, +1 for calling the kernel package "linux" for version 3.0.
--
Tavian Barnes

Agreed with Tavian Barnes.
Also, don't call it "linux30" just call it "linux"

Or just 'kernel.'
And yes, -1 on multiple kernels. That was one of the more idiotic brain-
damaged practices of Ubuntu that drove me away in the first place.

I don't see how kernel naming is on topic with this discussion, anyway i
wouldn't see like to see a preserved kernel on archlinux we already have
kernel26-lts and the fallback image.
Keeping more kernels would cost a) more time, b) more bugs on the
tracker and wouldn't in my point of view be the vision of rolling release.
You can always revert back a kernel version via pacman -U or chrooting
into your install.

[Tom Gundersen]

Post by Tavian Barnes
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

[Mauro Santos]

I'd say it would be better to have only one current and one lts kernel
(or whatever it ends up being called).

Having multiple older versions of the same package is not what it said
in the can, arch uses the latest stable versions of packages and not the
latest plus some number of older ones.

[Paul Gideon Dann]

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

Post by Tom Gundersen

Post by Tavian Barnes
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]

Post by Paul Gideon Dann
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!

Post by Paul Gideon Dann

Post by Tom Gundersen

Post by Tavian Barnes
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

[Tom Gundersen]

Post by Paul Gideon Dann
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-***@archlinux.org.

-t

[Paul Gideon Dann]

Post by Tom Gundersen

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

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]

Post by Paul Gideon Dann

Post by Tom Gundersen

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

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]

Post by Tom Gundersen

Post by Paul Gideon Dann

Post by Tom Gundersen

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

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]

Am Thu, 9 Jun 2011 06:36:08 +0800

Post by 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]

Post by Heiko Baums

Post by 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.

Post by Heiko Baums
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.

Post by Heiko Baums
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?

Post by Heiko Baums
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.

Post by Heiko Baums
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]

Post by Paul Gideon Dann

Post by Heiko Baums

Post by 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.

Post by Paul Gideon Dann

Post by Heiko Baums
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.

Post by Paul Gideon Dann

Post by Heiko Baums
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.

Post by Paul Gideon Dann

Post by Heiko Baums
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.

Post by Paul Gideon Dann

Post by Heiko Baums
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]

Post by Yaro Kasear

Post by Paul Gideon Dann
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).

Post by Yaro Kasear
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]

Post by Yaro Kasear

Post by Paul Gideon Dann

Post by Heiko Baums

Post by 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.

Post by Paul Gideon Dann

Post by Heiko Baums
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...

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

Post by Paul Gideon Dann

Post by Heiko Baums
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.

Post by Paul Gideon Dann

Post by Heiko Baums
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.

Post by Paul Gideon Dann

Post by Heiko Baums
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>- - - - - - - - - -

Post by Yaro Kasear

Post by Paul Gideon Dann

Post by Heiko Baums
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"...

Post by Yaro Kasear
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).

Post by Paul Gideon Dann
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...

[C Anthony Risinger]

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]

Post by C Anthony Risinger

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]

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

Post by 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]

Post by Heiko Baums
Am Thu, 9 Jun 2011 17:36:21 -0500

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.]

Post by C Anthony Risinger

Post by Heiko Baums
Am Thu, 9 Jun 2011 17:36:21 -0500

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
) 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]

Post by Timothy L.

Post by C Anthony Risinger

Post by Heiko Baums
Am Thu, 9 Jun 2011 17:36:21 -0500

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
) 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]

Post by C Anthony Risinger
... 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 <<HELPEOF
Kernel RECOVERY
HELPEOF

}

[C Anthony Risinger]

Post by C Anthony Risinger

Post by C Anthony Risinger
... 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]

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]

Post by Robert Howard
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]

Post by Yaro Kasear

Post by Robert Howard
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]

Post by Paul Gideon Dann
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]

Post by Vic Demuzere

Post by Paul Gideon Dann
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]

Post by Robert Howard
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
| \___/ <<***@ttlc.net>>



* 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]

Am Fri, 10 Jun 2011 21:06:21 -0400

Post by 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.

Post by Joe(theWordy)Philbrook
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]

Post by C Anthony Risinger

Post by Heiko Baums
Am Thu, 9 Jun 2011 17:36:21 -0500

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...

[Martti Kühne]

On Fri, Jun 10, 2011 at 12:36 AM, C Anthony Risinger <***@xtfx.me> wrote:
<snip>

Post by C Anthony Risinger
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]

Post by Martti Kühne
<snip>

Post by C Anthony Risinger
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]

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

Post by 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]

Post by Heiko Baums
Am Fri, 10 Jun 2011 12:48:57 +0200

Post by 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

Post by Heiko Baums
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...

[Heiko Baums]

Am Fri, 10 Jun 2011 21:21:17 -0400

Post by 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.

Post by Joe(theWordy)Philbrook
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
"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]

Post by Heiko Baums
Am Fri, 10 Jun 2011 21:21:17 -0400

Post by 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???

[Heiko Baums]

Am Sat, 11 Jun 2011 12:40:36 -0400

Post by 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
«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]

Post by Heiko Baums
Am Sat, 11 Jun 2011 12:40:36 -0400

Post by 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
«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!

Post by Heiko Baums
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!

Post by Heiko Baums
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.html

«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...

[Heiko Baums]

Am Sat, 11 Jun 2011 23:07:00 -0400

Post by 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.

Post by Joe(theWordy)Philbrook
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.

Post by Joe(theWordy)Philbrook
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.

Post by Joe(theWordy)Philbrook
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. ;-)

Post by Joe(theWordy)Philbrook
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]

Post by Heiko Baums
Am Sat, 11 Jun 2011 23:07:00 -0400

Post by 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.

Post by Heiko Baums
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...

Post by Heiko Baums

Post by Joe(theWordy)Philbrook
Well I call it grub legacy because that's what gnu.org is calling it now...

That's what it's called.

Post by Joe(theWordy)Philbrook
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...

Post by Heiko Baums

Post by Joe(theWordy)Philbrook
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. ;-)

Post by Joe(theWordy)Philbrook
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...

Post by Heiko Baums
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...

Post by Heiko Baums
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

[Yaro Kasear]

Post by Vic Demuzere

Post by Martti Kühne
<snip>

Post by C Anthony Risinger
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]

Post by Yaro Kasear
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]

Post by Martti Kühne
<snip>

Post by C Anthony Risinger
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]

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.

[Paul Gideon Dann]

Post by Mauro Santos
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