Bug 76222 – Kernel upgrading bug

• Product: Gentoo Linux
• Status: RESOLVED INVALID

[Description Jozef Behran 2004-12-31 02:59:53 UTC]

When I install some version of Linux (the kernel) and a newer version is released, that newer version gets installed, which is OK. But after that some weird behaviors are possible:

1. The /usr/src/linux points to the newest Linux instead of the Linux installed after Linux
   is upgraded.
2. When trying to cleanup using -P, the sources of the Linux that is currently installed
   get unmerged even when it is in fact in use.
3. (untested) After this misupgrade the system goes unstable like Windows (mysterious
   failures occur until rm -rf / with following complete reinstallation is done).


Reproducible: Always
Steps to Reproduce:
1. Install GENTOO with the newest Linux available in the package
   repository masked. I thing this should be sufficient: extract stage3, determine the 
   newest Linux available, mask it
2. Unmask the Linux masked in the previous step
3. emerge -u world
4. Weird behavior 1 occurs
5. emerge -P
6. Weird behavior 2 occurs
7. Continue using the system. Concetrate to packages that are known to be fragile when 
   it comes to Linux version mismatches such as alsa or filesystem drivers.
8. Weird behavior 3 may occur

Actual Results:  
At step 4 there are two Linux source code trees in /usr/src installed and /usr/src/linux 
points to the newer version of Linux (not the version already installed in the system). 
 
At step 6 in /usr/src there is a directory with complete sources of the latest Linux plus 
"linux" symlink pointing to it and a directory which contained sources for the currently 
instaled Linux but now it misses most source files (usually only binaries, object files and 
config file are left intact in the directory). 
 
