Bug#678696: Event based block device handling (fixes USB and nested devices problem)
On Wed, Mar 11, 2015 at 06:09:50PM +, Ben Hutchings wrote: On Tue, 2015-03-10 at 12:47 +0100, Goswin von Brederlow wrote: On Wed, Mar 04, 2015 at 09:30:24PM +, Ben Hutchings wrote: Thanks for your work on this bug. I ended up with a somewhat different implementation as I don't think it's necessary to duplicate the information that udev provides, and as we may now need to mount more than one filesystem. But I should have credited you in the changelog for prototyping this, and I forgot to do so. Ben. The idea with the udev rule was to wait up to ROOTDELAY seconds without a new device apearing before giving up. Now you wait ROOTDELAY seconds in total, which then can depend on the number of devices. It's now max(rootdelay, 30) because the rootdelay kernel parameter wasn't meant for this purpose at all. Add new disk and you have to increase the ROOTDELAY. I hope not! On one system the PSU isn't big enough to spin up all disks at once. So the SCSI controler is set to not start them on power on. Instead they come up sequentially. So one disk takes 5s, 2 disks 10s, 3 disks 15s, ... accordingly you have to set the delay. Add another disk and the total time goes up. Also it was ment so that block scripts could specifically target the new devices instead of having to scan all devices every time. For example say you have a crypt device and you forgot the password. Now I think you will be asked 30 times for the password before the initramfs gives up. True, but so far as I could see you didn't send scripts that made use of that. We could still implement that later, I think. And now that we potentially have to mount /usr (and possibly other filesystems), not just root and swap, lvm2's script needed to be told which device we're looking for, not which devices appeared. Ben. That isn't realy new. Debian already had root and swap. Adding a third doesn't realy change anything. LVM should already have known what devices to activate for root and swap. The problem I see there is detecting what devices to bring up. The /usr filesystem might be in a ZPOOL that uses a crypt device on a LVM logical volume on a raid. Or any other complex nesting. Could be any number of devices that are needed for /usr to become available. Again nothing new for /usr, / and swap already have that problem. Note: LVM has persistent metadata that tell it wether to bring up a device or not. So I'm not sure it makes much sense to guess what devices are needed and limiting lvm to only start those. The metadata already has this functionality and is more reliable than guessing what devices may be needed. MfG Goswin -- 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/20150312140917.GA20402@frosties
Bug#678696: Event based block device handling (fixes USB and nested devices problem)
On Wed, Mar 04, 2015 at 09:30:24PM +, Ben Hutchings wrote: Thanks for your work on this bug. I ended up with a somewhat different implementation as I don't think it's necessary to duplicate the information that udev provides, and as we may now need to mount more than one filesystem. But I should have credited you in the changelog for prototyping this, and I forgot to do so. Ben. The idea with the udev rule was to wait up to ROOTDELAY seconds without a new device apearing before giving up. Now you wait ROOTDELAY seconds in total, which then can depend on the number of devices. Add a new disk and you have to increase the ROOTDELAY. Also it was ment so that block scripts could specifically target the new devices instead of having to scan all devices every time. For example say you have a crypt device and you forgot the password. Now I think you will be asked 30 times for the password before the initramfs gives up. MfG Goswin -- 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/20150310114713.GA8425@frosties
Bug#678696: Event based block device handling (fixes USB and nested devices problem)
On Sun, Aug 31, 2014 at 10:14:18AM +0200, Michael Prokop wrote: Hi, f'up to our recent discussion we had on IRC * Goswin von Brederlow [Sat Jun 23, 2012 at 09:25:28PM +0200]: the attached patch adds an event based loop for block devices to the init script. New blockdevices are recorded in /run/initramfs/block-events by an udev rule as they appear. The init script repeadately waits for that and then calls /scripts/local-block/* with a list of new devices storedin NEWDEVS until $ROOT and $resume (if set) exists or a timeout is reached. This fixes the problem that USB devices take too long to be discovered and crypto, raid, lvm or multipath can't be started on them. It also adds support for arbitrary nestings of them, e.g. raid5 over raid1. [...] First of all thanks again for the patch and your helpful feedback on IRC. I've tested your patch based on top of current i-t git master (v0.116) with a setup like: BOOT_IMAGE=/boot/vmlinuz-3.14-2-amd64 root=/dev/mapper/vg0-root ro quiet but it sadly fails to work as intended (it boots but doesn't find the block devices until the timeout is kicking in). I didn't investigate closer yet, but AFAICS it seems to be related to the fact that /dev/mapper/vg0-root doesn't exist at that time yet. If it boots after the timeout then the device must exist. So either the test for it is wrong or the device only gets created after the timeout. If you or someones else finds time to try and possibly further investigate I'd very much welcome and appreciate that. regards, -mika- Questions: Does your system boot without the patch? If not then you also need the lvm patch to provide the hook script that scans for a VG when new block devices are detected. Do you see any messages about vg0 being activated before the timeout or after? MfG Goswin -- 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/20140901092406.GA23999@frosties
Bug#758544: nfsdrpc.nfsd: writing fd to kernel failed: errno 13 (Permission denied)
Package: nfs-kernel-server Version: 1:1.2.8-9 Severity: important Updating from wheezy breaks nfs-kernel-server (and updating again today doesn't fix it): Do you want to continue? [Y/n] y Get:1 http://ftp.de.debian.org/debian/ jessie/main nfs-common amd64 1:1.2.8-9 [206 kB] Get:2 http://ftp.de.debian.org/debian/ jessie/main nfs-kernel-server amd64 1:1.2.8-9 [115 kB] Get:3 http://ftp.de.debian.org/debian/ jessie/main libtirpc1 amd64 0.2.4-2.1 [77.8 kB] Fetched 398 kB in 0s (1015 kB/s) Reading changelogs... Done (Reading database ... 59958 files and directories currently installed.) Preparing to unpack .../nfs-common_1%3a1.2.8-9_amd64.deb ... Unpacking nfs-common (1:1.2.8-9) over (1:1.2.8-6) ... Preparing to unpack .../nfs-kernel-server_1%3a1.2.8-9_amd64.deb ... Unpacking nfs-kernel-server (1:1.2.8-9) over (1:1.2.8-6) ... Preparing to unpack .../libtirpc1_0.2.4-2.1_amd64.deb ... Unpacking libtirpc1:amd64 (0.2.4-2.1) over (0.2.3-2) ... Processing triggers for man-db (2.6.7.1-1) ... Setting up libtirpc1:amd64 (0.2.4-2.1) ... Setting up nfs-common (1:1.2.8-9) ... insserv: warning: current start runlevel(s) (2 3 4 5 S) of script `nfs-common' overrides LSB defaults (S). [ ok ] Stopping NFS common utilities: idmapd statd. [ ok ] Starting NFS common utilities: statd idmapd. Setting up nfs-kernel-server (1:1.2.8-9) ... [ ok ] Stopping NFS kernel daemon: mountd nfsd. [ ok ] Unexporting directories for NFS kernel daemon [ ok ] Exporting directories for NFS kernel daemon [] Starting NFS kernel daemon: nfsdrpc.nfsd: writing fd to kernel failed: errno 13 (Permission denied) rpc.nfsd: writing fd to kernel failed: errno 13 (Permission denied) rpc.nfsd: unable to set any sockets for nfsd failed! Processing triggers for libc-bin (2.19-7) ... ### syslog ### Aug 18 19:33:28 nas0 kernel: [42001389.592506] RPC: server localhost requires stronger authentication. Aug 18 19:33:28 nas0 kernel: [42001389.592512] svc: failed to register nfsaclv2 RPC service (errno 13). Aug 18 19:33:28 nas0 kernel: [42001389.592563] RPC: server localhost requires stronger authentication. Aug 18 19:33:28 nas0 kernel: [42001389.592614] RPC: server localhost requires stronger authentication. Aug 18 19:33:28 nas0 kernel: [42001389.592664] RPC: server localhost requires stronger authentication. Aug 18 19:33:28 nas0 kernel: [42001389.592714] RPC: server localhost requires stronger authentication. Aug 18 19:33:28 nas0 kernel: [42001389.592771] RPC: server localhost requires stronger authentication. Aug 18 19:33:28 nas0 kernel: [42001389.592809] nfsd: last server has exited, flushing export cache -- Package-specific info: -- rpcinfo -- program vers proto port service 104 tcp111 portmapper 103 tcp111 portmapper 102 tcp111 portmapper 104 udp111 portmapper 103 udp111 portmapper 102 udp111 portmapper 1000241 udp 50566 status 1000241 tcp 56743 status -- /etc/default/nfs-kernel-server -- RPCNFSDCOUNT=8 RPCNFSDPRIORITY=0 RPCMOUNTDOPTS=--manage-gids NEED_SVCGSSD= RPCSVCGSSDOPTS= -- /etc/exports -- /mnt/nas0-lva *(rw,fsid=7,no_subtree_check) /mnt/nas0-p2p *(rw,fsid=6,no_subtree_check) -- /proc/fs/nfs/exports -- # Version 1.1 # Path Client(Flags) # IPs -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages nfs-kernel-server depends on: ii libblkid1 2.20.1-5.8 ii libc6 2.19-7 ii libcap2 1:2.24-4 ii libsqlite3-0 3.8.5-2 ii libtirpc1 0.2.4-2.1 ii libwrap0 7.6.q-25 ii lsb-base 4.1+Debian13 ii nfs-common1:1.2.8-9 ii ucf 3.0030 nfs-kernel-server recommends no packages. nfs-kernel-server suggests no packages. -- no debconf information -- 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/20140818174113.328.65520.reportbug@nas0.localnet
Bug#678696: Event based block device handling (fixes USB and nested devices problem)
Package: initramfs-tools
Version: 0.106
Severity: wishlist
Tags: patch
Hi,
the attached patch adds an event based loop for block devices to the
init script. New blockdevices are recorded in
/run/initramfs/block-events by an udev rule as they appear. The init
script repeadately waits for that and then calls
/scripts/local-block/* with a list of new devices storedin NEWDEVS
until $ROOT and $resume (if set) exists or a timeout is reached.
This fixes the problem that USB devices take too long to be
discovered and crypto, raid, lvm or multipath can't be started on
them. It also adds support for arbitrary nestings of them, e.g. raid5
over raid1.
For the event loop I needed the $resume device translated to the
device node earlier. This was previously done in
scripts/local-premount/resume. It was essentially the same code used
to translate the $ROOT so I created a new function translate_device()
in script/functions and used that for both $ROOT and $resume.
Note: hooks/block-event and scripts/block-event are executable, not
represented in the patch.
MfG
Goswin
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Versions of packages initramfs-tools depends on:
ii cpio 2.11-7
ii klibc-utils2.0~rc3-1
ii module-init-tools 3.16-1
ii udev 175-3.1
Versions of packages initramfs-tools recommends:
ii busybox 1:1.19.3-5
Versions of packages initramfs-tools suggests:
ii bash-completion 1:1.99-3
-- no debconf information
Description: event based loop
This patch adds an event based loop for block devices to the init
script. New blockdevices are recorded in /run/initramfs/block-events
by an udev rule as they appear. The init script repeadately waits for
that and then calls /scripts/local-block/* with a list of new devices
storedin NEWDEVS until $ROOT and $resume (if set) exists or a timeout
is reached.
.
This fixes the problem that USB devices take too long to be
discovered and crypto, raid, lvm or multipath can't be started on
them. It also adds support for arbitrary nestings of them, e.g. raid5
over raid1.
.
For the event loop I needed the $resume device translated to the
device node earlier. This was previously done in
scripts/local-premount/resume. It was essentially the same code used
to translate the $ROOT so I created a new function translate_device()
in script/functions and used that for both $ROOT and $resume.
.
Note: hooks/block-event and scripts/block-event are executable, not
represented in the patch.
Author: Goswin von Brederlow
Last-Update: 2012-06-23
--
diff -Nru initramfs-tools-0.106/hooks/block-event initramfs-tools-0.106a0mrvn1/hooks/block-event
--- initramfs-tools-0.106/hooks/block-event 1970-01-01 01:00:00.0 +0100
+++ initramfs-tools-0.106a0mrvn1/hooks/block-event 2012-06-23 18:52:54.0 +0200
@@ -0,0 +1,13 @@
+#!/bin/sh
+
+mkdir -p $DESTDIR/etc/udev/rules.d
+
+cat $DESTDIR/etc/udev/rules.d/99-block-event.rules EOF
+# we are only interested in add and change actions for block devices
+ACTION==remove, GOTO=block_event_end
+SUBSYSTEM!=block, GOTO=block_event_end
+
+RUN+=/scripts/block-event $name
+
+LABEL=block_event_end
+EOF
diff -Nru initramfs-tools-0.106/init initramfs-tools-0.106a0mrvn1/init
--- initramfs-tools-0.106/init 2012-06-06 15:04:52.0 +0200
+++ initramfs-tools-0.106a0mrvn1/init 2012-06-23 21:14:40.0 +0200
@@ -69,41 +69,10 @@
init=${x#init=}
;;
root=*)
- ROOT=${x#root=}
- case $ROOT in
- LABEL=*)
- ROOT=${ROOT#LABEL=}
-
- # support any / in LABEL= path (escape to \x2f)
- case ${ROOT} in
- */*)
- if command -v sed /dev/null 21; then
-ROOT=$(echo ${ROOT} | sed 's,/,\\x2f,g')
- else
-if [ ${ROOT} != ${ROOT#/} ]; then
- ROOT=\x2f${ROOT#/}
-fi
-if [ ${ROOT} != ${ROOT%/} ]; then
- ROOT=${ROOT%/}\x2f
-fi
-IFS='/'
-newroot=
-for s in $ROOT; do
- newroot=${newroot:+${newroot}\\x2f}${s}
-done
-unset IFS
-ROOT=${newroot}
- fi
- esac
- ROOT=/dev/disk/by-label/${ROOT}
- ;;
- UUID=*)
- ROOT=/dev/disk/by-uuid/${ROOT#UUID=}
- ;;
- /dev/nfs)
+ ROOT=$(translate_device ${x#root=})
+ if [ $ROOT = /dev/nfs ]; then
[ -z ${BOOT} ] BOOT=nfs
- ;;
- esac
+ fi
;;
rootflags=*)
ROOTFLAGS=-o ${x#rootflags=}
@@ -190,7 +159,7 @@
export noresume
unset resume
else
- resume=${RESUME:-}
+ resume=$(translate_device ${RESUME:-})
fi
maybe_break top
@@ -205,6 +174,39 @@
[ -n ${netconsole} ] modprobe netconsole netconsole=${netconsole}
+maybe_break events
+TIMEOUT=20
+COUNT=$TIMEOUT
+echo Waiting for $ROOT
+if [ -n $resume ]; then
+ echo Waiting for $resume
+fi
+# run at least once
+touch /dev/.initramfs/block-events
+while [ $COUNT -gt 0
Bug#678696: Event based block device handling (fixes USB and nested devices problem)
Hi,
I filed bugs for cryptsetup, lvm, mdadm and multipath-tools to support
this solution (i.e. provide scripts/local-block/ sniplets) [#678688
#678691 #678692 #678693].
If anyone wants to test this prior to those packages being fixed the
scriplets below can be used.
MfG
Goswin
== scripts/local-block/cryptoroot ==
#!/bin/sh
PREREQ=
prereqs()
{
echo $PREREQ
}
case $1 in
# get pre-requisites
prereqs)
prereqs
exit 0
;;
esac
if [ -x /scripts/local-top/cryptoroot ]; then
exec /scripts/local-top/cryptoroot
fi
== scripts/local-block/lvm2 ==
#!/bin/sh
PREREQ=
prereqs()
{
echo $PREREQ
}
case $1 in
# get pre-requisites
prereqs)
prereqs
exit 0
;;
esac
if [ -x /scripts/local-top/lvm2 ]; then
exec /scripts/local-top/lvm2
fi
== scripts/local-block/mdadm ==
#!/bin/sh
PREREQ=
prereqs()
{
echo $PREREQ
}
case $1 in
# get pre-requisites
prereqs)
prereqs
exit 0
;;
esac
if [ -x /scripts/local-top/mdadm ]; then
exec /scripts/local-top/mdadm
fi
--
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/87obo9byp5.fsf@frosties.localnet
Re: Migration path for 'Multi-Arch:allowed' packages
Ben Hutchings b...@decadent.org.uk writes: On Tue, 2012-06-12 at 17:45 +0200, David Kalnischkies wrote: On Mon, Jun 11, 2012 at 9:40 PM, Michael Gilbert mgilb...@debian.org wrote: In particular, I filed a bug against dpkg requesting that it produce more informative error messages in these cases [0], but I wonder if a part of the solution shouldn't be more automated or at least presented at a higher level through apt/aptitude, etc? Chicken or the egg? You need to upgrade to support MultiArch, but you need MultiArch to upgrade⦠(beside, how would the detection for such a message look like?) [...] Maybe all maintainers who want to use Multi-Arch now in wheezy (and therefore drop amd64 packages) should get together and write a what to do after the distribution upgrade for the release notes, a (low priority) debconf message and if you want to be really fancy a transitional package which shows the same text in case the dropped binaries are executed. [...] I'd be interested in this for linux-image-amd64:i386. Currently I expect linux-image-3.2.0-n-amd64:i386 to remain in wheezy but we'll still need to advise the user to enable amd64 ready for wheezy+1. If we can document multi-arch well enough in release notes etc. then it might be possible to drop it now. Ben. Luckily you have an i386 package that will be updated to. So you can add something to the NEWS file or even pop up a debconf message telling the user about going multiarch. MfG Goswin -- 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/87haua5gjg.fsf@frosties.localnet
Re: amd64 as default architecture
Ben Hutchings b...@decadent.org.uk writes: On Sun, 2012-05-20 at 11:27 +0200, Goswin von Brederlow wrote: Ben Hutchings b...@decadent.org.uk writes: Eventually (wheezy+2? +3?) we would stop building a kernel package for i386. As in drop the i386 arch? No, keep i386 userland only. Though we might consider reducing even that to a 'partial architecture' that has only libraries (similar to ia32-libs today, only cleaner). Ben. Which basically means i386 is droped but we still support 32bit stuff for amd64. Isn't there still a large demand for i386 in the industry/embedded sector? MfG Goswin -- 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/87396fnyhz.fsf@frosties.localnet
Re: amd64 as default architecture
Ben Hutchings b...@decadent.org.uk writes:
Most new PCs have an Intel or AMD 64-bit processor, and
popcon.debian.org shows amd64 numbers almost matching i386.
For some time we have also provided the amd64 kernel for i386, identical
in all but the package metadata. This has not always been perfectly
compatible with i386 userland, but split 32/64-bit installations are
increasingly used and I think most bugs have been flushed out by now.
Thanks to multi-arch you can now add amd64 as a secondary architecture
and install the kernel package from amd64, and if your system is running
such a kernel then it can also support userland packages from amd64.
So in wheezy I would like to see:
1. Default architecture (top of the list for installation media/manual)
being amd64 ('64-bit PC').
Default image could be multiple archs. We had i386/amd64/ppc DVD images
in the past and that seems like the best default. It simply works (near
enough) everywhere. Doesn't work for all image types but where it does ...
2. Users of the amd64 kernel flavour on i386 encouraged to add amd64 as
a secondary architecture (debconf note?).
2b. Have D-I ask wether to enable multiarch on amd64 on i386 if it
installed the amd64 kernel image but also i386 on amd64.
Slightly OT but I wanted to mention it for its similarity:
One thing that should be tested and then documented prominently as yay
or nay in the wheezy upgrade notes is wether one can cross-grade from
i386 to amd64 using multiarch. Wether one can install apt/dpkg:amd64 and
then migrate to a 64bit userspace.
Then in wheezy+1:
3. amd64 kernel flavour for i386 dropped.
4. Kernel and common libraries for amd64 included in i386 installation
media; kernel included on low-number disc.
5. Installer for i386 prefers amd64 kernel on any capable machine
(that's a one-line change!) and adds amd64 as secondary architecture if
this is selected.
D-I (libdebian-installer) must be multiarch aware for that then.
Otherwise it won't see the amd64 kernel in the first place.
Eventually (wheezy+2? +3?) we would stop building a kernel package for
i386.
As in drop the i386 arch?
Does anyone see a problem with the above, in particular points 1 and 2?
No problem as such, just more ideas.
(Also, much of the above applies to s390x vs s390. And please let's
have ppc64 and sparc64 soon!)
Ben.
MfG
Goswin
--
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/87mx53i4mv.fsf@frosties.localnet
Bug#661996: Missing Recommends: linux-tools
Package: linux-base Version: 3.4 Severity: normal Hi, linux-base contains /usr/bin/perf but running that gives: mrvn@frosties:~% perf /usr/bin/perf: line 24: exec: perf_3.1: not found E: linux-tools-3.1 is not installed. A Recommends: linux-tools would ensure that at least the perf_x.y for the current kernel is normally installed. I've also filed a bug against linux-tools-3.2 that there should be a more generic perf_3, in which case linux-base should recommend that. MfG Goswin -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.1.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages linux-base depends on: ii debconf [debconf-2.0] 1.5.41 ii libuuid-perl 0.02-4+b2 ii udev 175-2 ii util-linux 2.20.1-1 linux-base recommends no packages. linux-base suggests no packages. -- debconf information excluded -- 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/20120303121254.4459.98593.reportbug@frosties.localnet
Bug#661998: version requirement too specific
Package: linux-tools-3.2 Version: 3.2.1-2 Severity: important Hi, running perf gives: mrvn@frosties:~% perf /usr/bin/perf: line 24: exec: perf_3.1: not found E: linux-tools-3.1 is not installed. But the linux-tools-3.1 package does no exist. There is only a linux-tools-3.2 package. On the other hand calling perf_3.2 directly seems to work just fine despite running a 3.1 kernel. So why is there such a close version requirement between perf and linux-tools-x.y? Why isn't there a perf_3 binary or just an alternative that works with 3.x kernels in general If there actualy is a good reason for the strict version requirement then please do make sure that linux-tools-x.y packages stick around longer. MfG Goswin -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.1.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages linux-tools-3.2 depends on: ii libc6 2.13-21 ii libdw10.153-1 ii libelf1 0.152-1+b1 ii libnewt0.52 0.52.11-2.1 ii libperl5.14 5.14.2-7 ii libpython2.7 2.7.2-7 ii libslang2 2.2.4-3 ii perl 5.14.2-7 ii python2.7.2-9 Versions of packages linux-tools-3.2 recommends: ii linux-base 3.4 Versions of packages linux-tools-3.2 suggests: pn linux-doc-3.2 none -- no debconf information -- 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/20120303120409.3144.12839.reportbug@frosties.localnet
Bug#661998: closed by Ben Hutchings b...@decadent.org.uk (Re: Bug#661998: version requirement too specific)
From: Ben Hutchings b...@decadent.org.uk Subject: Re: Bug#661998: version requirement too specific To: 661998-d...@bugs.debian.org Date: Sat, 03 Mar 2012 14:13:09 + On Sat, 2012-03-03 at 13:04 +0100, Goswin von Brederlow wrote: [...] So why is there such a close version requirement between perf and linux-tools-x.y? Why isn't there a perf_3 binary or just an alternative that works with 3.x kernels in general perf version x.y may generally depend on new kernel features in x.y. How does that prevent the existance of a perf_3 binary that requires only features present in all (most) 3.x kernels? Sure you wouldn't get all the bleeding edge features but you would get most functionality. MfG Goswin -- 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/87fwdp76ml.fsf@frosties.localnet
Bug#661996: closed by Ben Hutchings b...@decadent.org.uk (Re: Bug#661996: Missing Recommends: linux-tools)
661996: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661996 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems From: Ben Hutchings b...@decadent.org.uk Subject: Re: Bug#661996: Missing Recommends: linux-tools To: 661996-d...@bugs.debian.org Date: Sat, 03 Mar 2012 14:10:52 + linux-base is installed everywhere; linux-tools should not be. Ben. Then maybe perf should not be part of linux-base? MfG Goswin -- 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/87bood76io.fsf@frosties.localnet
Re: Planning for final lenny point release (5.0.10)
Adam D. Barratt a...@adam-barratt.org.uk writes:
On Mon, 2011-12-12 at 23:05 +, Adam D. Barratt wrote:
Working on the four-monthly schedule for oldstable, the next lenny point
release would be due in early February.
As the security team have recently confirmed that security support for
lenny will end on February 6th (a year after the release of squeeze) it
makes sense to schedule 5.0.10 to be after that date and make it the
final roll-up point release for lenny.
So, security EOL for lenny has now passed. We're in sync with the
security archive and the only missing packages are
openjdk-6/{alpha,ia64} and opie/{arm,armel}. AIUI the chances of those
ever building are remote but, given that we've nothing to lose we might
as well go ahead and accept them in to o-p-u and see what happens[tm].
I can't see any outstanding o-p-u package bugs in the BTS. If there's
any I missed on the list, please yell.
-kernel, -boot - were there any plans for a final kernel and/or d-i
upload for lenny? If so we need to get those sorted asap.
In terms of scheduling for the point release itself, the current
suggestions are:
25-26/2 - Steve's not available for CDs
3-4/3 - Cambridge BSP. Should be do-able as long as I can get decent
connectivity at the right time. :-)
10-11/3 - Joerg mentioned he's not available on the Sunday, but that's
only really an issue if stuff breaks and it then transpires that Mark's
also unavailable to help fix the world.
Thoughts / preferences / anything I missed?
Cheers,
Adam
Should ia32-libs be updated?
MfG
Goswin
--
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/87haysth07.fsf@frosties.localnet
Re: How to tell users that ia32-libs will go away
Ben Hutchings b...@decadent.org.uk writes: On Mon, Feb 13, 2012 at 04:30:47PM +0100, Goswin von Brederlow wrote: Ben Hutchings b...@decadent.org.uk writes: On Sat, 2012-02-11 at 17:33 +0100, Goswin von Brederlow wrote: Bastian Blank wa...@debian.org writes: On Fri, Feb 10, 2012 at 01:00:50PM +0100, Bernhard R. Link wrote: just to have a suiteable kernel would be quite a burden. The -amd64 kernel in i386 arch is some sort of upgrade tool. With multi-arch it gets easier. Either the machine can run 64bit code, than it is irrelevant what packages are installed from which arch. Or it can't, then you don't need the amd64 kernel in the first place. Bastian Actualy that raises an interesting point: If there is no 64bit kernel in i386 then you can not safely enable multiarch to install amd64 packages (in general, kernel my just work). It is kind of a prerequisite. By the same argument you can't ever enable any foreign architecture. This is nonsense. Ben. Why? I can install qemu-user-static and my system will be able to execute e.g. armel code. On the other hand installing linux-image-3.2.0-1-amd64:amd64 would pull in for example module-init-tools:amd64, making it impossible to load/remove modules on the running system or reboot with a 32bit kernel. Currently linux-image-3.2.0-1-amd64:amd64 is effectively uninstallable on i386 since various other packages depend on module-init-tools:i386. However, once #649437 is fixed, module-init-tools:i386 (or rather kmod:i386) will satisfy the dependency. Since dpkg will prefer to install packages from the native architecture, I don't see any problem here. I suppose I'm biased by having actually tested this. Ben. But it is only a preference, not a garanty. With aptitude even pining is just taken as advisement. So there will always be a risk of amd64 packages getting pulled in before the user reboots into a 64bit kernel. As I said, not safe. Are you sure you can get all the bugs fixed and the package and multiarch properly tested so wheezy can rely on it for something as essential as the kernel? MfG Goswin -- 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/87pqdgzs99.fsf@frosties.localnet
Re: How to tell users that ia32-libs will go away
Ben Hutchings b...@decadent.org.uk writes: On Sat, 2012-02-11 at 17:33 +0100, Goswin von Brederlow wrote: Bastian Blank wa...@debian.org writes: On Fri, Feb 10, 2012 at 01:00:50PM +0100, Bernhard R. Link wrote: just to have a suiteable kernel would be quite a burden. The -amd64 kernel in i386 arch is some sort of upgrade tool. With multi-arch it gets easier. Either the machine can run 64bit code, than it is irrelevant what packages are installed from which arch. Or it can't, then you don't need the amd64 kernel in the first place. Bastian Actualy that raises an interesting point: If there is no 64bit kernel in i386 then you can not safely enable multiarch to install amd64 packages (in general, kernel my just work). It is kind of a prerequisite. By the same argument you can't ever enable any foreign architecture. This is nonsense. Ben. Why? I can install qemu-user-static and my system will be able to execute e.g. armel code. On the other hand installing linux-image-3.2.0-1-amd64:amd64 would pull in for example module-init-tools:amd64, making it impossible to load/remove modules on the running system or reboot with a 32bit kernel. MfG Goswin -- 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/87zkcmsqc8.fsf@frosties.localnet
Re: How to tell users that ia32-libs will go away
Bernhard R. Link brl...@debian.org writes: * Ben Hutchings b...@decadent.org.uk [120209 20:45]: There is a similar issue with linux-image-*-amd64, which I would definitely like to remove from i386 as soon as possible. We have metapackages to help with this already, but we still need users to add amd64 as a foreign architecture before upgrading. From a user's point of view I'd really appreciate if that package could be kept. Needing multi-arch enabled (with all the dangers of getting the wrong packages installed or the additional index files to download) just to have a suiteable kernel would be quite a burden. Bernhard R. Link If you are talking just about the kernel then I do agree with you, at least for wheezy. Then again is there really a good reason to stay with a pure 32bit userspace if your system is capable of 64bit? During lasts debconf we had a brain storming session about multiarch and the archive. One of the things that came up was the idea of (how do I put this?) add-on partial architectures. What I mean by that is that you do not want to add all of amd64 to a i386 system or all of i386 to an amd64 system like you said. But you do want a small subset from it, e.g. the amd64 kernel on i386. Think of them as a filter over the Packages file. None of them would have a buildd as they would just be a subset of another arch. With that idea you would have something like i386-amd64 and amd64-i386 as architectures that could be added to your sources.list. [Iirc implementation details where never stated but I think you get the idea.] So maybe you could think about this and flesh out a proposal and specs for this. Note: There was also talk of dropping lilo, grub, isolinux from amd64 and getting them from i386 instead for reasons of not wanting to cross build 16bit/32bit code on amd64. MfG Goswin -- 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/871uq1e3ls.fsf@frosties.localnet
Re: How to tell users that ia32-libs will go away
Bastian Blank wa...@debian.org writes: On Fri, Feb 10, 2012 at 01:00:50PM +0100, Bernhard R. Link wrote: just to have a suiteable kernel would be quite a burden. The -amd64 kernel in i386 arch is some sort of upgrade tool. With multi-arch it gets easier. Either the machine can run 64bit code, than it is irrelevant what packages are installed from which arch. Or it can't, then you don't need the amd64 kernel in the first place. Bastian Actualy that raises an interesting point: If there is no 64bit kernel in i386 then you can not safely enable multiarch to install amd64 packages (in general, kernel my just work). It is kind of a prerequisite. MfG Goswin -- 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/87wr7tcot2.fsf@frosties.localnet
Re: Bug#605090: Linux 3.2 in wheezy
Yves-Alexis Perez cor...@debian.org writes: On mer., 2012-02-01 at 10:34 +0100, Wouter Verhelst wrote: On Wed, Feb 01, 2012 at 10:24:40AM +0100, Yves-Alexis Perez wrote: On mar., 2012-01-31 at 11:01 -0500, micah anderson wrote: What is stopping you from creating another package, that provides the kernel with grsecurity patches applied? Don't bother the kernel team with it, and just maintain it yourself in the archive? Its free software afterall. Honestly, having multiple linux source package in the archive doesn't really sound like a good idea. I don't really think the kernel team would appreciate, I'm pretty sure ftpmasters would disagree, and as a member of the security team, It's definitely something I would object. Well, that's what we have the 'linux-source' packages for: to allow other packages to build-depend on them. Hmhm, that might be a good idea indeed. I need to investigate and try that a bit. Ben, what would kernel team think of that? Regards, -- Yves-Alexis Don't forget to set Build-With: in the resulting binary package. That ensure DAK will keep the right linux-source package around as long as your package is in the repository. Otherwise you will have GPL violations. MfG Goswin -- 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/87zkcss5e4.fsf@frosties.localnet
Re: Uploading linux-2.6 (3.1.5-1)
Ben Hutchings b...@decadent.org.uk writes: I intend to upload linux-2.6 version 3.1.5-1 to unstable this weekend. This is another upstream stable update. It also includes a fix for the FTBFS on mips/mipsel in 3.1.4-1. No ABI bump seems to be necessary. Ben. Shouldn't that be linux-3 or just plain linux now? MfG Goswin -- 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/87wra423ni.fsf@frosties.localnet
Bug#650425: Please add options to set the port range for nfs clients
Package: nfs-common Version: 1:1.2.5-2 Severity: normal Today when I booted one of the NFS mounts used port 873, which is the port used for rsyncd. This then caused errors from inetd because it could not use that port for rsyncd. From nfs(5) I see that one can set a port range to be used by nfs clients but there is no mention of how to actualy go about that. Please add an option to /etc/default/nfs-common to specify a port range and set that range at boot time. MfG Goswin -- Package-specific info: -- rpcinfo -- program vers proto port 104 tcp111 portmapper 103 tcp111 portmapper 102 tcp111 portmapper 104 udp111 portmapper 103 udp111 portmapper 102 udp111 portmapper 1000241 udp 41413 status 1000241 tcp 49714 status 1000211 udp 42490 nlockmgr 1000213 udp 42490 nlockmgr 1000214 udp 42490 nlockmgr 1000211 tcp 59442 nlockmgr 1000213 tcp 59442 nlockmgr 1000214 tcp 59442 nlockmgr 132 tcp 2049 nfs 133 tcp 2049 nfs 134 tcp 2049 nfs 1002272 tcp 2049 1002273 tcp 2049 132 udp 2049 nfs 133 udp 2049 nfs 134 udp 2049 nfs 1002272 udp 2049 1002273 udp 2049 151 udp 46988 mountd 151 tcp 59293 mountd 152 udp 56779 mountd 152 tcp 53044 mountd 153 udp 43068 mountd 153 tcp 41808 mountd -- /etc/default/nfs-common -- NEED_STATD= STATDOPTS= NEED_IDMAPD= NEED_GSSD= -- /etc/idmapd.conf -- [General] Verbosity = 0 Pipefs-Directory = /var/lib/nfs/rpc_pipefs [Mapping] Nobody-User = nobody Nobody-Group = nogroup -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.1.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages nfs-common depends on: ii adduser 3.113 ii initscripts 2.88dsf-13.13 ii libc6 2.13-21 ii libcap2 1:2.22-1 ii libcomerr2 1.42~WIP-2011-11-20-1 ii libdevmapper1.02.1 2:1.02.67-1 ii libevent-1.4-2 1.4.14b-stable-1 ii libgssapi-krb5-21.9.1+dfsg-3 ii libgssglue1 0.3-3.1 ii libk5crypto31.9.1+dfsg-3 ii libkeyutils11.5.2-2 ii libkrb5-3 1.9.1+dfsg-3 ii libnfsidmap20.24-1 ii libtirpc1 0.2.2-5 ii libwrap07.6.q-21 ii lsb-base3.2-28 ii rpcbind 0.2.0-6 ii ucf 3.0025+nmu2 Versions of packages nfs-common recommends: ii python 2.7.2-9 nfs-common suggests no packages. Versions of packages nfs-kernel-server depends on: ii libblkid1 2.19.1-5 ii libc6 2.13-21 ii libcomerr21.42~WIP-2011-11-20-1 ii libgssapi-krb5-2 1.9.1+dfsg-3 ii libgssglue1 0.3-3.1 ii libk5crypto3 1.9.1+dfsg-3 ii libkrb5-3 1.9.1+dfsg-3 ii libnfsidmap2 0.24-1 ii libtirpc1 0.2.2-5 ii libwrap0 7.6.q-21 ii lsb-base 3.2-28 ii ucf 3.0025+nmu2 -- Configuration Files: /etc/default/nfs-common changed [not included] /etc/idmapd.conf changed [not included] -- no debconf information -- 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/2029173629.15291.71643.reportbug@frosties.localnet
Bug#623377: init: don't start in runlevel S *and* 2345
Note: libtirpc.so.1 is now in /lib/$(DEB_HOST_MULTIARCH)/ so the demaons can start before /usr is mounted. -- 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/E1RU0Ph-0001DS-PD@frosties.localnet
Bug#623377: init: don't start in runlevel S *and* 2345
Ben Hutchings b...@decadent.org.uk writes: On Fri, 2011-11-25 at 19:35 +0100, Luk Claes wrote: On 11/25/2011 07:22 PM, Goswin von Brederlow wrote: Note: libtirpc.so.1 is now in /lib/$(DEB_HOST_MULTIARCH)/ so the demaons can start before /usr is mounted. Sure like now, though not everything is available at that time: kerberised access or NFSv4 idmapping for instance. So it still needs to rerun after /usr is available. I think that means we need two init scripts. Ben. At least idmapd should be in / so one can have /usr on NFS4. The same could be said for kerberos but that is probably far less used. What's the point in restricting access to /usr? But if some daemon stays in /usr then there should be seperate scripts to start the stuff on / in rcS.d and the stuff in /usr in rc2.d. Note that ubuntu has seperate upstart scripts for portmap, statd and idmapd already. Maybe it makes sense to split them by daemon for sys-rc too. MfG Goswin -- 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/87zkfjldyo.fsf@frosties.localnet
Re: Increasing minimum 'i386' processor
Matthias Klose d...@debian.org writes: On 11/19/2011 11:42 PM, Ben Hutchings wrote: The i386 architecture was the first in Linux and in Debian, but we have long since dropped support for the original i386-compatible processors and now require a minimum of a 486-class processor. I think it is time to increase the minimum requirement to 586-class, if not for wheezy then immediately after. note that squeeze is built this way, and single packages like openjdk only build for 586. (Later it should be increased further, and eventually i386 should be reduced to a partial architecture that may be installed on amd64 systems.) This would allow the use of optimisations and new instructions throughout userland that improve performance for the vast majority of users. could you give numbers what kind of improvements you would expect? The biggest burden for i386 is the register pressure, which you won't fix with targeting a newer processor. The better approach would be a new port, the x32 architecture; I don't know if anybody did look into building a distribution for this architecture yet. The next thing could be to default to sse2 math instead of x87 (didn't look if this is already the default for x32). Matthias Where the relevant patches added to binutils and gcc for this? MfG Goswin -- 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/87obw3w2uc.fsf@frosties.localnet
Re: Increasing minimum 'i386' processor
Guillem Jover guil...@debian.org writes: Hi! On Sat, 2011-11-19 at 22:42:11 +, Ben Hutchings wrote: The i386 architecture was the first in Linux and in Debian, but we have long since dropped support for the original i386-compatible processors and now require a minimum of a 486-class processor. I think it is time to increase the minimum requirement to 586-class, if not for wheezy then immediately after. (Later it should be increased further, and eventually i386 should be reduced to a partial architecture that may be installed on amd64 systems.) This would allow the use of optimisations and new instructions throughout userland that improve performance for the vast majority of users. It seems gcc has been targetting i586 instruction set by default since gcc 4.4.0-1~exp1, although the triplet was not changed to match. On the discussion regarding multiarch tuples I proposed we should switch the triplet back to i386-linux-gnu to avoid this kind of confusion, fix the internal inconsistency and the one with other architectures (which do not track the base instruction set in the triplet) and so that we can use them directly as the multiarch tuples. For more details please see: http://lists.debian.org/debian-dpkg/2011/02/msg00061.html http://lists.debian.org/debian-dpkg/2011/02/msg00039.html regards, guillem While I agree that the triplet should be unique for all the reasons stated in the two mails I have to disagree with your conclusion to change the gcc triplet to i386-linux-gnu. A gcc compiling for i486-linux-gnu, i585-linux-gnu or even i686-linux-gnu is not compiling for the i386-linux-gnu ABI. You would be making the same mistake that arm does on i*86 too, making the triplet not unique. You could have a normal gcc and a i386-linux-gnu-gcc on your system. MfG Goswin -- 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/87y5vbf2f8.fsf@frosties.localnet
Bug#603858: Mount options for proc conflict with /etc/fstab breaking /etc/init.d/mountall.sh
Ben Hutchings b...@decadent.org.uk writes: On Thu, May 12, 2011 at 08:57:18PM +0200, Goswin von Brederlow wrote: rleigh rle...@codelibre.net writes: [...] tmpfs filesystems are different; here they /do/ differ in the sense that /run, /run/lock, /lib/init/rw etc. /are/ separate unique instances of tmpfs. Here, it might make sense to give them a name other than none or tmpfs in order to distinguish between them--that is to say, the tmpfs instance, rather than the mountpoint. So names such as run, runlock, would provide a unique key for /etc/fstab in addition to the mountpoint. But this is mostly cosmetic, and if we do make such a change we'll need to ensure that it's coordinated between initscripts and initramfs-tools. It really doesn't matter what it is as long as it is consitent. Given that /run and /run/lock aren't yet in use in Debian now would be the time to pick a name and then stick with it. Using run and runlock sounds good, go with that. [...] It does matter, as this is not just a matter for initramfs-tools and initscripts. We also need to agree with systemd and that is cross- distribution. Ben. So what is everyone else using? MfG Goswin -- 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/87pqnm3wcg.fsf@frosties.localnet
Bug#603858: Mount options for proc conflict with /etc/fstab breaking /etc/init.d/mountall.sh
Ben Hutchings b...@decadent.org.uk writes: On Wed, May 11, 2011 at 05:40:52PM +0100, rleigh wrote: [...] The fix for this is straightforward: by making initramfs-tools use the same options as initscripts and any additional user entries in /etc/fstab (which will naturally use the same options as the scripts in order to be functional), mount failures are prevented and existing user configuration is preserved and functional. How is that supposed to work when initramfs-tools mounts directories before /etc/fstab is accessible? Ben. The quick way is to just fix the hardcoded name to match what everything else uses. For the more flexible way the /etc/fstab is accessible when the initramfs is generated. Access it then. That means it still breaks when the user changes the entry or adds an incompatible entry without generating a new initaramfs but that can't be helped. MfG Goswin -- 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/87r583gbm0.fsf@frosties.localnet
Bug#603858: Mount options for proc conflict with /etc/fstab breaking /etc/init.d/mountall.sh
rleigh rle...@codelibre.net writes: On Thu, May 12, 2011 at 05:52:23PM +0200, Goswin von Brederlow wrote: Ben Hutchings b...@decadent.org.uk writes: On Wed, May 11, 2011 at 05:40:52PM +0100, rleigh wrote: [...] The fix for this is straightforward: by making initramfs-tools use the same options as initscripts and any additional user entries in /etc/fstab (which will naturally use the same options as the scripts in order to be functional), mount failures are prevented and existing user configuration is preserved and functional. How is that supposed to work when initramfs-tools mounts directories before /etc/fstab is accessible? Ben. The quick way is to just fix the hardcoded name to match what everything else uses. What, in this context, is everything else? The entry historically used in /etc/fstab, the initscripts, the Debian Installer (which puts the initial entry into /etc/fstab). The only thing that uses a different device is intramfs. At this point in time, initscripts is installed on every Debian system out there. As a result, any customised fstab files will /have/ to use the same names as those in the initscripts unless you edit both /etc/init.d/mount* /and/ fstab. So unless you've taken extraordinary measures, the hardcoded policy /is/ what is in use, and when it comes to changing it we do need to bear in mind that all of the filesystems in question could be in /etc/fstab and if we change it, we break things. Consider the breakage that would result on upgrades, for example. Now, of all the filesystems, only /proc is in /etc/fstab by default, so it's less risky to alter the others, particularly the newer additions such as /run. And /proc is what I was concerned about. Although I do have /sys in there too on most systems. For the more flexible way the /etc/fstab is accessible when the initramfs is generated. Access it then. That means it still breaks when the user changes the entry or adds an incompatible entry without generating a new initaramfs but that can't be helped. This is getting far too complex. Ensuring that all the names are consistent fixes the immediate problem which you reported. Indeed. We can expect a well formed entry in /etc/fstab. There is no good reason why the user would want to change the pseudo device used there. It is enough if initramfs just uses the same device name as everything else expects. The actual problem is that mount (rightly) checks mnt_fsname when it checks if a filesystem is already mounted; if they differ, they aren't the same filesystem. /However/, when it comes to special filesystems which don't have a block device as a backing store, the name /might/ be irrelevant--proc is proc, no matter where you mount it, and the same applies to devpts and sysfs. Maybe the real solution here is that mount should disregard different mnt_fsname for these special kernel filesystems. Having mount ignore the device name when it is a pseudo device sounds feasable. I still would like all packages to use the same device name just for consistencies sake. Also mount might not be the only thing comparing /etc/fstab to /proc/mounts. tmpfs filesystems are different; here they /do/ differ in the sense that /run, /run/lock, /lib/init/rw etc. /are/ separate unique instances of tmpfs. Here, it might make sense to give them a name other than none or tmpfs in order to distinguish between them--that is to say, the tmpfs instance, rather than the mountpoint. So names such as run, runlock, would provide a unique key for /etc/fstab in addition to the mountpoint. But this is mostly cosmetic, and if we do make such a change we'll need to ensure that it's coordinated between initscripts and initramfs-tools. It really doesn't matter what it is as long as it is consitent. Given that /run and /run/lock aren't yet in use in Debian now would be the time to pick a name and then stick with it. Using run and runlock sounds good, go with that. Since /run and /run/lock don't usualy have fstab entries it shouldn't be a problem to change the name for those that have the experimental initscripts installed or for a transition period when initscritps and initramfs disagree on the name. So I don't think any depends/breaks should be needed. MfG Goswin -- 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/8762pfhhm9.fsf@frosties.localnet
Bug#603858: Mount options for proc conflict with /etc/fstab breaking /etc/init.d/mountall.sh
severity 603858 important thanks Steve Langasek vor...@debian.org writes: On Wed, Nov 17, 2010 at 11:04:15PM +0100, Goswin von Brederlow wrote: Package: initramfs-tools Version: 0.93.4 Severity: critical File: /usr/share/initramfs-tools/init Tags: patch How in the world does this count as critical? The /etc/init.d/mountall.sh script reports a red FAILED because of that. This is the only symptom you describe, and that's certainly not critical! Usualy a FAILED message also means the script returns an error, which in turn means insserv stops executing depending scripts in that runlevel and skips to the next. Looking closer at the script I see now that mountall.sh does not report errors through its exit code. So it just makes it impossible to see if something real failed to mount because proc always fails to mount. Sorry for the severity. MfG Goswin -- 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/87eiaissyj@frosties.localnet
Bug#603858: Mount options for proc conflict with /etc/fstab breaking /etc/init.d/mountall.sh
Package: initramfs-tools Version: 0.93.4 Severity: critical File: /usr/share/initramfs-tools/init Tags: patch Hi, I recently installed a squeeze system. The generated /etc/fstab contains the following line: # file system mount point type options dump pass proc/proc procdefaults0 0 But in /usr/share/initramfs-tools/init you have: mount -t proc -o nodev,noexec,nosuid none /proc This causes mount to return an error when mounting all local filesystems because proc and none are different divices and it can't mount /proc again over an existing mountpoint. The /etc/init.d/mountall.sh script reports a red FAILED because of that. Node: /etc/mtab is a link to /proc/mounts here. That might affect this issue. Please change the mount command for proc to: mount -t proc -o nodev,noexec,nosuid proc /proc MfG Goswin -- Package-specific info: -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-book-1 (SMP w/1 CPU core; PREEMPT) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages initramfs-tools depends on: ii cpio 2.10-1 GNU cpio -- a program to manage ar ii findutils 4.4.2-1utilities for finding files--find, ii klibc-utils 1.5.15-1 small utilities built with klibc f ii module-init-tools 3.11-1 tools for managing Linux kernel mo ii udev 161-1 /dev/ and hotplug management daemo Versions of packages initramfs-tools recommends: ii busybox 1:1.14.2-2 Tiny utilities for small and embed initramfs-tools suggests no packages. -- no debconf information -- 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/20101117220415.3113.49703.report...@mailserv.localnet
Bug#589963: preinst fails if awk is unpacked but not configured
Bastian Blank wa...@debian.org writes: On Sat, Jul 24, 2010 at 04:51:50PM -0700, Steve Langasek wrote: Only because it's a cdebootstrap bug. Unless you see something that causes initramfs-tools to be pulled into the essential set (which I do not), this is a cdebootstrap bug for not fulfilling the pre-depends of the essential packages before continuing. At least in Lucid, initramfs-tools is essential: util-linux - upstart(upstart-job) - mountall - plymouth - initramfs-tools You should know better, awk is not essential. Also essential means that it have to work _without_ being configured. I know quite well that awk *is* part of the essential closure, because it's a pre-dependency of an essential package. Even *unpacking* of base-files is not supposed to happen (in an ideal world) before awk has been configured, and you definitely shouldn't be trying to configure *other* packages before the pre-depends of essential packages have been satisfied. In an ideal world, it is possible to configure every essential package with its dependencies and pre-dependendies on its own. Bastian Maybe since awk is essential by way of being a pre-depends of base-files both mawk and gawk should behave as if they were essential. Meaning awk should work with [gm]awk unpacked but not yet configured. If both gawk and mawk create the awk link in preinst if it is missing then awk can be used with [mg]awk unpacked. Probably needs some special hand holding of update-alternatives in postinst for it to work though. But it should be managable. MfG Goswin -- 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/87r5ire96t@frosties.localdomain
Bug#589996: Insane dependency on apt causes kernel to be removed on update
Ben Hutchings b...@decadent.org.uk writes: On Thu, 2010-07-22 at 22:19 +0200, Goswin von Brederlow wrote: Package: linux-base Version: 2.6.32-17 Severity: important Hi, in the linux-image packages there is now a dependency chain from linux-image-2.6... - linux-base - libapt-pkg-perl - libapt-pkg-libc6.9-6-4.8. Which is the virtual package provided by apt to signal the ABI of its library and binary caches. In effect the kernels are locked to a specific ABI version of apt. The problem is that the ABI changes from time to time and every time it does an update of apt will now remove the kernel for the duration of the transition. For an example try installing apt from experimental. Well, that is life you might say. That is what is called a library transition. But here comes the insane part. The 1637 line long perl postinst script of linux-base only depends on apt because of this code at the end: [...] What's really insane is that we don't have a nice and stable library to do this and instead I have to fork every time I want to compare two strings. Ben. Yes, a nice and stable libdpkg is needed. But here it is ONE fork and the script aready forks a zillion times for other tools. So no harm done. MfG Goswin -- 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/87iq46tvv4@frosties.localdomain
Bug#589963: preinst fails if awk is unpacked but not configured
Package: initramfs-tools
Version: 0.96.1
Severity: normal
Hi,
when cdebootstraping an Ubuntu Lucid system initramfs-tools gets
installed now. The problem then is that at the point initramfs-tools
is unpacked the mawk package is unpacked but not configured. That
means the /usr/bin/awk alternative is not yet setup.
O: Selecting previously deselected package mawk.
O: dpkg: regarding .../mawk_1.3.3-15ubuntu2_amd64.deb containing mawk,
pre-dependency problem:
O: mawk pre-depends on libc6 (= 2.11~20100104-0ubuntu3)
O: libc6 is unpacked, but has never been configured.
O: dpkg: warning: ignoring pre-dependency problem!
O: Unpacking mawk (from .../mawk_1.3.3-15ubuntu2_amd64.deb) ...
P: Unpacking package mawk
D: Updating mawk to status 2
O: Selecting previously deselected package base-files.
O: dpkg: regarding .../base-files_5.0.0ubuntu20_amd64.deb containing
base-files, pre-dependency problem:
O: base-files pre-depends on awk
O: mawk provides awk but is unpacked but not configured.
O: dpkg: warning: ignoring pre-dependency problem!
O: Unpacking base-files (from .../base-files_5.0.0ubuntu20_amd64.deb) ...
P: Unpacking package base-files
D: Updating base-files to status 2
...
O: Selecting previously deselected package initramfs-tools.
O: Unpacking initramfs-tools (from .../initramfs-tools_0.92bubuntu78_all.deb) ..
.
P: Unpacking package initramfs-tools
D: Updating initramfs-tools to status 2
O: /var/lib/dpkg/tmp.ci/preinst: 59:
O: awk: not found
O:
O: /var/lib/dpkg/tmp.ci/preinst: 59:
O: awk: not found
O:
O: dpkg: error processing
/var/cache/bootstrap/initramfs-tools_0.92bubuntu78_all.deb (--unpack):
O: subprocess new pre-installation script returned error exit status 127
While this could be blamed on cdebootstrap I think it might be a good
idea to fix initramfs-tools. The relevant command is
awk ' { print $1 } '
which really does not need awk. cut would do instead and avoid the
rather probelamtic pseudo-essential awk issue.
MfG
Goswin
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.31.6-xen-2010.02.18 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Versions of packages initramfs-tools depends on:
ii cpio 2.11-4 GNU cpio -- a program to manage ar
ii findutils4.4.2-1 utilities for finding files--find,
ii klibc-utils 1.5.18-1small utilities built with klibc f
ii module-init-tools3.12~pre2-3 tools for managing Linux kernel mo
ii udev 157-1 /dev/ and hotplug management daemo
Versions of packages initramfs-tools recommends:
ii busybox 1:1.15.3-1 Tiny utilities for small and embed
initramfs-tools suggests no packages.
-- no debconf information
--
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/20100722151026.23132.50164.report...@frosties.localdomain
Bug#589996: Insane dependency on apt causes kernel to be removed on update
Package: linux-base
Version: 2.6.32-17
Severity: important
Hi,
in the linux-image packages there is now a dependency chain from
linux-image-2.6... - linux-base - libapt-pkg-perl -
libapt-pkg-libc6.9-6-4.8. Which is the virtual package provided by apt
to signal the ABI of its library and binary caches. In effect the
kernels are locked to a specific ABI version of apt. The problem is
that the ABI changes from time to time and every time it does an
update of apt will now remove the kernel for the duration of the
transition. For an example try installing apt from experimental.
Well, that is life you might say. That is what is called a library
transition.
But here comes the insane part. The 1637 line long perl postinst
script of linux-base only depends on apt because of this code at the
end:
sub compare_versions {
return $AptPkg::Config::_config-system-versioning-compare(@_);
}
if ($ARGV[0] eq 'reconfigure' || defined($ENV{DEBCONF_RECONFIGURE}) ||
(!is_fresh_installation()
compare_versions($ARGV[1], $libata_transition_ver) 0)) {
DebianKernel::DiskId::transition();
}
Could I suggest replacing this with a call to
system('dpkg', '--compare-versions', $ARGV[1], '', $libata_transition_ver)
That way the dependency on apt can be droped completly.
MfG
Goswin
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.31.6-xen-2010.02.18 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Versions of packages linux-base depends on:
ii debconf [debconf-2.0] 1.5.32 Debian configuration management sy
ii libapt-pkg-perl 0.1.24 Perl interface to libapt-pkg
ii libuuid-perl 0.02-3+b1 Perl extension for using UUID inte
ii udev 157-1 /dev/ and hotplug management daemo
ii util-linux2.17.2-3 Miscellaneous system utilities
linux-base recommends no packages.
linux-base suggests no packages.
-- debconf information excluded
--
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/20100722201936.29008.4321.report...@frosties.localdomain
Bug#567468: md homehost
martin f krafft madd...@debian.org writes: also sprach Goswin von Brederlow goswin-...@web.de [2010.02.23.0831 +0100]: Both filesystems and LVM have UUIDs. Does dm-crypt / LUKS have one too? LVM already identifies PVs using UUIDs, so if you are using anything-on-LVM-on-md, you need not worry about device names anyway. dm-crypt currently needs to be told explicitly to use a base device using /dev/disk/by-uuid if you want it to be flexible. The only issue homehost protects against, I think, is machines that use /dev/md0 directly from grub.conf or fstab. grub.cfg (grub2) uses UUID for grub itself. But the kernel can be bootet with root=/dev/md0. But in that case where does it get the homehost from and since when does kernel raid autoconfig have a homehost? Any other case you have an initramfs that can use LABEL or UUID. Same for fstab. MfG Goswin -- 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/87y6iilqsu@frosties.localdomain
Bug#567468: md homehost
Neil Brown ne...@suse.de writes: On Tue, 23 Feb 2010 07:27:00 +0100 martin f krafft madd...@madduck.net wrote: The only issue homehost protects against, I think, is machines that use /dev/md0 directly from grub.conf or fstab. That is exactly correct. If no code or config file depends on a name like /dev/mdX or /dev/md/foo, then you don't need to be concerned about the whole homehost thing. You can either mount by fs-uuid, or mount e.g. /dev/disk/by-id/md-uuid-8fd0af3f:4fbb94ea:12cc2127:f9855db5 What if you have two raids (one local, one from the other hosts that broke down) and both have LVM on it with /dev/vg/root? Shouldn't it only assemble the local raid (as md0 or whatever) and then only start the local volume group? If it assembles the remote raid as /dev/md127 as well then lvm will have problems and the boot will likely (even randomly) go wrong since only one VG can be activated. I think it is pretty common for admins to configure LVM to the same volume group name on different systems. So if you consider raids being pluged into other systems please keep this in mind. MfG Goswin -- 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/87d3zulpj7@frosties.localdomain
Bug#567468: md homehost
Neil Brown ne...@suse.de writes: On Wed, 24 Feb 2010 14:41:16 +0100 Goswin von Brederlow goswin-...@web.de wrote: Neil Brown ne...@suse.de writes: On Tue, 23 Feb 2010 07:27:00 +0100 martin f krafft madd...@madduck.net wrote: The only issue homehost protects against, I think, is machines that use /dev/md0 directly from grub.conf or fstab. That is exactly correct. If no code or config file depends on a name like /dev/mdX or /dev/md/foo, then you don't need to be concerned about the whole homehost thing. You can either mount by fs-uuid, or mount e.g. /dev/disk/by-id/md-uuid-8fd0af3f:4fbb94ea:12cc2127:f9855db5 What if you have two raids (one local, one from the other hosts that broke down) and both have LVM on it with /dev/vg/root? Shouldn't it only assemble the local raid (as md0 or whatever) and then only start the local volume group? If it assembles the remote raid as /dev/md127 as well then lvm will have problems and the boot will likely (even randomly) go wrong since only one VG can be activated. I think it is pretty common for admins to configure LVM to the same volume group name on different systems. So if you consider raids being pluged into other systems please keep this in mind. You are entirely correct. However lvm problems are not my problems. It has always been my position that the best way to configure md is to explicitly list your arrays in mdadm.conf. But people seem to not like this and want it to all be 'automatic'. So I do my best to make it as automatic as possible but still remove as many of the possible confusion that this can cause as possible. But I cannot remove them all. If you move disks around and boot and lvm gets confused because there are two things call /dev/vg/root, then I'm sorry but there is nothing I can do about that. If you had an mdadm.conf which listed you md arrays, and had auto -all then you can be sure that mdadm would not be contributing to this problem. NeilBrown Yes you can do something about it: Only start the raid arrays with the correct homehost. If the homehost is only used to decide wether the prefered minor in the metadata is used for the device name then I feel the feature is entirely useless. It would only help in stupid configurations, i.e. when you use the device name directly. Another scenario where starting a raid with the wrong homehost would be bad is when the raid is degraded and you have a global spare. You probably wouldn't want the global spare of one host to be used to repair a raid of another host. MfG Goswin PS: If a raid is not listed in mdadm.conf doesn't it currently start too but the name can be random? -- 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/87eik94wg1@frosties.localdomain
Bug#567468: md homehost
Daniel Reurich dan...@centurion.net.nz writes: Could you please put forth the argument for why the homehost must match, and why unconditional auto-assembly is not desirable? Realistically, what problems are we protecting against? I can think of one or two. In the case of network boot, where the kernel and initrd served up via tftp, but the required filesystems are per host raid volumes served up ala ATAoverEthernet, iSCSI etc storage network. This could use the boot network device MAC or dhcp assigned hostname to as the homehost search paramater. This would of course require someway to tell mdadm how to obtain this homehost parameter. This could work well where different groups of hosts using different raid volumes for the root (or other) filesystems, each with a MAC group (first 3 or 4 MAC fields) is used to identify that groups homehost search parameter. To get AoE or iSCSI working you need networking. That means dhcp will already have run and the hostname be set. Another scenario, is a dual boot system that has separate raid volumes for the respective root filesystems, along with a separate initrd image for each OS. A system uuid stored in the initrd would work in this case for the homehost search parameter. Or virtualization with raid in the virtual hosts. The host system will see all the raids of the virtual systems but none of them should be started. MfG Goswin -- 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/87aav0pfz7@frosties.localdomain
Bug#567468: md homehost
martin f krafft madd...@madduck.net writes: also sprach Neil Brown ne...@suse.de [2010.02.23.0330 +0100]: The problem to protect against is any consequence of rearranging devices while the host is off, including attaching devices that previously were attached to a different computer. How often does this happen, and how grave/dangerous are the effects? But if '/' is mounted by a name in /dev/md/, I want to be sure mdadm puts the correct array at that name no matter what other arrays might be visible. Of course it would be nice if this happened, but wouldn't it be acceptable to assume that if someone swaps drives between machines that they ought to know how to deal with the consequences, or at least be ready to tae additional steps to make sure the system still boots as desired? Even if the wrong array appeared as /dev/md0 and was mounted as root device, is there any actual problem, other than inconvenience? Remember that the person who has previously swapped the drives is physically in front of (or behind ;)) the machine. I am unconvinced. I think we should definitely switch to using filesystem-UUIDs over device names, and that is the only real solution to the problem, no? Both filesystems and LVM have UUIDs. Does dm-crypt / LUKS have one too? MfG Goswin -- 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/87635opfwb@frosties.localdomain
Bug#567468: (boot time consequences of) Linux mdadm superblock question.
martin f krafft madd...@madduck.net writes: also sprach Daniel Reurich dan...@centurion.net.nz [2010.02.19.0351 +0100]: But if a generated 'system uuid' value (I just suggested the root fs UUID because it would be highly unlikely to be unchanged, and nobody would be likely to fiddle with it) was copied into a file called /etc/system_uuid and copied into the initrd, then we could add put into mdadms hook script in initramfs-tools, to verify and update the homehost variable in the boot time required raid volumes when ever a new initrd is installed. (This generally happens on debian whenever a kernel is installed and mdadm is installed or upgraded. Neil's point is that no such value exists. The root filesystem UUID is not available when the array is created. And updating the homehost in the RAID metadata at boot time would defeat the purpose of homehost in the first place. As an added protection we could include checks in mdadm shutdown script a check that warns when mdadm.conf doesn't exist and the /etc/system_uuid doesn't match the homehost value in the boottime assembled raid volumes. If we did use the root filesystem UUID for this, we could compare that as well. Debian has no policy for this. There is no way to warn a user and interrupt the shutdown process. It would be useful to have a tool similar to /bin/hostname that could be used to create|read|verify|update the system uuid, which would update all the relevant locations which store and check against this system uuid. Yes, it would be useful to have a system UUID that could be generated by the installer and henceforth written to the newly installed system. This is probably something the LSB should push. But you could also bring it up for discussion on debian-devel. How would that work with network boot where the initrd would have to work for multiple hosts? MfG Goswin -- 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/873a0t4ume@frosties.localdomain
Re: [Pkg-xen-devel] Success with linux-image-2.6.31-1-xen-amd64_2.6.31-2_amd64.deb
Thomas Schwinge tho...@schwinge.name writes: Hello! On Wed, Nov 18, 2009 at 11:54:49PM +0100, I wrote: I finally got back to spending a few hours on working on xenifying this pre-hardware-virtualization AMD64 machine. I re-installed the system. Basing it on stable (Lenny) this time. The ol' combo of xen-hypervisor-3.2-1-amd64 / linux-image-2.6.26-2-xen-amd64 boots fine. Likewise when switching to xen-hypervisor-3.4-amd64. And then the goal, http://hermes.jura.uni-tuebingen.de/~blank/debian/xen-test/linux-image-2.6.31-1-xen-amd64_2.6.31-2_amd64.deb [...] The plan is then to gradually update the system to Debian testing and see whether the booting / lvm / initramfs problems come back. Here we go: http://bugs.debian.org/557645 Regards, Thomas That is a strange one. MfG Goswin -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Custom Kernel Building in Debian
Stephen Powell zlinux...@wowway.com writes: I would like to suggest addressing the building of out-of-tree modules as well. This is kind of a moving target, as Debian does not currently offer a way to build deb packages from out-of-tree modules which have been (prematurely, IMO) converted to DKMS. I'm afraid that's beyond my area of recent experience. The last time I built an out-of-tree module was back in the days when the ALSA drivers were not part of the kernel source tree, and I was using Woody, I think, with a 2.4 kernel. But make-pkpg could do that back then, and I would hope that it still can. I have no experience at all with DKMS. I do mention building out-of-tree modules in passing in my document, but I give no examples because I have none to offer in my recent experience. FYI it can't. The DKMS using modules (vmware specifically) don't build with make-kpkg or module-assistant. That is actualy the reason for the mail. MfG Goswin -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#549647: hda: dma_timer_expiry: dma status == 0x21 errors
Paolo Sala paolo.s...@csaricerche.com writes: Furthermore I can't understand why if I set dma (hdparm -d1 /dev/hda) on, the dma is on even after a reboot; and why if I shut down the pc when I power up again the dma is off again... your conclusion is the hd is failing? While the IDE cable has a RESET line most drives do not fully reset themself when that is triggered. It would not really surprise me that the drive keeps its DMA status over a RESET signal, which is all the drive sees from your reboot. On the other hand if you power up again the drive is initited to defaults and that seems to not include DMA. You can try to save settings with hdparm if you see this again. MfG Goswin -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523735: /etc/kernel/postinst.d/initramfs-tools: please consider supporting the experimental kernel-package out of the box
Manoj Srivastava sriva...@debian.org writes: On Thu, Jul 02 2009, Matthijs Kooijman wrote: Hi all, I've CC'd Manoj on this, since I am proposing a change in kernel-package to solve this bug. [Summary: Kernel package stopped running update-initramfs, but the initramfs-tools postinst hook specifically doesn't run for kernel-package built kernels] 7c7,10 [ -z $2 ] || exit 0 --- [ -z $2 ] || echo warning: not running update-initramfs, see make-kpkg(1) and /usr/share/doc/kernel-package/README.gz for details exit 0 please use unifiedd diffs, aboves is unreadable. Actually, I think the above is quit readable, if you look at the /etc/kernel/postinst.d/initramfs-tools script. Some extra context would have been useful, though. also aboves is wrong as it would also be called by *official* linux-2.6 produced images. I don't think this is true, since the comment in the script says: # kernel-package passes an extra arg; hack to not run under kernel-package [ -z $2 ] || exit 0 So it seems that this line should really only apply to kernel-package generated kernels (official kernels are no longer generated by kernel-package, according to /usr/share/doc/kernel-package/NEWS.Debian.gz). However, just adding a warning line really won't solve anything. It seems the problem is that the initramfs hook script ignores kernel-package (which it should for older versions), which it shouldn't do for the latest version of kernel-package. However, the script really has no way to tell that the kernel currently installing was built by kernel-package = 12.001. Apparently it can only tell that it was called by kernel-package due to a second argument, which official kernels presumably don't pass? If this is so, what use is the argument anyway, if it's not always passed in? From a kernel-package kernel's postinst script: run-parts --verbose --exit-on-error --arg=$version --arg=$realimageloc$kimage-$version /etc/kernel/postinst.d so it seems it passes some location and version as a second argument, but I can't really tell what. I don't know if the interface for scripts in /etc/kernel/postinst.d is documented anywhere? There was some discussion about passing in the maintainer script options via the env variable DEB_MAINT_PARAMS (initiated by Frans Pop on the debian-kernel mailing list), but not anything beyond that. One obvious solution here, would be to let kernel-package no longer pass in the second argument. This makes it compliant with official kernels, the initramfs-tools can no longer distinguish them, and all should be well. Perhaps Manoj can comment on this? The second argument, which is the location of the kernel image (which need not be in /boot, you know) is used by the scripts shipped with kernel-package to create features that would not be otherwise possible -- unless we also remove from kernel-package the ability to install the image in locations other than /boot. One solution is to have the user deploy scripts into /etc/kernel that meets their needs, but this seems to be somewhat tedious for end users. A solution might be to create packages that just contain conffiles in /etc/kernel/, and who provide the virtual package kpkg-image-conf, and have all kernel-package image packages Recommend the virtual package. This way, the user will not be impacted by the inability of the initramfs-tools package's conffile to cater to the other flavours of kernel image packages. manoj As discussed on irc I like the idea of virtual package for conffile sniplets. But just kpkg-image-conf is to limiting. I suggest to create at least kpkg-image-conf-ramdisk and kpkg-image-conf-bootloader. Kernel images build with --initrd would Depends: kpkg-image-conf-ramdisk and all kernel images would Recommends: kpkg-image-conf-bootloader. Other things are possible as well. That doesn't change the problem though. The problem of having to work with both official Debian kernel images and custom build images. I often had both an official image and my own installed. That MUST be supported. MfG Goswin -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Raising minimum CPU requirement for i386 kernel
J.A. Bezemer cos...@wormhole.robuust.nl writes: On Sun, 24 May 2009, Bastian Blank wrote: Hi folks I would like to raise the minimum CPU requirement for the shipped Linux kernels in the i386 port to i686 (with cmov). [..] Popcon gives us some rough numbers to think about: linux-image-2.6-68649518 linux-image-2.6-486 6191 Given that the installer's automatic kernel choice tends to be accurate, we've got quite some non-cmov users. Actually, i386 has got many more non-cmov users than any non-i386/amd64 architecture has _in total_: linux-image-2.6-ixp4xx 772 (=arm/armel) linux-image-2.6-powerpc 551 linux-image-2.6-sparc64 192 linux-image-2.6-orion5x 106 (=arm/armel) (rest 100) #include popcon-accuracy-disclaimer.h So, the good work you're doing to keep supporting arm/powerpc/sparc/etc. will actually benefit much less users than the number you'll be annoying when you drop i386 non-cmov ... Best regards, Anne Bezemer And how many people with such low power systems do run popcon? How many use a custom kernel? MfG Goswin -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Critical Temperature
timo 2...@famous-timo.de writes: Hi people, I have got the following problem: At random X is being closed by force and the terminal says «critical temperature reached» and then some high number around 150°C. At the next moment the computer turns off. That problem occurs with linux 2.6.27 till 2.6.28 and does not occur with linux 2.6.26. I have found only a few posts on google. How can I find out whether this is a software or a hardware issue and what might the cause be? regards, Timo Have you checked if this is a false reading or a cooling failure? After the shutdown go into the bios and check the temperature. MfG Goswin -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: fstab update for persistent device names
dann frazier [EMAIL PROTECTED] writes: On Thu, Jul 26, 2007 at 07:42:20PM +0200, Bastian Blank wrote: On Thu, Jul 26, 2007 at 10:47:00AM -0600, dann frazier wrote: We need to decide which arches needs this rewrite now and which value should be filed in. And also, how should we re-write them? Should we just provide documentation, or also provide a utility to do it? You don't want to do things manual if you can automate them. ... No. Maintainer scripts must not change _any_ conffile. What is your idea for implementing this? Creating a utility that must be manually executed by the administrator? If so, how will the the admin be informed that they need to run it - by causing linux-image preinsts to error out if old-style names are detected? Should be after unpacking so the utility exists already. Or not? Or should the util be another package? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: fstab update for persistent device names
Bastian Blank [EMAIL PROTECTED] writes: On Thu, Jul 26, 2007 at 01:23:51PM +0200, Goswin von Brederlow wrote: Which of those change and why? None. I don't see how an libata update would change the serial number of the disk, the filesystem label, /dev/hd* is gone. Bastian Ok, THAT I see. :) At a minimum you could fail in preinst if /dev/hd* is in fstab and recommend to use one of the alternatives and explain how to look up the right value. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Must I use dh_installkpatches for kernel patches?
Hi, I'm looking at the lustre kernel patches and upstream uses quilt to apply sets of patch files depending on the kernel version. So far the lustre debian package uses dh_installkpatches which requires one single patch file per kernel version. Generating the patch file for dh_installkpatches is rather akward as you need the linux-source-x.y.z packages for all supported kernels to make them. Is there some policy for kernel patches I should read up on? Must I use dh_installkpatches for kernel patches? Or can I just write my own apply/unpatch scripts? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: file mounted after debootstrap + udev
[EMAIL PROTECTED] writes: Hi, I've been using debootstrap to produce my live linux based on debian 2.6.18 . At first, my system was built with devfs and everything was fine . Recently, i moved to udev (i added kernel support + udev package) and although the live linux works just fine , after the build process - there are mounted files that i cannot remove from my development machine. If i try to delete my working directory, i got the following error: /bin/rm: cannot remove directory `working_dir/dev/.static/dev': Device or resource busy I've found out the following facts: 1. my build process installs an apache server 2. before running the build process , i had NO apache running 3. after running the build process , i an apache process is running 4. if i kill the apache process, umount the file , i can remove the directory My questions: - How come the build process starts an apache ? i thought it should just install it... - where should i look for the mount or apache installation scripts ? (it's not my scripts...so i have no idea... i'm kinda a newbie in this area...) - am i doing something wrong ? how can i prevent this behaviour ? - what's the standard procedure for building/installing a live linux with apache ? tnx, zferentz For this specific case see the other mails. But generally you need to do the following (or at least check them unneccessary): 1. check for any processes left running in the chroot. Check the /proc/root link of each pid and hope you have to fork bomb like process in the chroot. 2. check for any filesystems left mounted below the chroot. Use /proc/mounts and not /etc/mtab (or mount output) as that may be incorrect. 3. remove working_dir If any step fails you have to abort. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian kernel packaging: changes forthcoming in kernel-package 11.x
Hi, nice to hear about new ideas and fresh developement now that etch is out of the way. Manoj Srivastava [EMAIL PROTECTED] writes: Third, I want to do away with the postinst deciding which initrd generator to run. The current initramfs packages already have commands to create the initrd; and these packages can again dump in scripts to run the initrd generator in /etc/kernel/*.d. This is the chance that initrd generator people have to fix the interface that they have been complaining about. At work we have many systems with a custom kernel that has all boot hardware support build in (no need for initrd) but they have / on lvm (needs initrd). So what I would like would be to have one initrd for all kernels but still have it update if lvm or mdadm requires a change. If anyone is writing a /etc/kernel/*.d script for initrd please try to implement this feature. Finally, I want to have kernel-package come closer to the version numbering scheme that the official kernel images have been using, complete with native flavour support, but this can be dealt with in a separate thread. The critical issues are: a) How to configure which one of competing boot-loader scripts get run, if more than one boot loaders are installed b) Which initramfs generator gets run, if we have more than one installed. c) What information would the scripts need, apart from kernel version, and the location of the image? d) How do we transition the changes -- wait for all involved packages to create a changed version, and upload all packages at once in a staged fashion, or just stagger it into Sid? Experimental? The first two issues are specific instances of the general problem of how to configure any set of cooperating scripts; and a solution similar to those used for init scripts can be adopted (/etc/default/script-or-package-name) So, the next step should be to create example symlink, boot-loader invocation, and initrd invocation scripts for people to dump into /etc/kernel. I was thinking of also including these examples into the kernel image packages, even if there is some duplication on disk of these small examples, at least while the transition is still going on. It might be a good idea to have a debconf frontend to chose scriplets and then install them with ucf. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#417995: initramfs-tools: lets ordinary users read the root filesystem's raw block device
Steve Langasek [EMAIL PROTECTED] writes:
On Fri, Apr 06, 2007 at 01:39:35AM +0200, Fabian Pietsch wrote:
--- /usr/share/initramfs-tools/scripts/functions.orig
+++ /usr/share/initramfs-tools/scripts/functions
@@ -231,6 +231,7 @@
;;
esac
mknod /dev/root b ${major} ${minor}
+chmod go-rw /dev/root
ROOT=/dev/root
}
This looks like an appropriate fix to me.
Cheers,
Wouldn't it be better to set the mode instead of alter it? What if the
next mknod decides to not give r permissions on /dev/root or
something? Just seems more robust to chmod to 0400 or 0600.
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#410039: No /usr/lib/xen folder so it's confusing other packages
Thomas Goirand [EMAIL PROTECTED] writes: Goswin von Brederlow wrote: Thomas Goirand [EMAIL PROTECTED] writes: Goswin von Brederlow wrote: The problem is that multiple xen versions (3.0-unstable, 3.0.3, 3.0.4) can be installed and they are incompatible with each other. If each one contained /usr/lib/python/xen then the packages would have to conflict. I understood that, for sure! What you need is a common package that contains wrapper scripts in /usr/lib/python/xen that will pick the right /usr/lib/xen-VERSION/lib/python subdir applicable to the running xen version. Maybe xen-utils-common is what you should be using? Maybe a script run at startup could check for the xen version that is running and make the appropriate symlink? Sure that could be in a xen-common package, for example... Is that what xen-utils-common does? Thomas /usr is (potentially) read-only. You can only write there during install time which is not enough. You would have to put a static link to /var/lib/xen and then have a dynamic link there or something. MfG Goswin Then what's the solution??? Thomas Beats me. The xen maintainer(s) have to make a choice there. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#410039: No /usr/lib/xen folder so it's confusing other packages
Thomas Goirand [EMAIL PROTECTED] writes: Goswin von Brederlow wrote: The problem is that multiple xen versions (3.0-unstable, 3.0.3, 3.0.4) can be installed and they are incompatible with each other. If each one contained /usr/lib/python/xen then the packages would have to conflict. I understood that, for sure! What you need is a common package that contains wrapper scripts in /usr/lib/python/xen that will pick the right /usr/lib/xen-VERSION/lib/python subdir applicable to the running xen version. Maybe xen-utils-common is what you should be using? Maybe a script run at startup could check for the xen version that is running and make the appropriate symlink? Sure that could be in a xen-common package, for example... Is that what xen-utils-common does? Thomas /usr is (potentially) read-only. You can only write there during install time which is not enough. You would have to put a static link to /var/lib/xen and then have a dynamic link there or something. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#411663: linux-image-2.6.18-4-amd64: iptables do not work correctly with amd64 kernel
[EMAIL PROTECTED] writes: Package: linux-image-2.6.18-4-amd64 Version: 2.6.18.dfsg.1-10 Severity: normal It seems that the 32bit iptables package do not work correctly together with the (i386) amd64 kernel. After installing this kernel, shorewall do not start anymore. Here you can see snippets of the logs: snippet of /var/log/shorewall-init.log: ... Processing /etc/shorewall/continue ... ip6tables v1.3.6: can't initialize ip6tables table `filter': Invalid argument Perhaps ip6tables or your kernel needs to be upgraded. ip6tables v1.3.6: can't initialize ip6tables table `filter': Bad file descriptor Perhaps ip6tables or your kernel needs to be upgraded. ... Setting up TC Rules... iptables: Invalid argument ERROR: Command /sbin/iptables -t mangle -A tcpre -s 0.0.0.0/0 -d 0.0.0.0/0 -p icmp --icmp-type echo-request -j MARK --set-mark 1 Failed ... Wow, another one of those alignment changes. For now there is a patch in the BTS to build an iptables64 package on i386 that you can use or you can install the amd64 iptables with --force-architecture along with amd64-libs. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel image: difference between xen and xen-vserver
Rakotomandimby (R12y) Mihamina [EMAIL PROTECTED] writes: Hi, What is the difference between those two kernels? Their description is the same and I dont know which one to take... http://packages.debian.org/unstable/admin/linux-image-2.6.18-4-xen-amd64 http://packages.debian.org/unstable/admin/linux-image-2.6.18-4-xen-vserver-amd64 Thank you for your answer One has vserver support and one does not. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel 2.6.19
Otavio Salvador [EMAIL PROTECTED] writes: maximilian attems [EMAIL PROTECTED] writes: On Thu, Feb 01, 2007 at 10:14:10AM +0100, Matthias Popp wrote: Hallo, Why is kernel 2.6.19 removed from here ? http://kernel-archive.buildserver.net/debian-kernel/pool/main/l/linux-2.6/ just use the 2.6.20-rc6 I noticed that some flavours aren't being build yet. Does anyone has any idea when XEN could be add on 2.6.20-rc6 packages? When redhat gets their xen 2.6.20 mercurial repository to actualy compile so a xen patch can be extracted I guess. They do have a working 2.6.19.2 branch though. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian-kernel-maint
dann frazier [EMAIL PROTECTED] writes: On Fri, Feb 09, 2007 at 10:47:58PM -0800, Jurij Smakov wrote: I believe the original idea was to create d-k-m for discussions and keep d-k as the address in maintainer field (and the primary contact address for the user requests). This appears to be the most straightforward way, as it requires no changes. That seems inherently conflicting because external people are most likely to start discussions on the maintainer address. And wouldn't every user have to subscribe to the other list? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#410039: No /usr/lib/xen folder so it's confusing other packages
Thomas GOIRAND [EMAIL PROTECTED] writes: Package: linux-image-2.6-xen-686 Severity: wishlist Hello, Our package, dtc-xen, uses /usr/lib/python/xen installed by the normal xen source package using make install. With this package, there is no such folder, but instead something with version number like this: /usr/lib/xen-3.0.3-1/lib/python. So we cannot include the xen python bindings for xen.xm that we use to start and stop a VM. Of course, there is no error when using the source version of xen from xensource.com. I highly think that not having this /usr/lib/python/xen folder under the Debian package is really problematic. The problem is that multiple xen versions (3.0-unstable, 3.0.3, 3.0.4) can be installed and they are incompatible with each other. If each one contained /usr/lib/python/xen then the packages would have to conflict. What you need is a common package that contains wrapper scripts in /usr/lib/python/xen that will pick the right /usr/lib/xen-VERSION/lib/python subdir applicable to the running xen version. Maybe xen-utils-common is what you should be using? As there would be a problem to just insert a symlink in the package itself (diversion problems when upgrading or when you want to have both versions installed at the same time), my suggestion is that the postinst of the package creates a symlink in /usr/lib/python/xen so that it always works. Note that our package (dtc-xen) will not care if it's not the corresponding kernel that is started, I believe, but this would for sure solve our issues. What if you remove the package? The postrm would remove the symlink. But it would not create a symlink to an alternative version normaly. This sounds more like a job for update-alternatives but can you use that on directories? And only if it truely doesn't matter what version you end up with. I'd appreciate A LOT if this was fixed. Note that I have filed a bug only for this i686 version, but of course, the same problem occurs when running on amd64 and other images. Best regards and thanks for this work, Thomas Goirand MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch: Debian kernel compilation with Xen support
JSergey [EMAIL PROTECTED] writes: Please help: how to make Debian kernel (2.6.18) with Xen 3 support? Precompiled Debian kernels does not support my hardware (backport for intel-agp is needed). I use script from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=382699;msg=12 and commands: $ tar xfvj /usr/src/linux-source-2.6.18.tar.bz2 $ cd linux-source-2.6.18 $ cp /boot/config-2.6.18-3-amd64 .config $ make-kpkg --added-patches xen clean $ fakeroot make-kpkg --added-patches xen --config=menuconfig --initrd kernel-image I enable Privileged guest in menuconfig, but this kernel does not work (message from grub: unknown executable format). Did you add a grub menu entry like the xen doku says? You need to boot the hypervisor and add the kernel and initrd as modules. You should install xen-linux-system... to get all depends installed and then you have an automatic entry from the official debian kernel as a template. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#408093: closed by Bastian Blank (Re:Bug#408093: linux-image-2.6.18-3-xen-686: CONFIG_LEGACY_PTY_COUNT=16)
Stijn Tintel [EMAIL PROTECTED] writes: Goswin von Brederlow wrote: Stijn Tintel [EMAIL PROTECTED] writes: Bastian The machine were I reported this problem from, is running Debian Etch + Xen. Everything is installed from packages from the Etch repository, no self-built packages, etc. Do you have devpts mounted? MfG Goswin Right, I didn't have it mounted. Now I just feel stupid, thanks for the suggestion. The weird thing is that on all my Debian boxes, devpts get's mounted automatically, although there is no line for it in their /etc/fstab. Only on Xen domU's running Debian, it's not mounted automatically. But I guess I should just add it to fstab... Thanks Stijn grep devpts /etc/init.d/* You must be missing one of the packages that usualy mount it. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#408093: closed by Bastian Blank (Re:Bug#408093: linux-image-2.6.18-3-xen-686: CONFIG_LEGACY_PTY_COUNT=16)
Stijn Tintel [EMAIL PROTECTED] writes: Bastian The machine were I reported this problem from, is running Debian Etch + Xen. Everything is installed from packages from the Etch repository, no self-built packages, etc. Do you have devpts mounted? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407263: initramfs-tools: resume2 from lvm/dm-crypt not possible
maximilian attems [EMAIL PROTECTED] writes: On Thu, Jan 18, 2007 at 03:21:57PM +0100, Goswin von Brederlow wrote: Daniel Maier [EMAIL PROTECTED] writes: Package: initramfs-tools Version: 0.85e Severity: normal Please add the possibility to resume from lvm/dm-crypt using suspend2 or similar. Please test this with: swap on dm-crypt swap on dm-crypt on lvm swap on lvm on dm-crypt swap on raid swap on dm-crypt on raid swap on lvm on raid swap on dm-crypt on lvm on raid swap on lvm on dm-crypt on raid to name the likely combinations. Also test all these with evms, plain file and crypted file. Most importantly all the automatic partitionings of D-I must work. MfG Goswin are you crazy? i don't care about suspend2, it's not to be merged in current state. it's simple to write an hook script that supports suspend2, i'd be surprised if the debian userspace doesn't do it anyway. -- maks This was for whoever writes those hook scripts, not neccessarily you. I would assume the suspend2 maintainer (if there is one) would have to write the scripts. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407263: initramfs-tools: resume2 from lvm/dm-crypt not possible
Daniel Maier [EMAIL PROTECTED] writes: Package: initramfs-tools Version: 0.85e Severity: normal Please add the possibility to resume from lvm/dm-crypt using suspend2 or similar. Please test this with: swap on dm-crypt swap on dm-crypt on lvm swap on lvm on dm-crypt swap on raid swap on dm-crypt on raid swap on lvm on raid swap on dm-crypt on lvm on raid swap on lvm on dm-crypt on raid to name the likely combinations. Also test all these with evms, plain file and crypted file. Most importantly all the automatic partitionings of D-I must work. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How do I build a XEN kernel with make-kpkg
Rainer Koenig [EMAIL PROTECTED] writes: Ok. Next try. Finding some sort of HowTos on the net, one describing that I need the XEN source package that applies patches to the kernel and then compile it. Whatever I do with 2.6.18 the kernel build process exits with errors that show me that something is very wrong in the kernel source tree. So I'm stuck, but I wonder: There IS a package linux-image-2.6.18-3-xen-686 so it SHOULD be possible to build such an image. But HOW can I do that? Is there any sort of magic spell that I have to say before building it or am I just missing an important point? The debian patch package is incompatible to make-kpkg. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=382699 I was sure I did send in the workaround for xen but can't see it in the BTS. So here we go again (CCing the bug). As a quick fix for xen do: mkdir /usr/src/kernel-patches/all/2.6.18/xen/ cat /usr/src/kernel-patches/all/2.6.18/apply/xen EOF #!/bin/sh echo Applying debian patch with xen parts if [ -z $KPKG_ARCH ]; then KPKG_ARCH=$(dpkg-architecture -qDEB_HOST_ARCH) fi /usr/src/kernel-patches/all/2.6.18/apply/debian --arch $KPKG_ARCH --subarch xen EOF cat /usr/src/kernel-patches/all/2.6.18/unpatch/xen EOF #!/bin/sh set -e upstream=2.6.18 exec /usr/src/kernel-patches/all/$upstream/apply/debian $upstream-0 EOF chmod a+x /usr/src/kernel-patches/all/2.6.18/apply/xen /usr/src/kernel-patches/all/2.6.18/unpatch/xen After that you can use make-kpkg --added-patches xen clean make-kpkg --added-patches xen kernel-image The same can be done for vserver and xen-vserver. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.19, kernel-package problems and what are our plans for etch ...
Sven Luther [EMAIL PROTECTED] writes: On Fri, Dec 15, 2006 at 04:40:16PM +0100, Goswin von Brederlow wrote: From personal experience I must say that bugs reported against kernel-package get manojs attention fast and get fixed fast. Bugs against the linux-2.6 source get ignored or you get comments like breaks cross building and any request of the error or a build log gets ignored. ... I think the blame is much more on the kernel team than manoj. He doesn't have a crystal ball to see linux-2.6 problems relevant to kernel-package. The team has to report them first. Only then can you have a discussion about the problems and find solutions. Well, the real problem is that Manoj could be part of the kernel team, and to a point even is, since he has svn access to the repo. But there is a problem, in that Manoj's principal preocupacion is those user who build their own kernel, and the official kernel is only an after thought (not mentioning memories of when he was the debian kernel maintainer all those years ago and whatnot), while Bastian handles most of the official kernel infrastructure, and obviously doesn't care much about self-built ones. And Bastian is decidetly anti make-kpkg and wants to remove all make-kpkg use from linux-2.6 as stated several times now. You can see beginings of that in the xen kernels. Further one result of this dislike of kernel-package seems to be that you can't build proper custom kernels on mips, mipsel, s390 and ppc and no xen or vserver flavours anywhere. The debian patch is not make-kpkg compatible and again Bastian spoke against fixing the patch to work with kernel-package. So, basically, the problem is of two infrastructure people, both proud and head-strong, and both pulling the stuff in their own separate direction. I don't think pointing the fingers about responsability will help in any way here, but more cooperacion on both sides would be helpful. Let's all have a kernel-team meeting somewhere post-etch, and try to work together or something ? One can dream. Friendly, Sven Luther MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.19, kernel-package problems and what are our plans for etch ...
Sven Luther [EMAIL PROTECTED] writes: On Sat, Dec 02, 2006 at 12:43:06PM -0600, Manoj Srivastava wrote: On Sat, 2 Dec 2006 11:36:30 +0100, Bastian Blank [EMAIL PROTECTED] said: I'm not longer interrested in communicating errors in software, which is not able to catch errors but reports silent success instead. This is the fourth bug with this result in the last 6 months or so. And none of which you report. If you can't put together a Notice that this is the same problem as the guy with 2.6.11 reported. coherent bug report, you can't expect issues to get resolved. Frankly, k-p works fine when used as expected -- linux-2.6 tries to mould it in a fashion which is not exactly supported, by overriding bits and pieces, and I am not surprised when things do not work as you try to force them to. The real problem is that you don't really integrate well with the kernel team, and have your own agenda. This is also true from the other side though. From personal experience I must say that bugs reported against kernel-package get manojs attention fast and get fixed fast. Bugs against the linux-2.6 source get ignored or you get comments like breaks cross building and any request of the error or a build log gets ignored. What we really need is a strategy where you work better with the kernel team, where we have more communication (also applies to Bastian), and where the stated goal of kernel-package is to build both older kernel and the kernel packages. This would be a good starting point to take Jonas idea again, and move the postinst scripts out of kernel-package and the linux-images, and into separate package ? Even then, I would respond to bug reports which show misbehavior by kernel-package -- which have not exactly been forthcoming, have they? manoj tired of people trying to bend k-p into doing things it is not supposed to do, and then complaining when they fail Well, to be honest, it goes both way. I think the blame is much more on the kernel team than manoj. He doesn't have a crystal ball to see linux-2.6 problems relevant to kernel-package. The team has to report them first. Only then can you have a discussion about the problems and find solutions. Friendly, Sven Luther MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379090: Cross building
Hi, I tried cross building on amd64 for i486 and it all went fine. I believe Bastian and Andi when they say cross building breaks but I lack an arch to reproduce it. amd64 is too similar to i386 to trigger it aparently. And I'm not going to build on m68k. So someone needs to send in a build log showing the error for anything to be improved. Bastian hinted at having some patch to fix something but any further info about that is also missing. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: No more than 255 device files with Debian Sarge
Stefan Sperling [EMAIL PROTECTED] writes: Hello! 0. I discovered a strange phenomenon with a Debian Sarge installation. I am able to replicate it on several machines. It occurs on freshly installed machines as well as on older ones. The problem is this: I want to create more than 4000 device files for a project. I am aware that this is an uncommon scenario. But it is a customer request. Generating the device files works well for the first 255 ones. Then the major number is incremented by 1 and the minor number starts over with 0. mknod NEVER returns an error. 1. I tried this with kernel 2.6.8 as well as with kernel 2.6.16 - no change. devfs is removed. I can show this phenomenon on a Debian machine with some example values: nattest:/home/sperl/tmp# mknod testnode1 c 200 16 nattest:/home/sperl/tmp# mknod testnode2 c 200 255 nattest:/home/sperl/tmp# mknod testnode3 c 200 256 nattest:/home/sperl/tmp# mknod testnode4 c 200 511 nattest:/home/sperl/tmp# mknod testnode5 c 200 512 nattest:/home/sperl/tmp# ls -l total 0 crw-r--r-- 1 root root 200, 16 2006-11-23 10:07 testnode1 crw-r--r-- 1 root root 200, 255 2006-11-23 10:07 testnode2 crw-r--r-- 1 root root 201, 0 2006-11-23 10:07 testnode3 crw-r--r-- 1 root root 201, 255 2006-11-23 10:07 testnode4 crw-r--r-- 1 root root 202, 0 2006-11-23 10:07 testnode5 You have 16bit major/minor numbers, 8 bit for major, 8 bit for minor. Since 8 bit can only hold values from 0 to 255 the minor number overflows. I'm assuming the code looks like this: unsigned short major_minor = (major 8) + minor; 2. Doing the same on my Ubuntu installation running a 2.6.15 kernel I get this: [EMAIL PROTECTED]:/home/sperl/tmp2# mknod testnode1 c 200 16 [EMAIL PROTECTED]:/home/sperl/tmp2# mknod testnode2 c 200 255 [EMAIL PROTECTED]:/home/sperl/tmp2# mknod testnode3 c 200 256 [EMAIL PROTECTED]:/home/sperl/tmp2# mknod testnode4 c 200 511 [EMAIL PROTECTED]:/home/sperl/tmp2# mknod testnode5 c 200 512 [EMAIL PROTECTED]:/home/sperl/tmp2# ls -l insgesamt 0 crw-r--r-- 1 root root 200, 16 2006-11-23 10:10 testnode1 crw-r--r-- 1 root root 200, 255 2006-11-23 10:11 testnode2 crw-r--r-- 1 root root 200, 256 2006-11-23 10:11 testnode3 crw-r--r-- 1 root root 200, 511 2006-11-23 10:11 testnode4 crw-r--r-- 1 root root 200, 512 2006-11-23 10:11 testnode5 As you can see, on Ubuntu everything is as expected. Then someone noticed that 16 bit for major+minor are quite restrictive and more and more of it gets used up. What if we run out of major/minor pairs? So they sat down and created bigger major/minor numbers so now there are more of them. 3. I even wrote an own version of mknod to check if there is a bug in the tool. Result: All files are created correctly with Ubuntu but not with Debian. 4. I wrote a tiny device driver just to verify that the minor numbers are not only displayed wrong by ls. Result: I was able to access all devices with major number 200 from my test application but not the ones with 201, 202,... For major number 200 everything looked sane; the minor number I have seen in my open function looked healthy. 5. When I do create a devicefile like testnode3 (with minor number 256) from the Ubuntu machine via NFS this is what happens: On the Ubuntu machine the file looks ok (major 200, minor 256). On the Debian console I see the same file with major 201 and minor 0. 6. When I start my test application and try to open testnode3 on the Debian machine I cannot open the device. 7. I already experimented with the kernel configuration. Even excluding devfs did not help. I found nothing similair in the Debian bug report database nor on the rest of the Internet either. Does anyone of you have an idea? Fetch a newer kernel for debian from backports or compile your own. That should solve the problem. Thanks for reading! Greetings, Stefan MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why does linux-2.6 not use make-kpkg build for xen flavours?
Bastian Blank [EMAIL PROTECTED] writes: On Wed, Nov 22, 2006 at 08:50:38PM +0100, Goswin von Brederlow wrote: when I build linux-2.6 I would like to use both my cpus. So I set CONCURRENCY_LEVEL=2. | $ grep CONCURRENCY_LEVEL -r debian | ./debian/rules.real: setup_env_kpkg_jobs = CONCURRENCY_LEVEL=$(DEBIAN_KERNEL_JOBS) | $ CONCURRENCY_LEVEL is not defined in the included documentation. There is a setting available for that, even if not documented, which works properly: DEBIAN_KERNEL_JOBS. Bastian Thanks, that solves my problem. But not my question. Why don't the xen kernels build with make-kpkg? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379090: preparation for 2.6.18-6 kernel upload on monday 20th of november 2006.
Christian T. Steigies [EMAIL PROTECTED] writes: On Tue, Nov 21, 2006 at 10:05:06AM +0100, Goswin von Brederlow wrote: 3. How else do you build a kernel for a different arch (amd64) than your systems arch (i386)? This is how I build m68k kernels on i386/amd64 machines: DEB_HOST_ARCH=m68k debuild -B -am68k But I guess you want to something slightly different? Christian Exactly. If DEB_HOST_ARCH != DEB_BUILD_ARCH then make-kpkg automatically adds the m68k-gnu-linux- prefix for cross compiling. But building amd64 on i386 has to be done native with the i486-linux-gnu-gcc (or just gcc) as it is not cross-compiling. make-kpkg has the special --cross-compile='-' to tell it to use the native gcc even if DEB_HOST_ARCH != DEB_BUILD_ARCH. Could you apply the patch and check that 'DEB_HOST_ARCH=m68k debuild -B -am68k' still works? If it breaks something I'm happy to fix the patch. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Why does linux-2.6 not use make-kpkg build for xen flavours?
Hi, when I build linux-2.6 I would like to use both my cpus. So I set CONCURRENCY_LEVEL=2. Now the build starts of building the normal images fine with 2 cpus by calling: 28945 pts/3S+ 0:00 bash -e -c cd 'debian/build/build-i386-none-686'; env -u ABINAME -u ARCH -u SUBARCH -u FLAVOUR -u VERSION -u LOCALVERSION -u MAKEFLAGS PATH='/home/mrvn/linux-2.6/linux-2.6-2.6.18/build:/home/mrvn/linux-2.6/linux-2.6-2.6.18/bin:/usr/local/bin:/usr/bin:/bin:/usr/games' make-kpkg --arch 'i386' --stem linux --config silentoldconfig --initrd build Then, when it gets to the xen flavours, it only uses one cpu: 15197 pts/3S+ 0:00 bash -e -c cd 'debian/build/build-i386-xen-vserver-686'; env -u ABINAME -u ARCH -u SUBARCH -u FLAVOUR -u VERSION -u LOCALVERSION -u MAKEFLAGS make Suddenly make-kpkg is not used to compile the kernel. No make-kpkg, no concurrency. WHY? I get that you might use a different install target to split the xen kernel and modules. But why build? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379090: 64bit kernel for i386
Bastian Blank [EMAIL PROTECTED] writes: On Tue, Nov 21, 2006 at 10:05:06AM +0100, Goswin von Brederlow wrote: 1. Who says so? | ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH)) | override CROSS_COMPILE = $(DEB_HOST_GNU_TYPE)- | endif So it works for the not crosscompilation variant. But not for other archs in an arch set. And the linux-2.6 source is hardly the authorative source for make-kpkg syntax. 3. How else do you build a kernel for a different arch (amd64) than your systems arch (i386)? The system is i386 but the kernel architecture is x64_64. amd64 produces packages with amd64 as architecture. The debian arch is i386: DEB_*_ARCH=i386 The make-kpkg arch is amd64: kpkg-arch: amd64 The kernel arch is x86_64: kernel-arch: x86_64 Which is eaxctly what the patch sets. Have you even once tried the patch before guessing? At no time does it build amd64 debs under i386. In fact it does exactly what is is supposed to do. Build 64bit kernels for i386: -- Format: 1.7 Date: Wed, 22 Nov 2006 10:04:07 +0200 Source: linux-2.6 Binary: linux-image-2.6.18-2-powerpc linux-headers-2.6.18-2-mac linux-headers-2.6.18-2-amiga linux-headers-2.6.18-2-xen-686 xen-linux-system-2.6.18-2-xen-k7 linux-headers-2.6.18-2-r3k-kn02 linux-modules-2.6.18-2-xen-vserver-686 linux-headers-2.6.18-2-all-hppa linux-image-2.6.18-2-s3c2410 linux-image-2.6.18-2-xen-686 linux-image-2.6.18-2-ixp4xx linux-image-2.6.18-2-r3k-kn02 linux-headers-2.6.18-2-xen-vserver-686 linux-headers-2.6.18-2-prep linux-headers-2.6.18-2-sb1a-bcm91480b linux-headers-2.6.18-2-vserver-s390x linux-headers-2.6.18-2-parisc linux-image-2.6.18-2-xen-k7 linux-headers-2.6.18-2-vserver linux-headers-2.6.18-2-686 linux-headers-2.6.18-2-qemu linux-headers-2.6.18-2-s3c2410 linux-headers-2.6.18-2-rpc linux-manual-2.6.18 linux-headers-2.6.18-2-s390 linux-headers-2.6.18-2-xen-amd64 linux-image-2.6.18-2-vserver-powerpc linux-image-2.6.18-2-vserver-alpha linux-image-2.6.18-2-amiga linux-image-2.6.18-2-alpha-smp linux-headers-2.6.18-2-all-amd64 linux-image-2.6.18-2-mckin ley linux-image-2.6.18-2-parisc-smp linux-headers-2.6.18-2-all-alpha xen-linux-system-2.6.18-2-xen-amd64 linux-image-2.6.18-2-alpha-legacy linux-image-2.6.18-2-sparc64 linux-image-2.6.18-2-r5k-ip32 linux-image-2.6.18-2-parisc64 linux-headers-2.6.18-2 linux-headers-2.6.18-2-xen-vserver-amd64 linux-image-2.6.18-2-sparc64-smp linux-image-2.6.18-2-itanium linux-headers-2.6.18-2-vserver-amd64 linux-headers-2.6.18-2-all-ia64 linux-modules-2.6.18-2-xen-amd64 linux-image-2.6.18-2-686-bigmem linux-image-2.6.18-2-vserver-686 linux-image-2.6.18-2-s390x linux-headers-2.6.18-2-vserver-sparc64 linux-headers-2.6.18-2-sparc32 linux-headers-2.6.18-2-parisc64-smp linux-modules-2.6.18-2-xen-k7 linux-image-2.6.18-2-rpc linux-image-2.6.18-2-iop32x linux-headers-2.6.18-2-mckinley linux-headers-2.6.18-2-footbridge linux-image-2.6.18-2-amd64 linux-headers-2.6.18-2-powerpc64 linux-image-2.6.18-2-footbridge linux-image-2.6.18-2-vserver-s390x linux-headers-2.6.18-2-all linux-headers-2.6.18-2-powerpc-m iboot linux-modules-2.6.18-2-xen-vserver-amd64 linux-headers-2.6.18-2-vserver-686 linux-image-2.6.18-2-xen-vserver-amd64 linux-headers-2.6.18-2-iop32x linux-headers-2.6.18-2-alpha-legacy linux-headers-2.6.18-2-parisc64 linux-image-2.6.18-2-vserver-sparc64 linux-image-2.6.18-2-parisc64-smp xen-linux-system-2.6.18-2-xen-686 linux-headers-2.6.18-2-k7 linux-image-2.6.18-2-sb1-bcm91250a linux-headers-2.6.18-2-powerpc linux-headers-2.6.18-2-r4k-kn04 linux-image-2.6.18-2-sparc32 linux-headers-2.6.18-2-vserver-powerpc linux-headers-2.6.18-2-all-mipsel linux-headers-2.6.18-2-all-sparc linux-support-2.6.18-2 linux-doc-2.6.18 linux-image-2.6.18-2-686 linux-image-2.6.18-2-486 linux-headers-2.6.18-2-686-bigmem linux-image-2.6.18-2-sb1a-bcm91480b linux-headers-2.6.18-2-r5k-cobalt linux-image-2.6.18-2-k7 linux-headers-2.6.18-2-xen linux-source-2.6.18 linux-image-2.6.18-2-powerpc-miboot linux-headers-2.6.18-2-vserver-powerpc64 linux-headers-2.6.18-2-parisc-smp linux-image-2.6.18-2-powerpc64 linux-headers-2.6.18-2-powerpc-smp linux-image-2.6.18-2-r4k-kn04 linux-headers-2.6.18-2-sparc64-smp linux-headers-2.6.18-2-all-m68k linux-headers-2.6.18-2-r5k-ip32 linux-headers-2.6.18-2-vserver-k7 linux-image-2.6.18-2-vserver-k7 linux-headers-2.6.18-2-xen-vserver linux-image-2.6.18-2-prep linux-image-2.6.18-2-r5k-cobalt linux-headers-2.6.18-2-r4k-ip22 linux-headers-2.6.18-2-s390x linux-headers-2.6.18-2-alpha-smp linux-headers-2.6.18-2-itanium linux-image-2.6.18-2-vserver-amd64 linux-headers-2.6.18-2-all-powerpc linux-image-2.6.18-2-s390 linux-headers-2.6.18-2-xen-k7 linux-headers-2.6.18-2-all-s390 linux-headers-2.6.18-2-all-i386 linux-image-2.6.18-2-mac linux-headers-2.6.18-2-sb1-bcm91250a linux-headers-2.6.18-2-alpha-generic linux-headers-2.6.18-2-all-arm linux-headers-2.6.18-2-vserver-alpha linux-patch-debian-2.6.18
Re: preparation for 2.6.18-6 kernel upload on monday 20th of november 2006.
Sven Luther [EMAIL PROTECTED] writes: On Fri, Nov 17, 2006 at 06:32:54AM +0100, Goswin von Brederlow wrote: Sven Luther [EMAIL PROTECTED] writes: Hi, ... As you may know, or not, we are waiting for the abi-breaking 2.6.18-6 to be uploaded for pushing the 2.6.18 kernel into etch. It seems 2.6.18.3 is announced for saturday, so this would mean a natural tentative schedule of let's say monday the 20th of november 2006 as upload date. Is there any comment on this ? Anyone has any particular stuff they would like included before -6 is released ? Or otherwise comments on this tentative deadline ? Friendly, Sven Luther 64bit i386 kernels even if that adds time to the build. Live with it. Please provide patches to our svn packages that enable it. Just demanding stuff and expecting others to do the work is not nice :) Friendly, Sven Luther Check the BTS. Its been there for ages now. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: preparation for 2.6.18-6 kernel upload on monday 20th of november 2006.
Sven Luther [EMAIL PROTECTED] writes: On Fri, Nov 17, 2006 at 10:20:09PM +0100, Goswin von Brederlow wrote: Sven Luther [EMAIL PROTECTED] writes: On Fri, Nov 17, 2006 at 06:32:54AM +0100, Goswin von Brederlow wrote: Sven Luther [EMAIL PROTECTED] writes: Hi, ... As you may know, or not, we are waiting for the abi-breaking 2.6.18-6 to be uploaded for pushing the 2.6.18 kernel into etch. It seems 2.6.18.3 is announced for saturday, so this would mean a natural tentative schedule of let's say monday the 20th of november 2006 as upload date. Is there any comment on this ? Anyone has any particular stuff they would like included before -6 is released ? Or otherwise comments on this tentative deadline ? Friendly, Sven Luther 64bit i386 kernels even if that adds time to the build. Live with it. Please provide patches to our svn packages that enable it. Just demanding stuff and expecting others to do the work is not nice :) Friendly, Sven Luther Check the BTS. Its been there for ages now. Bug number ? Friendly, Sven Luther #379090 MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: preparation for 2.6.18-6 kernel upload on monday 20th of november 2006.
Sven Luther [EMAIL PROTECTED] writes: Hi, ... As you may know, or not, we are waiting for the abi-breaking 2.6.18-6 to be uploaded for pushing the 2.6.18 kernel into etch. It seems 2.6.18.3 is announced for saturday, so this would mean a natural tentative schedule of let's say monday the 20th of november 2006 as upload date. Is there any comment on this ? Anyone has any particular stuff they would like included before -6 is released ? Or otherwise comments on this tentative deadline ? Friendly, Sven Luther 64bit i386 kernels even if that adds time to the build. Live with it. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396721: [PATCH] Missing compatibility with make-kpkg
Bastian Blank [EMAIL PROTECTED] writes: severity 396721 wishlist retitle 396721 linux-patch-debian - only main debian part usable via make-kpkg thanks On Thu, Nov 02, 2006 at 03:01:03PM +0100, Goswin Brederlow wrote: attached is a compatibility script for make-kpkg to build xen kernels. The script can be used with The xen support is linux-2.6 internal, it is only exported into the patch package as it uses the same infrastructure. Only the main debian part of the patch is compatible with make-kpkg. Bastian Oh come on. That is just not true. The attached patch proves it. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396683: marked as done (linux-source-2.6.18: make-kpkg fails - debian subdirectory missing?)
From: maximilian attems [EMAIL PROTECTED] Subject: Re: Bug#396683: linux-source-2.6.18: make-kpkg fails - debian subdirectory missing? To: [EMAIL PROTECTED] Date: Thu, 2 Nov 2006 17:45:10 +0100 On Thu, Nov 02, 2006 at 05:21:05PM +0100, Meik Hellmund wrote: Goswin von Brederlow [EMAIL PROTECTED] writes: What version of make-kpkg is this? You might have to use the unstable version. You are absolutely right. I used kernel-package 8.135 which is from stable. The current unstable kernel-package runs fine. Sorry for wasting your time. I think this bug can be closed. the common linux-2.6 source needs newer kernel-package since long, it is expressed as correct build-dep. thus closing. best regards Can you think of any way to express that it needs a new enough kernel-package that isn't a depends? I'm thinking Conflicts: kernel-package ( version). That would force an upgrade of kernel-package if installed or removal of same but not install it if missing. Would that be acceptable behaviour? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#372479: what's the difference between xen and xen-vserver
Lu Xuxiao [EMAIL PROTECTED] writes: Is this right that the -xen- kernels are used for both host and guest? You can use the same kernel for host and guest (dom0 and domU) or build seperate kernels. But I think with the split out modules the difference should be marginal. And what are the -xen-vserver- kernels for, xen over vserver? :-) Thanks! I think the other way around vserver under xen domains. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396683: linux-source-2.6.18: make-kpkg fails - debian subdirectory missing?
Meik Hellmund [EMAIL PROTECTED] writes: Goswin von Brederlow [EMAIL PROTECTED] writes: What version of make-kpkg is this? You might have to use the unstable version. You are absolutely right. I used kernel-package 8.135 which is from stable. The current unstable kernel-package runs fine. Sorry for wasting your time. I think this bug can be closed. Best regards, Meik No. The linux-source-2.6.18 should have a versioned depends on kernel-package that pulls in a new enough version. So this is a bug, now we just know the fix for it. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396683: linux-source-2.6.18: make-kpkg fails - debian subdirectory missing?
Meik Hellmund [EMAIL PROTECTED] writes: Package: linux-source-2.6.18 Version: 2.6.18-3 Severity: important # make-kpkg kernel_image /usr/share/kernel-package/rules:1637: *** Error. I do not know where the kernel image goes to [kimagedest undefined] The usual case for this is that I could not determine which arch or subarch tihs machine belongs to. Please specify a subarch, and try again.. Stop. There is no debian subdirectory in the unpacked source file. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-1-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages linux-source-2.6.18 depends on: ii binutils 2.17-3 The GNU assembler, linker and bina ii bzip2 1.0.3-6high-quality block-sorting file co Versions of packages linux-source-2.6.18 recommends: ii gcc 4:4.1.1-13 The GNU C compiler ii libc6-dev [libc-dev] 2.3.6.ds1-7 GNU C Library: Development Librari ii make 3.81-3 The GNU version of the make util -- no debconf information What version of make-kpkg is this? You might have to use the unstable version. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Schedule for linux-2.6 2.6.18-4
Andreas Barth [EMAIL PROTECTED] writes: * Frederik Schueler ([EMAIL PROTECTED]) [061030 16:30]: Fellow kernel-team members, it has been a while since our last upload, and the issues are cumulating. We have a total of 8 RC bugs we need to take care before the release, and another dozen of driver issues we should try to sort out. IMHO, the most pressing issues are: - the ext3 corruption (#392818) - the need to rebuild using a newer kernel-package (#395110) - the broken ABI - renaming the orig.tar.gz in order to remove the 8 firmwares as discussed with the release managers - alpha gcc-4.1 migration Can we also have amd64-kernels again on i386? Cheers, Andi The patch is in the BTS and quite small. About 5 lines of code change and the obvious ton of .config files. The latest statement on this issue is still that adding any more kernel images to the build would exhaust the resources of the build process for the linux team. So what if it takes a bit longer and takes a bit more disk space? Try building on m68k. :) MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Schedule for linux-2.6 2.6.18-4
Goswin von Brederlow [EMAIL PROTECTED] writes: Andreas Barth [EMAIL PROTECTED] writes: Can we also have amd64-kernels again on i386? Cheers, Andi The patch is in the BTS and quite small. About 5 lines of code change and the obvious ton of .config files. Replying to myself, juhey. Sorry for breaking the threading. Could we have one of these compromises? 1) Apply the patch and set the config but keep the actual images commented out. 2) Do 1 and enable one generic 64bit image. No xen, no vserver. Or is even one more images too much? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Schedule for linux-2.6 2.6.18-4
Bastian Blank [EMAIL PROTECTED] writes: On Tue, Oct 31, 2006 at 02:13:33PM +0100, Goswin von Brederlow wrote: So what if it takes a bit longer and takes a bit more disk space? Try building on m68k. :) Ask cts, it takes less. Especialy as m68k currently builds only two images. Bastian He cross-compiles on a fast system. Without that I think it is around 6 hours per image. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383481: Must source code be easy to understand to fall under DFSG?
Ola Lundqvist [EMAIL PROTECTED] writes:
Ok, you are probably right if the person use an automated tool to make
this obfuscation. (Not sure though, see below).
However as it is impossible to know if someone use a obfuscation program
or if the person use a text editor to edit this, I can not see it as
a violation anyway.
At least it is a bit harsh to see it as a policy violation just because
it may be obfuscated.
If you have 'char data[] = { 0xef, 0x45, ... };' and from running a
disassembler it is clear that this was produced with gcc for arm (yes,
that is not too wilde an idea) or some other compiler I think then it
is at least suspect.
Personaly I rather have such a char array under GPL than no driver or
a binary only driver. At least you can perfectly legaly dissasemble
the data and, comment the code and make it readable again.
Ultimately I think the decision is with ftp-master and then you have
to fight hard to reverse that. They usualy make good calls there.
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379090: Still no news on 64bit i386 kernels
Frederik Schueler [EMAIL PROTECTED] writes: Hello, On Tue, Oct 31, 2006 at 01:30:59AM -0800, Steve Langasek wrote: Can someone from the kernel team comment on whether there are problems with this particular patch that have not yet been noted in the bug report? If there aren't any known objections, I could review the patch myself and look at committing it. Adding amd64 as subarch to i386 would mean 3 additional flavors to build, raising the overall build-time of that package by 1.5-2h. And that is a problem? Additionally, I don't know in what state the current cross-build env for i386 is, and building 64bit kernels on i386 might produce abi-incompatible kernels causing even more problems. They aren't exactly cross build. Just with -m64. This is supported upstream in both kernel and gcc and it better not have abi differences. It is also used in libc6, gcc, fakeroot, zlib1g and a bunch of other packages during build. The same method (but much less elegantly) was used in sarge and nobody has reported problems there, have they? So I guess we can rule that out. IMHO the best solution would be to repackage the amd64 debs into i386 ones. This can be trivially done and should not cause any regressions. I asked this before and haven't yet recieved an answere: What does w-b do when the amd64 build uploads amd64+i386 64bit kernel debs but not 32bit. Afaik the package should be detected as incomplete and set to needs-build for i386. i386 then builds the 32bit kernels only and uploads them. Unless someone is willing to test this technical aspect repackaging seems out of question. The real solution for this still is multiarch. I haven't heard much of it since a couple of months, is anyone still actively working on it? Which means, at a minimum, changes to debian-cd and D-I to include the amd64 packages on i386 and the linux64 boot option and a wrapper package for apt/aptitude/dpkg to make the amd64 debs appear and installable. If the patch for 64bit kernel won't get accepted I can upload the wrapper package. Best regards Frederik Schueler MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Schedule for linux-2.6 2.6.18-4
Andreas Barth [EMAIL PROTECTED] writes: * Goswin von Brederlow ([EMAIL PROTECTED]) [061031 17:31]: Goswin von Brederlow [EMAIL PROTECTED] writes: Andreas Barth [EMAIL PROTECTED] writes: Can we also have amd64-kernels again on i386? Cheers, Andi The patch is in the BTS and quite small. About 5 lines of code change and the obvious ton of .config files. Replying to myself, juhey. Sorry for breaking the threading. Could we have one of these compromises? 1) Apply the patch and set the config but keep the actual images commented out. 2) Do 1 and enable one generic 64bit image. No xen, no vserver. Or is even one more images too much? I think xen or vserver are the perfect environment to have both worlds live on the same machine. :) Then try that and make sure the hypervisor has no 32/64 bit problems. Cheers, Andi MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383481: Must source code be easy to understand to fall under DFSG?
Ola Lundqvist [EMAIL PROTECTED] writes: Hi First I want to tell to you Kyle and Matthew, that this is not a personal thing against you, and that I have noted the question mark in the end of the subject (Contains obfuscated source code, DFSG violation?). I actually want to thank you for making me think on what my opinion about open source is. (I have decided to Cc debian-legal, but I'm not subscribed to that list so please CC me if you want me to read it). Now to the reason why I wrote this mail. I have a question about the bugreport (#383481) because I do not understand what the problem is. The source code is there, you can modify it and release it under the same license. Perfectly legal under GPL. Let me take two examples: * Person A create a driver by reverse engineering, determine that by setting a number of memory parts to different values, the hardware will work as expected. Person A do not know why. * Person B create a driver knowing, that by setting a number of memory parts to different values, the hardware will work as expected. Person B knows why. * Person C creates a driver knowing with properly names defines and comments explaining why he does what and where to easily readable structures of the register mappings of the hardware. Person C then goes and obfuscates the code into putting seemingly random values into seemingly random addresses. Person C still uses his unobfuscated code to makes changes but only releases the obfuscated version under GPL. Both persons have released their code under the same license and they look (almost at least) the same. Which one will break DFSG? - Person A? - Person B? - None? - Both? Only C. But deciding if B or C applies it quite impossible. I'll take each item in DFSG and determine it from that points: - #1 Free Redistribution No restriction here. #2 Source Code Source code is available. Not perfectly readable, but this is the source that was released, and licensed away, so yes we have the source. Under GPL (as in my example Person C) you need the prefered form of modification, which is more than what the DFSG strictly called for. But most people might take it as the same (meaning ofuscating is so evil it breaks this rule). #3 Derived Works No restriction. #4 Integrity of The Author's Source Code No restriction, you can change as much as you want. #5 and 6 No Discrimination ... No discrimination on specific groups in the licsense. #7 Distribution of License No problem here. #8 License Must Not Be Specific to Debian No problem here. #9 License Must Not Contaminate Other Software No restriction here. #10 Example Licenses Just examples, and according to the DFSG, GPL is a fully ok license. - MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#395181: missing dependency on libdevmapper1.01
dann frazier [EMAIL PROTECTED] writes: reassign 395181 initrd-tools thanks On Wed, Oct 25, 2006 at 03:05:33PM +0200, martin f krafft wrote: The package is missing a dependency on libdevmapper1.01 Thanks - the issue is most likely with initrd-tools, so reassigning. -- dann frazier On that note there seems to be a versioned conflict between newer 2.6 kernels and libdevmapper causing the filesystem to deadlock. Could you coordinate with the lvm maintainers to get the kernels to conflict with an too old lvm please. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: need distro people opinion on config.gz changes
Oleg Verych [EMAIL PROTECTED] writes: Andrew Morton wants opinions on resent changes in upstream: http://permalink.gmane.org/gmane.linux.kernel/452074 Message-ID: [EMAIL PROTECTED] Say I build a kernel with /proc/config.gz. 2 days later I notice that I forgot some module and just build that. If the config.gz is compiled into the vmlinuz then that won't refelct the actual kernel+modules anymore. If there is a config.ko that could get rebuild on every change to .config and thus include the update to build an extra module. I kind of like that. For distributions I think it is rather irelevant. They build the kernel debs or rpms and that is that. They don't change during use. If the .config changes a complete new deb/rpm is build. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379090: Still no news on 64bit i386 kernels
Hi, just a small reminder that etch still has no 64bit kernels for i386. This is a regression from sarge which has them. The bug (#379090) has a simple patch to reintroduce those kernel images (+5/-1 lines code change and the rest is config) for nearly 100 days without a comment so far. Would it be possible for the release team to make this a release issue and raise the severity of the bug accordingly? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Xen patches used in kernel 2.6.17-2-xen-amd64
Jaume Sabater [EMAIL PROTECTED] writes: Hello everyone! I am currently using a custom kernel 2.6.16.19 with the Xen 3.0.2 patches at Alioth[1]. Just noticed there is a new package linux-image-2.6.17-2-xen-amd64 in the repositories and wondered where could I find the patches that were used to generate that kernel. I am not an expert with Debian packages, but I guess I should be able to get them from the sources of the linux-image-2.6.17-2-xen-amd64 package. I was expecting to be able to download them from Alioth, though. Is is already a stable release? Will they be uploaded to Alioth any time soon? [1] http://alioth.debian.org/project/showfiles.php?group_id=30894 Thanks in advance. The normal debian patch package and linux-2.6 source package contain the xen patches. But you can't apply them with make-kpkg though. You have to manualy invoke the apply script with --arch=amd64 --subarch=xen to get the extra xen patches applied. make-kpkg only sets ENV varibales to that effect but does not pass them along as arguments (and is right to do so). Hopefully this will be fixed soon in the debian patch apply script. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Making a custom vserver capable linux-image-2.6.17 package
Janusz Krzysztofik [EMAIL PROTECTED] writes: Is it possible in 2.6.17 to build a custom linux kernel package using make-kpkg --added-patches vserver, as it was in previous versions? The only way I can see for now is to manualy apply vserver patches found in the linux-patch-debian package. Am I missing something? Janusz I reported a bug on this a while back (for Xen images in my case). The debian patch needs --arch and --subarch arguments but make-kpkg uses the ENV to pass those options. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Sven Luther [EMAIL PROTECTED] writes: If even yourself are not able to understand it, and thus gives bogus advice, i guess you will find nobody. Sven Luther Maybe the reason the now proper advice wasn't given to you was that the feature did not exist back when you asked? Or you asked the question in a way that didn't trigger the right answere. I highly doubt understanding of the kernel-wedge was at fault here. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Sven Luther [EMAIL PROTECTED] writes: On Sun, Aug 13, 2006 at 07:14:02PM +0200, Goswin von Brederlow wrote: Moving the problem from A to B. Doesn't matter what svn repository it is in. Yes, it does matter. If it is inside kernel-wedge, you need to upload kernel wedge to benefit from any fix, while if it is in d-i, you can just build the out-of-svn tree and be happy. And I can just as easily build the kernel-wedge out-of-svn. That really makes no difference. Furthermore, the build, failure, check what the heck kernel module has changed name or dissapeared, or whatnot, is a *ROYAL PAIN*, and very much time consuming., especially on slow arches with lot of flavours. A factor of 1 or so faster than building the linux-2.6 source. As combined time the kernel-wedge time is neglible. Ah, but the beauty of my proposal is that you have tool which handles the config files and module-as-udebs without needing to do a full build. Like Bastian created the nice debian/rules target to check all config options. Which helps exactly 0 if you build all the kernels and then detect that a module was not manualy maintained in the to be udeb-ed list. Since not all modules are to be put in udebs I see no way how you will automate the list. And instead of having a 1 minute run of kernel-wedge to build the udeb for the one generic kernel of most archs you have a 6h build of all the (non D-I except for generic) flavours. Getting a module into an udeb would be a hell of a lot more time consuming. Furthermore, given that you need to install the kernel image package, you can't even start to autobuild that without hosing the autobuilders. Last I use kernel-wedge, and this is ~2 years ago now, you could build all kernel udebs on a single arch with the help of a little wrapper script. Did somone break that? This has been rumored, but i have not seen this script, and the latest round of discussion during debconf/mexico, Frans rejected the idea of doing a single kernel .udeb package for all arches, claiming this was not possible, that it would break autobuilders who wanted to install the kernels and so on. But then, maybe he was isssuing clueless suppositions ? The script was in the repository and was never for auto-building. Buildds must install the kernel image package because a Build-Depends is the only way to download a deb on a buildd. You can not rely on a network connection during build so you can't download the debs some other way. And since you can't install a s390 kernel on arm that makes building for all archs impossible for buildds. With a manual build you can just apt-get the debs and unpack them on the spot without having to install anything. Rewrite that script. Get ride of it and build the .udebs from the kernel packages :) modules which need to go into each ramdisk flavour, not mentioning that the Which is pretty constant from my experience since the modules are already split right into udebs. They are split into the right .udebs for the x86 and other mainstream cases the kernel-wedge maintainer cares about. Even if they are not split right you don't change what udebs go into the ramdisk. You fix the split itself (which you already have to do, that work is already accounted for). So this part of the job is a NOP. Ah, but the interesting part of it comes when the constraint for x86 floppies and powerpc floppies for example impose different distribution of modules. That is why each arch has possibly different modules listed. And as Joeyh posted even per flavour. This is really a non problem solve years ago. As an example, i was not able to build apus flavoured .udebs, since i don't remember which .udeb included a module not built on apus, and which needed kernel-wedge modifications, which Frans forbade me to make. You were forbidden to do it. It wasn't impossible or even difficult. ramdisk package list has no support for per-flavour module selection, and you have to end up with stuff like the netboot64 list, which has as sole usage to add the ibm power hypervisor and virtualization modules, all an ugly mess. Something to improve. No argument for or against your proposal. Because you miss that my proposal makes this whole issue obsolet and non-existent. No it doesn't. You still have to list the modules that get into the ramdisk. That list doesn't magically build itself just because you parse .config. Again, you fail to understand. In the current case, you do the work 3 times : 1) the kernel team choses the configuration option for the kernel, and thus chose which modules to enable or not. Which is a trivial step as they basicaly enable all modules and hardly ever disable one again. 2) the kernel-wedge contains a list of modules per .udeb, and is completed by the linux-*-di packages, all 12+ of them. And per flavour. That list changes on kernel updates (not so often) and much more
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Sven Luther [EMAIL PROTECTED] writes: So, now that we agreed that those modules need to go into non-free, but that provided their licence is clear enough, like in the tg3 case, they are indeed distriutable in non-free, let's go back to the initial point. This is upstream work, and work which is slowly happening upstream, but will never be ready in time for the etch release. The kernel team has not the ressources to do all that work in a timely fashion for the stated etch release, and delaying until it is ready may mean at least a year of delay for the etch release, which is unacceptable for many. Upstream is not doing it and Debian has written it on their flag (DFSG and SC) to get it done. That means Debian has to do it. If that means etch will be delayed a year then etch will be delayed one year. THAT fact was the begining of the thread. Showing that the kernel is not ready to be frozen in accordance to the timeline because the firmware is still not removed. If you can't live with that delay then please start a GR to get an exemption like sarge had. I don't think there has to be more arguing about it anymore. Friendly, Sven Luther MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
CC limited to debian-kernel as this isn't for release anymore. Sven Luther [EMAIL PROTECTED] writes: On Sat, Aug 12, 2006 at 12:46:18AM +0200, Goswin von Brederlow wrote: And actualy just recently the first one was uploaded to non-free including udebs: http://ftp.debian.org/debian/pool/non-free/f/firmware-non-free/ Now the DAK must be configured to create a dists/sid/non-free/debian-installer/ subdir and index files for the udebs. But I feel we are already one step closer to the goal. Step 1: Create non-free udebs. *checked* Step 2: Add DAK config *waiting for ftp-masters* Step 3: Add D-I support I would propose something even more advanced, and not put the kernel .udebs into the main debian-installer thing, but into a separate section. The way i envision this, we would create a debian/sid/main|non-free/kernel section, where the kernel .udebs would be hold, and we start building them from the main kernel package. Ideally, we would go a step further, and have debian/sid/main|non-free/kernel/flavour sections, so we can split the kernel .udeb packages in a finer grain, and each running installer will only be seeing the modules corresponding to the kernel flavour he is running. What for? The installer always needs the installer udebs. Having the kernel udebs in another section just means more files to generate and to download that can go wrong. It saves nothing. Splitting the udebs by flavour would save a few bytes on the Packages file but the only affect that has would be a few bytes less downloaded (inconsequential) and a few bytes less ram used (if you are that low then you have problems anyway). If you want the user to only see the kernel components that match the running kernel then filter them in the display. I don't think splintering the Index files into tons of sections is the way to go there. Also think about what that would mean for a newly added kernel flavour in terms of delays till the DAK gets reconfigured for a new section. This was my proposal from the start, and if you think down to it, it is the best solution for all the kernel/d-i related problems, and would allow to complete the work started with the common packaging, into a solution where there will be only a single package build, easily doable on the usual buildd network, will allow the most flexible solution for abi bumps and security upgrades. The layout of the Index files and sections used has absoluetly no effect on either abi bumps nor security nor in any way the package building. Extra sections just means much more work for the DAK with little to no benefit. I don't even consider that a good solution. Quite opposite. The requirement of a new section for a new kernel flavour would create a lot of delays for the kernel-team when adding a new flavour. But then, i was not able to complete these ideas, due to my mothers illness ... And there you go again. STOP IT PLEASE. It is totaly off-topic. ... So, you see, if i am angry and hurt, and you dislike me repeating it always, you know who to blame. You for repeating it over and over. With every repetition the precieved blames shifts a little bit to your side until all people see precieve is that you are to blame. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
[EMAIL PROTECTED] (Marco d'Itri) writes: On Aug 07, Goswin von Brederlow [EMAIL PROTECTED] wrote: No, because those are not linked together with the GPLed code, but are a mere aggregation of works inside the same media, i.e. the binary file. Those non-free firmware will never run inside the same memory space as the kernel, and are offloaded to a peripheral processor, and the communication media between the kernel and this peripheral processor running said firmware is clearly defined, there is no doubt that those non-free firmware do not break the kernel GPL. They are linked in, they have symbols, the code directly references their address. Can you name one tool that will easily remove such No. They are a char array, it's data copied where the hardware wants it. It's not code called by other functions. That still leaves the symbol for the variable holding the char array and its size. The code copying the data references that variable and size. I didn't say the code is called. Compare it to including a hexdump of an image or sound in a header file and including that in the binary. And compare it with having that same image or sound as external file shipped in the same deb. Assume the image/sound was rendered/generated from some source format not included in the source. E.g. povray input. Is it an aggregation with the image linked into the binary? aggregated code from the kernel image? Not relevant. If it is an aggregation then there must be a way to break it up and only keep the GPLed parts. I think that is very much relevant. I don't think you can call something an aggregation if it is inseperably bound together. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Sven Luther [EMAIL PROTECTED] writes: On Sat, Aug 12, 2006 at 10:32:54PM +0200, Goswin von Brederlow wrote: Indeed. The proposal to split the packages file in a per flavour kernel repository comes directly from the need to counterbalance this augmentation of the number of packages. So instead of having 5 module udebs for my ONE generic kernel I get 200? For say amd64 it would be a big step back. Indeed, but smaller ones. How many archs with flavours are we talking about anyway? I think m68k has 3 flavours and ppc some and every other archs has a generic flavour or drivers buildin already. I know that the more exotic ones have many flavours. Also, the amount of packages will be proportional of the non-builtin drivers. POwerpc has currently 5 d-i flavours (or would have if the new d-i powerpc people did they work correctly), powerpc, powerpc64, powerpc-miboot, prep and apus. So the worst case is 5 flavours while most archs have only one. Your solution would cut the number of kernel udebs by at most a factor of 5 while you want to increase by a factor of 40. That is still a net loss by a factor of 8 for 5 flavours. So why then do you want to split module udebs? Because the current way of doing it is problematic. The d-i folk don't want to give control of it to the kernel team, and the new proposal handled they keeping the same and even better control of how to build the ramdisks, while at the same time building the module .udebs from the common kernel source, thus saving around 2 weeks of time the d-i folk need to adjust to a new abi or version, thus making for more timely kernel security updates, and making the work of the divers security teams easier. Who controls the udebs has nothing to do with splitting the module udebs into smaller chunks. You could split them while D-I has control of them or have them build by the kernel team and not split them up further or do both. The two issues are independent of each other. You just agreed that downloading the module udebs is inconsequential given their size. You agreed that more udebs increases the Index files which is bad. Err, let's say we have 5 flavours like on powerpc, and each would have 200+ little module .udebs, which gives us Package numbers of 1000+. Worse if there are more flavours. This is the part that joeyh objected to this plan of spliting modules because of the fact that d-i loads three in memory copy of the Packages file, which in turn prompted the idea of per-flavour repositories. If you look at the whole idea though, you find out that it is a really neat solution to this problem, it cares for all the technical hurdles, and is elegant and nice, and if you throw in the part that can be automated, it saves work for everyone involved. Say you do get your per flavour split despite increasing the number of kernel modules worst arch has to deal with by a factor of 8 and for most archs a factor of 40. Can you imaging the poor users of a low-mem system going through the list of 200+ components to pick out the right modules to download? Neat? In my book, this makes it a good idea, or at least something that should be tried, and not something you have to menace the implementator so he doesn't dare pursue it. So all I'm left with is that you don't end up with as much modules in the ramdisk. Something I find irelevant unless you talk about the low-mem flavour. And the fact that it is much easier to update config option and add and remove new modules doesn't count. Naturally, you don't handle kernel .udebs. I did, and it was a royal pain in the ass to handle those, it took me hours, for stuff that was already done 10 times for the other flavours. And even a few days ago, the powerpc64 flavour was still broken with the 2.6.17 kernels, because some random module listed in the list of modules was not present. The whole concept is of an extreme fragility, prone to break again and again, cause lot of work for all involved, who become irritable, and bash on you when you even mention it. I did it when working on the amd64 D-I for sarge. I found it quite trivial to do, a matter of minutes. In fact a hell of a lot simpler and way faster than getting the linux-2.6 source package to do something for me. The kernel-wedge lists do break from time to time but they are simple to adjust and quick to rebuild. And another advantage with kernel-wedge: You can easily take your (maybe even prebuild) custom kernel and create udebs from it. I would hate to have to add the SuSe or RH patch sets to the linux-2.6 source to build kernel udebs for hardware that requires their patches. This, in my book, is not an example of good software engineering, and any proposal to help improve this should be worth considering. Still not convinced. You do have some points but I see more drawbacks and problems than advantages. Is the space taken up by the installed modules your actual argument for having finer
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Sven Luther [EMAIL PROTECTED] writes: On Sat, Aug 12, 2006 at 11:03:29PM +0200, Goswin von Brederlow wrote: Compare it to including a hexdump of an image or sound in a header file and including that in the binary. And compare it with having that same image or sound as external file shipped in the same deb. Well, the FSF argues that it is not important where the file is, as long as there is a logical link, in order to have the GPL cross the dynamic linking barrier. In the same way, the only relationship of the non-free firmware or your image or sound, is that it is transported in the same binary, and used as data offloaded to the peripheral device. Assume the image/sound was rendered/generated from some source format not included in the source. E.g. povray input. So ? What has this to do with it ? So you can't claim the hexdump (or binary file) is the prefered form of modification (source). Is it an aggregation with the image linked into the binary? It depends if your binary is an image compressor, and only transports the image, or if said image is used in the binary for icons of its GUI for example or as splash screen. If I just dump my hexcode of the image/sound to my black box (qiv or xmms for example) for (dis)playing then I only transport the file. If I (dis)play it myself then it isn't an aggregation. Intresting. Or does the black box have to be hardware? aggregated code from the kernel image? Not relevant. If it is an aggregation then there must be a way to break it up and only keep the GPLed parts. I think that is very much relevant. I don't think you can call something an aggregation if it is inseperably bound together. Well, sure there is part to separate them. You could imagine a (non-free) tool called before lilo or grub, and which would upload those firmwares for the peripheral device to be ready when the free driver comes into play. I can imagine a tool that rewrites non-free parts of a binary as free software from scratch without breaking any laws about reverse engeneering too. Does that mean they exist or are even possible? no. Or you could use the new initramfs/firmware loading kernel infrastructure to separate the firmware from the kernel. That requires changes in the source. Exactly those changes is what I say must happen. The firmware loading kernel infrastructure marks a clear lines where an external blob of firmware gets loaded that isn't part of the kernel binary itself. Err, is not this latest one what you are suggesting we do ? So, if i understood you well, your own argumentation is hitting you back there, and this is usually proof that there is something terribly wrong in your argumentation to start with. No. You just argumented my point. The source changes to seperate the firmware and to use the firmware loading kernel infrastructure makes a difference imho. Also notice that with the firmware loading kernel infrastructure you can just delete the firmware file and the loader will give a simple error. Good luck trying to remove the char *firmware from a kernel image and not have it crash. Best you can do there is fill it with dummy data. Friendly, Sven Luther MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
