Problems 10.7 KB
Newer Older
1

2
    $Id: Problems,v 1.16 2003/08/14 17:15:52 srivasta Exp $
3

4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
 This is an (incomplete) list of problems that people have encountered
 in the past while using kernel-package. Please remember to configure
 the kernel for your machine using make menuconfig, and to clean the
 source tree before compiling a new image using make-kpkg clean.

 a) Failure to format a floppy disk while installing kernel image.

    fdformat from the obsolete package miscutils sometimes has problems 
    formatting floppies.  Install the package fdutils instead.
    Also, sometimes the new fdformat fails for /dev/fd0 unless the
    parameters are set using setfdprm -- in short, make sure that you can
    format floppies manually before asking the kernel image postinst to do
    so.

 b) warning, 'debian/tmp-image/DEBIAN/control' contains user-defined field
19
   'Installed-Size' warning,
20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66
    dpkg-deb: unable to create  '..': is a directory

    The problem is actually that the version of dpkg being used is
     too old for kernel-package; kernel-package version 3.X needs dpkg
     1.4.0.0 at least.

 c) dpkg-gencontrol fails with the error message 
    failure: chown new files list file: Illegal seek

    This is an error in older versions of dpkg-dev. Upgrading to version
    1.4.0.9 should help.

 d) install: debian/changelog: No such file or directory
   
     Remember to do make-kpkg clean with a patched/old kernel source tree
     (if this is not a clean tree, clean it first).

 e) make-kpkg goes into an infinite loop when trying to make oldconfig.

    This is _not_ a bug with kernel-package, it is a well known
    incompatibility between the new version of expr (which has suddenly
    become POSIX compliant) and the kernel sources (which did not expect
    expr to behave this way).

    The fix is to apply the following patch to the kernel sources. 


--- scripts/Configure.dist	Mon Jan 20 14:43:24 1997
+++ scripts/Configure	Tue Jan 21 05:41:30 1997
@@ -288,7 +288,7 @@
 	def=${old:-$3}
 	while :; do
 	  readln "$1 ($2) [$def] " "$def" "$old"
-	  if expr "$ans" : '0$\|-?[1-9][0-9]*$' > /dev/null; then
+	  if expr "$ans" : '0$\|-\?[1-9][0-9]*$' > /dev/null; then
 	    define_int "$2" "$ans"
 	    break
 	  else
@@ -319,7 +319,7 @@
 	while :; do
 	  readln "$1 ($2) [$def] " "$def" "$old"
 	  ans=${ans#*[x,X]}
-	 if expr "$ans" : '[0-9a-fA-F]+$' > /dev/null; then
+	 if expr "$ans" : '[0-9a-fA-F]\+$' > /dev/null; then
 	   define_hex "$2" "$ans"
 	   break
 	 else
67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82


  f) % depmod -a
     modprobe: error reading ELF header: No such file or directory


     This is a problem with the newly changed behavior of depmod and
     friends, who suddenly stopped liking non .o files in
     /lib/modules/<version>. Newer versions of kernel package, like this
     one, handle that right. For older image packages, the test is:

     % find /lib/modules/2.0.30/ -type f -exec file {} \; | grep -v 'ELF 32-bit'
     /lib/modules/2.0.30/modules.dep: ASCII text

     Anything other than modules.dep showing up is something that depmod
     can no longer tolerate. Remove those files, and things should be fine.
83 84 85 86 87

   g) dpkg-gencontrol fails if LC_ALL is set to de_DE.  Actually, I can't
      really confirm this works for anything except en_US. This is true as of
      dpkg/dpkg-dev 1.4.0.19. The error actually reported seems to be
      either that debian/substvars file can not be found, or that the
88
      changelog file is empty (even when the file is not empty). 
89 90 91 92 93 94 95 96 97

      The work around seems to be to set the LC_ALL to en_US while compiling
      the kernel. This should be fixed soon.

    h) dpkg upgrades the custom kernel to a new standard kernel. This
       means that epochs were used; unfortunately I did not consider
       that when I wrote all the documentation. I have since upgraded
       the documentation; and you can add epochs to your custom kernel
       just as well as the upstream maintainers.
98

99 100
    i) The build keeps erring out. It fails with the following:
       objdump:  illegal option -- k
101 102 103


	rm `which encaps`
104

105
    j) build fails with a bizarre error talking about /bin/ls and tab
106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122
       sizes = Text:
make[3]: Leaving directory `/usr/src/kernel-source-2.0.32/arch/i386/math-emu'
make[2]: Leaving directory `/usr/src/kernel-source-2.0.32/arch/i386/math-emu'
ld -m elf_i386 -Ttext 0x100000 -e stext arch/i386/kernel/head.o init/main.o in
it/version.o \
        arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o net/network.a \
        fs/filesystems.a \
        drivers/block/block.a drivers/char/char.a drivers/net/net.a drivers/cdrom/cdrom.a drivers/pci/pci.a arch/i386/math-emu/math.a \
         /usr/src/kernel-source-2.0.32/arch/i386/lib/lib.a /usr/src/kernel-source-2.0.32/lib/lib.a /usr/src/kernel-source-2.0.32/arch/i386/lib/lib.a -o vmlinux