At step 8 you probably experience that the system is unstable like Windows. I didn't 
tested this because my Gentoo installation is broken and is unable to boot (I wouldn't be 
surprised if this was this bug's fault). Mysterious crashes, hangs, data losses, ebuild 
failures etc appears. To get cured you must backup all data, remove the whole system 
and install it again starting from the stage (the only thing that should be preserved is the 
/usr/portage directory. I guess this is due to the fact that most lernel-level packages 
(including glibc) expect that /usr/src/linux points to the Linux sources of the Linux 
currently in use. 

Expected Results:  
Portage should maintain the answers to the question (suggested place: ebuilds) if a 
particular package can be build on a system with a particular Linux installed. It should be 
sufficient to have information about the oldest Linux required for it. Packages 
unbuildable with the Linux currently installed and all packages that have one of such 
package as a dependency should be masked. In that case Portage should warn the user 
that there are such masked packages and that he needs to upgrade his kernel in order 
to unmask them. The Portage should do this upgrade automatically when the newer 
Linux has the same configuration items as the old one (by reusing the .config file from 
the source code directory of the old kernel). If new configuration items are available or 
some old items disappear, Portage should ask the user to reconfigure the kernel. 
 
More specifically at the step 4 the /usr/src/linux symling should still point to the old Linux 
(not the latest Linux just emerged). I suggest you to create /usr/src/linux-latest symlink 
pointing to the latest Linux (and update this symlink when kernel sources get upgraded 
instead of the /usr/src/linux symlink). At the step 6 the sources in the directory the 
/usr/src/linux symlink points to should not be touched until the user upgrades the Linux 
to a newer version (and redirects /usr/src/linux). The user should be warned that he is 
required to reboot after the Linux is upgraded and the Portage should refuse to 
emerge/update/unmerge everything that looks around kernel sources until a reboot 
occurs. 
 

The above solution should be sufficient for now but the problem it not so easy to be  
fixed. It is common to have multiple Linuxes installed in the system for example due to  
the fact that the user wants to keep his old Linux around until he realizes that the new  
Linux is stable enough for him. So Portage should be able to work with the bootloader  
configuration (to be able to get the active Linuxes from that configuration and remove a 
Linux from the configuration). All active Linuxes should have their sources in /usr/src 
untouched after emerge -P. Also packages depending on one of the active Linuxes 
should be kept intact by emerge -P. 
 
I think the emerge info is not important here but it if you want it: 
 
Portage 2.0.51-r8 (default-linux/x86/2004.3, gcc-3.4.3, glibc-2.3.4.20041102-r0, 
2.4.21-0.13mdk i686) 
================================================================= 
System uname: 2.4.21-0.13mdk i686 AMD Athlon(tm) Processor 
Gentoo Base System version 1.6.8 
Python:              dev-lang/python-2.3.4 [2.3.4 (#1, Dec 29 2004, 21:34:09)] 
dev-lang/python:     2.3.4 
sys-devel/autoconf:  2.13, 2.59-r6 
sys-devel/automake:  1.5, 1.8.5-r2, 1.6.3, 1.7.9, 1.4_p6, 1.9.3 
sys-devel/binutils:  2.15.92.0.2-r2 
sys-devel/libtool:   1.5.10-r2 
virtual/os-headers:  2.4.22 
ACCEPT_KEYWORDS="x86 ~x86" 
AUTOCLEAN="yes" 
CFLAGS="-O2 -march=i686 -fomit-frame-pointer -pipe makecheck" 
CHOST="i686-pc-linux-gnu" 
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env 
/usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb 
/usr/share/config /var/qmail/control" 
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" 
CXXFLAGS="-O2 -march=i686 -fomit-frame-pointer -pipe makecheck" 
DISTDIR="/usr/portage/distfiles" 
FEATURES="autoaddcvs autoconfig ccache distlocks maketest sandbox sfperms" 
GENTOO_MIRRORS="http://distfiles.gentoo.org 
http://distro.ibiblio.org/pub/Linux/distributions/gentoo" 
LDFLAGS="" 
MAKEOPTS="-j2" 
PKGDIR="/usr/portage/packages" 
PORTAGE_TMPDIR="/var/tmp" 
PORTDIR="/usr/portage" 
PORTDIR_OVERLAY="" 
SYNC="rsync://rsync.gentoo.org/gentoo-portage" 
USE="x86 X acl alsa apm arts avi berkdb bitmap-fonts bonobo crypt cups emacs 
encode esd fam flac foomaticdb fortran gdbm gif gnome gpm gtk gtk2 gtkhtml 
imagemagick imlib ipv6 java jpeg junit kde libwww mad mikmod motif mpeg ncurses nls 
oggvorbis opengl oss pam pdflib perl pic png postgres python qt quicktime readline 
samba sdl slang spell ssl svga tcpd tiff truetype xml xml2 xmms xv zlib"

[Comment 1 Daniel Drake (RETIRED) 2004-12-31 06:10:58 UTC]

1. /usr/src/linux is dynamically created the first time you merge a kernel, it is never automatically updated (that is up to you to do).
2. Yes, and this is expected behaviour. If you feel it is a problem, then you should approach the portage developers about this.
3. Almost certainly incorrect

If the kernel sources are not present, or /usr/src/linux points to something other than your running kernel, then you will get problems when emerging extneral kernel modules e.g. alsa-driver. However the emerge will fail with a clear message ("kernel sources could not be found at ...").

Your system will not suffer otherwise. Failure to boot, hangs, data loss, etc, are not caused by this. My laptop does not have any kernel sources on it: it is quite slow at compiling and doesn't have much disk space. I compile my laptop kernels on my main PC and transfer them over. I have been running this way for months without problems. (One of the things that I like a lot about the Linux kernel is how it is very seperate from "user space" and doesnt really depend on it at all)

We generally do not experience the problem you describe at the start of "Expected Results" (which seems to be entirely different from the main content of your bug report..?) as we apply fixes to our kernel module ebuilds to make them work on all currently supported kernels. If you find any that fail for a particular (and supported) kernel version then please open a bug and we will fix it.

One of the great flexibilities of portage is that it allows you to build things for a kernel that you are *not* currently running (this is especially useful for me building things for my laptop..). Forcing the user to reboot into the kernel they are building for would remove this flexibility.