why is there only one kernel by default?

hypermegachi · 2006-04-25 18:58:05

i just noticed this when trying out ubuntu. every time you upgrade or install a new kernel, they create a completely new initrd image, config file, and kernel image, and store them in /boot. so...in the event that a new kernel screws up, you can always roll back to an older kernel.

why doesn't arch do something like this?

mpie · 2006-04-25 19:29:40

as kernel26 pkgs are stable, any potential errors would be warned of at install

hypermegachi · 2006-04-26 02:06:46

mpie wrote:

as kernel26 pkgs are stable, any potential errors would be warned of at install

some messages may be displayed, but the kernel will still be updated regardless. if you happened to wait a long time to -Syu you might not even see the kernel warning mesage when it's upgrading the package (speakin of which, is there a log file that contains these messages?)

McQueen · 2006-04-26 02:08:07

mpie wrote:

as kernel26 pkgs are stable, any potential errors would be warned of at install

An "error" (this is a little vague) would not be the only thing to protect against when installing a new kernel. There is also the potential threat that configuration changes or the introduction of new features might cause issues with either local hardware, or required daemons and modules. How stable a particular kernel is may not take into account these type of events.

viniosity · 2006-04-26 03:36:20

Bah, I've made my share of mistakes after a kernel upgrade (not getting the correct ipw2200 firmware for instance) and it sucks to have to recover manually. If nothing else, having at least one backup (recovery) kernel would be nice.

AndyRTR · 2006-04-26 06:25:45

We are arch! So you should know how to do it yourself if you really want it.

And there are other kernel packages in the repo: kernel24, kernel26beyond, mm, archck.... Not enough for a rescue? Arch iso cd is good for rescue too ;-)

McQueen · 2006-04-26 13:16:56

hypermegachi, there are a variety of methods to rescue your system or install different kernels via pacman. However, to get back to your original question, what you are talking about is a feature that is not currently implemented, and while this could be due to a variety of reasons, it probably has a lot to do with the philosophy of Arch, which is that the user should be afforded with a greater role in managing their system than with some other distros.

You can always make a feature request at flyspray.

Moo-Crumpus · 2006-04-26 13:31:10

McQueen, I can't follow your arguments. If managing your own system had such a weight, then udev and hotplug, initrd and one kernel for all, hardwaredetection and hwd would break the rule, wouldn't it.

I'ld file a feature request, so a kernel update would keep the older kernel as a fallback in case of errors.

Bison · 2006-04-26 14:20:56

It isn't hard to rename your kernel before updating. As for the Ubuntu feature, i found that really annoying.

myst · 2006-04-26 15:56:21

Moo-Crumpus wrote:

McQueen, I can't follow your arguments. If managing your own system had such a weight, then udev and hotplug, initrd and one kernel for all, hardwaredetection and hwd would break the rule, wouldn't it.
I'ld file a feature request, so a kernel update would keep the older kernel as a fallback in case of errors.

Hmm... how to upgrade package then? Should the new kernel always installed as new package? If not, how to keep track of all that trash that will be after several kernel updates?

hypermegachi · 2006-04-26 17:13:30

i realize that arch is a more "do it yourself" kinda distro, but i don't think it should even be necessary to "whip out that live CD" to save your computer after an unexpected problem from upgrading the kernel.

i know there are probably a lot of users here who add kernel26 to the IgnorePkg list, for fear of breaking the system. of course, if each kernel upgrade is its own package, they could try out the new kernel pretty much without worry of screwing things up.

also, with symlinks it's pretty easy to default the grub entry to the latest version. if for some reason the new kernel doesn't work, you can still use grub and manually edit the boot entry prior to booting.

hypermegachi · 2006-04-26 17:15:06

myst wrote:

Hmm... how to upgrade package then? Should the new kernel always installed as new package? If not, how to keep track of all that trash that will be after several kernel updates?

pacman?

iBertus · 2006-04-26 17:37:17

A simple solution to this problem would be to add a postfix to the kernel names, initrd, etc to make sure that no files conflicted. This could be done from within the PKGBUILD. Give the package a custom name and it should work just fine.

Moo-Crumpus · 2006-04-26 17:54:03

Would we really need a custom package name? Couldn't we just move kernel26, System.map26 etc. to kernel26_previous, System.map26_previous etc in pre-install? Users could add a menu entry in grub / lilo and would just be able to boot the latest and the last kernel. This is what I did manually (before I had initrd and so on).

hypermegachi · 2006-04-26 20:07:05

Moo-Crumpus wrote:

Would we really need a custom package name? Couldn't we just move kernel26, System.map26 etc. to kernel26_previous, System.map26_previous etc in pre-install? Users could add a menu entry in grub / lilo and would just be able to boot the latest and the last kernel. This is what I did manually (before I had initrd and so on).