/usr/src/kernel-source-2.0.32
/bin/ls: invalid tab size: text
make[1]: *** [vmlinux] Error 1
make[1]: Leaving directory `/usr/src/kernel-source-2.0.32'
make: *** [all] Error 2

	make-kpkg --zimage <other options> kernel_image
	This is truly a weird error message for machines that need
123
	zImage rather than the default bzImage
124 125 126

     k) Modules do not build when there is an epoch in the version.
        Some modules have been reported to have problems with epochs
127 128 129 130 131 132 133 134 135
        in the version number.

     l) The version number seems to be dropped in the name of the package,
	i.e., you get results like kernel-image-.._300_i386.deb, where the 
	300 is from the --revision flag.

	This seems to result from using the broken perl 5.005 packages
	installed a while ago in unstable. That package has since been
	withdrawn. Problems seem to go away when one downgrades to 5.004.
136 137

	This is also caused by a broken grep, (for example, grep
138
	2.3-1). Upgrading to a fixed grep solves this (2.3-4 is known
139 140 141 142 143 144 145 146
	to work, at the time of writing this).

     m) Some versions of gcc do not interact well with the kernel
        sources (the upcoming gcc 2.95 has problems compiling the
        kernel without the flag '-fno-strict-aliasing' (I think you
        may have to edit the makefile for this, or something). This is
        an universal problem, hopefully there shall be a compromise
        somewhere 
147 148 149 150
 
        A symptom may be failures like:
Makefile:153: arch/i586/Makefile: No such file or directory
make[1]: *** No rule to make target `arch/i586/Makefile'.  Stop.
151 152 153 154 155 156

      n) I keep getting this kind of messages:  

 make[1]: i386-linux-gcc: Command not found        

	This is a result of having the env variable ARCH set when you do 
157 158 159 160 161 162 163 164
        not intend to cross compile the kernel.  Unsetting ARCH works fine.

      o)  booting from the new kernel fails with 
VFS: Cannot open root device "308" or 03:08
          immediately followed by a kernel panic

	The cause for this is either you have not compiled the file
	system type of the root file system into the kernel, or you
165
	have instructed your boot loader to expect an initrd kernel
166 167 168 169 170
	(this is required for running a recent official kernel image,
	and have installed a non-initrd garden variety kernel image.
	You need to go back and recompile the kernel image, either
	including the root file system type as a builtin, or adding a
	--initrd flag to the make-kpkg run.
171 172 173 174 175 176 177 178 179 180 181 182
      p) Even when the kernel is built with a regular user using fakeroot, 
         it fails with
> install -p -d -o root -g root -m 755 debian/tmp-image/DEBIAN
> install: cannot create directory `debian/tmp-image/DEBIAN': Permission
> denied
         since the ./debian/tmp-image directory is owned by root.root

	It was actually due to the fact that (somehow) the XFS filesystem
	didn't have restrict_chown set (see /proc/sys/fs/xfs/restrict_chown),
	which was causing install to give away permissions on a directory
	(lesson: fakeroot and xfs w/o restrict_chown=1 don't play together
	nicely).
183 184 185 186 187 188 189 190 191 192 193 194 195
       q) The most recent versions of sudo (versions after 1.6.8p12-1)
          now create a default sudoers file with the env_reset option
          set.  This causes make-kpkg to fail with the rather
          unexpected error message "make: Nothing to be done for
          `$(i_package)'." since the i_package variable is constructed
          without the APPEND_TO_VERSION string in the sub-make
          invocation with sudo because env_reset causes sudo to clean
          it out of the environment.  Clearly there are other possible
          failure conditions/messages depending on which variables the
          root sub-make is expecting to find.

          So, using sudo with env_reset will cause errors, possibly
          with the above error message.
196 197 198 199

        r) When run in a git sourced tree, scripts/setlocalversion
           checks to see if the tree is the trunk, if not, it adds
           version information to the kernel version. It also checks
200
           to see if there are uncommitted changes, if so, it adds the
201 202 203
           string "-dirty" to the version. Since we change a couple of
           files in ./scripts/, this falls afoul of the make-kpkg
           checks, since the version number is now different from what
204 205 206 207 208 209 210 211 212
           make-kpkg knows it to be. 

      s) there is an additional truncated commit ID added by the
         script scripts/setlocalversion whenever it detects that we
         are not building from a tagged commit of the official tree,
         so it might be just simpler to get rid of it altogether,
         which is what make-kpkg does now.

      t)
Manoj Srivastava's avatar
Manoj Srivastava committed
213
         There is a problem when GREP_OPTIONS are exported, since it
214 215
         may impact the results coming out of grep in scripts that
         are tun in subshells -- and, of course, make-kpkg is one of
Manoj Srivastava's avatar
Manoj Srivastava committed
216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234
         them.

           $ echo $GREP_OPTIONS --colour=always

         So the Perl regex does not match in:
         UTS_RELEASE_VERSION=$(call doit,if [ -f $(UTS_RELEASE_HEADER) ]; then                        \
                          grep 'define UTS_RELEASE' $(UTS_RELEASE_HEADER) |                       \
                          perl -nle  'm/^\s*\#define\s+UTS_RELEASE\s+("?)(\S+)\1/g && print $$2;';\
                          else echo "" ;                                                          \
                          fi)

         This shows up as an error message like:
,----
| The UTS Release version in include/linux/utsrelease.h
|      ""
| does not match current version:
|      "2.6.18"
| Please correct this.
| make: *** [install/linux-image-2.6.18] Erreur 2
235 236 237 238 239 240 241 242 243 244
`----

          u) The current version of make-kpkg is incompatible with
             older versions of make. Specifically, the problem shows
             up as:
,----
| $ fakeroot make-kpkg --initrd                  
| exec make -f /usr/share/kernel-package/ruleset/minimal.mk debian INITRD=YES 
| /usr/share/kernel-package/ruleset/misc/version_vars.mk:55: *** missing `endif'.  Stop.
| Failed to create a ./debian directory: No such file or directory at /usr/bin/make-kpkg line 1096.
Manoj Srivastava's avatar
Manoj Srivastava committed
245
`----