i2o drivers not needed after all!
On Wed, 01 Jul 2015 19:05:57 +0100, Ben Hutchings wrote: > > Please note that i2o will be going away entirely (disabled in 4.0, > removed upstream in 4.2). (The above quote is from Debian bug report 790722, now archived.) And so it did. I was able to build custom kernels which included these drivers by enabling them in staging for 4.0 and 4.1. For 4.2 and later, I created a patch file that added these drivers back. But recently, while researching something else, I happened to stumble upon something on the internet which suggested that the dpt_i2o driver, which is still in the kernel, might work in my situation, since I have an Adaptec i2o raid controller. I reviewed the boot logs and discovered that this driver tried to load, but it failed to initialize because it was unable to reserve some memory. I wondered if it was trying to obtain resources already reserved by i2o_core. So I blacklisted i2o_core. dpt_i2o came right up! It creates the device as /dev/sda instead of /dev/i2o/hda, but that's fine. As another happy coincidence, I no longer need local mods to udev to get the symbolic links to the disk created in /dev/disk. (udev has dropped support for the /dev/i2o/hd* devices). Of course, with unmodified newer kernels, I won't need to blacklist i2o_core, since it no longer exists. The problem was that i2o_core always loaded first, and therefore the load of dpt_i2o always failed. Therefore, I thought I needed i2o_core. But as it turns out, I don't. dpt_i2o is working just fine for me. All's well that ends well! Regards, -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
Bug#825141: dasd_mod: module verification failed: signature and/or required key missing - tainting kernel
On Mon, May 23, 2016, at 22:16, Ben Hutchings wrote: > On Mon, 2016-05-23 at 21:06 -0400, Stephen Powell wrote: >> >> The following message is received at boot time when booting the stock Debian >> kernel >> version 4.5.3-2 on the s390x architecture: >> >> dasd_mod: module verification failed: signature and/or required key missing >> - tainting kernel > > This is expected until we sort out support for loading signed modules > in unstable. > I've done a little research on this. I haven't checked other architectures, but the stock s390x kernel for 4.5.3-2 (and today I also tried 4.5.4-1) has CONFIG_MODULE_SIG=y # CONFIG_MODULE_SIG_ALL is not set This seems to be the problem. From what I've read, If CONFIG_MODULE_SIG=y, but CONFIG_MODULE_SIG_ALL is not set, then the modules need to be manually signed via scripts/sign-file between the "make modules" and "make modules_install" phases of the build process. But automated tools for building debian kernel packages, such as make-kpkg from kernel-package, "make deb-pkg", and I presume the tools you use for building stock kernels as well, do not allow this manual signing step to take place. I have been able to build a successful kernel using make-kpkg with both of the above options not set, as well as with both of them set to y. But the combination of options currently used in the stock kernel is problematic for these tools. -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
Bug#825141: dasd_mod: module verification failed: signature and/or required key missing - tainting kernel
Package: linux Version: 4.5.3-2 Severity: minor X-Debbugs-CC: debian-s...@lists.debian.org The following message is received at boot time when booting the stock Debian kernel version 4.5.3-2 on the s390x architecture: dasd_mod: module verification failed: signature and/or required key missing - tainting kernel The kernel does boot; but the kernel gets tainted, which disables lock debugging. -- .''`. Stephen Powell<zlinux...@fastmail.com> : :' : `. `'` `-
Bug#820156: parse_numeric function cannot handle composite device numbers of more than 8 hex digits
On Tue, Apr 5, 2016, at 20:37, Ben Hutchings wrote:
>
> I'm not applying this until the kernel actually supports device numbers
> that large. Currently it defines (in include/linux/kdev_t.h):
>
> static inline u32 new_encode_dev(dev_t dev) { ... }
> static inline dev_t new_decode_dev(u32 dev) { ... }
>
> static inline u64 huge_encode_dev(dev_t dev)
> {
> return new_encode_dev(dev);
> }
>
> static inline dev_t huge_decode_dev(u64 dev)
> {
> return new_decode_dev(dev);
> }
>
> i.e. anything above bit 31 is zeroed.
>
> Ben.
>
Interesting. I wasn't aware of that. Thank you for calling my attention
to it. Under the circumstances, wishlist is fine.
Regards,
--
.''`. Stephen Powell<zlinux...@fastmail.com>
: :' :
`. `'`
`-
Bug#820156: parse_numeric function cannot handle composite device numbers of more than 8 hex digits
Package: initramfs-tools-core
Version: 0.123
Severity: minor
Tags: patch
Congratulations on initramfs-tools version 0.123! Many bugs in version 0.120
have been fixed in this version. However, it appears that the parse_numeric
function, while improved over the 0.120 version, still doesn't handle the
general case of a composite device number. It seems it will only handle 8 hex
digits or less correctly.
I have submitted a patch for your consideration. The patch will accommodate the
general case of a composite device number of up to 16 hex digits (the limit).
It also tightens up some other error checking corner cases.
Respectfully submitted,
--
.''`. Stephen Powell<zlinux...@fastmail.com>
: :' :
`. `'`
`-
--- a/functions 2016-01-21 18:33:59.0 -0500
+++ b/functions 2016-03-24 08:09:11.0 -0400
@@ -128,14 +128,28 @@
# lilo compatibility
parse_numeric() {
- case $1 in
+ case "$1" in
*:*)
# Does it match /[0-9]*:[0-9]*/?
- minor=${1#*:}
- major=${1%:*}
- case $major$minor in
+ minor="${1#*:}" # Everything after the first colon.
+ major="${1%%:*}" # Everything before the first colon.
+ [ X"$major" = X ] && return # major is null.
+ [ X"$minor" = X ] && return # minor is null.
+ case "$major$minor" in
*[!0-9]*)
- # No.
+ # major or minor contains a non-numeric character.
+ return
+ ;;
+ esac
+ case "$major" in
+ 0?*)
+ # major has a leading zero.
+ return
+ ;;
+ esac
+ case "$minor" in
+ 0?*)
+ # minor has a leading zero.
return
;;
esac
@@ -146,9 +160,56 @@
;;
*)
# [A-Fa-f0-9]*
- value=$(( 0x${1} ))
- minor=$(( (${value} & 0xff) | (${value} >> 12) & 0xfff00 ))
- major=$(( (${value} >> 8) & 0xfff ))
+ case "$1" in
+ 0?*)
+ # Composite device number has a leading zero.
+ return
+ ;;
+ esac
+ [ ${#1} -gt 16 ] && return # More than 16 hex digits.
+ #
+ # 16 hex digits, with leading zeros suppressed.
+ # Format is MmmMMMmm, where the "M"s are the hex
+ # digits of the major device number and the "m"s are the
+ # hex digits of the minor device number.
+ #
+ # Note: the shell uses 64-bit two's complement signed binary
+ # integer arithmetic internally when evaluating arithmetic
+ # expressions, even on 32-bit platforms such as i386. Bitwise
+ # shift operations are arithmetic shifts, not logical shifts.
+ # Only the right-most 63 bits participate in a shift operation.
+ # The left-most bit, the sign bit, does not participate in
+ # the shift operation and remains unchanged. For a shift
+ # left operation, bits shifted out of the left-most bit
+ # position which participates in the shift are lost; and zeros
+ # are shifted in on the right. Arithmetic overflow occurs
+ # if any bits unlike the sign bit are shifted out of the
+ # left-most bit position which participates in the shift.
+ # (However, arithmetic overflow is ignored.) For a shift
+ # right operation, bits shifted out of the right-most bit
+ # position are lost; and copies of the sign bit are shifted
+ # in on the left. All 64 bit positions, including the sign
+ # bit, participate in bitwise "and" and bitwise "or"
+ # operations.
+ #
+ # Hexadecimal constants are treated as padded on the left
+ # with zeros, if needed, or truncated on the left, if needed,
+ # to make 16 digits. If the left-most digit, after padding
+ # or truncating if needed, is in the range 8-f, inclusive,
+ # then the number is treated as negative, in two's complement
+ # form. Otherwise, the number is treated as positive (or zero
+ # if all digits are zero).
+ #
+ # For the three operators used in the expressions below,
+ # the bitwise shift right operator (>>) has the highest
+ # priority, followed by the bitwise "and" operator (&),
+ # followed by the bitwise "or" operator (|). Therefore, the
+ # default order of operations is correct; and no parentheses
+ # are needed in the expressions themselves.
+ #
+ devno=$(( 0x$1 ))
+ major=$(( devno >> 8 & 0xfff | devno >> 32 & 0xf000 ))
+ minor=$(( devno & 0xff | devno >> 12 & 0xff00 ))
;;
esac
Bug#797023: Fwd: [PATCH 3.16.y-ckt 125/130] s390/sclp: fix compile error
Forwarding to the Debian bug log - Forwarded Message - From: Luis Henriques <luis.henriq...@canonical.com> To: linux-ker...@vger.kernel.org, sta...@vger.kernel.org, kernel-t...@lists.ubuntu.com Cc: Sebastian Ott <seb...@linux.vnet.ibm.com>, Martin Schwidefsky <schwidef...@de.ibm.com>, Stephen Powell <zlinux...@wowway.com>, Luis Henriques <luis.henriq...@canonical.com> Sent: Fri, 04 Sep 2015 09:08:33 -0400 (EDT) Subject: [PATCH 3.16.y-ckt 125/130] s390/sclp: fix compile error 3.16.7-ckt17 -stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Ott <seb...@linux.vnet.ibm.com> commit a313bdc5310dd807655d3ca3eb2219cd65dfe45a upstream. Fix this error when compiling with CONFIG_SMP=n and CONFIG_DYNAMIC_DEBUG=y: drivers/s390/char/sclp_early.c: In function 'sclp_read_info_early': drivers/s390/char/sclp_early.c:87:19: error: 'EBUSY' undeclared (first use in this function) } while (rc == -EBUSY); ^ Signed-off-by: Sebastian Ott <seb...@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidef...@de.ibm.com> Cc: Stephen Powell <zlinux...@wowway.com> Signed-off-by: Luis Henriques <luis.henriq...@canonical.com> --- drivers/s390/char/sclp_early.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/s390/char/sclp_early.c b/drivers/s390/char/sclp_early.c index 1918d9dff45d..45c3d7041c81 100644 --- a/drivers/s390/char/sclp_early.c +++ b/drivers/s390/char/sclp_early.c @@ -7,6 +7,7 @@ #define KMSG_COMPONENT "sclp_early" #define pr_fmt(fmt) KMSG_COMPONENT ": " fmt +#include #include #include #include -- .''`. Stephen Powell<zlinux...@wowway.com> : :' : `. `'` `-
Bug#797023: Fwd: [3.16.y-ckt stable] Patch "s390/sclp: fix compile error" has been added to staging queue
Forwarding the below message to the relevant Debian Bug Log - Forwarded Message - From: Luis Henriques <luis.henriq...@canonical.com> To: Sebastian Ott <seb...@linux.vnet.ibm.com> Cc: Martin Schwidefsky <schwidef...@de.ibm.com>, Stephen Powell <zlinux...@wowway.com>, Luis Henriques <luis.henriq...@canonical.com>, kernel-t...@lists.ubuntu.com Sent: Thu, 03 Sep 2015 06:38:07 -0400 (EDT) Subject: [3.16.y-ckt stable] Patch "s390/sclp: fix compile error" has been added to staging queue This is a note to let you know that I have just added a patch titled s390/sclp: fix compile error to the linux-3.16.y-queue branch of the 3.16.y-ckt extended stable tree which can be found at: http://kernel.ubuntu.com/git/ubuntu/linux.git/log/?h=linux-3.16.y-queue This patch is scheduled to be released in version 3.16.7-ckt17. If you, or anyone else, feels it should not be added to this tree, please reply to this email. For more information about the 3.16.y-ckt tree, see https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable Thanks. -Luis -- >From 2741d9ee96a36721b961a7c99594b1d9248e8edb Mon Sep 17 00:00:00 2001 From: Sebastian Ott <seb...@linux.vnet.ibm.com> Date: Thu, 25 Jun 2015 09:32:22 +0200 Subject: s390/sclp: fix compile error commit a313bdc5310dd807655d3ca3eb2219cd65dfe45a upstream. Fix this error when compiling with CONFIG_SMP=n and CONFIG_DYNAMIC_DEBUG=y: drivers/s390/char/sclp_early.c: In function 'sclp_read_info_early': drivers/s390/char/sclp_early.c:87:19: error: 'EBUSY' undeclared (first use in this function) } while (rc == -EBUSY); ^ Signed-off-by: Sebastian Ott <seb...@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidef...@de.ibm.com> Cc: Stephen Powell <zlinux...@wowway.com> Signed-off-by: Luis Henriques <luis.henriq...@canonical.com> --- drivers/s390/char/sclp_early.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/s390/char/sclp_early.c b/drivers/s390/char/sclp_early.c index 1918d9dff45d..45c3d7041c81 100644 --- a/drivers/s390/char/sclp_early.c +++ b/drivers/s390/char/sclp_early.c @@ -7,6 +7,7 @@ #define KMSG_COMPONENT "sclp_early" #define pr_fmt(fmt) KMSG_COMPONENT ": " fmt +#include #include #include #include -- .''`. Stephen Powell<zlinux...@wowway.com> : :' : `. `'` `-
Bug#797023: Linux kernel FTBFS error for ARCH=s390, CONFIG_SMP=n, and CONFIG_DYNAMIC_DEBUG=y
On Thu, 27 Aug 2015 18:06:49 -0400 (EDT), Ben Hutchings wrote: > > On Wed, 2015-08-26 at 21:33 -0400, Stephen Powell wrote: >> >> The Linux kernel in jessie fails to build from source for >> the combination ARCH=s390, CONFIG_SMP=n, and CONFIG_DYNAMIC_DEBUG=y. >> Compilation of drivers/s390/char/sclp_early.c fails with a number >> of undefined symbols. >> >> The problem also exists in the stretch and sid kernels at the time >> of this writing. The following patch fixes the problem for all three >> kernel versions: >> >> https://git.kernel.org/cgit/linux/kernel/git/s390/linux.git/patch/?id=a313bdc5310dd807655d3ca3eb2219cd65dfe45a > > Please mail sta...@vger.kernel.org to request that this is included in > the relevant stable branches. Hello, sta...@vger.kernel.org. Per the above, please include the above-referenced git commit in the relevant stable branches. Respectfully submitted, -- .''`. Stephen Powell<zlinux...@wowway.com> : :' : `. `'` `-
Bug#797023: Linux kernel FTBFS error for ARCH=s390, CONFIG_SMP=n, and CONFIG_DYNAMIC_DEBUG=y
Package: linux Version: 3.16.7-ckt11-1+deb8u3 Severity: minor X-Debbugs-CC: debian-s...@lists.debian.org Tags: patch The Linux kernel in jessie fails to build from source for the combination ARCH=s390, CONFIG_SMP=n, and CONFIG_DYNAMIC_DEBUG=y. Compilation of drivers/s390/char/sclp_early.c fails with a number of undefined symbols. The problem also exists in the stretch and sid kernels at the time of this writing. The following patch fixes the problem for all three kernel versions: https://git.kernel.org/cgit/linux/kernel/git/s390/linux.git/patch/?id=a313bdc5310dd807655d3ca3eb2219cd65dfe45a -- .''`. Stephen Powellzlinux...@wowway.com : :' : `. `'` `-
Bug#793929: Operation Exception in arch/s390/kernel/cache.c (init_cache_level) on pre-z10 processors (s390x)
Package: linux Version: 4.0.8-1 Severity: important X-Debbugs-CC: Heiko Carstens heiko.carst...@de.ibm.com Tags: patch Dear Debian kernel team, The s390x port of the Linux kernel, version 4.0, crashes during boot on processors without the general-instructions-extension facility. This is all processors prior to the z10, namely, the z800, z900, z890, z990, z9 BC, and z9 EC. I have assigned the severity of this bug as important because it affects relatively few users. However, for those affected, it would have to be critical, as it prevents the system from booting. Here is a sample symptom dump from the console: - Kernel BUG at 001219d0 [verbose debug info unavailable] illegal operation: 0001 ilc:3 [#1] SMP Krnl PSW : 0704e0018000 001219d0 (init_cache_level+0x38/0xe0) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 EA:3 Krnl Code: 001219c2: a7840056 brc 8,121a6e 001219c6: a719 lghi%r1,0 #001219ca: eb10104c ecag%r1,%r0,0(%r1) 001219d0: a739 lghi%r3,0 001219d4: e310f0a00024 stg %r1,160(%r15) 001219da: a708 lhi %r0,0 001219de: a7b9f000 lghi%r11,-4096 001219e2: c0a0002899d9 larl%r10,634d94 Call Trace: [00478ee2] detect_cache_attributes+0x2a/0x2b8 [0097c9b0] cacheinfo_sysfs_init+0x60/0xc8 [001001c0] do_one_initcall+0x98/0x1c8 [0094fdc2] kernel_init_freeable+0x212/0x2d8 [0062352e] kernel_init+0x26/0x118 [0062fd2e] kernel_thread_starter+0x6/0xc - I have been working with upstream on this, and the following two patches need to be applied (in the order listed) to fix the problem: https://git.kernel.org/cgit/linux/kernel/git/s390/linux.git/patch/?id=77bb36e57bbe5586bea29b67ba7f87cfe03610a0 https://git.kernel.org/cgit/linux/kernel/git/s390/linux.git/patch/?id=0b991f5cdcd6201e5401f83ca3a672343c3bfc49 I have personally tested the fixes, and they work for me on my z890. Respectfully submitted, -- .''`. Stephen Powellzlinux...@wowway.com : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/343840314.3792556.1438130556030.javamail.zim...@wowway.com
Bug#792910: modprobe: module css:t0 not found in modules.dep issued during boot
Package: initramfs-tools
Version: 0.120
Severity: minor
During boot of a jessie system on the s390x platform, I noticed the
following error message on the console:
Begin: Loading essential drivers ...
modprobe: module css:t0 not found in modules.dep
The error didn't seem to affect the ability of the system to boot,
but I decided to investigate. I traced the problem to the
sys_walk_modalias function in /usr/share/initramfs-tools/hook-functions.
The relevant code goes something like this:
if [ -n ${modalias} ]; then
force_load ${modalias}
fi
The problem here is that the code does not distinguish between a regular
module alias and what I call a udev alias. (I'm not sure what the proper
terminology is. If you know please tell me.) A udev alias associates
a module with a piece of hardware. When udev sees a piece of hardware
which matches the pattern of the alias, it loads the corresponding module.
Compare, for example, the output of modinfo ext4, which lists true
aliases, with the output of modinfo e100, which lists udev aliases.
Most of the udev aliases have asterisks in them. All of them seem to have
a colon in them. I suggest the following code to replace the above:
case ${modalias} in
|*:*)
:
;;
*)
force_load ${modalias}
;;
esac
The attached patch file fixes the problem on my system.
--
.''`. Stephen Powellzlinux...@wowway.com
: :' :
`. `'`
` hook-functions.orig 2015-03-01 16:44:34.0 -0500
+++ hook-functions 2015-07-19 21:04:19.587616682 -0400
@@ -222,9 +222,14 @@
while [ ${device_path} != /sys ]; do
if [ -e ${device_path}/modalias ]; then
modalias=$(cat ${device_path}/modalias)
- if [ -n ${modalias} ]; then
-force_load ${modalias}
- fi
+ case ${modalias} in
+|*:*)
+ :
+ ;;
+*)
+ force_load ${modalias}
+ ;;
+ esac
fi
device_path=$(dirname ${device_path})
done
Bug#792910: modprobe: module css:t0 not found in modules.dep issued during boot
Control: tags -1 patch -- .''`. Stephen Powellzlinux...@wowway.com : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1190905225.16131929.1437358328102.javamail.zim...@wowway.com
Bug#790722: mkinitramfs fails with latest udev (= 220-7) on some systems
Incidentally, I have now filed a bug report against udev also. The udev bug is what caused me to switch back, temporarily, to specifying partitions via a traditional block special file name instead of by uuid. Doing so exposed this bug in initramfs-tools. The bug number for udev is 790823, in case you're interested. -- .''`. Stephen Powellzlinux...@wowway.com : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1982051385.5796616.1435833751763.javamail.zim...@wowway.com
Bug#790722: mkinitramfs fails with latest udev (= 220-7) on some systems
Package: initramfs-tools
Version: 0.120
Severity: normal
A recent upgrade of my stretch system via
apt-get upgrade
failed with
mkinitramfs: failed to determine device for /
I run with MODULES=dep in /etc/initramfs-tools/conf.d/driver-policy. My system
uses an i2o hardware RAID device, device major number 80 (decimal) and device
minor number 0, with user-space name /dev/i2o/hda. The root partition is
/dev/i2o/hda6 (device minor number 6).
The main culprit seems to be the new udev at release 220-7. I have tried the
sid version also at 221-1 with no better luck. However, initramfs-tools
may be partially at fault.
udev has 2 major deficiencies, from my perspective:
(1) The symbolic links in /dev/disk/by-uuid and /dev/disk/by-label are no
longer being created at boot time. I don't know why they aren't being created,
but they should be.
(2) The new udev does not contain a command called udevd.
I was able to work around the first problem by changing /etc/fstab,
/etc/initramfs-tools/conf.d/resume, and /etc/lilo.conf to use traditional
block special file names (/dev/i2o/hda6, etc.) instead of uuids (UUID=...).
(I use lilo as my boot loader.) This is a regression from recommended practice,
but I must have a functioning system.
The second problem causes a problem for initramfs-tools. The parse_numeric
function in /usr/share/initramfs-tools/scripts/functions has code in it which
looks like this:
if command -v udevd /dev/null 21; then
ROOT=/dev/block/${major}:${minor}
else
mknod -m 600 /dev/root b ${major} ${minor}
ROOT=/dev/root
fi
Obviously, initramfs-tools is testing for the existence of udev by checking
to see if there is a command available called udevd. If not, then it assumes
that there is no udev. Older releases of udev contained this command. udev
220-7 (and above) does not. As a temporary kludge, I have changed the first
line
of the above to
if command -v udevd /dev/null 21; :; then
which causes the if test to always test true, resulting in the correct code
path. I had to change MODULES=dep to MODULES=most temporarily, but after
building the initramfs, shutting down, and rebooting, I was able to change back
to MODULES=dep and successfully build an initial RAM file system with
MODULES=dep.
The system then boots correctly using the smaller initial RAM file system image.
Either it is a bug for udev to be missing the udevd command, or initramfs-tools
needs to find another way to determine if udev is present. I plan to eventually
report a bug in udev, but I need to do more research first, and my first goal
was to get my system running again. Thus this bug report came first.
By the way, I am still hoping to get my parse_numeric patch, available at
http://users.wowway.com/~zlinuxman/kernel/parse_numeric.patch, included in
initramfs-tools. The current code cannot handle a kernel composite device
number
greater than 0xf. With the patch, it should be able to handle any valid
kernel composite device number.
Respectfully submitted,
--
.''`. Stephen Powellzlinux...@wowway.com
: :' :
`. `'`
`-
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/1993869501.4988405.1435736347189.javamail.zim...@wowway.com
Bug#790722: mkinitramfs fails with latest udev (= 220-7) on some systems
On Wed, 01 Jul 2015 14:05:57 -0400 (EDT), Ben Hutchings wrote: Please note that i2o will be going away entirely (disabled in 4.0, removed upstream in 4.2). Thanks, Ben, I hadn't heard that; but it really doesn't have anything to do with this bug, per se. I happened to discover it using an i2o RAID device on i386 using lilo. But this bug can happen with any disk device, on any hardware platform, and with any boot loader. All one need do to expose it is to supply the root parameter on the kernel command line, specifying the root file system as a kernel composite device number, such as root=801 If you do this, and if you use MODULES=dep, and if udev is at version 220-7, then mkinitramfs (and update-initramfs), performed during this boot session, will fail. I've done a little more research, and I suggest using udevadm, instead of udevd, as the command to look for. You already make use of this command elsewhere in initramfs-tools. The fix for this problem is a canonical (pardon the pun) one-line change. Simply change if command -v udevd /dev/null 21; then to if command -v udevadm /dev/null 21; then in the parse_numeric function. Problem solved. And yes, I realize that using disk labels or uuids is the recommended way to specify the root file system these days. But that's another story, as I mentioned earlier. Respectfully yours, -- .''`. Stephen Powellzlinux...@wowway.com : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1967416753.5648099.1435795665776.javamail.zim...@wowway.com
Bug#697017: root=compute fails at parse_numeric() for lilo compatibility
On Sat, 30 Aug 2014 18:36:34 -0400 (EDT), Michael Prokop wrote: If someone would provide an up2date patch (against current git master would be awesome) which resolves this issue (without possibly breaking anything else :)) I'm absolutely willing to accept it. Here is what I am currently using on my system: http://users.wowway.com/~zlinuxman/kernel/parse_numeric.patch Sorry, I know that it's customary to include patches inline, but my e-mail client has the nasty habit of expanding tabs to blanks, inserting extra line breaks, etc. Therefore, to prevent my e-mail client from corrupting the patch, I have included a link instead. I tried to think of every perverse case my devious little mind could think of. (For example, what if there is more than one colon, what if a colon is the first or last character, etc.) Note that although the comments say lilo compatibility, this code is executed whenever the kernel boot parameters contain a root specification, regardless of the hardware architecture and regardless of the boot loader. It is associated with lilo because lilo translates a specification of root=/dev/... in /etc/lilo.conf into the corresponding kernel composite device number, such as root=801 This translation takes place behind the user's back. The user never sees this number. But the kernel does. However, you can always code a root file system specification in this format directly, if you want to, with any boot loader. Let me know what you think. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1613143933.450991.1409541999417.javamail.r...@md01.wow.synacor.com
Bug#717805: initramfs-tools: lsinitramfs doesn't understand early microcode images
Brett, your patch (and Olivier, your revised one) don't seem to work for me anymore. By trial and error experimentation (wild guessing), I find that the magic number is no longer 8, but 4, for the two initial RAM file systems that I currently possess, both of which have a real_offset value, before incrementing, of 6796. I note that 6796 divided by 8 yields a quotient of 849 and a remainder of 4. Hmm. Adding 4 brings the value to an integer multiple of 8. I wonder. Maybe the correct algorithm is real_offset=$(((real_offset+8)/8*8)) This will bump real_offset to the next higher multiple of 8. Is this correct? I have no idea. What I do know is that the current algorithm doesn't work for me, but the above does. For now. Will it continue to work in the future? I don't know. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/66851843.402888.1408838404613.javamail.r...@md01.wow.synacor.com
Bug#758264: tabs not working for 3215 tty
Package: linux Version: 3.14.15-2 Severity: normal Tags: patch When logging in to linux from the 3215 virtual machine console under z/VM, and typing out a file which contains tabs, tab expansion does not work. I've been working with upstream on this, and they have written a patch, which I have tested, and it fixes the problem. Here's a link to the official upstream git commit at kernel.org: https://git.kernel.org/cgit/linux/kernel/git/s390/linux.git/commit/?h=featuresid=e512d56c799517f33b301d81e9a5e0ebf30c2d1e -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/69086115.339701.1408147375774.javamail.r...@md01.wow.synacor.com
Bug#747922: kernel hang during boot on s390x in a virtual machine under z/VM when logged on to a terminal
On Sun, 27 Jul 2014 19:16:44 -0400 (EDT), Ben Hutchings wrote: Thanks. This looks like a sensible change so far as I can understand it, but since I know nothing of s390 drivers I would like to see it go through upstream review before applying it. Please let us know when that has happened. The patch is now official. Here is a link to the official git commit at kernel.org: https://git.kernel.org/cgit/linux/kernel/git/s390/linux.git/commit/?h=featuresid=26d766c60f4ea08cd14f0f3435a6db3d6cc2ae96 -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/465539106.152070.1406588089435.javamail.r...@md01.wow.synacor.com
Bug#747922: kernel hang during boot on s390x in a virtual machine under z/VM when logged on to a terminal
I have been working with upstream on this. Upstream has sent me a patch, which I have applied and tested, and it seems to fix the problem. Here is a link to the patch: http://users.wowway.com/~zlinuxman/119-3215-hangs.diff This patch is not yet official, but an official patch should be submitted to kernel.org soon, if it hasn't been already. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/108995111.135436.1406396813691.javamail.r...@md01.wow.synacor.com
Bug#750925: make deb-pkg produces a non-installable package on the s390x architecture
On Sun, 08 Jun 2014 09:59:47 -0400 (EDT), maximilian attems wrote: see scripts/package/builddeb: s390*) debarch=s390 ;; this debarch setting very likely predates s390x Thanks for the tip. While looking at this file, I discovered a circumvention. Use the make variable KBUILD_DEBARCH=s390x This works, even with an unmodified builddeb script. In my test case, I set CONFIG_LOCALVERSION to -1custom01-s390x during kernel configuration (under General Setup). I also set CONFIG_DEBUG_INFO off. (This is under Kernel Hacking.) Then I issued make KDEB_PKGVERSION=3.14.4-1 KBUILD_PKG_ROOTCMD=fakeroot \ INSTALL_MOD_STRIP=1 KBUILD_DEBARCH=s390x deb-pkg as a non-root user. It built a kernel image package just the way I wanted it. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/223528771.113881.1402361863179.javamail.r...@md01.wow.synacor.com
Bug#750925: make deb-pkg produces a non-installable package on the s390x architecture
Package: linux Version: 3.14.4-1 Severity: normal make deb-pkg, when issued on the s390x architecture, produces a non-installable package. The package is built for the s390 architecture, not the s390x architecture, and dpkg won't allow it to be installed, even if the package file is renamed to the expected naming convention (*_s390x.deb). -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/121909425.93017.1402234223970.javamail.r...@md01.wow.synacor.com
Bug#747922: kernel hang during boot on s390x in a virtual machine under z/VM when logged on to a terminal
Package: linux Version: 3.10.1-1 Severity: normal I have discovered a bug in the Linux kernel. This bug only occurs for the s390x port, only when running in a virtual machine under z/VM, only with conmode=3215, and only when the virtual machine is logged on to a 3270 terminal (not disconnected). I am using TERM=dumb as a kernel boot parameter, and the console definition in /etc/inittab looks like this: T0:23:respawn:/sbin/getty -L --noclear ttyS0 9600 dumb The problem is that the kernel hangs during boot. The last message displayed on the console during boot before the hang varies. One common freeze point for the 3.13 kernel is PID hash table entries: 2048 (order: 2, 16384 bytes) Pressing the Enter key a couple of times gets it going again. Pressing it once puts the virtual machine into a VM READ state. Pressing it the second time causes console output to resume. However, due to buffering, I don't think the above message is indicative of where the kernel actually is in its processing. Many of the messages have time stamps on them. By comparing the time stamps, I can tell where the long pause actually was. In a recent boot, for example, I saw the following sequence of messages: - Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. Begin: Running /scripts/local-premount ... [ 1.973615] PM: Starting manual resume from disk done. [ 1.999199] EXT4-fs (dasdc1): mounting ext3 file system using the ext4 subsystem [ 2.042526] EXT4-fs (dasdc1): mounted filesystem with ordered data mode. Opts: (null) Begin: Running /scripts/local-bottom ... done. done. Begin: Running /scripts/init-bottom ... done. INIT: version 2.88 booting Using makefile-style concurrent boot in runlevel S. Starting the hotplug events dispatcher: udevd. Synthesizing the initial hotplug events... [ 164.525332] systemd-udevd[277]: starting version 204 done. Waiting for /dev to be fully populated... - (I have reformatted the above messages so that messages without a timestamp prefix and messages with a timestamp prefix line up starting with the main message text.) As you can see, there is a huge time gap between 2.042526 and 164.525332. That is where it was hung, waiting for me to press the Enter key. It is somewhere between mounting the permanent root file system read only and starting the second instance of the udev daemon. (The first instance of the udev daemon starts shortly after mounting the initial RAM file system.) By bisecting the kernel using official Debian kernel image packages only, it appears that the problem exists between 3.9.8-1 and 3.10.1-1. That is, linux-image-3.9-1-s390x_3.9.8-1_s390x.deb works, and linux-image-3.10-1-s390x_3.10.1-1_s390x.deb fails. And every version I have tried since 3.10.1-1 fails also. It should be noted that a kernel which fails does not always fail. Sometimes it does not hang. But it hangs the majority of the time. If the virtual machine is disconnected, that is, not logged on to a real terminal, it seems to always boot fine, whether the virtual machine has a SECUSER or not. When logged on to a terminal, the chances of failure are increased if the kernel is explicitly selected from the boot menu, such as with #CP VINPUT VMSG 1 as opposed to letting a timeout occur and letting the default kernel boot via a timeout. I don't know why that matters, but that has been my experience. I will be more than happy to assist in debugging this. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/299380321.1225525.1399939304318.javamail.r...@md01.wow.synacor.com
[SOLVED] Debian has become totally unusable on my amd64 system -- no stable kernel available
On Sat, 01 Feb 2014 14:54:32 -0500 (EST), Stephen Powell wrote: I may have found the problem. This problem may be related to Debian bug number 736892. As it turned out, Debian bug number 736892 was an unrelated problem. My real problem was faulty memory (RAM). Ben, I know that you already know this, but I thought that this thread should have some closure. Replacing the faulty memory DIMM solved my problems. I highly recommend that owners of systems with non-ECC memory test their memory with a tool such as memtest86+, especially on new, previously untested systems. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/291566371.1081766.1393093262861.javamail.r...@md01.wow.synacor.com
Bug#737938: BUG: unable to handle kernel paging request at 000008000000001c
After replacing the bad memory and reinstalling Debian from scratch, I have had no further problems. I am assuming that the symptoms of this bug report were caused by the bad memory. You may close this bug report at your convenience. I've made a new friend: memtest86+, which I will use on all systems with non-ECC memory from now on. Thanks for the tip! -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1741790913.991874.1392641404754.javamail.r...@md01.wow.synacor.com
Bug#737938: BUG: unable to handle kernel paging request at 000008000000001c
On Fri, 07 Feb 2014 05:49:55 -0500 (EST), Ben Hutchings wrote: Stephen Powell wrote: [38587.355263] BUG: unable to handle kernel paging request at 081c Looks like a bit flip to me (0 turned to 0x800 and then treated as a real pointer). Did you run memtest86+ or other memory test yet? I'm not used to systems that don't automatically check their memory, as all my old i386 systems do. And I hate non-ECC memory, which this system uses. But your hunch was right. memtest86+ revealed a bad memory DIMM, which makes my entire installation suspect. New memory is on order. I'll reinstall Debian from scratch once the new memory has been installed and tested. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/65674401.857452.1391875484657.javamail.r...@md01.wow.synacor.com
Bug#737938: BUG: unable to handle kernel paging request at 000008000000001c
Package: linux Version: 3.11.10-1 [38587.355263] BUG: unable to handle kernel paging request at 081c [38587.355328] IP: [8110b149] find_get_page+0x29/0x90 [38587.355382] PGD 0 [38587.355401] Oops: [#1] SMP [38587.355430] Modules linked in: tun bnep rfcomm bluetooth rfkill parport_pc ppdev lp parport nfsd auth_rpcgss oid_registry nfs_acl nfs lockd fscache sunrpc fuse loop usb_storage ata_generic snd_hda_codec_realtek kvm crc32c_intel ghash_clmulni_intel aesni_intel aes_x86_64 ablk_helper cryptd lrw gf128mul glue_helper evdev edac_mce_amd psmouse edac_core pcspkr radeon serio_raw fam15h_power k10temp sp5100_tco ttm drm_kms_helper drm i2c_algo_bit wmi button snd_hda_intel sg snd_hda_codec acpi_cpufreq snd_hwdep mperf snd_pcm processor snd_page_alloc snd_seq snd_seq_device snd_timer sr_mod ohci_pci cdrom ohci_hcd snd pata_atiixp i2c_piix4 ehci_pci ehci_hcd i2c_core usbcore alx thermal_sys shpchp usb_common soundcore mdio ext4 crc16 mbcache jbd2 sd_mod crc_t10dif ahci libahci libata scsi_mod microcode [38587.356087] CPU: 2 PID: 4050 Comm: hercules Not tainted 3.11-2-amd64 #1 Debian 3.11.10-1 [38587.356151] Hardware name: Gigabyte Technology Co., Ltd. GA-78LMT-S2P/GA-78LMT-S2P, BIOS F3 10/18/2012 [38587.356223] task: 8801f42b1140 ti: 8801f436c000 task.ti: 8801f436c000 [38587.356281] RIP: 0010:[8110b149] [8110b149] find_get_page+0x29/0x90 [38587.356348] RSP: 0018:8801f436dd80 EFLAGS: 00010246 [38587.356390] RAX: 880101caf718 RBX: 8801e06379f8 RCX: fffa [38587.356445] RDX: 0800 RSI: 000444c4 RDI: [38587.356499] RBP: 000444c4 R08: 0800 R09: 880101caf718 [38587.356554] R10: 0006 R11: 0293 R12: 000e [38587.356608] R13: eac3b920 R14: R15: 8801f4233580 [38587.356664] FS: 7f2c70237700() GS:88020fc8() knlGS: [38587.356726] CS: 0010 DS: ES: CR0: 80050033 [38587.356770] CR2: 081c CR3: 0001f434c000 CR4: 000407e0 [38587.356825] Stack: [38587.356842] 8801e06379f0 000444c4 8110c720 8801e06378a0 [38587.356904] 8801f42335f8 000444d2 810abac2 [38587.356965] 000444c3 000444c4 8801f436de68 [38587.357027] Call Trace: [38587.357053] [8110c720] ? generic_file_aio_read+0x250/0x6f0 [38587.357108] [81169527] ? do_sync_read+0x67/0x90 [38587.357154] [81169ab4] ? vfs_read+0x94/0x160 [38587.357199] [8116a5a3] ? SyS_read+0x43/0xa0 [38587.357244] [81481469] ? system_call_fastpath+0x16/0x1b [38587.357291] Code: 00 00 55 48 89 f5 53 48 8d 5f 08 48 89 ee 48 89 df e8 ac e5 14 00 48 85 c0 49 89 c1 74 34 48 8b 10 48 85 d2 74 26 f6 c2 03 75 45 8b 4a 1c 85 c9 74 d9 8d 71 01 48 8d 7a 1c 89 c8 f0 0f b1 72 1c [38587.357502] RIP [8110b149] find_get_page+0x29/0x90 [38587.357551] RSP 8801f436dd80 [38587.360506] CR2: 081c [38587.363626] ---[ end trace a69c5e0ca2716703 ]--- -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2027073877.834564.1391741777992.javamail.r...@md01.wow.synacor.com
Debian has become totally unusable on my amd64 system -- no stable kernel available
Gentlemen, Never have I seen such an unstable system. In fairness, this is my first amd64 system. All previous systems I have used have been i386 systems. But I cannot find any Debian Linux kernel that is stable on my amd64 system. The best I can find is linux-image-3.11-2-amd64, version 3.11.10-1. This kernel boots, but falls apart as soon as it needs to page. The 3.12 kernel currently in jessie and sid won't even boot. It craps out on me before I can even login. The 3.13 kernel in experimental will boot, but is even more unstable than the 3.11 kernel. Paging problems seem to be the common denominator. I don't even know where to start. I may as well turn my computer off until I can find a stable kernel. If there's anything I can do to help, please let me know. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1949220422.738977.1391265504400.javamail.r...@md01.wow.synacor.com
Re: Debian has become totally unusable on my amd64 system -- no stable kernel available
On Sat, 01 Feb 2014 11:58:06 -0500 (EST), Ben Hutchings wrote: It's not clear to me whether you were previously running an i386 installation on the same hardware. If so, this behaviour is very surprising. No, I'm comparing to an i386 system on different hardware. If this is a new system then I suspect there is a hardware fault, such as: - faulty memory (memtest86+ may be able to confirm this) - faulty disk controller - inadequate power supply I may have found the problem. This problem may be related to Debian bug number 736892. At last contact, the Debian package maintainer was convinced that this is not a bug; and that everything is working as designed. However, new evidence documented in my last post to the bug report now has me convinced otherwise. I varied offline the two CPUs which apparently did *not* get their microcode updated by means of echo 0 /sys/devices/system/cpu/cpu1/online echo 0 /sys/devices/system/cpu/cpu3/online (issued as root), and so far, the system is now stable. I'm running on half power, but at least the system is stable. Of course, I have to be running a kernel that survives long enough for me to login as root and issue these two commands before it crashes. But once I get that far, I haven't had any problems since. I now think 736892 really is a bug, and that it is the cause of the kernel crashes I have been experiencing. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1191836467.743203.1391284472876.javamail.r...@md01.wow.synacor.com
[SOLVED] What happened to the real-time preemption patches for kernel 3.11?
On Sun, 24 Nov 2013 23:25:41 -0500 (EST), Ben Hutchings wrote: On Sun, 2013-11-24 at 20:29 -0500, Stephen Powell wrote: The real-time preemption patches for kernel 3.11 do not appear to be present in linux-source-3.11. What happened to them? They don't exist. Since 3.0 they have only been released for even-numbered minor versions (3.0, 3.2, 3.4, etc.). That explains it. Thank you. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1581378594.572915.1385426356646.javamail.r...@md01.wow.synacor.com
What happened to the real-time preemption patches for kernel 3.11?
The real-time preemption patches for kernel 3.11 do not appear to be present in linux-source-3.11. What happened to them? -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/70943889.555315.1385342942561.javamail.r...@md01.wow.synacor.com
Bug#697017: root=compute fails at parse_numeric() for lilo compatibility
On Thu, 03 Jan 2013 01:49:14 -0500 (EST), Jonathan Nieder wrote: Less than or equal to 4095 and 255 respectively, technically. ;-) The full formula was just trivia. (stat's st_dev and lilo's MKDEV() macro use it, for what it's worth.) Well I rolled up my sleeves and took a look at lilo's source code, particularly the MKDEV, MAJOR, and MINOR functions, and now I understand what you are talking about. And you're right. The current initramfs-tools code, particularly the parse_numeric function, can handle major device numbers up to 4095 and minor device numbers up to 255. Whether lilo itself, in actual fact, can correctly handle major and minor device numbers outside this range, I don't know. I didn't dig deeply enough to verify that. But given that the above three functions understand the format, I suspect that it will. If you want to enhance the code to correctly handle the full 16-hex-digit composite device number, go ahead. As you say, it's trivial. And that would once again make you the author of the final patch, which is fine. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/740091575.600602.1357397828433.javamail.r...@md01.wow.synacor.com
Bug#697017: root=compute fails at parse_numeric() for lilo compatibility
On Tue, 01 Jan 2013 13:50:07 -0500 (EST), Jonathan Nieder wrote:
Technically the current code only makes sense for 5 hexdigits.
After that, something more complicated could work:
# 16 hexdigits: 0xMmmMMMmm
devno=$(( 0x${1} ))
major=$(( (($devno 8) 0xfff) | (($devno 32) ~0xfff) ))
minor=$(( ($devno 0xff) | (($devno 12) 0xff00) ))
I'm not sure I follow this. But in any case, it's not worth doing.
The use of a hexadecimal number is largely a legacy case left over
from the pre-udev days; and as far as I know, lilo is the only boot
loader which still uses this method (for some cases only). If lilo
is configured as recommended for modern GNU/Linux distributions,
it specifies the root file system via a UUID or LABEL specification.
The current code works the way that lilo works, and I doubt that
the lilo code in question will ever change its algorithm. It currently
assumes that both the major and minor device numbers of the root file
system are less than or equal to 255, and that is what the parse_numeric
shell function in initramfs-tools assumes also. If those assumptions
ever become a problem, lilo will probably specify the root file system
in a different way rather than continuing to use a hexadecimal number.
--
.''`. Stephen Powell
: :' :
`. `'`
`-
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/846143425.556937.1357180686930.javamail.r...@md01.wow.synacor.com
Bug#697017: An improved patch over Jonathan's
On Tue, 01 Jan 2013 10:18:06 -0500 (EST), Gabriel Klawitter wrote: sorry for the ambiguity. I did't mean cases like 0x and 0x but the cases for which this function is being used. These are, as far as I've understood your post correctly, the case where root equals something like 08:02 and root equals a hex decimal numer with at most 4 digits like abcd. What confused me was that you seemed to think that upper case vs. lower case made a difference. It doesn't. Not to the shell hex conversion function anyway. The evaluation a=$((0xcompute)) might leave the value of the variable intact but the script fails and init dies.(http://pastebin.com/7BJAY1Wj) Yes, that was precisely my point. That's why Jonathan wrote his patch (and I made a slight correction to it). Your patch will sort out cases like 08:02 but not the case where root equals 'facade', 'added' or 'dead01'. I'm using the root= parameter for giving the name of the boot profile, which might differ from 'compute'. Hmm. I'm not familiar with the term boot profile. Either my ignorance is showing, or you are using the root= kernel boot parameter for something for which it was not intended. Here is a comment from the kernel source code (init/do_mounts.c) which explains the supported uses of the root= kernel boot parameter We accept the following variants: 1) device number in hexadecimal represents itself 2) /dev/nfs represents Root_NFS (0xff) 3) /dev/disk_name represents the device number of disk 4) /dev/disk_namedecimal represents the device number of partition - device number of disk plus the partition number 5) /dev/disk_namepdecimal - same as the above, that form is used when disk name of partitioned disk ends on a digit. 6) PARTUUID=00112233-4455-6677-8899-AABBCCDDEEFF representing the unique id of a partition if the partition table provides it. 7) PARTUUID=UUID/PARTNROFF=int to select a partition in relation to a partition with a known unique id. If name doesn't have fall into the categories above, we return (0,0). So unless I'm missing something, it appears that you are attempting to use the root kernel boot parameter in a non-standard way. With your patch 'dead01' would still be interpreted as a hex number which would be parsed correctly this time, but the function would evaluate it as a hex number that'd be changed for lilo compatibility. This is a rare case and I could circumvent it by requiring that the root string shouldn't contain only hex digits. That is true. We could maybe add the restriction that the hex number must be less than or equal to four characters, as in lilo's case it always will be. But that still leaves things like dead, fade, and ace as valid hexadecimal numbers that you might want to use as boot profile names. I haven't tested your patch yet, as I'm convinced that it'll work fine for root=compute but not for root=facade01. Again, it appears to me that you are using the root kernel boot parameter in a non-standard way, in which case you are on your own. There is a legitimate bug in the parse_numeric function which has been discovered as the result of your bug report, and it appears to me that this proposed patch fixes that problem. But adding support for boot profiles, whatever that may be, is something that you will need to submit to the Linux kernel team (and initramfs-tools upstream development) as an enhancement request. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/240263452.530207.1357059360648.javamail.r...@md01.wow.synacor.com
Bug#697017: root=compute fails at parse_numeric() for lilo compatibility
On Sun, 30 Dec 2012 21:28:33 -0500 (EST), Jonathan Nieder wrote: How about this patch? ... I like your patch better. It is more general and solves the more general problem of non-numeric strings being treated like numeric strings. Whenever I see something which includes a bracketed expression, such as [0-9]*, I tend to think regular expressions. And apparently, the original author did too. In a regular expression, [0-9]* means a string of zero or more numeric digits somewhere in the complete string. ( ^[0-9]*$ would mean the complete string is numeric or is the null string.) But these are not regular expressions, these are shell patterns. As a shell pattern, [0-9]* means a single numeric digit at the beginning of the string followed by zero or more arbitrary characters. Your patch solves the more general problem. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2132308463.512198.1356963589483.javamail.r...@md01.wow.synacor.com
Bug#697017: An improved patch over Jonathan's
Jonathan, After further study of your patch, I did notice one flaw: the pattern *[!A-Fa-f0-9]* will not match the null string, as your comments suggest it will. And you have deleted the separate case which handles the null string. Here is an improved patch: http://users.wowway.com/~zlinuxman/parse_numeric.patch I have used a link to it, rather than include the patch inline, since my e-mail client has the nasty habit of expanding tabs, inserting unwanted line breaks, etc. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2025178380.514198.1356969323931.javamail.r...@md01.wow.synacor.com
Bug#697017: An improved patch over Jonathan's
On Mon, 31 Dec 2012 12:24:44 -0500 (EST), Gabriel Klawitter wrote: thank you for the efforts to solve the problem. Maybe I missed something, but isn't the case that is to be sorted out (for major/minors) the one that has a colon surrounded by digits (like [0-9]*:[0-9]*) and the case where the root string contains at most 4 hex digits? Why do not match the cases exactly as suggested by your second reply? I'm confused, Gabriel. I don't understand what you are asking. As I see it, root=compute, which is what you are specifying, starts with the letter c, which is a valid hexadecimal digit. Therefore, the parse_numeric function tries to treat the whole string as a hexadecimal number, even though it contains non-valid hex digits, and that causes a syntax error in the shell. The case of the letter doesn't matter. Try the following at a shell prompt: a=$((0x)) echo $a a=$((0x)) echo $a a=$((0xcompute)) The first two assignment statements produce no errors, and the result of the echo command is 65535 in both cases, but the third assignment statement gets a syntax error and the value of the variable a remains unchanged. In bash, I get the error bash: 0xcompute: value too great for base (error token is 0xcompute) In ash, I get ash: arithmetic syntax error in dash, I get dash: 1: arithmetic expression: expecting EOF: 0xcompute The exact error message differs depending on which shell is being used, but an error results in every case. This will cause a script to bomb off. The latest patch proposal fixes this, so that the conversion is not attempted, as well as fixing some other numeric conversion errors that you have not encountered. Have you tried the patch? (You will of course need to rebuild the initial RAM file system after applying the patch.) -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1990132421.519552.1356988082268.javamail.r...@md01.wow.synacor.com
Bug#697017: root=compute fails at parse_numeric() for lilo compatibility
On Sun, 30 Dec 2012 15:58:14 -0500 (EST), Gabriel Klawitter wrote: Package: initramfs-tools Version: 0.109 Dear Maintainer, I'm using your package to set up a netboot environment where I use a script at local-bottom to retrieve a image to extract it into a tmpfs. The kernel command line looks as follows: rw rootfstype=tmpfs root=compute imgurl=http://10.0.0.254/profiles/compute.xz ip=eth0 ipv6.disable=1 This is working in any case when the root= option doesn't start with an hex digit, else parse_numeric tries to parse it as hex value in complete. I don't know why this [A-Fa-f0-9]*) case switch is necessary, but maybe it could be made a little more precise. Unfortunately I don't have a clue how. I'm using Debian GNU/Linux wheezy up to date. Gabriel, I am not one of the Debian package maintainers for the initramfs-tools package, but I am familiar with the LILO boot loader and why that logic is there. I just happened to see this bug report and thought I might attempt an explanation. When the lilo command sees the root file system specified by means of a block special file name, such as root=/dev/sda2 or by means of a symbolic link to a block special file name, such as root=/dev/disk/by-id/... it translates this specification into the kernel major and minor device numbers associated with the device at the time the lilo command is issued. In the above case, this would be major device number 0x08 (used by the SCSI driver) and minor device number 0x02. At boot time, LILO will use this as a specification for the root file system as the concatenation of these two numbers, major number first, with leading zeros suppressed. For example, root=802 This historic behavior of lilo/LILO dates back to the days before udev (and its predecessor, devfs). The idea was that maybe the mknod command for the root file system might be missing from /dev; so using the kernel major and minor device numbers was a way around this. Today, with udev, and especially since the assignment of kernel device numbers and user space device names is no longer predictable, as it once was, the use of a traditional block special file name, or a symbolic link to a block special file name, is no longer recommended. The LILO developers recommend the use of the form root=UUID=xxx or root=LABEL=xxx However, initramfs-tools still has to have logic in it to interpret a string of hexadecimal characters as a major/minor device number specification to accomodate the historic behavior of LILO that will occur if the user specifies a block special file name or a symbolic link to a block special file name. For more information, see my LILO web page: http://users.wowway.com/~zlinuxman/lilo.htm I hope this helps. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/411072193.505516.1356903838328.javamail.r...@md01.wow.synacor.com
Bug#697017: Possible patch for your problem?
Gabriel, I've taken a look at the code in question, /usr/share/initramfs-tools/scripts/functions, in function parse_numeric. The pattern in question, [A-Fa-f0-9]*, will match any string of characters of arbitrary length (at least one character long) whose first character is a valid hex digit (0-9, a-f, or A-F). Remember, this is a shell pattern, not a regular expression. The following pattern will only match a string of from one to four characters in length, inclusive, all of which are valid hex digits. [A-Fa-f0-9] | [A-Fa-f0-9][A-Fa-f0-9] | [A-Fa-f0-9][A-Fa-f0-9][A-Fa-f0-9] |\ [A-Fa-f0-9][A-Fa-f0-9][A-Fa-f0-9][A-Fa-f0-9] (Note the backslash-newline combination at the end of the first line to logically continue the line.) This MAY solve your problem. Note that this suggested change is NOT endorsed by the upstream developer or Debian package maintainer. Use at your own risk. But if you do try it, please report your results. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/303996858.506040.1356906314576.javamail.r...@md01.wow.synacor.com
Bug#689558: Patch now available for bug 689558
I finally got time to look at this. I have found and fixed this bug. A patch is available here: http://users.wowway.com/~zlinuxman/hook-functions.i2o.patch Sorry, I realize that it is customary to include patches in-line in an e-mail; but my e-mail client has the nasty habit of expanding tabs, inserting unwanted line breaks, etc. Therefore, to preserve the patch unaltered, I provided a link instead. I have tested the patch on my system, and it works fine. The patch is applied to /usr/share/initramfs-tools/hook-functions. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1207751320.408091.1356229734536.javamail.r...@md01.wow.synacor.com
Bug#689558: initramfs-tools with MODULES=dep does not work with i2o hardware RAID controller
135198 3 libata,sr_mod,sg usbcore 108302 3 ehci_hcd,uhci_hcd usb_common 12338 1 usbcore Obviously not all of these need to be in the initial RAM file system. When using MODULES=most, everything works fine. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1174598773.259884.1349311362011.javamail.r...@md01.wow.synacor.com
Re: I can't compile kernel with Debian 6.0.4(squeeze) since gold.h
On Fri, 24 Feb 2012 09:53:28 -0500 (EST), peter.meng wrote: HI I'm newbie on Debian . I install Debian 6.0.4(squeeze) on Dell E6410 . I just compile kernel as following step bu met the issue . 1. aptitude install fakeroot kernel-package linux-source-2.6 2. cd /usr/src/linux-source-2.6.32 3. copy /boot/config-2.6.32-5-686 to /usr/src/linux-source-2.6.32/.config 4. fakeroot make-kpkg --initrd --revision=peter1.0 kernel_image WARNING: modpost: Found 2 section mismatch(es). To see full details build your kernel with: 'make CONFIG_DEBUG_SECTION_MISMATCH=y' GEN .version CHK include/linux/compile.h UPD include/linux/compile.h CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 ld: internal error in convert_types, at ../../gold/gold.h:294 make[1]: *** [.tmp_vmlinux1] Error 1 make[1]: Leaving directory `/usr/src/linux-source-2.6.32' make: *** [debian/stamp/build/kernel] Error 2 5. dpkg -l binutils-gold Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Description +++-=-=-== ii binutils-gold 2.20.1-16 The (experimental) GNU gold linker utility Please help me to solve this issue . Best Regards . Peter Meng mengsans...@gmail.com Hello, Peter. I am not on the kernel team and I do not speak for them. I do, however, monitor the debian-kernel mailing list. The kernel team does not support kernel-package. They will no doubt suggest other methods for building a custom kernel, such as make deb-pkg. If you want to use kernel-package (make-kpkg) to build your kernel, I suggest that you look at the following web page: http://users.wowway.com/~zlinuxman/Kernel.htm I myself still use kernel-package, for various reasons which are documented in the above web page. However, I am starting to become concerned about the lack of attention that the upstream author and Debian package maintainer for kernel-package, Manoj Srivastava, has been paying to the package lately. The last upload was an NMU, and an unofficial patch is required to get it to work with Linux Version 3 kernels. Also, kernel-package doesn't work with make 3.82 or later. Unless the package gets some attention soon, I may stop recommending it. Any further communication regarding this issue should be posted to debian-user, since the kernel team does not support kernel-package. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1733626537.566900.1330134799559.javamail.r...@md01.wow.synacor.com
Re: kernel-package for wheezy
On Sun, 29 Jan 2012 17:09:32 -0500 (EST), Ben Hutchings wrote: kernel-package is apparently not compatible with Linux 3.x and I don't believe it can be released with wheezy in this state. You have not uploaded a new version for 18 months. If you do not have time to work on kernel-package, please RFH/RFA/orphan it as appropriate. I don't mean to butt in to a private conversation here, gentlemen, but I too have noticed the problem with kernel-package and Linux 3.x, and I have published an unofficial patch that seems to enable it to work. The patch is available here http://users.wowway.com/~zlinuxman/kernel-package/linuxv3.diff I refer to this patch on my kernel-building web page http://users.wowway.com/~zlinuxman/Kernel.htm As I state in my web page, this is an unofficial patch: it is not provided by, nor endorsed by, the upstream author or the Debian package maintainer for kernel-package (i.e. Manoj). It seems to work for me and for my purposes, but I do not warrant the patch to be free from defects. Take this with as many grains of salt as you think it's worth. P.S. kernel-package is also incompatible with make 3.82 -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1851217686.783815.1327878307221.javamail.r...@md01.wow.synacor.com
Re: Symbolic links to kernel image files and initial RAM file system image files
On Wed, 20 Jul 2011 04:52:59 -0400 (EDT), Ben Hutchings wrote: Boot loaders *should not* maintain symbolic links, since that means duplicating logic (and there are probably cases where multiple boot loaders are installed and they may trip over each other). I agree that if it's going to be done it would be best to do it in one place (i.e. avoid duplicating logic). Hook scripts will just perpetuate the use of the undocumented /etc/kernel-img.conf. Hmm. I don't follow that logic. If symbolic links are maintained in hook scripts, then it makes sense to me that the user would set do_symlinks = no in /etc/kernel-img.conf to avoid duplication of effort. That's what I do. And if do_symlinks is set to no, then the settings for link_in_boot and relative_links become meaningless. And that's one more step in the direction of eliminating /etc/kernel-img.conf. To me, it's similar to setting do_bootloader = no in conjunction with providing boot loader hook scripts. Once boot loader hook scripts are provided, boot loader invocation logic can be eliminated from the kernel image package maintainer scripts, and the value of do_bootloader in /etc/kernel-img.conf can be ignored. Similarly, once symbolic links are maintained in hook scripts, the values of do_symlinks, link_in_boot, and relative_links in /etc/kernel-img.conf can also be ignored, and symbolic link maintenance logic can be eliminated from the kernel image package maintainer scripts. It's almost an exact analogy with boot loader hook scripts to my way of thinking. What I was thinking was that if the hook scripts detect pre-existing symbolic links they will maintain them, and if symbolic links don't currently exist, they won't create them. Here's what I'm currently using on my system. For /etc/kernel/postinst.d I have a hook script called zy-symlinks, available here: http://users.wowway.com/~zlinuxman/kernel/postinst.d/zy-symlinks and for /etc/kernel/postrm.d I have a similar (but not identical) hook script, also called zy-symlinks, available here: http://users.wowway.com/~zlinuxman/kernel/postrm.d/zy-symlinks That gives you some idea of what I had in mind. Note that since the name starts with zy, they will be invoked before any boot loader hook script, which must start with zz. Yet, they will be invoked after any currently-existing hook script other than a boot loader hook script. In particular, they will be invoked after initramfs-tools. That is the order in which it needs to run. I would like to see these 'traditional' boot loaders provide the option to update their configuration automatically. This should be done with the aid of the new 'linux-version' command from linux-base. I guess my working definition of traditional boot loaders means anything other than grub (either version). But keep in mind that on some architectures a traditional boot loader is all that is available. zipl is all there is for s390, for example. That's a nice idea, but there are implementation problems that come to mind. I don't know about zipl, I'll check; but I do know that lilo, for example, is limited to 15-character names in it's labels. The traditional labels, used with the symbolic links, are something like Linux and LinuxOLD, which are well within the 15-character limit. But if one attempts to auto-generate labels based on the name of the kernel, I can easily see a problem with guaranteeing uniqueness while still remaining within the 15-character limit. Also, since each boot loader has its own unique configuration file format, similar logic will need to be invented multiple times. I have been meaning to work on this, but it's just one of a long list of tasks. I didn't start this thread as criticism. As a matter of fact, I am amazed at the prolific productivity of the kernel team. I don't know how you find time to do all that you do. But I didn't want to wait until the last minute to bring up the subject. I want to give whoever needs to make changes plenty of time before the freeze to get things implemented. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1454887986.786413.1311161961069.javamail.r...@md01.wow.synacor.com
Re: Symbolic links to kernel image files and initial RAM file system image files
On Wed, 20 Jul 2011 09:25:37 -0400 (EDT), Ben Hutchings wrote:
On Wed, 2011-07-20 at 07:39 -0400 (EDT), Stephen Powell wrote:
On Wed, 20 Jul 2011 04:52:59 -0400 (EDT), Ben Hutchings wrote:
Hook scripts will just perpetuate the use of the undocumented
/etc/kernel-img.conf.
Hmm. I don't follow that logic. If symbolic links are maintained
in hook scripts, then it makes sense to me that the user would set
do_symlinks = no in /etc/kernel-img.conf to avoid duplication
of effort.
If the hook scripts are in some common package then they would need to
be configured somehow.
I must not understand something. What's to configure? Just drop them
into /etc/kernel/postinst.d and /etc/kernel/postrm.d, respectively,
and you're done. /etc/kernel-img.conf doesn't need to be touched.
You can put something into linux-base, if you want to, that issues
a warning if it finds do_symlinks = yes set in /etc/kernel-img.conf,
as you did in Squeeze for do_bootloader = yes, but you would do that
anyway, I presume, regardless of the solution implemented.
The hook scripts that I have written are boot-loader-independent,
and I presume that any hook scripts that maintain symbolic links
that end up in production will be as well.
I would like to see these 'traditional' boot loaders provide the option
to update their configuration automatically. This should be done with
the aid of the new 'linux-version' command from linux-base.
That's a nice idea, but there are implementation problems
that come to mind. I don't know about zipl, I'll check; but I do know that
lilo, for example, is limited to 15-character names in its labels.
The traditional labels, used with the symbolic links, are something like
Linux and LinuxOLD, which are well within the 15-character limit.
But if one attempts to auto-generate labels based on the name of the
kernel, I can easily see a problem with guaranteeing uniqueness while
still remaining within the 15-character limit.
The version list could then be truncated, e.g.:
#!/bin/bash
generate_entry() {
...
}
{ read new_version; read old_version; } (linux-version list |
linux-version sort --reverse)
[ -z new_version ] || generate_entry Linux $new_version
[ -z old_version ] || generate_entry LinuxOLD $old_version
...
I'm not convinced it's that complicated.
Oh, I get it now. Keep the label names the same as before, but change
the image and initrd values to point directly to file names instead
of symbolic link names. Yes, that would work. I was thinking of
trying to incorporate the kernel name into the label. Something like
2.6.39-2custom1-686-pae is too long.
But that still leaves each boot loader maintainer with the task of
coming up with his own script to automatically generate his boot
loader's configuration file with each kernel installed or removed,
allowing for invariant sections too, of course. This would be the
equivalent of the update-grub command of grub-legacy, except that
something like it would have to be created for each boot loader.
That is more work and it does involve duplication of effort, but it
can probably be done that way.
I'm OK with it either way, but I am not a package maintainer for
any boot loader. I would really like to get some participation in
this thread by boot loader maintainers. They are more of a stake
holder than I am. My interest is simply to see custom kernels
generated by make-kpkg or make deb-pkg work properly in the
Debian environment without users having to write their own hook
scripts to maintain the symbolic links. But since I've already
done that for my own purposes, I have little work to do in the
future, regardless of the implementation chosen. That is not the
case for the boot loader maintainers.
--
.''`. Stephen Powell
: :' :
`. `'`
`-
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/139049450.806101.1311211183164.javamail.r...@md01.wow.synacor.com
Symbolic links to kernel image files and initial RAM file system image files
It's hard to believe that it's been over a year since we discussed this topic. (See http://lists.debian.org/debian-kernel/2010/06/msg01049.html.) Time flies when you're having fun, I guess. ;-) Anyway, back when the boot loader hook script policy was being formulated, shortly before the Squeeze freeze, I brought up the subject of symbolic links to kernel image files and initial RAM file system image files, their maintenance, and their use by boot loader configuration files. This subject is not really addressed in the current hook script policy for boot loaders. Nevertheless, traditional boot loaders, such as lilo and zipl, particularly the way their configuration files are set up by the Debian installer, do use these symbolic links. The last time I checked, the do_symlinks = yes setting in /etc/kernel-img.conf was still honored by the maintainer scripts for official stock Debian kernel image packages; therefore, as long as the user runs only official Debian stock kernel image packages he can keep current by setting do_symlinks = yes in /etc/kernel-img.conf (along with companion options such as link_in_boot and relative_links). However, the last time I checked, do_symlinks = yes in /etc/kernel-img.conf is not honored by the maintainer scripts that are packaged with a kernel image package created by current versions of make-kpkg or make deb-pkg. Consequently, for custom kernel image packages at least, we have a chink in the armor for boot loaders to get out of sync with installed kernel images. Boot loader hook scripts are not currently required to maintain symbolic links, and none of the boot loader hook scripts that I have looked at do so. But neither do the hook scripts provided by these traditional boot loaders edit the configuration file (similar to the update-grub command of grub version 1) to reference the kernel image files and their initial RAM file system image files directly, so that symbolic links are not needed. Thus we have the situation where the boot loader is implicitly assuming that the symbolic links are going to be maintained somehow, someway, and, for custom kernels, no official part of the Debian system is maintaining them. For my own use on my own systems, I have written hook scripts which maintain the symbolic links; and if anyone wants them, they are available for download on my web site. But obviously they are not part of the official Debian system. While we still have plenty of time before the Wheezy freeze, I would like to discuss what, if anything, should be done about this situation. I see several alternatives: o Require boot loader hook scripts to either edit their configuration files or maintain the symbolic links o Provide hook scripts in some other package (base-files? initramfs-tools?) that maintain symbolic links o Eliminate symbolic links entirely and require boot loader hook scripts to edit their configuration files o Bury our heads in the sand and ignore the problem (Obviously I don't care for that last one or I wouldn't have started this thread!) The second option would seem to be the quickest solution, but the quickest solution is not always the best solution. Perhaps there are other alternatives that I haven't thought of. What are your thoughts? P.S. For this initial post I have CC-ed debian-boot and debian-devel, as there may be interested parties on that list that are not subscribed to debian-kernel, but it is my intention that the discussion take place on debian-kernel. So please excuse this initial cross-post. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1702198171.779349.139811090.javamail.r...@md01.wow.synacor.com
Bug#589452: nouveau driver doesn't work with interlaced video modes
Well, I'm afraid I'm going to have to give up my goal of producing a perfectly working fix and just publish what I have so far. I have been able to get a stable interlaced display, but it is only showing the even numbered lines (or the odd numbered lines, depending on whether you start numbering the lines with 0 or 1). I feel certain that there's more work to be done on drivers/gpu/drm/drm_irq.c, but I do not understand the design well enough to be able to make further progress. I hope that a kernel guru can take over from here and make it work correctly. Here is my partial fix: http://users.wowway.com/~zlinuxman/kernel/interlace.diff I used kernel 2.6.38 as my code base. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2122238831.325738.1308792937750.javamail.r...@md01.wow.synacor.com
Bug#589452: nouveau driver doesn't work with interlaced video modes
I originally opened this bug report against xserver-xorg-video-nouveau, but I am reassigning it to the kernel because my research indicates that this is a kernel bug. I have a partial fix which allows a display, but fonts are not rendered correctly. Graphic images seem to display OK though. So far all my changes have been to generic KMS code and are not nouveau-specific. I'd rather wait to publish my fixes until I have everything working correctly. The trouble is I haven't had much time to work on it lately. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/980702584.997790.1307319369503.javamail.r...@md01.wow.synacor.com
Bug#607416: [stable] Device table incorrect for drivers/s390/block/dasd_eckd.c: 3880/3390 should be 3880/3380
On Sun, 24 Apr 2011 19:52:47 -0400 (EDT), Greg KH g...@kroah.com wrote: On Sat, Apr 23, 2011 at 09:10:19AM -0400, Stephen Powell wrote: On Fri, 22 Apr 2011 23:09:50 -0400 (EDT), Jonathan Nieder wrote: If you run git log dd30ac3 --grep='dasd: correct device table', then the fix will show up: commit 5da24b7627ff821e154a3aaecd5d60e1d8e228a5 Author: Stefan Haberland stefan.haberl...@de.ibm.com Date: Thu Feb 17 13:13:55 2011 +0100 [S390] dasd: correct device table The 3880 storage control unit supports a 3380 device type, but not a 3390 device type. Reported-by: Stephen Powell zlinux...@wowway.com Signed-off-by: Stefan Haberland stefan.haberl...@de.ibm.com Signed-off-by: Martin Schwidefsky schwidef...@de.ibm.com ... Presumably that (5da24b76) is the commit to backport; I am not sure which kernels it applies to. Thanks for the information, Jonathan. I'm afraid I don't know much about git, and my ignorance is showing. What I do know how to use is the Linux cross reference at http://lxr.linux.no/+trees, and by using that it appears that this bug, in some form, goes all the way back to day 1. All supported stable kernels will no doubt contain the bug, though the line numbers in the patch may need to be adjusted from one release to the next. It is a very simple one-line change. So, stable, I hereby respectfully request that the above-mentioned bug fix be backported to the supported stable kernel releases. Personally, I am most interested in the 2.6.32 kernel, as that is the basis for Debian Squeeze. Ok, now queued up, thanks. greg k-h Thanks, Greg. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1625182866.141240.1303693000864.javamail.r...@md01.wow.synacor.com
Bug#607416: Device table incorrect for drivers/s390/block/dasd_eckd.c: 3880/3390 should be 3880/3380
On Fri, 22 Apr 2011 23:09:50 -0400 (EDT), Jonathan Nieder wrote: If you run git log dd30ac3 --grep='dasd: correct device table', then the fix will show up: commit 5da24b7627ff821e154a3aaecd5d60e1d8e228a5 Author: Stefan Haberland stefan.haberl...@de.ibm.com Date: Thu Feb 17 13:13:55 2011 +0100 [S390] dasd: correct device table The 3880 storage control unit supports a 3380 device type, but not a 3390 device type. Reported-by: Stephen Powell zlinux...@wowway.com Signed-off-by: Stefan Haberland stefan.haberl...@de.ibm.com Signed-off-by: Martin Schwidefsky schwidef...@de.ibm.com ... Presumably that (5da24b76) is the commit to backport; I am not sure which kernels it applies to. Thanks for the information, Jonathan. I'm afraid I don't know much about git, and my ignorance is showing. What I do know how to use is the Linux cross reference at http://lxr.linux.no/+trees, and by using that it appears that this bug, in some form, goes all the way back to day 1. All supported stable kernels will no doubt contain the bug, though the line numbers in the patch may need to be adjusted from one release to the next. It is a very simple one-line change. So, stable, I hereby respectfully request that the above-mentioned bug fix be backported to the supported stable kernel releases. Personally, I am most interested in the 2.6.32 kernel, as that is the basis for Debian Squeeze. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2113607793.121790.1303564219125.javamail.r...@md01.wow.synacor.com
Bug#607416: Bug #607416: Device table incorrect for drivers/s390/block/dasd_eckd.c: 3880/3390 should be 3880/3380
On Thu, 14 Apr 2011 11:05:37 +0200, Bastian Blank wrote: You know sta...@kernel.org? Use it. Yes, I contacted sta...@kernel.org regarding bug number 550898. But this situation is a little bit different. With 550898, IBM wrote a single git commit to fix a single bug. Asking for that commit to be back-ported was a routine matter. But for bug number 607416 it appears that they didn't do it that way. Thanks to the information provided by Jonathan Nieder, I was able to find the commit for this bug. It is listed below: - commit f85cca6b25971a09efbe4c6a3ae405d40c8f86da Merge: 6f576d5 dd30ac3 Author: Linus Torvalds torva...@linux-foundation.org Date: Mon Feb 21 14:55:49 2011 -0800 Merge branch 'for-linus' of git://git390.marist.edu/pub/scm/linux-2.6 * 'for-linus' of git://git390.marist.edu/pub/scm/linux-2.6: [S390] net: provide architecture specific NET_SKB_PAD [S390] atomic: use inline asm [S390] correct ipl parameter block safe guard [S390] atomic: use ACCESS_ONCE() for atomic_read() [S390] dasd: correct device table - As far as I can tell, only the last line is applicable to this bug. [S390] dasd: correct device table In other words, instead of producing a single fix for a single bug, they threw the fix in with several other miscellaneous fixes and enhancements. I wish IBM hadn't done it that way, but they did. Therefore, I am unsure as to how to proceed. Do I ask sta...@kernel.org to port the whole commit? (It may have dependencies on previous commits and get complicated rather quickly.) Or do I ask them to cherry pick that one-line change in drivers/s390/block/dasd_eckd.c? I could use some advice here. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/345969826.117662.1303525222133.javamail.r...@md01.wow.synacor.com
Bug#622570: [OOPS s390] Unable to handle kernel pointer dereference at virtual kernel address (null)
On Mon, 18 Apr 2011 07:51:41 -0400 (EDT), Heiko Carstens wrote:
That's a bug in the pfault interrupt code. After a cleanup patch which
simplified lowcore accesses we are left with a dereference which shouldn't
be there. The patch below should fix it.
The bug was introduced with 2.6.37-rc1.
diff --git a/arch/s390/mm/fault.c b/arch/s390/mm/fault.c
index 9217e33..4cf85fe 100644
--- a/arch/s390/mm/fault.c
+++ b/arch/s390/mm/fault.c
@@ -558,9 +558,9 @@ static void pfault_interrupt(unsigned int ext_int_code,
* Get the token (= address of the task structure of the affected task).
*/
#ifdef CONFIG_64BIT
- tsk = *(struct task_struct **) param64;
+ tsk = (struct task_struct *) param64;
#else
- tsk = *(struct task_struct **) param32;
+ tsk = (struct task_struct *) param32;
#endif
if (subcode 0x0080) {
I applied the above patch and re-built the kernel. I did not apply
Jan Glauber's suggested patch, since Heiko's suggested patch seemed to be a
direct hit. I have had the server up for more than 24 hours now,
which is definitely a good sign. Without this patch, I've not been able
to keep a 2.6.38 s390x kernel up for more than a few hours. Unfortunately,
since I can't reproduce the problem on demand, I cannot say with 100%
certainty that the problem is fixed, but it looks good and makes sense.
--
.''`. Stephen Powell
: :' :
`. `'`
`-
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/248142179.74791.1303353294865.javamail.r...@md01.wow.synacor.com
Bug#622570: [OOPS s390] Unable to handle kernel pointer dereference at virtual kernel address (null)
On Tue, 19 Apr 2011 02:34:01 -0400 (EDT), Heiko Carstens wrote:
Stephen Powell wrote:
I installed linux-image-2.6.38-2-s390x version 2.6.38-3 on my up-to-date
Wheezy
system today. It runs in a virtual machine under z/VM 5.4.0 running in an
LPAR
on an IBM z/890. It IPLed just fine. After the IPL, the system fell idle
for a while.
Then a CRON job kicked off, which caused a page fault, which caused a kernel
oops.
Here is the log:
...
Ok, I was able to reproduce it and could verify that my patch fixes the bug.
Thanks for reporting! The patch below will go upstream:
Great! That's confirming evidence! Thanks Heiko, Jonathan, Jan, and all others
who contributed.
Subject: [S390] pfault: fix token handling
From: Heiko Carstens heiko.carst...@de.ibm.com
f6649a7e [S390] cleanup lowcore access from external interrupts changed
handling of external interrupts. Instead of letting the external interrupt
handlers accessing the per cpu lowcore the entry code of the kernel reads
already all fields that are necessary and passes them to the handlers.
The pfault interrupt handler was incorrectly converted. It tries to
dereference a value which used to be a pointer to a lowcore field. After
the conversion however it is not anymore the pointer to the field but its
content. So instead of a dereference only a cast is needed to get the
task pointer that caused the pfault.
Fixes a NULL pointer dereference and a subsequent kernel crash:
Unable to handle kernel pointer dereference at virtual kernel address (null)
Oops: 0004 [#1] SMP
Modules linked in: nfsd exportfs nfs lockd fscache nfs_acl auth_rpcgss sunrpc
loop qeth_l3 qeth vmur ccwgroup ext3 jbd mbcache dm_mod
dasd_eckd_mod dasd_diag_mod dasd_mod
CPU: 0 Not tainted 2.6.38-2-s390x #1
Process cron (pid: 1106, task: 1f962f78, ksp: 1fa0f9d0)
Krnl PSW : 040420018000 0002c03e (pfault_interrupt+0xa2/0x138)
R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:0 CC:2 PM:0 EA:3
Krnl GPRS: 0001 0001
1f962f78 00518968 9002 1ff03280
0064f000 1f962f78 2603
06002603 1ff7fe68 1ff7fe48
Krnl Code: 0002c036: 5820d010l %r2,16(%r13)
0002c03a: 1832lr %r3,%r2
0002c03c: 1a31ar %r3,%r1
0002c03e: ba23d010cs %r2,%r3,16(%r13)
0002c042: a744fffcbrc 4,2c03a
0002c046: a7290002lghi%r2,2
0002c04a: e320d024stg %r2,0(%r13)
0002c050: 07f0bcr 15,%r0
Call Trace:
([1f962f78] 0x1f962f78)
[0001acda] do_extint+0xf6/0x138
[0039b6ca] ext_no_vtime+0x30/0x34
[7d706e04] 0x7d706e04
Last Breaking-Event-Address:
[] 0x0
For stable maintainers:
the first kernel which contains this bug is 2.6.37.
Reported-by: Stephen Powell zlinux...@wowway.com
Cc: Jonathan Nieder jrnie...@gmail.com
Cc: sta...@kernel.org
Signed-off-by: Heiko Carstens heiko.carst...@de.ibm.com
---
arch/s390/mm/fault.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/s390/mm/fault.c b/arch/s390/mm/fault.c
index 9217e33..4cf85fe 100644
--- a/arch/s390/mm/fault.c
+++ b/arch/s390/mm/fault.c
@@ -558,9 +558,9 @@ static void pfault_interrupt(unsigned int ext_int_code,
* Get the token (= address of the task structure of the affected task).
*/
#ifdef CONFIG_64BIT
- tsk = *(struct task_struct **) param64;
+ tsk = (struct task_struct *) param64;
#else
- tsk = *(struct task_struct **) param32;
+ tsk = (struct task_struct *) param32;
#endif
if (subcode 0x0080) {
--
.''`. Stephen Powell
: :' :
`. `'`
`-
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/2008017174.74978.1303353953675.javamail.r...@md01.wow.synacor.com
Bug#622570: linux-image-2.6.38-2-s390x: Unable to handle kernel pointer dereference at virtual kernel address (null)
On Thu, 14 Apr 2011 21:48:56 -0400 (EDT), Stephen Powell wrote: The problem appears to be fixed in the latest vanilla upstream kernel source, which at the time of this writing is 2.6.39-rc3. ... Oops! I spoke too soon. I checked the server before I went to bed last night, and it was still up at that time; but when I got up this morning I checked it again, and it had crashed during the night with the same protection exception at the same offset in the same function. That's the trouble with these kind of bugs. The problem can't be reproduced on demand; so one can never say with 100% certainty that the bug is fixed. One can say for sure that it isn't fixed, if the oops occurs, but one can never say for sure that it works. Anyway, I guess it's time to bisect the kernel. Oh joy. This will take a while. It does appear to be an s390-specific bug. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2099315211.286690.1302917498637.javamail.r...@md01.wow.synacor.com
Bug#622570: linux-image-2.6.38-2-s390x: Unable to handle kernel pointer dereference at virtual kernel address (null).
On Wed, 13 Apr 2011 04:55:00 -0400 (EDT), Jonathan Nieder wrote: ... If you find time, could you try the latest (or close to the latest) upstream version, following the instructions from here? ... The problem appears to be fixed in the latest vanilla upstream kernel source, which at the time of this writing is 2.6.39-rc3. I don't know which git commit contained the fix, but the server has been running for several hours, with no other load than the hourly cron jobs; so it is reasonable to assume that a number of page faults have occurred and have been successfully handled. I will run the upstream vanilla kernel source until a Debian package containing the fix is available. Thanks, Jonathan. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1600830032.261998.1302832136085.javamail.r...@md01.wow.synacor.com
Bug#607416: Device table incorrect for drivers/s390/block/dasd_eckd.c: 3880/3390 should be 3880/3380
I can confirm that the problem reported in this bug report has been fixed in linux-source-2.6.38 version 2.6.38-3 (and in binaries derived from that source). Perhaps it was fixed in earlier versions as well; but this is the first version I have tried in which it works. /sbin/modinfo dasd_eckd_mod will confirm the fix. Notice that control unit 3880 is associated with device 3380 in the alias, not device 3390, as is the case for the broken version. I don't know what git commit is associated with this fix, but whatever it is it is present in version 2.6.38-3. See companion bug number 620126 in package sysconfig-hardware for the same bug in another package. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/200411640.232817.1302737655590.javamail.r...@md01.wow.synacor.com
Bug#622570: linux-image-2.6.38-2-s390x: Unable to handle kernel pointer dereference at virtual kernel address (null).
Package: linux-2.6 Version: 2.6.38-3 Severity: important I installed linux-image-2.6.38-2-s390x version 2.6.38-3 on my up-to-date Wheezy system today. It runs in a virtual machine under z/VM 5.4.0 running in an LPAR on an IBM z/890. It IPLed just fine. After the IPL, the system fell idle for a while. Then a CRON job kicked off, which caused a page fault, which caused a kernel oops. Here is the log: [ 2697.934752] Unable to handle kernel pointer dereference at virtual kernel address (null) [ 2697.982153] Oops: 0004 [#1] SMP [ 2698.001730] Modules linked in: nfsd exportfs nfs lockd fscache nfs_acl auth_rpcgss sunrpc loop qeth_l3 qeth vmur ccwgroup ext3 jbd mbcache dm_mod dasd_eckd_mod dasd_diag_mod dasd_mod [ 2698.003407] CPU: 0 Not tainted 2.6.38-2-s390x #1 [ 2698.003430] Process cron (pid: 1106, task: 1f962f78, ksp: 1fa0f9d0) [ 2698.003455] Krnl PSW : 040420018000 0002c03e (pfault_interrupt+0xa2/0x138) [ 2698.021870]R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:0 CC:2 PM:0 EA:3 [ 2698.021902] Krnl GPRS: 0001 0001 [ 2698.021943]1f962f78 00518968 9002 1ff03280 [ 2698.021979] 0064f000 1f962f78 2603 [ 2698.022016]06002603 1ff7fe68 1ff7fe48 [ 2698.022096] Krnl Code: 0002c036: 5820d010l %r2,16(%r13) [ 2698.051390]0002c03a: 1832lr %r3,%r2 [ 2698.051407]0002c03c: 1a31ar %r3,%r1 [ 2698.051430] 0002c03e: ba23d010cs %r2,%r3,16(%r13) [ 2698.051448]0002c042: a744fffcbrc 4,2c03a [ 2698.051466]0002c046: a7290002lghi%r2,2 [ 2698.051486]0002c04a: e320d024stg %r2,0(%r13) [ 2698.051502]0002c050: 07f0bcr 15,%r0 [ 2698.051514] Call Trace: [ 2698.051521] ([1f962f78] 0x1f962f78) [ 2698.051537] [0001acda] do_extint+0xf6/0x138 [ 2698.051555] [0039b6ca] ext_no_vtime+0x30/0x34 [ 2698.052373] [7d706e04] 0x7d706e04 [ 2698.052387] Last Breaking-Event-Address: [ 2698.052395] [] 0x0 [ 2698.052406] [ 2698.053263] Kernel panic - not syncing: Fatal exception in interrupt [ 2698.053316] CPU: 0 Tainted: G D 2.6.38-2-s390x #1 [ 2698.053502] Process cron (pid: 1106, task: 1f962f78, ksp: 1fa0f9d0) [ 2698.053516] 1ff7fa70 0002 [ 2698.053539]1ff7fb10 1ff7fa88 1ff7fa88 00397b9e [ 2698.053576]0001 1ff03280 [ 2698.053623]0008 000e 0078 [ 2698.053674]1ff7faf0 00011b36 1ff7fa70 1ff7fab8 [ 2698.053740] Call Trace: [ 2698.053762] ([00011a60] show_trace+0x5c/0xa4) [ 2698.053801] [003979de] panic+0x9e/0x214 [ 2698.054443] [00012046] die+0x15e/0x170 [ 2698.054485] [0002c5d6] do_no_context+0xd6/0xe0 [ 2698.054529] [0002cd52] do_protection_exception+0x46/0x2a0 [ 2698.054577] [0039b208] pgm_exit+0x0/0x4 [ 2698.054627] [0002c03e] pfault_interrupt+0xa2/0x138 [ 2698.054679] ([1f962f78] 0x1f962f78) [ 2698.056408] [0001acda] do_extint+0xf6/0x138 [ 2698.056424] [0039b6ca] ext_no_vtime+0x30/0x34 [ 2698.056439] [7d706e04] 0x7d706e04 HCPGIR450W CP entered; disabled wait PSW 00020001 8000 0001DE26 I have backed out to a 2.6.32 kernel until the problem is resolved. The 2.6.38 kernel is obviously unusable for me. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/968077117.213426.1302662030653.javamail.r...@md01.wow.synacor.com
Bug#607416: Device table incorrect for drivers/s390/block/dasd_eckd.c: 3880/3390 should be 3880/3380
On Mon, 27 Dec 2010 10:43:45 +0100, Christian Borntraeger wrote: Stephen, thanks for your report. I forwarded your report to our DASD developers to handle the report. Christian PS: For bug reports or patches you can also include linux-s...@vger.kernel.org most of our developers are subscribed to that list. Well, it's been about a month and a half, and I have seen no activity, and this is a very simple fix; so I thought I would post directly to linux-s...@vger.kernel.org to see if I can generate some activity. The details of this bug report can be found at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607416 -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/955743419.776849.1297563007891.javamail.r...@md01.wow.synacor.com
Bug#607416: Device table incorrect for drivers/s390/block/dasd_eckd.c: 3880/3390 should be 3880/3380
On Sat, 18 Dec 2010 19:59:00 -0500 (EST), Stephen Powell wrote: This is a bug report for drivers/s390/block/dasd_eckd.c in the Linux kernel source code. The device table indicates that a combination of a 3880 storage control unit and a 3390 DASD device type is valid. This is incorrect. A 3880 storage control unit cannot support a 3390 device type. However, it can support a 3380 device type, and that is not present in the table. In case anybody cares but doesn't know, the authoritative reference on this subject is the following IBM publication: IBM 3880 Storage Control Models 1, 2, 3, and 4 Reference Manual (Publication Number GA26-1661) I happen to have a (hard) copy of this manual, the -6 version dated April, 1983. IBM didn't publish soft-copy documentation back then, only hard copy. Nevertheless, I was able to find a soft-copy version on the internet. Someone took his hard-copy version, ran it page-by-page through a scanner, and converted the results to a PDF file. This copy is a newer revision, the -9 version, dated September, 1987. See http://www.bitsavers.org/pdf/ibm/dasd look for the link titled GA26-1661-9_3880_StorageCtrlDescr_Sep87.pdf single right click on it and select Save Target as from the pop-up menu to download it. Open it with whatever you normally use to open a PDF file. Of course, you can't search it for text, since the whole manual is a collection of images, due to the way it was created. You won't get very far into the document before you will find a list of devices supported by the control unit. A 3390 is not one of them. But a 3380 is. The only other device supported by the Linux kernel that the 3880 Storage Control unit supports is a 3370, which is an FBA device. It is (correctly) listed in the device table in drivers/s390/block/dasd_fba.c. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1299807564.1267414.1293152554487.javamail.r...@md01.wow.synacor.com
Bug#607416: Device table incorrect for drivers/s390/block/dasd_eckd.c: 3880/3390 should be 3880/3380
Hello upstream, This is a bug report for drivers/s390/block/dasd_eckd.c in the Linux kernel source code. The device table indicates that a combination of a 3880 storage control unit and a 3390 DASD device type is valid. This is incorrect. A 3880 storage control unit cannot support a 3390 device type. However, it can support a 3380 device type, and that is not present in the table. See Debian bug report number 607416 for details. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607416 I have made the one-line change indicated in the bug report and created a custom kernel, which runs with no apparent ill effects. However, you might want to look things over to see if anything needs to be changed in the code logic as well. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1841269051.1165093.1292720340853.javamail.r...@md01.wow.synacor.com
Bug#607416: Device table incorrect for drivers/s390/block/dasd_eckd.c: 3880/3390 should be 3880/3380. (s390/s390x only)
Package: linux-2.6
Version: 2.6.32-29
The device table in drivers/s390/block/dasd_eckd.c which indicates which
storage control unit and dasd device type combinations are supported by
the driver is incorrect. The device table indicates that a combination
of 3880 for a control unit and 3390 for a device type is supported. That
is incorrect. A 3880 storage control unit will support a 3380 device
type, but not a 3390 device type. Here is a code excerpt:
static struct ccw_device_id dasd_eckd_ids[] = {
{ CCW_DEVICE_DEVTYPE (0x3990, 0, 0x3390, 0), .driver_info = 0x1},
{ CCW_DEVICE_DEVTYPE (0x2105, 0, 0x3390, 0), .driver_info = 0x2},
{ CCW_DEVICE_DEVTYPE (0x3880, 0, 0x3390, 0), .driver_info = 0x3}, /*
bad one! */
{ CCW_DEVICE_DEVTYPE (0x3990, 0, 0x3380, 0), .driver_info = 0x4},
{ CCW_DEVICE_DEVTYPE (0x2105, 0, 0x3380, 0), .driver_info = 0x5},
{ CCW_DEVICE_DEVTYPE (0x9343, 0, 0x9345, 0), .driver_info = 0x6},
{ CCW_DEVICE_DEVTYPE (0x2107, 0, 0x3390, 0), .driver_info = 0x7},
{ CCW_DEVICE_DEVTYPE (0x2107, 0, 0x3380, 0), .driver_info = 0x8},
{ CCW_DEVICE_DEVTYPE (0x1750, 0, 0x3390, 0), .driver_info = 0x9},
{ CCW_DEVICE_DEVTYPE (0x1750, 0, 0x3380, 0), .driver_info = 0xa},
{ /* end of list */ },
};
The bad line should be changed to
{ CCW_DEVICE_DEVTYPE (0x3880, 0, 0x3380, 0), .driver_info = 0x3}, /*
corrected */
Other supporting code in the driver may also need to be changed, I don't know.
But I do know that a 3880 storage control unit does not support a 3390 device.
It does support a 3380 device, but that is missing from the table.
This is clearly an issue to be pursued upstream, it is not an issue of
Debian packaging. But I opened this bug report to have a place to
put upstream correspondence related to this bug. I will pursue the matter
with upstream, as I did the last kernel bug that I opened.
This is not a release-critical bug and should not delay the process of
making squeeze the stable release. However, it would be nice if the fix
for this bug eventually made it into a future stable point release.
--
.''`. Stephen Powell
: :' :
`. `'`
`-
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/1201615255.1150826.1292643537606.javamail.r...@md01.wow.synacor.com
Bug#606806: initramfs-tools: Handling of numeric root= arguments is not udev-friendly
On Mon, 13 Dec 2010 03:31:44 -0500 (EST), H. R. Oberhage wrote: This is also the answer to you question what I use 'it' for, namely simply LILO. As I suspected. First of all, as Ben is well aware, I am not a maintainer for initramfs-tools, udev, or any other Debian package. I'm just a fellow lilo user, and therefore, an interested party. The translation of a root specification from user-space notation (root=/dev/whatever) to kernel-space notation (root=, where is a three- or four-digit hexadecimal number representing the major and minor number of the device) is something that lilo has always done. There is nothing new here. Adding udev to the mix is what has complicated things. There may be other boot loaders which do the same thing. I also am opposed to deprecating the ability of initramfs-tools to handle a hexadecimal numeric root specification. While the powers that be figure out how best to handle this type of root specification, I would like to call your attention to a work-around for the problem that will get you up and running in the meantime: use a UUID specification. For example, on my system I use ... boot=/dev/disk/by-uuid/055d446a-977d-4aa6-877d-62c716f5e85a ... root=UUID=055d446a-977d-4aa6-877d-62c716f5e85a in /etc/lilo.conf. In this example, the lilo stage 1 boot loader is installed in the boot sector of a primary partition, which is also the root partition. (It happens to correspond to /dev/sda2 on my system.) Note that boot must be a block special device or a symbolic link to a block special device, as above, but root can be a quoted UUID specification, as supported by /etc/fstab. When the root device is specified this way, lilo does not do any translation. The kernel command line sees ... root=UUID=055d446a-977d-4aa6-877d-62c716f5e85a ... which gets you around the problem for now. Respectfully submitted, -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2056035689.1026734.1292241127784.javamail.r...@md01.wow.synacor.com
Bug#606806: initramfs-tools: Handling of numeric root= arguments is not udev-friendly
On Sat, 11 Dec 2010 16:34:56 -0500 (EST), Ben Hutchings wrote: On Sat, 2010-12-11 at 13:14 -0800, Evan Broder wrote: If you pass a root= argument with a numeric device number (i.e. root=0806), that's currently resolved by running mknod to create a /dev/root device with an appropriate major/minor number and setting ROOT=/dev/root (the parse_numeric function in scripts/functions). Maybe this feature should simply be deprecated. What do you use it for? Pardon me for butting in here, gentlemen, but I think I know the answer to Ben's question. This is done by a number of boot loaders. I know lilo does it, and I think zipl (part of s390-tools) does it also. If, for example, in /etc/lilo.conf one identifies the root device as root=/dev/sda6 then lilo's map installer converts this specification into a four-digit hexadecimal number, where the first two hex digits are the major number of the device and the last two hex digits are the minor number of the device. Thus, /dev/sda6 becomes 0806, meaning the device with major number 8 and minor number 6. At boot time, lilo passes a kernel command line to the kernel that says ... root=806 ... (the leading zero is suppressed). Chances are, the user is not directly specifying the root device as a hexadecimal number anywhere. The boot loader makes this substitution. lilo has done this forever, and zipl was patterned after lilo. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2011415305.1003437.1292106009163.javamail.r...@md01.wow.synacor.com
Bug#594189: initramfs-tools: environment variable to disable run_bootloader
On Tue, 24 Aug 2010 10:55:43 -0400 (EDT), Michael Prokop m...@debian.org wrote: Jepp. But isn't this (possibility for user configuration) exactly what Colin is requesting? I'm for example shipping lilo and grub with the live system (so the binaries as well as its documentation is available to the user), but nowadays the build process fails due to errors like: run-parts: /etc/initramfs/post-update.d//lilo exited with return code 1 [...] run-parts: /etc/kernel/postinst.d/zz-lilo exited with return code 1 So the IMHO open question is what's a proper way to disable such stuff on request? I am not a member of the kernel team. I'm just an ordinary user. So I speak with zero authority. And Ben may have his own ideas that he wishes to share. But one way to prevent a hook script from executing is to remove its executable attribute. For example, chmod -x /etc/kernel/postinst.d/zz-lilo chmod -x /etc/kernel/postrm.d/zz-lilo chmod -x /etc/initramfs/post-update.d/lilo This is not supported, of course, nor is it recommended. But it will work. As a general rule I agree with Ben. If you don't want the hook scripts to run, don't install the package. But in special situations, such as where you want the man page installed for reference purposes but don't want the package to be used, this is one solution. I have used this technique to run my own hook scripts instead of the package hook scripts without changing the package hook scripts when the package hook scripts are buggy or incomplete. (But of course I open a bug report against the package too.) -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2024030366.328076.1282663119633.javamail.r...@md01.wow.synacor.com
Bug#594189: initramfs-tools: environment variable to disable run_bootloader
On Tue, 24 Aug 2010 11:08:47 -0400 (EDT), Ben Hutchings wrote: Report a bug on lilo; I suppose it should warn but still 'succeed' if /etc/lilo.conf is missing. elilo should do the same. This is my bug and I can fix it. :-) No idea about zipl but I doubt you care about s390 live media. The last time I checked, the official version of lilo in both squeeze and sid still did not include any hook scripts. Joachim Wiedorn's latest upstream version, 23.0, does include hook scripts; but Joachim is not the Debian package maintainer for lilo, William Pitcock still is. And William's official version does not include the hook scripts. Therefore, opening a Debian bug report against Joachim's unofficial Debian package is not appropriate. I do hope that the Technical Committee eventually gives control of the package to Joachim, but as far as I know, no decision has yet been made. (See bug number 587886.) -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/398211408.328559.1282663787782.javamail.r...@md01.wow.synacor.com
Bug#594189: initramfs-tools: environment variable to disable run_bootloader
On Tue, 24 Aug 2010 11:29:46 -0400 (EDT), Michael Prokop wrote: I'm aware of this, though I'd prefer a clean interface and not hacks. :) Especially since I'm not aware of a way how to chmod -x the files before installing the packages that fail during installation then. ;) I haven't been following the thread; so I don't know precisely what installation problem you are having. But Joachim's version of lilo does contain a bashism in it's initramfs hook which may be the cause of the installation failure. It uses substring expansion, which works with the Bourne Again Shell (bash), but not with the Bourne Shell or clones thereof (dash, ash, etc.). This is partly my fault, since his initramfs hook is based on a template which I provided which has the same problem. I have reported the problem to him, but so far I have not received a reply. If this is the cause of the installation failure, temporarily change the symlink /bin/sh to point to bash instead of dash. This will allow the package to install. Then, change #!/bin/sh on line 1 of /etc/initramfs/post-update.d/lilo to #!/bin/bash and change your symlink /bin/sh to point back to dash, or whatever it used to be pointing to. But maybe this is not why you are having installation problems. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/531310898.329182.1282664833095.javamail.r...@md01.wow.synacor.com
Bug#594189: initramfs-tools: environment variable to disable run_bootloader
On Tue, 24 Aug 2010 11:37:29 -0400 (EDT), Michael Prokop wrote: , [ aptitude changelog lilo/unstable | head ] | Get: Changelog of lilo | lilo (1:22.8-8.2) unstable; urgency=high | | * Non-maintainer upload. | * Add kernel and initramfs hook scripts to ensure lilo is reinstalled | whenever the kernel or initramfs is updated. (Closes: #590022) | | -- Ben Hutchings b...@decadent.org.uk Tue, 24 Aug 2010 04:25:24 +0100 | | lilo (1:22.8-8.1) unstable; urgency=low ` Aha! Nice work, Ben. I didn't check far enough. I used this link http://packages.debian.org/search?keywords=lilosearchon=namessuite=unstablesection=all and saw that the current version was still 1:22.8-8.1. Either the package hasn't been uploaded yet or the web page is not in sync with the repository. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1917756674.329474.1282665282267.javamail.r...@md01.wow.synacor.com
Bug#582281: Bug fix confirmation
I see that this bug has already been marked resolved, but I just wanted to confirm that the backport of the upstream fix for this bug to kernel 2.6.32, which was originally written for a 2.6.35 kernel, does indeed fix the problem. I don't know if upstream backported the fix to 2.6.32 or if the Debian kernel team wrote their own patch, but package linux-source-2.6.32 version 2.6.32-20 does show the change to fs/partitions/ibm.c, and running a test case using stock kernel package linux-image-2.6.32-5-s390x version 2.6.32-20 shows that the problem has been fixed. Nice work, kernel team! Thanks! I can go back to running stock kernel images again instead of custom builds with custom patches. And thanks to upstream too! Peter, Moritz, Ben, thank you all. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1071420156.334874.1282675859457.javamail.r...@md01.wow.synacor.com
Re: [DRAFT v2] Policy for Linux kernel, initramfs, boot loader update process
On Fri, 06 Aug 2010 02:20:53 -0400 (EDT), Guillem Jover wrote: This should probably be 'eval set -- $DEB_MAINT_PARAMS' instead, or the single quotes will not be stripped, neither any possible spaces will be correctly preserved. This is what my template scripts do. I got that logic originally from a template script in kernel-package It seems from my system at least grub2 will need fixing. I wasn't aware that grub2 used -- or needed -- any hook scripts. grub1, yes; but not grub2. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/229089153.218736.1281100278973.javamail.r...@md01.wow.synacor.com
Bug#582281: Upstream fix
On Wed, 04 Aug 2010 04:43:50 -0400 (EDT), Peter Oberparleiter wrote: Note that is the shift right operator in C and that shifting an integer 9 positions to the right is the same as a division by 512. I used the operator for consistency with the remaining function. Aha! Now it makes sense. I see I still have much more to learn about C. ;-) And thank you for being so gracious about explaining it without making fun of my C ignorance, which would have been very easy for you to do. I left myself wide open. I am satisfied with the fix. Thank you, Peter. Currently, the newest Debian kernel available (in experimental) is 2.6.35~rc6-1~experimental.1, so I trust it won't be too long until a kernel with this fix applied gets uploaded. Debian kernel team: please leave this Debian bug report open until an official Debian kernel with this fix included has been uploaded to the Debian archive. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/497358035.165440.1280929170923.javamail.r...@md01.wow.synacor.com
Bug#582281: Upstream fix
On Tue, 20 Jul 2010 09:55:58 -0400 (EDT), Peter Oberparleiter wrote: A fix for this problem has been accepted for inclusion into 2.6.35-rc5. See: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=cffab6bc5511cd6f67a60bf16b62de4267b68c4c Hello, Peter. I finally got a chance to take a look at this today. I can't apply the patch as written to my 2.6.32 source code due to changes between 2.6.32 and 2.6.35 that will cause the patch to not apply. However, I did look at the patch. While I confess to being a complete novice in the C language, the patch doesn't look quite right to me. Consider the following excerpt from the patch: + if ((info-cu_type == 0x6310 info-dev_type == 0x9336) || + (info-cu_type == 0x3880 info-dev_type == 0x3370)) + labelsect = info-label_block; + else + labelsect = info-label_block * (blocksize 9); This is unexpected. I expected that last line to be + labelsect = info-label_block * (blocksize/512) My concern is not for FBA DASD. I expect your code to execute correctly for FBA DASD. My concern is that it will break for CKD DASD. Are you sure that this is correct? Did you test the fix for CKD DASD as well as FBA DASD? Respectfully submitted. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/985995703.149130.1280864598758.javamail.r...@md01.wow.synacor.com
Bug#582281: Upstream fix
On Tue, 20 Jul 2010 09:55:58 -0400 (EDT), Peter Oberparleiter wrote: A fix for this problem has been accepted for inclusion into 2.6.35-rc5. See: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=cffab6bc5511cd6f67a60bf16b62de4267b68c4c Thanks, Peter. I'm really busy right now, but I'll try to test this sometime in the next few weeks. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1006577487.39581.1279823196854.javamail.r...@md01.wow.synacor.com
Bug#588770: initramfs-tools: modules=dep in initramfs.conf breaks suspend-to-disk
On Mon, 12 Jul 2010 01:56:04 -0400 (EDT), Matthias Berndt wrote: i just noticed using modules=dep instead of modules=most breaks suspend-to-disk for me. My swap partition lies on a PATA disk while my root file system lies on a SATA disk, so the needed PATA drivers aren't loaded and thus the device file for the swap partition doesn't exist. Perhaps there should be a resume hook script that checks for this condition? I am not one of the maintainers for initramfs-tools, just a user who happened to notice this bug report. But as a temporary circumvention, you may be able to work around this problem by listing the extra modules you need in /etc/initramfs-tools/modules. I was able to circumvent a similar problem by doing this. (See bug report 588452.) -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/32724179.121188.1278941254175.javamail.r...@md01.wow.synacor.com
Bug#588452: softdep modules not included in initramfs when MODULES=dep is specified
Package: initramfs-tools Version: 0.97 softdep modules are not included in the initial RAM file system when MODULES=dep is specified. Here's an example from the s390 architecture: /etc/modprobe.d/dasd.conf: options dasd_mod dasd=0.0.0200(diag),0.0.0201,0.0.0202-0.0.0203(diag) softdep dasd_eckd_mod pre: dasd_diag_mod softdep dasd_fba_mod pre: dasd_diag_mod (/etc/modprobe.conf does *not* exist) /etc/initramfs-tools/conf.d/driver-policy: MODULES=dep /etc/initramfs-tools/modules: (dasd_diag_mod is *not* listed) dasd_eckd_mod is included in the initial RAM file system. I assume that that is due to matching on the alias ccw:t3990m*dt3390dm*. dasd_mod is also included in the initial RAM file system. I presume that that is due to the fact that dasd_mod is a hard dependency of dasd_eckd_mod. But dasd_diag_mod is *not* included in the initial RAM file system, even though it is listed as a soft dependency of dasd_eckd_mod, which has already been selected for inclusion. On the system above, this prevents the system from booting, as the devices marked for use with the diag driver, including the root file system in this case, cannot be brought online. Therefore, the permanent root file system cannot be mounted. I am able to circumvent the problem by explicitly listing dasd_diag_mod in /etc/initramfs-tools/modules, but this should not be necessary. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/922649436.38679.1278600800110.javamail.r...@md01.wow.synacor.com
Bug#588452: softdep modules not included in initramfs when MODULES=dep is specified
On Thu, 08 Jul 2010 12:03:39 -0400 (EDT), Michael Prokop wrote:
For MODULES=dep we use modprobe as interface to detect dependencies.
To display the dependencies of dasd_eckd_mod you could run:
modprobe --set-version=$(uname -r) --ignore-install --quiet --show-depends
dasd_eckd_mod | awk '/^insmod/ { print $2 }'
which will not list dasd_diag_mod as a dependency AFAICS.
Output of the above command on my system:
/lib/modules/2.6.32-custom5b-s390x/kernel/drivers/s390/block/dasd_mod.ko
/lib/modules/2.6.32-custom5b-s390x/kernel/drivers/s390/block/dasd_eckd_mod.ko
In other words, it list only the module itself plus hard dependencies.
--
.''`. Stephen Powell
: :' :
`. `'`
`-
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/1294535410.43811.1278611163548.javamail.r...@md01.wow.synacor.com
Re: Proposed changes to initramfs-tools hook scripts
On Thu, 08 Jul 2010 09:24:02 -0400 (EDT), maximilian attems wrote: so mika reviewed http://git.debian.org/?p=kernel/initramfs-tools.git;a=shortlog;h=refs/heads/maks/hooks he critisize the exit 0 without any stdout/stderr message. so rethinking why do you want that anyway? I do not see the point of it, update-initramfs is already told to not care if that initramfs exists with the takeover flag so will not errexit. You're right. With the -t flag, attempting to delete a non-existent initial RAM file system does not cause an error exit. Exit status is zero, even if the file does not exist. The exit 0 is unnecessary. Good catch, Mika! -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1884856145.37359.1278598343367.javamail.r...@md01.wow.synacor.com
Re: [DRAFT v2] Policy for Linux kernel, initramfs, boot loader update process
On Sun, 04 Jul 2010 13:48:20 -0400 (EDT), Ben Hutchings wrote: 0. The arguments given to all kernel hook scripts are the kernel ABI version (the string that uname -r reports) and, optionally, the absolute path to the kernel image. If the second argument is missing then the path is either /boot/vmlinuz-$version or /boot/vmlinux-$version, according to architecture convention. Pardon my ignorance, but what architectures use the vmlinux convention rather than the vmlinuz convention? I've only worked with the i386 and s390 architectures, and they both use the vmlinuz convention. Perhaps more importantly, why do these architectures use the vmlinux naming convention and why is it important to maintain a separate naming convention? Wouldn't it be simpler to use the same naming convention on all architectures? No doubt this has been discussed before, but I'm new at this. Feel free to refer me to a previous discussion thread if appropriate. ... Kernel hook scripts may be run under debconf. In this case they must not use stdin and stdout, and should send all output to stderr (fd 2). [Alternately we should change linux-2.6 and kernel-package to do the necessary redirection. Is there any legitimate reason for a hook script to interact with debconf?] So far, I have had no requirement to interact directly with debconf in a hook script, but why close out our options? If you redirect standard output to standard error at, say, the invocation of the run-parts command, then the hook script *cannot* interact with debconf, even if it wants to or needs to. If you leave things as they are now, the hook script will normally redirect standard output to standard error, but if for some unforeseen reason it later needs or wants to interact with debconf, it can. Therefore, I would prefer to leave things as in the first quoted sentence above. That's my two cents worth. 2. Packages for boot loaders that need to be updated whenever the files they load are modified must also install hook scripts in /etc/initramfs/post-update.d. Initramfs builders must call these scripts using run-parts after they create, update or delete an initramfs. The arguments given to these hook scripts are the kernel ABI version and the absolute path to the initramfs image. My template hook script for this directory currently tests whether a maintainer script beginning with linux-image- is being processed, and, if so, exits without doing anything. Presumably, only such a maintainer script will create or delete an initramfs. At least that is my assumption. Upon further reflection, however, maybe I should expand this test to look for Hurd kernels and FreeBSD kernels? I don't know how to test for those. Alternately, the hook script needs some way of determining whether it is being called for a create, delete, or update. In my case anyway, the hook script is only interested in an update (to match the current behavior of update-initramfs). -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/609145822.187199.1278422298504.javamail.r...@md01.wow.synacor.com
Re: [DRAFT v2] Policy for Linux kernel, initramfs, boot loader update process
On Tue, 06 Jul 2010 09:38:53 -0400 (EDT), Ben Hutchings wrote: On Tue, 2010-07-06 at 09:18 -0400, Stephen Powell wrote: ... Perhaps more importantly, why do these architectures use the vmlinux naming convention Hysterical raisins. I take that to mean historical reasons. OK. and why is it important to maintain a separate naming convention? Wouldn't it be simpler to use the same naming convention on all architectures? ... That would require an upstream change. Oh. ... So far, I have had no requirement to interact directly with debconf in a hook script, but why close out our options? So that hook script authors can't make the mistake of failing to redirect. Well, yes, it would solve that problem. But if redirection is listed in the policy, and they don't do it, it's their fault. My stuff works either way, at this point. Do what you think is best. ... Upon further reflection, however, maybe I should expand this test to look for Hurd kernels and FreeBSD kernels? It's possible that this policy can be extended to cover them, but I just don't know anything about their boot process. Then I'll leave it as-is for now. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1227172348.193220.1278429963259.javamail.r...@md01.wow.synacor.com
Re: Proposed changes to initramfs-tools hook scripts
On Fri, 02 Jul 2010 02:20:45 -0400 (EDT), maximilian attems wrote: On Wed, 30 Jun 2010, Stephen Powell wrote: As promised, here are my proposed changes to the initramfs-tools hook scripts. thank you very much. applied your 3 changes to branch maks/hooks on http://git.debian.org/?p=kernel/initramfs-tools.git;a=summary please review before I'd merge into master for next upload. I just reviewed them. They look good to me. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1762086613.144660.1278180301574.javamail.r...@md01.wow.synacor.com
Re: Proposed changes to initramfs-tools hook scripts
On Fri, 02 Jul 2010 02:20:45 -0400 (EDT), maximilian attems wrote: On Wed, 30 Jun 2010, Stephen Powell wrote: Max, As promised, here are my proposed changes to the initramfs-tools hook scripts. ... thank you very much. applied your 3 changes to branch maks/hooks on http://git.debian.org/?p=kernel/initramfs-tools.git;a=summary please review before I'd merge into master for next upload. I'll take a look at those tonight, the Lord willing. I'm not sure if the indirection to STDERR is needed for make deb-pkg, but it shouldn't hurt there? It all depends on whether debconf is active or not. If it is, then it's necessary. If it's not, it won't hurt anything. you may want to have a look at for initramfs-tools dev http://git.debian.org/?p=kernel/initramfs-tools.git;a=blob_plain;f=docs/maintainer-notes.html;h=eeceafdfc498bd6585328d1eeb52e6e454d524ee;hb=HEAD changes in git send-email or online git repo are easier to handle. I'll take a look at that too. There are so many new things to learn all at once! -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874427008.133057.1278106852146.javamail.r...@md01.wow.synacor.com
Re: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process
On Wed, 30 Jun 2010 09:29:42 -0400 (EDT), Stephen Powell wrote: Since symlinks are not associated with any package in particular, and since they seem to have been designed for the convenience of historic boot loaders such as lilo and zipl, perhaps the best way to handle this is for the boot loader hook script, zz-whatever, to maintain the symlinks, if desired. As a matter of fact, I already have a hook script on hand that does this very thing, and with minor modifications will do nicely, I think. Right now, it unconditionally maintains the symlinks. To generalize it more, it could determine if symlinks already exist or not, and if so where, then maintain them where they are. If the symlinks don't exist, it won't create them. It could also be changed to determine if lilo or zipl is in use, based on the presence of the config file, and invoke the appropriate boot loader. Then, all the maintainer of the s390-tools package would have to do is to include it in the s390-tools package. And the maintainer of lilo could do the same. OK, I now have some templates to shoot at. /etc/kernel/postinst.d/zz-bootloader http://www.wowway.com/~zlinuxman/kernel/postinst.d/zz-bootloader /etc/kernel/postrm.d/zz-bootloader http://www.wowway.com/~zlinuxman/kernel/postrm.d/zz-bootloader These templates should work for both lilo and zipl, and they maintain the symbolic links, if they already exist. When doing an initial install (Debian installer), (1) the initial kernel must be installed first, then (2) the boot loader must be installed, then (3) the initial symlinks must be created (if lilo or zipl), then (4) dpkg-reconfigure or the boot loader installer (lilo or zipl) must be run. (Steps 2 and 3 could optionally be reversed or combined.) After that, the hook scripts will maintain the symbolic links as long as there is at least one installed kernel at all times. (Presumably one will never purge the running kernel!) In particular, /etc/kernel-img.conf is not examined to see if do_symlinks = yes is set. If symlinks are present, they will be maintained. If they are not, they will not be created. ... [discussion of initramfs-tools issues ] Since you're obviously very busy, I will submit a version of the initramfs-tools script which I believe will address all these issues. Then you can take pot shots at it. These are included here: /etc/kernel/postinst.d/initramfs-tools http://www.wowway.com/~zlinuxman/kernel/postinst.d/initramfs-tools /etc/kernel/postrm.d/initramfs-tools http://www.wowway.com/~zlinuxman/kernel/postrm.d/initramfs-tools For the boot loader hook to initramfs builders: /etc/initramfs/post-update.d/bootloader http://www.wowway.com/~zlinuxman/initramfs/post-update.d/bootloader (This last interface is not currently functional, of course.) How do they look? -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1920933269.99141.1278000752640.javamail.r...@md01.wow.synacor.com
Re: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process
On Tue, 29 Jun 2010 16:35:40 -0400 (EDT), maximilian attems wrote: On Tue, Jun 29, 2010 at 04:24:48PM -0400, Stephen Powell wrote: Sorry I didn't think of this the first time, but there are up to four steps to preparing a kernel for booting: (1) Installation of the kernel itself (2) Creation of an initial RAM file system (3) Updating symbolic links ... they are deprecated and shouldn't be necessary. there are even more evil incarnations like reverse symlinks or whatever. which we no longer support since longer.. it be better to just get rid of them. Hmm. Well, I don't mind if you drop support for direct symlink maintenance from the kernel maintainer scripts, but the symlinks serve a very useful function: they make it possible for the boot loader configuration file, /etc/lilo.conf, /etc/zipl.conf, etc. to remain a relatively static file. That is how these historic boot loaders, such as lilo and zipl, are used to operating. And remember, on the s390 platform, zipl is the *only* supported boot loader. Since symlinks are not associated with any package in particular, and since they seem to have been designed for the convenience of historic boot loaders such as lilo and zipl, perhaps the best way to handle this is for the boot loader hook script, zz-whatever, to maintain the symlinks, if desired. As a matter of fact, I already have a hook script on hand that does this very thing, and with minor modifications will do nicely, I think. Right now, it unconditionally maintains the symlinks. To generalize it more, it could determine if symlinks already exist or not, and if so where, then maintain them where they are. If the symlinks don't exist, it won't create them. It could also be changed to determine if lilo or zipl is in use, based on the presence of the config file, and invoke the appropriate boot loader. Then, all the maintainer of the s390-tools package would have to do is to include it in the s390-tools package. And the maintainer of lilo could do the same. ... [discussion of initramfs-tools script issues] ... hate those indirections due to debconf magic, but why would the hook scripts need one. thanks for hints, been staying away from debconf for long.. the unconditional is expected and there is a wishlist bug open for that it has not high priority as many things do not work if you don'T use an initramfs. Understood. Since you're obviously very busy, I will submit a version of the initramfs-tools script which I believe will address all these issues. Then you can take pot shots at it. ps if you want the no cc thing set up your mua appropriately. here in d-kernel we do cc. I don't care either way, actually. But when in Rome, do as the Romans do. I included you on the cc list, per the above. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1257454917.65146.1277904582236.javamail.r...@md01.wow.synacor.com
Re: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process
On Wed, 30 Jun 2010 10:00:10 -0400 (EDT), Jonas Smedegaard wrote: On Wed, Jun 30, 2010 at 09:29:42AM -0400, Stephen Powell wrote: ... Since symlinks are not associated with any package in particular, and since they seem to have been designed for the convenience of historic boot loaders such as lilo and zipl, perhaps the best way to handle this is for the boot loader hook script, zz-whatever, to maintain the symlinks, if desired. Beware that multiple boot loaders might be installed concurrently. If each of them provide a zz- hook script implemented independently, they might handle symlinks differently, leading to surprises. dpkg does not prevent multiple boot loaders from being installed concurrently; but this environment is not supported by the various system maintainer scripts of Debian, even today. For example, update-initramfs -u currently checks to see if lilo is installed, and if it is, it runs lilo. But if grub (either version 1 or version 2) is installed also, it issues the following messages: WARNING: grub and lilo installed. Please de-install unused bootloader. It could also test for other boot loaders as well, such as extlinux, but it doesn't. The point is that Debian's maintainer scripts do not support multiple concurrently-installed boot loaders even today. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/952598886.67029.1277908292511.javamail.r...@md01.wow.synacor.com
Re: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process
On Wed, 30 Jun 2010 10:54:53 -0400 (EDT), Jonas Smedegaard wrote: On Wed, Jun 30, 2010 at 10:31:32AM -0400, Stephen Powell wrote: dpkg does not prevent multiple boot loaders from being installed concurrently; but this environment is not supported by the various system maintainer scripts of Debian, even today. For example, update-initramfs -u currently checks to see if lilo is installed, and if it is, it runs lilo. But if grub (either version 1 or version 2) is installed also, it issues the following messages: WARNING: grub and lilo installed. Please de-install unused bootloader. It could also test for other boot loaders as well, such as extlinux, but it doesn't. The point is that Debian's maintainer scripts do not support multiple concurrently-installed boot loaders even today. I read above as initramfs-tools in particular not supporting multiple bootloaders. Could you perhaps elaborate more on why this is a general problem? I think Max has answered that question, as least as it pertains to initramfs-tools. To generalize from that, it makes it difficult for various tools to know what to do or to co-ordinate with each other. For example, only one boot loader can own the master boot record. So if two hook scripts starting with zz- are installed, one for each boot loader, what happens? The last one to execute wins? That's not going to work. Let's turn that question around. What legitimate purpose is served by having multiple concurrently-installed boot loaders? -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/459396134.69046.1277911907155.javamail.r...@md01.wow.synacor.com
Re: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process
On Mon, 28 Jun 2010 19:07:16 -0400 (EDT), Ben Hutchings wrote: Please reply to debian-kernel only. As you wish. I had reason to believe that some key players were probably not subscribed to debian-kernel. But they are now at least aware of the thread and can follow it further if they so desire. I have now subscribed to debian-kernel myself; so there is no need to CC me. On Mon, 2010-06-28 at 11:16 -0400, Stephen Powell wrote: On Sun, 27 Jun 2010 22:02:35 -0400 (EDT), Ben Hutchings wrote: [...] The environment variable DEB_MAINT_PARAMS will contain the arguments given to the kernel maintainer script, single-quoted. Is this environment variable provided by the maintainer scripts that come with kernel image packages created by make deb-pkg? (I honestly don't know. I've never used make deb-pkg.) It has done since 2.6.31, though without single-quotes. I'll note that they may or may not be quoted, and recommend how to use this variable. OK. [...] 5. Kernel and initramfs builder packages must not invoke boot loaders except via hooks. If /etc/kernel-img.conf contains an explicit 'do_bootloader = yes', kernel package maintainer scripts should warn that this is now ignored. At the risk of flogging a dead horse, I would prefer to see do_bootloader = yes supported until Squeeze+1, both by the kernel maintainer scripts and by update-initramfs -u, particularly since we are so close to a freeze. The release team has stated we are not close to a freeze. So we have a little time to sort this out. That's good. But if you're going to drop support for it in Squeeze, then yes, a warning message is necessary. Both the kernel maintainer scripts *and* update-initramfs -u *must* issue a warning message if they find do_bootloader = yes specified in /etc/kernel-img.conf. In fact, since the default value is yes, they should issue the warning message unless do_bootloader is *explicitly* set to no. I can put a one-time warning into linux-base. But the default for squeeze must be 'no'. It should not be necessary to create /etc/kernel-img.conf at all in squeeze. That's a good idea. I'm just concerned about migrations from a previous release where users may be relying on the implicit default to get their boot loader run. 6. The installer must not define do_bootloader, postinst_hook or postrm_hook in /etc/kernel-img.conf. Doesn't this conflict with point 4 (a)? Not at all. This means postinst_hook and postrm_hook are now strictly for use by the user. OK. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1129698791.34865.1277816465356.javamail.r...@md01.wow.synacor.com
Re: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process
On Mon, 28 Jun 2010 19:07:16 -0400 (EDT), Ben Hutchings wrote: ... I can put a one-time warning into linux-base. But the default for squeeze must be 'no'. It should not be necessary to create /etc/kernel-img.conf at all in squeeze. Sorry I didn't think of this the first time, but there are up to four steps to preparing a kernel for booting: (1) Installation of the kernel itself (2) Creation of an initial RAM file system (3) Updating symbolic links (4) Running the boot loader installer Not all steps are required in all cases, depending on the circumstances. Neither grub version 1 nor grub version 2 generally use symbolic links; so that hasn't been on the forefront of most people's minds. Strictly speaking, the historic boot loaders such as lilo and zipl don't *have* to use symbolic links, but as they have historically been used in Debian systems, they generally do. Obviously, item 1 takes care of itself. For stock kernels, item 2 also takes care of itself. And it appears that the latest version of initramfs-tools provides hook scripts of the same name in /etc/kernel/postinst.d and /etc/kernel/postrm.d which take care of item 2 for kernel image packages created by make-kpkg and make deb-pkg as well. (Actually, that item does need some work, but I'll come back to that later. For now, let's assume that item 2 is taken care of.) Item 4 is what we've been talking about. Each boot loader that needs some kind of update will have to provide a hook script starting with zz-. Now the question is, what should we do about item 3, maintaining the symlinks? For stock kernels, that has historically been handled by variables in /etc/kernel-img.conf: do_symlinks, relative_links, and link_in_boot, mainly, though there are other seldom-used variations. But you just said that the goal was to be able to eliminate /etc/kernel-img.conf. So what do we do about symlinks? Fortunately, the update-initramfs -u issue doesn't affect the symlinks. The symlinks only need to be maintained, if at all, when a kernel is installed, updated, or removed. The symlinks are not, strictly speaking, associated with a package. Should the boot loader script take care of it? Or should this be a separate script? What do you think? I said I would come back to initramfs-tools; so now I'm back. There are two issues with the script as written today. (1) it does not redirect standard output to standard error when invoking update-initramfs. Thus, the user sees no output (since debconf swallows it) and, depending on the output, it may cause problems for debconf. (2) it unconditionally creates an initial RAM file system for kernel image packages created by make-kpkg, even if the user doesn't want one. There is a way to check to see if one is needed. I can submit a revised version of the script if you like. Would you like me to do so? -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1783519414.48436.1277843088409.javamail.r...@md01.wow.synacor.com
Re: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process
the default value is yes, they should issue the warning message unless do_bootloader is *explicitly* set to no. 6. The installer must not define do_bootloader, postinst_hook or postrm_hook in /etc/kernel-img.conf. Doesn't this conflict with point 4 (a)? -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1266213194.8135.1277738218774.javamail.r...@md01.wow.synacor.com
Re: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process
On Mon, 28 Jun 2010 12:45:10 -0400 (EDT), maximilian attems wrote:
On Mon, 28 Jun 2010 03:02:35 +0100 Ben Hutchings wrote:
The arguments given to all kernel hook scripts are the kernel ABI
version (the string that uname -r reports) and the absolute path to the
kernel image.
On Mon, Jun 28, 2010 at 11:16:58AM -0400, Stephen Powell wrote:
Currently, hook scripts invoked by a stock kernel maintainer script
or a maintainer script from a kernel image package created by make-kpkg
pass these exact same arguments.
no.
From a Squeeze system running a custom kernel created by make-kpkg:
-
debian3:~# dpkg-reconfigure linux-image-2.6.32-custom5b-s390x
Running depmod.
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/S30initramfs 2.6.32-custom5b-s390x
/boot/vmlinuz-2.6.32-custom5b-s390x
^ ^
+-- 1st argument
+-- 2nd argument
-
From a Squeeze system running a stock kernel image:
-
r...@testdebian:~# dpkg-reconfigure linux-image-2.6.32-3-686
Running depmod.
Running update-initramfs: Generating /boot/initrd.img-2.6.32-3-686
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/S30initramfs 2.6.32-3-686
/boot/vmlinuz-2.6.32-3-686
^^
|+-- 2nd
argument
+-- 1st argument
-
Q.E.D.
On Mon, Jun 28, 2010 at 11:16:58AM -0400, Stephen Powell wrote:
But a maintainer script for a kernel
image package created by make deb-pkg passes only the first argument.
no.
The actual text of /etc/kernel/postinst.d/initramfs-tools:
-
#!/bin/sh
version=$1
bootopt=
# passing the kernel version is required
[ -z ${version} ] exit 0
# kernel-package passes an extra arg
if [ -n $2 ]; then
if [ -n ${KERNEL_PACKAGE_VERSION} ]; then
bootdir=$(dirname $2)
bootopt=-b ${bootdir}
else
# official Debian linux-images take care themself
exit 0
fi
fi
# avoid running multiple times
if [ -n $DEB_MAINT_PARAMS ]; then
eval set -- $DEB_MAINT_PARAMS
if [ -z $1 ] || [ $1 != configure ]; then
exit 0
fi
fi
# we're good - create initramfs. update runs do_bootloader
update-initramfs -c -t -k ${version} ${bootopt}
-
I admit that I have never personally used make deb-pkg, but
clearly the source code speaks for itself. This hook script is
expecting only one argument when invoked by make deb-pkg.
Q.E.D.
On Mon, Jun 28, 2010 at 11:16:58AM -0400, Stephen Powell wrote:
Existing hook scripts rely on that difference to determine whether or
not to take action. For example, the initramfs hook script provided by
the initramfs-tools package tests the number of arguments and exits
without doing anything if more than one argument is supplied. In other
words, this hook script is designed to create the initial RAM file system
for a kernel image created by make deb-pkg, and only for a kernel
image created by make deb-pkg. It does nothing otherwise. Are you
proposing to change this behavior?
please get your facts right before spamming the world.
OK, you're partly right on this one. Execution tracing shows that it
does nothing when invoked by a stock kernel maintainer script but
does create an initial RAM file system when invoked by a maintainer
script from a kernel image package created by make-kpkg. (By the way,
since this script is running under debconf, output from update-initramfs
should be redirected to standard error via 2.) I don't remember the
kernel-package logic being present in this script the last time I looked
at it.
(1) As far as I am able to determine, my original statements are correct,
with the exception of the correction made in the above paragraph.
If you can prove me wrong, please do so.
(2) This was not spam. Spam is unsolicited advertising.
This was a response to an RFC, to which I was explicitly
included as an adressee.
(3) All the addressees of my e-mail were legitimate stake-holders
in this process. This is not the world.
--
.''`. Stephen Powell
: :' :
`. `'`
`-
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/1137353821.16101.1277752206454.javamail.r...@md01.wow.synacor.com
Re: [RFC] Updating boot loaders in lenny and squeeze
On Sun, 27 Jun 2010 14:22:07 -0400 (EDT), Ben Hutchings wrote: There is a minor problem with this, which is that it will likely result in updating the boot loader twice during a kernel installation or upgrade. We could avoid that by specifying that: 3. Boot loaders must install kernel hook scripts named beginning with 'zz-'. All other packages must use names that sort before this. (This ensures that the boot loader update happens last.) I'm glad to see that someone is finally beginning to see the need for a naming convention for hook scripts to control execution order. Franz Pop brought up this topic in May of 2009, but no-one seemed to think it was important then. (See http://lists.debian.org/debian-kernel/2009/03/msg00611.html) 4. Initramfs builders may omit calling initramfs hook scripts when they are invoked from a kernel hook script. We're still left with the question of how to transition from the current mess. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1832443220.328974.1277684570933.javamail.r...@md01.wow.synacor.com
Re: [RFC] Updating boot loaders in lenny and squeeze
On Sat, 26 Jun 2010 15:50:27 -0400 (EDT), Ben Hutchings wrote: On Wed, 2010-06-23 at 23:31 +0200, Jonas Smedegaard wrote: A great while back initramfs-tools and kernel packages broke the ABI coordinated across initramfs-tools, linux-2.6, yaird and kernel-package. Sure would be nice with a stable ABI again, and getting informed if it changes. That is a separate issue. What we need here is an interface for the initramfs builder to update the boot loader if necessary. No such interface exists yet, AFAIK. I suggest something like the following: 1. Boot loaders that maintain block lists install a script under /etc/mkinitramfs/post-update.d which takes two arguments: the kernel ABI version (uname -r) and the absolute path to an initramfs. 2. Initramfs builders call the scripts in this directory after creating, updating or deleting an initramfs by running: run-parts --verbose --exit-on-error --arg=$version --arg=$path /etc/mkinitramfs/post-update.d or similar. We could alternately use multiple directories or an argument to distinguish creation, update and deletion. However, I suspect that these scripts will need to invoke the same command in all cases. Sounds reasonable to me. This is for Squeeze+1, right? -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/910677554.313851.1277598904174.javamail.r...@md01.wow.synacor.com
Re: [RFC] Updating boot loaders in lenny and squeeze
On Sat, 26 Jun 2010 20:45:58 -0400 (EDT), Ben Hutchings wrote: On Sat, 2010-06-26 at 20:35 -0400, Stephen Powell wrote: Sounds reasonable to me. This is for Squeeze+1, right? No, we need something like this for squeeze. On Fri, 18 Jun 2010 17:51:11 +0200, Maximilian Attems wrote: On Fri, 18 Jun 2010 10:55:35 -0400 (EDT), Stephen Powell wrote: As for update-initramfs -u, it *will* invoke lilo if lilo is installed and do_bootloader = yes is specified in /etc/kernel-img.conf, which I highly recommend. this fall back will be gone as soon as squeeze is out. so you'd really need to gear up. (The above quotes are from the bug log for Debian bug number 505609.) This led me to believe that, for lilo and zipl anyway, specifying do_bootloader = yes in /etc/kernel-img.conf would be sufficient to get the boot loader run when update-initramfs -u is executed at least through and including the Squeeze release. But in Squeeze+1 this fallback, as Max put it, will no longer work and therefore a new architecture will be needed. Did I misunderstand something? -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1719776969.315340.1277606604200.javamail.r...@md01.wow.synacor.com
Re: [RFC] Updating boot loaders in lenny and squeeze
On Fri, 18 Jun 2010 22:55:38 -0400 (EDT), Ben Hutchings wrote: Stephen Powell recently reminded the kernel team that LILO is not automatically updated on installation of a new kernel version in lenny. In fact there is a general problem that there are several different ways a boot loader may be updated automatically and currently no guarantee that this does happen whenever it should. There are two major cases where a boot loader should be updated automatically: 1. Where the boot loader relies on block lists rather than reading the filesystem, these block lists need to be updated whenever a kernel image or an initramfs is updated or removed. 2. Where the boot loader allows selection between arbitrarily many installed versions, the configuration should be updated whenever a kernel package is newly installed or removed. There are several ways such updates may be triggered: A. Packages built with older versions of kernel-package, including the official kernel packages in etch, run a platform-specific default boot loader if it is installed and if it falls into case 1 above. B. The maintainer scripts of kernel packages invoke hook scripts installed in appropriate subdirectories under /etc/kernel/. C. The maintainer scripts of kernel packages invoke hook commands specified in /etc/kernel-img.conf. D. update-initramfs -u will run certain boot loader update programs if installed. In lenny, route A was effectively disabled in official kernel packages. However, no boot loader uses route B and debian-installer enables route C only for GRUB (as far as I know). Disabling route A in lenny was clearly premature and I intend to restore it in a stable update. However, given that route B is present in both lenny and squeeze (and even in etch, I think) there is no good reason for packages not to rely on it now. (Well, except lack of documentation.) All boot loader packages that fall into case 1 or 2 should be installing hook scripts, but currently only extlinux does. That's a well-organized summary, Ben. I intend to remove the vestigial code for route A, and file bugs on all boot loaders in case 1 or 2 that do not use route B. I believe that bug number 585856 will qualify for this purpose for the lilo boot loader. If you decide to extend this maintainer script feature to the s390 platform also (for Squeeze and later releases) then you should, at the same time, file a bug report against the s390-tools package, which includes the zipl boot loader, which has the same basic design as lilo. (It reads the kernel and the initrd as a list of blocks, which must be kept in sync with the file system.) In case 1, the boot loader should also be called by update-initramfs when it is called outside of kernel package installation and removal. This is normally covered by route D, but this seems a little fragile. I would prefer to replace this with a hook system (as already exists for building the initramfs itself), but I'm not that involved in initramfs-tools development. That does seem like a more general-purpose solution, rather than having lilo and zipl treated as special cases. But please keep the appropriate parties informed of any future design changes to update-initramfs. I myself have never used yaird, but I assume that to be consistent it should have a similar hook system. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1301681916.226806.1277302362845.javamail.r...@md01.wow.synacor.com
Re: [RFC] Updating boot loaders in lenny and squeeze
On Wed, 23 Jun 2010 11:04:06 -0400 (EDT), Ben Hutchings wrote: yaird is no longer present in testing or unstable, so it is a non-issue as far as I'm concerned. I see it is gone from testing, but it is still present in unstable, as of this moment, according to the Debian web site. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/765636083.229248.1277306459777.javamail.r...@md01.wow.synacor.com
Doesn't boot with large initramfs
Guido, Bug number 505609 has been closed by the kernel team. However, the kernel team is only going to fix the problem for Lenny. To fix the problem in Squeeze and later releases will require that a hook script of some kind be added to the lilo package. The problem is that lilo didn't get run during the kernel upgrade, as it should have been, due to changes in the kernel maintainer scripts which, for Squeeze and later releases, the kernel team regards as a feature and not a bug. Their position is that lilo needs to provide a hook script to make sure lilo gets run during a kernel upgrade. This bug report will remain open until a lilo package with a suitable hook script gets uploaded. In the mean time, here's one way to work around it. (Do this as root.) (1) Make sure that large-memory is specified in /etc/lilo.conf. (2) Create a file called /usr/sbin/lilo-update. It should look like this: #!/bin/sh # This file is referenced by /etc/kernel-img.conf. lilo -v 2 (3) Mark the file executable, like this: chmod +x /usr/sbin/lilo-update (4) Edit the file /etc/kernel-img.conf. Make sure that do_bootloader = yes is specified in this file (for the sake of update-initramfs -u), then add postinst_hook = lilo-update postrm_hook = lilo-update This will cause lilo to get run when a stock kernel image is installed or upgraded. If you are going to use a custom kernel, such as one created by make-kpkg or make deb-pkg, then this is not adequate. I recommend that you read my unofficial kernel building web page, http://www.wowway.com/~zlinuxman/Kernel.htm, for more complete information on how to make sure that lilo gets run (as well as other necessary stuff) when using a custom kernel. If you have any further questions about this lilo problem, please post to this bug log (585856). -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1604981149.188065.1277222833350.javamail.r...@md01.wow.synacor.com
Bug#505609: loader varialbe in kernel maintainer scripts
On Fri, 18 Jun 2010 04:25:38 -0400 (EDT), Joachim Wiedorn wrote: Ben Hutchings b...@decadent.org.uk wrote on 2010-06-18 02:02: On Thu, 2010-06-17 at 20:37 -0400, Stephen Powell wrote: And how would one go about setting this loader variable? The loader variable is not documented in the man page for /etc/kernel-img.conf in Lenny, which appears to be the closest thing there is to documentation for the variables supported by official Debian stock kernel images. Nevertheless, at your suggestion, I tried putting loader = lilo in /etc/kernel-img.conf. (do_bootloader = yes was also set.) Then I issued dpkg-reconfigure linux-image-2.6.26-2-686 There was no evidence from the output that lilo was run. [...] I'm sorry, you're right. Most of the other variables at the top of the postinst script can be overridden by /etc/kernel-img.conf, but not this one. Given that, I think you are right that the 'historical' bootloader setting should be restored in an update to lenny. Now I am a little confused. How is the recommended procedure for using the LILO bootloader within squeeze/sid? How I understand the normal installation of lilo package have the result, that lilo doesn't be started after an kernel update (and also after update of initramfs-tools?). What must I config on my squeeze machine that lilo bootloader will be automatically updated after kernel update? So far, Ben has only agreed to reinstate the historic function of do_bootloader = yes in /etc/kernel-img.conf for Lenny kernel maintainer scripts. It hasn't actually happened yet, but he has agreed to restore its former function in Lenny as it was in Etch and previous releases. I am trying to persuade him to restore its function in Squeeze too. Whether or not I am successful remains to be seen. In the mean time, for lilo users of Squeeze/Sid who use *only* official stock Debian kernels, I recommend that they use the hook script described in an earlier post to this bug log in conjunction with other appropriate settings in /etc/kernel-img.conf. For lilo users of Squeeze/Sid who use custom kernels created by make-kpkg, I recommend that they use the hook scripts provided on my unofficial kernel building web page, http://www.wowway.com/~zlinuxman/Kernel.htm, under Step 10: Customize the Kernel Installation Environment. I must add that this recommendation is my own and not official Debian advice. I have never used the upstream-provided make deb-pkg way of building a custom kernel; so I don't have any hook scripts pre-made for that purpose. There doesn't seem to be a one size fits all solution at this point. If Ben agrees to reinstate the historic function of do_bootloader = yes for Squeeze, then there will be a one size fits all solution for lilo users, at least as it pertains to stock kernels. Users of custom kernels are on their own. They need to figure out what hook scripts they need and how to customize and configure them. And if they don't do it right, you may be sure that they will blame lilo! (That's one of the reasons why I think it would be a good idea for lilo to implement a check sum method of figuring out if something changed in the kernel image or initial RAM file system image without lilo being re-run. But I digress.) As for update-initramfs -u, it *will* invoke lilo if lilo is installed and do_bootloader = yes is specified in /etc/kernel-img.conf, which I highly recommend. There are types of upgrades which do not affect the kernel itself but which do require that the initial RAM file system be re-built. And for lilo users, it is essential that lilo be run after any changes are made to the initial RAM file system. update-initramfs -c and update-initramfs -d, however, will *not* invoke lilo, even if do_bootloader = yes is specified in /etc/kernel-img.conf. HTH -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/531218163.101000.1276872935122.javamail.r...@md01.wow.synacor.com
Bug#505609: loader varialbe in kernel maintainer scripts
On Fri, 18 Jun 2010 11:51:11 -0400 (EDT), maximilian attems wrote: On Fri, Jun 18, 2010 at 10:55:35AM -0400, Stephen Powell wrote: As for update-initramfs -u, it *will* invoke lilo if lilo is installed and do_bootloader = yes is specified in /etc/kernel-img.conf, which I highly recommend. this fall back will be gone as soon as squeeze is out. so you'd really need to gear up. That is interesting. Suppose that the user issues an aptitude update aptitude full-upgrade sequence. And suppose something other than the kernel gets updated that requires that the initial RAM file system be updated. Somehow, aptitude knows to run update-initramfs -u. But if update-initramfs -u does not invoke lilo, and the kernel is not updated, what will cause lilo to get run? The kernel hook scripts won't be run because the kernel itself was not updated. The same principle applies to zipl on the s390 platform, which is the *only* supported boot loader on this platform, by the way. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1199263906.109692.1276893897406.javamail.r...@md01.wow.synacor.com
Bug#505609: new lilo package maintainer? (was lilo removal in squeeze or please test grub2)
On Tue, 15 Jun 2010 23:25:45 -0400 (EDT), Ben Hutchings wrote: On Tue, 2010-06-08 at 09:43 -0400, Stephen Powell wrote: do_bootloader = yes in /etc/kernel-img.conf means run the historic boot loader for this platform. For the i386 platform (and amd64) the historic boot loader is lilo. For the s390 platform, that boot loader is zipl. The kernel maintainer scripts for the s390 platform still specify zipl as the boot loader my $loader= zipl; # lilo, silo, quik, palo, vmelilo, nettrom, arcboot, or delo so that do_bootloader = yes in /etc/kernel-img.conf will work. The kernel maintainer scripts for i386 and amd64 for Lenny and beyond specify a null string. That is inconsistent. It should specify my $loader= lilo; # lilo, silo, quik, palo, vmelilo, nettrom, arcboot, or delo for consistency between platforms. [...] This code and the file /etc/kernel-img.conf are vestiges of kernel-package which are gradually being removed from the official kernel packages. Therefore I don't think we should reinstate this idea of the default loader but we should change the code so that it doesn't silently fail if do_loader is set and loader is not. Well, I agree that the maintainer script should not silently fail. But removing support for the historic boot loader actually makes the official stock Debian kernel image package maintainer scripts *more* like kernel-package, not less. To be more precise, it makes them more like the *Squeeze* version of kernel-package. The maintainer scripts which get packaged with a kernel image package created by make-kpkg under Squeeze and later releases no longer perform *any* post installation activities. They do not create an initial RAM file system (even if the --initrd option was specified on the make-kpkg command line), they do not maintain symbolic links (even if do_symlinks = yes is specified in /etc/kernel-img.conf), and they do not run the historic boot loader (even if do_bootloader = yes is specified in /etc/kernel-img.conf). If you want any of these things done, then either the user or an installed package must provide hook scripts to accomplish this. The maintainer scripts packaged with kernel image packages created by make-kpkg under Lenny and previous releases still do all these things. I can maybe accept your proposal for Squeeze. But for Lenny, I believe that the maintainer scripts should be changed back they way they were. In other words, my $loader= lilo; # lilo, silo, quik, palo, vmelilo, nettrom, arcboot, or delo should be set in the maintainer scripts. After all, Lenny does not have the generalized hook script environment that Squeeze does. I believe that this bug is severe enough to warrant inclusion of the fix in stable-proposed-updates. All packages that need to react to kernel installation or removal should install appropriate hook scripts in the directories under /etc/kernel instead of relying on specific support in the kernel maintainer scripts. Again, I can maybe accept that argument for Squeeze, but not for Lenny. However, to be consistent, if you're going to leave my $loader set to the null string in i386 and amd64 kernel maintainer scripts, you should also set it to the null string for s390 kernel maintainer scripts. This will affect the s390-tools package, which includes the zipl boot loader for the s390 platform; so I'm copying them in on this. If your proposed solution goes through, they will need to create some kind of hook script too, or at least document the need for one. And so will lilo. And when we're all done, that leaves us with one foot in the old way of doing things and one foot in the new way of doing things. The initial RAM file system will still be created automatically, symlinks will still be maintained (if requested in /etc/kernel-img.conf), but the historic boot loader will not be run. I would rather see the the stock kernel maintainer scripts do none of the above, like the new kernel-package, or all of the above, like the historic stock kernel maintainer scripts. And this is pretty late in the Squeeze development cycle to start making design changes. We're getting pretty close to a freeze, are we not? It sure seems to me like a one-line change in the kernel maintainer scripts is a much faster and much simpler fix, not to mention more consistent. The maintainer scripts' support for the historic boot loader should be retained, in my opinion, at least for Squeeze. Then, if you want to change the design of how kernel maintainer scripts work, that can be done in Squeeze+1. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1270915198.75740.1276792438126.javamail.r...@md01.wow.synacor.com
Bug#505609: loader varialbe in kernel maintainer scripts
On Thu, 17 Jun 2010 18:11:04 -0400 (EDT), Ben Hutchings wrote: On Thu, Jun 17, 2010 at 12:33:58PM -0400, Stephen Powell wrote: [...] I can maybe accept your proposal for Squeeze. But for Lenny, I believe that the maintainer scripts should be changed back they way they were. In other words, my $loader= lilo; # lilo, silo, quik, palo, vmelilo, nettrom, arcboot, or delo should be set in the maintainer scripts. After all, Lenny does not have the generalized hook script environment that Squeeze does. But it does allow users to configure the loader to be run, using either the 'loader' or 'postinst_hook' variable. And how would one go about setting this loader variable? The loader variable is not documented in the man page for /etc/kernel-img.conf in Lenny, which appears to be the closest thing there is to documentation for the variables supported by official Debian stock kernel images. Nevertheless, at your suggestion, I tried putting loader = lilo in /etc/kernel-img.conf. (do_bootloader = yes was also set.) Then I issued dpkg-reconfigure linux-image-2.6.26-2-686 There was no evidence from the output that lilo was run. As for the postinst_hook and postrm_hook variables, they do work, but one can't simply specify postinst_hook = lilo postrm_hook = lilo in /etc/kernel-img.conf. That won't work because lilo doesn't like the parameters passed to it. It is necessary to create a wrapper script around lilo that strips off the parameters passed to it and redirects standard output to standard error. For example, on my unofficial kernel building web page, I recommend that lilo users create a hook script called /usr/sbin/lilo-update that looks like this: #!/bin/sh # The purpose of this script is to strip off any # arguments passed and simply invoke lilo, redirecting # standard output to standard error. It is intended # to be referenced by /etc/kernel-img.conf in the # postinst_hook and postrm_hook variables. # lilo 2 Then mark it executable with chmod +x /usr/sbin/lilo-update Then edit /etc/kernel-img.conf and specify postinst_hook = lilo-update postrm_hook = lilo-update That is how I have been recommending that users circumvent this bug (or feature, depending on your point of view). I believe that this bug is severe enough to warrant inclusion of the fix in stable-proposed-updates. The fact that the historical bootloader is not automatically run is not a bug; it is an intentional change. Only the silent failure is a bug. Preventing the historic boot loader from being run could have been accomplished by simply setting do_bootloader = no in /etc/kernel-img.conf. By setting my $loader to the null string, you made it *impossible* for the user to request that the historic boot loader be run. But OK, if you say it's a feature, not a bug, then I'll have to accept that. I must say I'm disappointed though. However, to be consistent, if you're going to leave my $loader set to the null string in i386 and amd64 kernel maintainer scripts, you should also set it to the null string for s390 kernel maintainer scripts. Yes. I think that's probably a reasonable change for squeeze. I was trying to use that argument to convince you to change it back for i386 and amd64, not to convince you to break it for s390! Oh well. Now it appears that s390 users will be able to look forward to this feature also. [...] The maintainer scripts' support for the historic boot loader should be retained, in my opinion, at least for Squeeze. Then, if you want to change the design of how kernel maintainer scripts work, that can be done in Squeeze+1. It cannot be 'retained' because it is not there at present. Nor will it be reinstated. OK, if you're determined not to set my $loader to the name of the historic boot loader, then please do make a change similar to the one you proposed so that it will tell the user to manually run the boot loader. Then close this bug report. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1328912820.87883.1276821442557.javamail.r...@md01.wow.synacor.com
Bug#505609: loader varialbe in kernel maintainer scripts
On Thu, 17 Jun 2010 21:02:54 -0400 (EDT), Ben Hutchings wrote: I'm sorry, you're right. Most of the other variables at the top of the postinst script can be overridden by /etc/kernel-img.conf, but not this one. Given that, I think you are right that the 'historical' bootloader setting should be restored in an update to lenny. Great! What about Squeeze? It still supports creating the initial RAM file system and updating symlinks via variables in /etc/kernel-img.conf. Doesn't it make sense to allow the historical boot loader code to work as well? -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1536816555.88906.1276824140357.javamail.r...@md01.wow.synacor.com
Re: new lilo package maintainer? (was lilo removal in squeeze or please test grub2)
On Tue, 08 Jun 2010 07:39:58 -0400 (EDT), Vincent Danjean wrote:
On 07/06/2010 17:37, Stephen Powell wrote:
But for a kernel install or reconfigure, it is the responsibility of the
kernel maintainer scripts to invoke the bootloader. See also, for example,
linux-image-2.6.26-2-s390.postinst, where zipl is assigned as the bootloader
on line 38. This really is an open and shut case, if only I can the kernel
people to actually look at it! Please look at it!
If I recall correctly, kernel maintainers have introduced
/etc/kernel/post{inst,rm}.d/ in order to avoid to hardcode each possible
bootloader in their script.
Can't lilo provide a script here ?
do_bootloader = yes
in /etc/kernel-img.conf means run the historic boot loader for this platform.
For the i386 platform (and amd64) the historic boot loader is lilo. For
the s390 platform, that boot loader is zipl. The kernel maintainer scripts
for the s390 platform still specify zipl as the boot loader
my $loader= zipl; # lilo, silo, quik, palo, vmelilo, nettrom,
arcboot, or delo
so that
do_bootloader = yes
in /etc/kernel-img.conf will work. The kernel maintainer scripts for i386 and
amd64
for Lenny and beyond specify a null string. That is inconsistent. It should
specify
my $loader= lilo; # lilo, silo, quik, palo, vmelilo, nettrom,
arcboot, or delo
for consistency between platforms. For non-historic boot loaders, the method
used is to set
do_bootloader = no
in /etc/kernel-img.conf and supply a hook script of some kind, if needed. For
example,
grub version 1 in Lenny invokes it's hook scripts via
do_bootloader = no
postinst_hook = update-grub
postrm_hook = update-grub
in /etc/kernel-img.conf. Grub version 2 does not need a hook script; so it
simply sets
do_bootloader = no
in /etc/kernel-img.conf. In Squeeze and later, there is an alternate method
for running
hook scripts (so that more than one hook script can be invoked). Simply
install the
script in /etc/kernel/preinst.d, /etc/kernel/prerm.d, /etc/kernel/postinst.d, or
/etc/kernel/postrm.d. But even in Squeeze/Sid, the historic boot loader can
still be run
by setting
do_bootloader = yes
in /etc/kernel-img.conf. That still works for zipl on the s390 platform. But
it's
been broken since Lenny on the i386 and amd64 platforms for lilo.
initramfs-tools also examines this variable and runs the historic boot loader
when
update-initramfs -u
is invoked. That still works, even on the i386 and amd64 platforms, provided
that
do_bootloader = yes
is specified in /etc/kernel-img.conf. But
update-initramfs -c
does not invoke the boot loader. Running the historic boot loader during
installation,
reconfiguration, or upgrade of a kernel is still the responsibility of the
kernel
maintainer scripts. And it cannot do so unless my $loader is set to the name
of
the historic boot loader. On s390, that variable is set properly. On i386 and
amd64,
it is not.
The kernel maintainer scripts provided by kernel image packages created by
make-kpkg
on Squeeze and later are another story. They no longer do *any*
post-installation
actions unless user-provided hook scripts cause it to happen. But the
maintainer
scripts for official stock Debian kernel images still support these historic
post-installation activities.
--
.''`. Stephen Powell
: :' :
`. `'`
`-
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/1661542040.41185.1276004599156.javamail.r...@md01.wow.synacor.com
