This file is indexed.

/usr/share/kernel-package/templates.in is in kernel-package 12.036+nmu3.

This file is owned by root:root, with mode 0o644.

The actual contents of the file can be viewed below.

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 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
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
Template: =ST-image-=V/preinst/failed-to-move-modules-=V
Type: note
_Description:  Failed to move modules out of the way, aborting
 You are attempting to install a kernel image (version =V)
 However, the directory ${modules_base}/=V/kernel still exists.
 .
 As you have instructed, an attempt was made to move the directory out
 of the way. Unfortunately, There was a problem moving
 ${modules_base}/=V to ${modules_base}/${dest}.
 .
 I suggest you move ${modules_base}/${version} out of the way manually,
 and then try re-installing this image.
 .
 I am aborting.

Template: =ST-image-=V/preinst/overwriting-modules-=V
Type: boolean
Default: true
_Description:  Stop install since the kernel-image is already installed?
 You are attempting to install a kernel image (version =V)
 However, the directory ${modules_base}/=V/kernel still exists.  If this
 directory belongs to a previous ${package} package, and if
 you have deselected some modules, or installed standalone modules
 packages, this could be bad. 
 .
 If ${modules_base}/=V/kernel belongs to an old install of
 ${package}, then this is your last chance to abort the
 installation of this kernel image (nothing has been changed yet).
 .
 If you know what you are doing, and if you feel that this
 image should be installed despite this anomaly, Please answer n to the
 question.
 .
 Otherwise, I suggest you move ${modules_base}/=V/kernel out of the way,
 perhaps to ${modules_base}/=V.kernel.old or something, and then try
 re-installing this image.

Template: =ST-image-=V/preinst/abort-overwrite-=V
Type: note
_Description:  Aborting install since modules exist
 You are attempting to install an initrd kernel image (version =V).
 However, the corresponding kernel modules directory exists, and there was
 no permission given to silently delete the modules directory. 
 Unfortunately, since this Question pertaining to this was not shown, and
 the default action is to abort the install. =ST-image-=V aborted.

Template: =ST-image-=V/preinst/already-running-this-=V
Type: note
_Description:  The kernel version running is the same as the one being installed
 You are attempting to install a kernel version that is the same as the
 version you are currently running (version ${running}). The modules list
 is quite likely to have been changed, and the modules dependency file
 ${modules_base}/=V/modules.dep needs to be re-built. It can not be built
 correctly right now, since the module list for the running kernel are
 likely to be different from the kernel installed. I am creating a new
 modules.dep file, but that may not be correct. It shall be regenerated
 correctly at next reboot.
 .
 I repeat: you have to reboot in order for the modules file to be created
 correctly. Until you reboot, it may be impossible to load some modules.
 Reboot as soon as this install is finished (Do not reboot right now, since
 you may not be able to boot back up until installation is over, but boot
 immediately after). I can not stress that too much. You need to reboot
 soon.

Template: =ST-image-=V/postinst/kimage-is-a-directory
Type: note
_Description:  Image symbolic link destination is a directory, aborting
 ${kimage} is a directory, which I did not expect.  I am trying to create a
 symbolic link with that name linked to ${image_dest}. Since a directory
 exists here, my assumptions are way off, and I am aborting.

Template: =ST-image-=V/postinst/depmod-error-=V
Type: boolean
Default: false
_Description:  Do you want to abort now?
 This may be benign, (You may have versioned symbol names, for instance).
 Or this could be an error. depmod exited with return value ${exit_value}
 ${SIGNAL}${CORE}. I am deleting the file ${modules_base}/=V/modules.dep.
 However, since depmod is run at install time, we could just defer running
 depmod.

Template: =ST-image-=V/postinst/depmod-error-initrd-=V
Type: boolean
Default: false
_Description:  Do you want to abort now?
 This may be benign, (You may have versioned symbol names, for instance).
 Or this could be an error. depmod exited with return value ${exit_value} .
 ${SIGNAL} ${CORE} Since this image uses initrd, I am not deleting the file
 ${modules_base}/=V/modules.dep. However, there is no guarantee that the
 file is valid. I would strongly advice you to either abort and fix the
 errors in depmod, or regenerate the initrd image with a known good
 modules.dep file. I repeat, an initrd kernel image with a bad modules.dep
 shall fail to boot.

Template: =ST-image-=V/postinst/old-dir-initrd-link-=V
Type: boolean
Default: true
_Description:  Should the old initrd link be deleted now?
 I note that you have an old ${image_dir}/initrd symbolic link in place. 
 The location of the symbolic link is now the same location as the kernel
 image symbolic links, namely, in ${image_dest}.  If the old link is
 deleted, you may have to update the boot loader. If the link is left in
 place, it will point to the wrong image.

Template: =ST-image-=V/postinst/old-system-map-link-=V
Type: boolean
Default: true
_Description:  Should the old /System.map link be deleted now?
 You have /System.map symbolic link. These were installed by ancient kernel
 image packages. However, all the programs that look at the information in
 the map files (including top, ps, and klogd) also will look at
 /boot/System.map-=V Having the symbolic link in / is technically
 detrimental (apart from cluttering up /); many programs, though looking in
 /boot, still allow /System.map to override. If you install multiple
 kernels on this machine, then the /System.map symbolic link only applies
 to one such kernel, for all other choices the symbols loaded will be
 wrong. Not having /System.map at all prevents this.

Template: =ST-image-=V/prerm/removing-running-kernel-=V
Type: boolean
Default: true
_Description:  Do you want to abort removal now?
 You are running a kernel (version ${running}) and attempting to remove the
 same version. This is a potentially disastrous action. Not only will
 /boot/vmlinuz-${running} be removed, making it impossible to boot it, (you
 will have to take action to change your boot loader to boot a new kernel),
 it will also remove all modules under the directory
 /lib/modules/${running}. Just having a copy of the kernel image is not
 enough, you will have to replace the modules too.
 .
 I repeat, this is very dangerous. If at all in doubt, answer Yes. If you
 know exactly what you are doing, and are prepared to hose your system,
 then answer No.