i think if a fallback kernel would be implemented, this suggestion would be easiest and painless to do. you could even make a new directory under /boot/oldkernels or something, and the user can just rmdir that whenever they want. it won't clutter /boot at all.

vidal · 2006-04-26 22:01:49

What will you do if upgrading some other package renders your system unbootable?

phrakture · 2006-04-26 22:25:04

Moo-Crumpus wrote:

McQueen, I can't follow your arguments. If managing your own system had such a weight, then udev and hotplug, initrd and one kernel for all, hardwaredetection and hwd would break the rule, wouldn't it.

That's untrue. Doing something automatically does not imply that it removes control from a user. If it did, then there would be no rc.d scripts, you would have to put everything in rc.local. Hardware detection is the same - you have the option of not using it.

There is not a single app you can name that does not do something automatically. How would you like it if firefox failed on first start with "no profile directory, please create it first" or if your IDE controller modules failed saying "hey, I found some drives, but you didn't specify names for them when loading me - too bad, failing....".

phrakture · 2006-04-26 22:31:09

The most important point to note here is that no one _reads_.

There is alot of information spit off by the kernel install, just so you don't run into problems like this. But everyone ignores it. I have an idea.... _read it_

In this very thread someone even stated "oh sometimes you miss install messages" - that's not my fault or anyone elses. It is yours and yours alone for not reading.

Do you really want Arch packages to start taking care of the people who don't "RTFM" ?

hypermegachi · 2006-04-26 23:09:55

what happens when it scrolls so fast you can't read it? if you're on a 320x240 terminal or something outside of X, you won't have an option of scrolling back to read those messages.

speaking of which, why doesn't pacman.log have messages from package upgrades? do those messages even get logged?

T-Dawg · 2006-04-27 00:33:44

hypermegachi wrote:

what happens when it scrolls so fast you can't read it? if you're on a 320x240 terminal or something outside of X, you won't have an option of scrolling back to read those messages.

try SHIFT + page up

hypermegachi · 2006-04-27 00:50:05

Penguin wrote:

hypermegachi wrote:
what happens when it scrolls so fast you can't read it? if you're on a 320x240 terminal or something outside of X, you won't have an option of scrolling back to read those messages.
try SHIFT + page up

very cool! thanks for the tip!

iphitus · 2006-04-27 08:39:58

or /var/log/pacman.log

tomk · 2006-04-27 08:42:05

The log does not record post-install messages.

Snarkout · 2006-04-27 13:31:03

How about looking at this from the other way around? Bang together a script that moves kernel26 to kernel26-safe, and run it once you're satisfied a new kernel isn't going to eat your brain. Have a grub entry that boots this kernel by default rather than arch's new kernel.

sebcactus · 2006-04-27 13:57:25

If you are afraid of kernel update, you can add in /etc/pacman.conf

NoUpgrade=/boot/vmlinuz26

So that it will create a /boot/vmlinuz26.pacnew next time you update your kernel

Arch Linux

#1 2006-04-25 18:58:05

why is there only one kernel by default?

#2 2006-04-25 19:29:40

Re: why is there only one kernel by default?

#3 2006-04-26 02:06:46

Re: why is there only one kernel by default?

#4 2006-04-26 02:08:07

Re: why is there only one kernel by default?

#5 2006-04-26 03:36:20

Re: why is there only one kernel by default?

#6 2006-04-26 06:25:45

Re: why is there only one kernel by default?

#7 2006-04-26 13:16:56

Re: why is there only one kernel by default?

#8 2006-04-26 13:31:10

Re: why is there only one kernel by default?

#9 2006-04-26 14:20:56

Re: why is there only one kernel by default?

#10 2006-04-26 15:56:21

Re: why is there only one kernel by default?

#11 2006-04-26 17:13:30

Re: why is there only one kernel by default?

#12 2006-04-26 17:15:06

Re: why is there only one kernel by default?

#13 2006-04-26 17:37:17

Re: why is there only one kernel by default?

#14 2006-04-26 17:54:03

Re: why is there only one kernel by default?

#15 2006-04-26 20:07:05

Re: why is there only one kernel by default?

#16 2006-04-26 22:01:49

Re: why is there only one kernel by default?

#17 2006-04-26 22:25:04

Re: why is there only one kernel by default?

#18 2006-04-26 22:31:09

Re: why is there only one kernel by default?

#19 2006-04-26 23:09:55

Re: why is there only one kernel by default?

#20 2006-04-27 00:33:44

Re: why is there only one kernel by default?

#21 2006-04-27 00:50:05

Re: why is there only one kernel by default?

#22 2006-04-27 08:39:58

Re: why is there only one kernel by default?

#23 2006-04-27 08:42:05

Re: why is there only one kernel by default?

#24 2006-04-27 13:31:03

Re: why is there only one kernel by default?

#25 2006-04-27 13:57:25

Re: why is there only one kernel by default?

Board footer