The "why does pacman replace the kernel image when upgrading" topic ag

stavrosg · 2008-03-09 13:40:00

...once again.

I know this is discussed to death, but I had my little race condition today:
While building the initcpio image, the computer froze completely (I am troubleshooting it now), so I was left with the *new* vmlinuz26 and the *old* initcpio.
So, naturally, I was greeted with a kernel panic at boot so I booted off my install image to sort things out.

But if pacman renamed the image and initcpio image to *-old before replacing anything, I would at least have a working kernel to boot my system from.

Now, flame away

Last edited by stavrosg (2008-03-09 13:40:34)

Dusty · 2008-03-09 14:03:09

I think its a good idea. I'm not sure if the devs have a reason for not implementing this or if they just haven't had time. I suspect the problem lies with how to clean up old kernel images when a new one is installed. The obvious way to do this is using post-install script, but that seems kind of hackish.

A more elegant solution would be to provide hooks in pacman to allow users to run arbitrary code whenever a specific package is installed or removed. Then people could contribute hooks to back up the kernel or run lilo or do the countless other optional requests some people have. Basically it'd allow a custom post_install.

In the meantime, if you don't or can't contribute a pacman patch to do this, write a simple wrapper for pacman that backs up the kernel each time pacman is run.

Dusty

shining · 2008-03-09 14:42:12

And how would pacman know that some package is a kernel? And how would it know which files to backup?
Or do you suggest always moving files to -old before removing them? That doesn't seem realistic.
So maybe you meant something like the NoUpgrade array, for example a Backup array?

Anyway, I also think the second file hooks solution is more elegant. And besides that idea already exists for a while, it was even on a pacman todo list.
We just need someone to implement it

brebs · 2008-03-09 17:32:59

Compile your own kernel and add it to grub. Job done

schivmeister · 2008-03-10 04:41:27

Well it can be implemented in the install scripts for kernels only, no? Remove them when mkinitcpio has successfully finished, so in case of a crash they are still there.

phrakture · 2008-03-10 16:26:06

Dusty wrote:

I think its a good idea. I'm not sure if the devs have a reason for not implementing this or if they just haven't had time

Here's one for ya. How about the age old holy crap bug reports and feature requests on the forums are a terrible idea because no one ever sees them!

http://bugs.archlinux.org

shining · 2008-03-10 17:11:50

schivmeister wrote:

Well it can be implemented in the install scripts for kernels only, no? Remove them when mkinitcpio has successfully finished, so in case of a crash they are still there.

When the post install script is run, the old package was already removed and replaced by the new one.
But maybe you could also add in pre remove a backup of the image.
It sounds a bit ugly though.

stavrosg · 2008-03-11 17:47:32

phrakture wrote:

Dusty wrote:
I think its a good idea. I'm not sure if the devs have a reason for not implementing this or if they just haven't had time
Here's one for ya. How about the age old holy crap bug reports and feature requests on the forums are a terrible idea because no one ever sees them!
http://bugs.archlinux.org

I wanted to discuss it on the forum a bit, and then file a bug report, ideally with a rudimentary solution attached, too.

wuischke · 2008-03-11 18:15:26

How about having two default kernel packages?

One fallback-kernel (let's say a well tested current-1 kernel, i.e. currently 2.6.23) and of course the arch default kernel? I did something similar by installing a "custom" kernel which I know works well I can always boot in case of a problem with my primary kernel. (At least after I fscked up both initrds for the only installed kernel when playing with klibc...)

schivmeister · 2008-03-11 18:46:17

What about simple, plain %BACKUP%? We already do that with kconfig, and this way we'd facilitate removal upon successful generation of the new stuff. Not too ugly I'd think, things like that get done all the time.

iphitus · 2008-03-11 23:49:55

schivmeister wrote:

What about simple, plain %BACKUP%? We already do that with kconfig, and this way we'd facilitate removal upon successful generation of the new stuff. Not too ugly I'd think, things like that get done all the time.

It'd be terribly ugly. Remember, kernel modules are dependent. So the backup line would look somewhat like the output of this:

pacman -Ql kernel26|grep -v '/$'|sed "s/kernel26 //g"

pacman -Ql kernel26|grep -v '/$'|sed "s/kernel26 //g"|wc -l
6859

Nobody has an objection to doing something like this, it's just a matter of finding a tidy way of doing it. I think we agreed that the tidiest way would be for pacman to have user configurable 'hooks' for various packages, and someone could write a hook to backup all the kernel files before installing the new kernel....

Also remember, the new and old kernels' files conflict, so they both _cannot_ be installed at the same time. At best, you'd be able to backup the old, boot a liveCD and recover the old.... which you can do already with the pacman package cache.

patches welcome.

schivmeister · 2008-03-12 04:09:18

ahh yeah..i totally ignored anything else besides the boot files, like you could boot with just an image and nothing in /lib/modules

stavrosg · 2008-03-12 15:27:13

schivmeister wrote:

ahh yeah..i totally ignored anything else besides the boot files, like you could boot with just an image and nothing in /lib/modules

Indeed, that was my mistake too when starting the thread.
The obvious solution - version naming the kernel and then having multiple versions installed instead of replaced like other distros do generates a host of other problems, like the need to rebuild other packages and how to remove the old kernels.

So, let this thread die in peace.

Arch Linux

#1 2008-03-09 13:40:00

The "why does pacman replace the kernel image when upgrading" topic ag

#2 2008-03-09 14:03:09

Re: The "why does pacman replace the kernel image when upgrading" topic ag

#3 2008-03-09 14:42:12

Re: The "why does pacman replace the kernel image when upgrading" topic ag

#4 2008-03-09 17:32:59

Re: The "why does pacman replace the kernel image when upgrading" topic ag

#5 2008-03-10 04:41:27

Re: The "why does pacman replace the kernel image when upgrading" topic ag

#6 2008-03-10 16:26:06

Re: The "why does pacman replace the kernel image when upgrading" topic ag

#7 2008-03-10 17:11:50

Re: The "why does pacman replace the kernel image when upgrading" topic ag

#8 2008-03-11 17:47:32

Re: The "why does pacman replace the kernel image when upgrading" topic ag

#9 2008-03-11 18:15:26

Re: The "why does pacman replace the kernel image when upgrading" topic ag

#10 2008-03-11 18:46:17

Re: The "why does pacman replace the kernel image when upgrading" topic ag

#11 2008-03-11 23:49:55

Re: The "why does pacman replace the kernel image when upgrading" topic ag

#12 2008-03-12 04:09:18

Re: The "why does pacman replace the kernel image when upgrading" topic ag

#13 2008-03-12 15:27:13

Re: The "why does pacman replace the kernel image when upgrading" topic ag

Board footer