from:"Martin Steigerwald"

Re: Updates to linux-firmware

2024-08-21 Thread Martin Steigerwald

Hi Ben, Mark, hello.

Martin Steigerwald - 16.07.24, 17:08:42 CEST:
> I have a ThinkPad T14 AMD Gen 5 and I am in contact with Mark about some
> issues with the new platform as Lenovo readies their Linux support for
> it. It is already working quite good, but a few strange issues remain.
> 
> I currently installed linux-firmware upstream package on top of the
> Debian ones in order to for example make WLAN and Bluetooth work but I
> am happy to remove it once I see the new version of the Debian packages
> coming in and report in case I see any issues. I can report here before
> accidentally opening any bug report needlessly. But I could also open a
> bug report if need be.

I can report back that with firmware-atheros 20240709-1 both WLAN and 
Bluetooth are recognized and can be enabled on the ThinkPad T14 AMD Gen 5. 
I did not yet test using them, but I bet it will work.

Upstream firmware package is no longer installed.

Thanks.

-- 
Martin

Re: Updates to linux-firmware

2024-07-16 Thread Martin Steigerwald

Martin Steigerwald - 16.07.24, 17:08:42 CEST:
> Ben Hutchings - 16.07.24, 15:20:23 CEST:
> > Sorry for not responding to this earlier.
> > 
> > I've finally uploaded an update to (nearly) the current version.  This
> > incorporates some of Diederik's work, but I also made changes that
> > should reduce the amount of manual effort required for future updates.
> 
> Thank you, Ben!

Also of course thanks to Diederik. I appreciate it!

Thanks to everyone involved.

-- 
Martin

Re: Updates to linux-firmware

2024-07-16 Thread Martin Steigerwald

Hi Ben, hi Mark, hi all of you,

Ben Hutchings - 16.07.24, 15:20:23 CEST:
> Sorry for not responding to this earlier.
> 
> I've finally uploaded an update to (nearly) the current version.  This
> incorporates some of Diederik's work, but I also made changes that
> should reduce the amount of manual effort required for future updates.

Thank you, Ben!

I can also test it. I have been following this thread with interest, but 
did not comment so far.

I have a ThinkPad T14 AMD Gen 5 and I am in contact with Mark about some 
issues with the new platform as Lenovo readies their Linux support for it. 
It is already working quite good, but a few strange issues remain.

I currently installed linux-firmware upstream package on top of the Debian 
ones in order to for example make WLAN and Bluetooth work but I am happy 
to remove it once I see the new version of the Debian packages coming in 
and report in case I see any issues. I can report here before accidentally 
opening any bug report needlessly. But I could also open a bug report if 
need be.

Best,
-- 
Martin

Re: HFS/HFS+ are insecure

2023-07-21 Thread Martin Steigerwald

Hi Marco, hi,

Marco d'Itri - 21.07.23, 10:55:39 CEST:
> On Jul 21, Matthew Garrett  wrote:
> > > You are totally correct.
> > > Kernel team, please blacklist HFS/HFS+ for automounting.
> > 
> > Isn't this a userland policy decision? udisks will happily trigger a
> > module load for hfsplus if udev has identified it, and I don't think
> > there's a trivial mechanism for the kernel to disable that. I
> > believe
> 
> Yes, I was also thinking about this and I believe that you are right.
> The kernel team did this in the past for some uncommon network
> protocols, but they could do it themselves because these modules are
> autoloaded using aliases.
> 
> Since I happen to be the kmod maintainer it looks like that solving
> this is on me. :-)
> 
> Unless somebody has a better idea then then my plan is to ship in the
> next upload of kmod a file in /etc/modprobe.d/ which uses the
> blacklist directive to prevent automatically loading some file system
> modules.
[…]
> I think that all of these have enough of a niche usage that it would
> not be an unreasonable burden for the affected users to manually load
> the modules when needed (ad hoc or using /etc/modules-load.d/).

In case you do this, I'd like there to be a NEWS.Debian entry about 
this, explaining both the justification behind it and how people can work 
around it. It could go like this:

---

Since version xyz of kmod the file /etc/modprobe.d/block-unsafe-
filesystems.conf prevents loading of several filesystem modules that are 
automatically loaded by udev when inserting a medium that contains one 
of them. These filesystems are either known to be unsafe or are not 
maintained actively anymore. A deliberately corrupted filesystem 
structure could trigger the filesystem driver in the module to crash, 
corrupt memory of other kernel components or to cause other problems. 
[Adjust to whatever risks are most likely to occur] [Add some links here 
for the discussion about that]

In case you rely on using one or more of these filesystems you can either 
edit the file /etc/modprobe.d/block-unsafe-filesystems.conf and put a 
comment sign before the filesystem in question or add the filesystem to a 
file to a file in /etc/modules-load.d/. [Please clarify here as needed]

Please take care not to plug in any device that you do not trust.

---

This is just a rough idea it probably needs several iterations to obtain 
a good wording that balances on assessing the risk correctly (without 
over or under estimating it). Also the method of circumventing the 
blocking may need further explanations. I am not using systemd, so I can 
not describe exactly how modules-load.d works. In case you like to use 
any of the above wording, feel free to use it under the license of the 
packaging of kmod.

I wonder about other kernel modules in other areas of the kernel that 
may be automatically loaded when connecting some hardware… especially 
some random USB device, but… that appears to me like opening a huge can 
of worms. I bet the Linux kernel has more than several hundreds of 
specialized USB drivers maybe even more than thousand meanwhile despite 
all the USB standards out there?

Linux is not a micro kernel. It was not designed to run drivers in a 
restricted and (somewhat) safe environment to begin with. That means 
ideally you'd have to audit all the drivers for security issues 
regularly or at least after a certain amount of changes made to it. In 
case you do not, for some random driver it will be difficult to know for 
sure whether it is safe or unsafe to use. Maybe some small filesystem 
driver like affs that still receives a patch every now and then is safer 
to use than the much more complex BTRFS filesystem driver.¹ Who knows? Of 
cause some fuzzing may really help. But it is not a guarantee either.

And then what about other kernel functionally that is loaded as module 
on demand that is only rarely used by some people?

So I wonder what body of evidence there is to base a policy decision on 
which driver to load or not to load automatically. Without a reliable 
body of evidence there is always the risk to either over or under policy 
the users of Debian and derived distributions (whose maintainers do not 
decide to change such a policy decision again). So I'd argue against 
taking the quick route on that to allow the time for a more informed 
decision. Maybe start with clear-cut cases likely probably HFS/HFS+ 
instead of just adding all kinds of other filesystems without even know 
whether there is a known exploit. Of course you could go by maintenance 
status, however, this can be inaccurate. How to do accurately determine 
maintenance status, especially as MAINTAINERS file may not be accurate or 
up-to-date at all times? And how many specialized USB drivers are there 
that are compiled as modules on Debian kernels that may not

Re: Pressure stall information (was: Re: linux-signed-amd64_5.0.1+1~exp1_source.changes ACCEPTED into experimental, experimental)

2019-03-15 Thread Martin Steigerwald

Harald Weidner - 15.03.19, 17:02:
> Is there any chance to get pressure stall information (CONFIG_PSI)
> enabled on the linux-image 4.20 and 5.x packages?
> 
> Pressure stall information are a useful extension to the load average
> numbers. They allow a better distinction between cpu, memory and i/o
> bound workloads.
> 
> See https://lwn.net/Articles/759781/ and
> https://lwn.net/Articles/759658/ for details.

I second this. Would be really nice to have.

I contacted atop author Gerlof about support for it and he implemented 
it already (extraline "PSI"). Marc packaged it as atop 2.4-1.

Thanks,
-- 
Martin

Bug#919325: [pkg-netfilter-team] Bug#919325: iptables -nvL consumes 100% of CPU and hogs memory with kernel 5.0-rc2

2019-01-15 Thread Martin Steigerwald

Hi Arturo.

Arturo Borrero Gonzalez - 15.01.19, 11:57:
> Control: reassign -1 linux
> Control: tags -1 + upstream patch
> 
> On 1/14/19 11:55 PM, Martin Steigerwald wrote:
> > I asked on LKML using similar subject about it.  Not yet visible on
[…]
> When reassigning the bug to the kernel, I noticed there is no linux
> v5.0-rc2 in Debian yet. So closing this bug now, since no software in
> the Debian archive is affected by this.

Fair enough. Was a bit prematurely to report on Debian bug tracker 
before testing on 4.20. Sorry for the noise.

> 
> Anyway, for the record, there is an upstream patch to address this:
> 
> http://patchwork.ozlabs.org/patch/1024772/
> ("netfilter: nf_tables: Fix for endless loop when dumping ruleset").

Yep, I learned that from upstream as well meanwhile.

Thanks,
-- 
Martin

Bug#910090: SD card reader does not work any more

2018-11-01 Thread Martin Steigerwald

Marc Haber - 01.11.18, 09:30:
> On Tue, Oct 02, 2018 at 10:23:41PM +0200, Martin Steigerwald wrote:
> > Marc Haber - 02.10.18, 18:34:
> > > Package: src:linux
> > > Version: 4.18.8-1
> > > Severity: minor
> > 
> > […]
> > 
> > > since a few kernel versions (sorry, I don't know which one), SD
> > > cards
> > > put into the built-in reader of the ThinkPad T520 don't work any
> > > more. There is nothing happening in the kernel log when the card
> > > is inserted.
> > 
> > Strange.
> > 
> > The one in this ThinkPad T520 still works. With self-compiled
> > 4.18.7.
> > 
> > Configuration attached.
> 
> Can you paste the output of lsmod with an SD card inserted and
> mounted?

Kernel is newer already, but I bet it would be the same with self-
compiled 4.18 kernel. Configuration of this new kernel attached anyway.

% cat /proc/version
Linux version 4.19.0-tp520 (martin@merkaba) (gcc version 8.2.0 (Debian 
8.2.0-8)) #65 SMP PREEMPT Mon Oct 22 14:18:36 CEST 2018

% LANG=en df -hT /media/martin/CHDK   
Filesystem Type  Size  Used Avail Use% Mounted on
/dev/mmcblk0p1 vfat  2.0G   30M  2.0G   2% /media/martin/CHDK

I think the important ones are these:

lsmod | grep -i mmc
mmc_block  40960  2
mmc_core  135168  4 sdhci,cqhci,mmc_block,sdhci_pci

Complete list:

% lsmod   
Module  Size  Used by
nls_ascii  16384  1
nls_cp437  20480  1
vfat   20480  1
fat73728  1 vfat
mmc_block  40960  2
fuse  114688  3
nft_chain_route_ipv416384  1
xt_CHECKSUM16384  0
nft_chain_nat_ipv4 16384  4
ipt_MASQUERADE 16384  0
nf_nat_ipv416384  2 ipt_MASQUERADE,nft_chain_nat_ipv4
nf_nat 32768  1 nf_nat_ipv4
xt_conntrack   16384  0
nf_conntrack  118784  4 
xt_conntrack,nf_nat,ipt_MASQUERADE,nf_nat_ipv4
nf_defrag_ipv6 20480  1 nf_conntrack
nf_defrag_ipv4 16384  1 nf_conntrack
ipt_REJECT 16384  0
nf_reject_ipv4 16384  1 ipt_REJECT
nft_counter16384  0
xt_tcpudp  16384  0
nft_compat 20480  0
tun45056  0
bridge180224  0
stp16384  1 bridge
llc16384  2 bridge,stp
acpi_call  16384  0
devlink69632  0
ebtable_filter 16384  0
ebtables   36864  1 ebtable_filter
nf_tables 131072  4 
nft_chain_route_ipv4,nft_compat,nft_chain_nat_ipv4,nft_counter
snd_usb_audio 208896  2
nfnetlink  16384  2 nft_compat,nf_tables
snd_usbmidi_lib28672  1 snd_usb_audio
snd_rawmidi32768  1 snd_usbmidi_lib
snd_seq_device 16384  1 snd_rawmidi
binfmt_misc20480  1
xfs  1384448  2
snd_hda_codec_hdmi 57344  2
snd_hda_codec_conexant24576  1
snd_hda_codec_generic77824  1 snd_hda_codec_conexant
msr16384  0
pktcdvd40960  1
intel_rapl 24576  0
x86_pkg_temp_thermal16384  0
intel_powerclamp   16384  0
kvm_intel 192512  0
kvm   630784  1 kvm_intel
irqbypass  16384  1 kvm
crct10dif_pclmul   16384  0
crc32_pclmul   16384  0
ghash_clmulni_intel16384  0
pcbc   16384  0
arc4   16384  2
iwldvm147456  0
mac80211  671744  1 iwldvm
aesni_intel   200704  0
aes_x86_64 20480  1 aesni_intel
crypto_simd16384  1 aesni_intel
iwlwifi   217088  1 iwldvm
cryptd 24576  3 
crypto_simd,ghash_clmulni_intel,aesni_intel
glue_helper16384  1 aesni_intel
intel_cstate   16384  0
i915 1585152  55
intel_rapl_perf16384  0
input_leds 16384  0
pcspkr 16384  0
drm_kms_helper159744  1 i915
snd_hda_intel  36864  3
snd_hda_codec 122880  4 
snd_hda_codec_generic,snd_hda_codec_conexant,snd_hda_codec_hdmi,snd_hda_intel
drm   405504  23 drm_kms_helper,i915
snd_hda_core   69632  5 
snd_hda_codec_generic,snd_hda_codec_conexant,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec
thinkpad_acpi  90112  1
snd_hwdep  16384  2 snd_usb_audio,snd_hda_codec
i2c_algo_bit   16384  1 i915
sg 36864  0
snd_pcm98304  6 
snd_hda_codec_hdmi,snd_hda_intel,snd_usb_audio,snd_hda_codec,snd_hda_core
nvram  16384  1 thinkpad_acpi
fb_sys_fops16384  1 drm_kms_helper
snd_timer  32768  1 snd_pcm
syscopyarea16384  1 drm_kms_helper
cfg80211  643072  3 iwldvm,iwlwifi,mac80211
sysfillrect1638

Bug#910090: SD card reader does not work any more

2018-10-02 Thread Martin Steigerwald

Marc Haber - 02.10.18, 18:34:
> Package: src:linux
> Version: 4.18.8-1
> Severity: minor
[…]
> since a few kernel versions (sorry, I don't know which one), SD cards
> put into the built-in reader of the ThinkPad T520 don't work any more.
> There is nothing happening in the kernel log when the card is
> inserted.

Strange.

The one in this ThinkPad T520 still works. With self-compiled 4.18.7. 

Configuration attached. 

I did not test with Debian kernel. I can make a make-kpkg generated 
Debian package with my self-compiled kernel available to you, if you 
like to test with that kernel in comparison to the Debian one.

Thanks,
-- 
Martin

config-4.18.7-tp520.xz
Description: application/xz


signature.asc
Description: This is a digitally signed message part.

Re: Debian Kernel info

2018-09-05 Thread Martin Steigerwald

Fabian Grünbichler - 05.09.18, 17:19:
> On Wed, Sep 05, 2018 at 02:33:33PM +0200, Martin Steigerwald wrote:
> > Tomas Bortoli - 05.09.18, 08:48:
> > > is there a place where I find the config used to compile Linux for
> > > the latest Debian ?
> > > 
> > > 
> > > The alternative idea I had is to `apt source linux-image-version`
> > > but
> > > that requires to download the whole package.
> > 
> > Probably via
> > 
> > https://sources.debian.org/src/linux/4.17.17-1/debian/config/amd64/
> > 
> > or something like that?
> 
> linux-image-$(uname -r) ships /boot/config-$(uname -r), which AFAIK is
> the actual config used to compile that kernel image.

Sure, I know that. And yes, it appears the source package puts the 
config together from various sources. But that was the closest 
approximation I came up with so far.

I am not sure whether there is something similar than sources.debian.org 
for binary packages. I thought there was, but currently I have no idea 
where that might be.

Thanks,
-- 
Martin

Re: Debian Kernel info

2018-09-05 Thread Martin Steigerwald

Hi Tomas.

Tomas Bortoli - 05.09.18, 08:48:
> is there a place where I find the config used to compile Linux for the
> latest Debian ?
> 
> 
> The alternative idea I had is to `apt source linux-image-version` but
> that requires to download the whole package.

Probably via

https://sources.debian.org/src/linux/4.17.17-1/debian/config/amd64/

or something like that?

Ciao,
-- 
Martin

Re: 4.13: blk-mq fails to recover from suspend

2017-09-01 Thread Martin Steigerwald

Hello Boyan,

Boyan Penkov - 01.09.17, 17:40:
> I just pulled in 4.13, with the intention of trying bfq.
> 
> To enable bfq as a scheduler, I passed "scsi_mod.use_blk_mq=1" to
> grub, and added bfq via modprobe.  So far, so good: the scheduler does
> turn up (vis-a-vis cat /sys/block/sda/queue/scheduler).
> 
> If I leave the machine and it sleeps, however, it does not wake up.
> This is documented: https://lkml.org/lkml/2017/7/30/3
> 
> It seems, based on the discussion in the thread above, that the issue
> has been resolved in 4.13-rc4 and 4.13-rc7, as the two patches
> mentioned there are in mainline.
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h
> =v4.13-rc4&id=765e40b675a9566459ddcb8358ad16f3b8344bbe
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h
> =v4.13-rc7&id=5f042e7cbd9eb
> 
> Am I missing something here?  Does 4.13 from experimental really have
> these in?  Should I be looking elsewhere to help resolve this?

Did you review the thread "I/O hangs after resuming from suspend-to-ram" on 
LKML (I think I have been epically misunderstood in this thread as it can 
indeed be the case that my issue is also related to blk-mq, I am currently 
using cfq again and machine is stable on resume from suspend)? In the end Ming 
Lei posted about seven more fundamental patches to fix the issue for good and I 
am not sure that these went in.

Its late and I wanna go sleep…, but I see if I find the Message-Id of that 
message. Hmmm, no its not in that thread. It was in a different thread, I 
think Ming posted that patch series as a new thread, but I don´t find it right 
now.

Well maybe I gave enough pointers for you to dig it up yourself. If you find 
anything, please let me know. I just don´t find the thread with that patch 
series right now. Ah, I did. Its not on LKML, but on linux-block:

[PATCH 0/9] block/scsi: safe SCSI quiescing

Message-Id: <20170831172728.15817-1-ming@redhat.com>

I bet that should be enough for you to dig it out.

Goodnight,
-- 
Martin

Bug#865866: libreoffice-writer crash on startup Debian 9 i386 arch

2017-07-29 Thread Martin Steigerwald

Aaron Valdes - 28.07.17, 19:49:
> How do I edit my /etc/apt/source.list in order to see older kernel versions?
> 
> # apt-cache  policy linux-image-`uname -r`
[…]

I think its best to use snapshot.debian.org for that

Thanks,
-- 
Martin

Re: [PATCH initramfs-tools 0/9] Fix resume device configuration

2017-04-21 Thread Martin Steigerwald

Dear Ben.

Ben Hutchings - 21.04.17, 04:33:
> The change in version 0.128 to wait for the resume device to appear
> uncovered a number of systems for which the resume device is not
> properly configured.  In fact, systems with swap partitions that
> are never available at boot could not be configured correctly,
> other than by adding 'noresume' to the kernel command line!
> 
> While working on that, I found and fixed a couple of other
> longstanding bugs in resume device selection.
> 
> This patch series:
> 
> - Fixes the sorting of swap partitions
> - Makes the RESUME variable work like every other configuration
>   variable, and documents it
> - Adds support for RESUME=none (disable resume) and RESUME=auto
>   (explicitly request automatic selection)
> - Adds warning and informational messages where the resume device
>   configuration is automatically fixed-up

Thats interesting. I have an old ThinkPad T42 above my hi-fi equipment as a 
media player and it stopped resuming from hibernation after some update quite 
some time ago.  But instead it just boots as if there would be no hibernation 
image. On hibernation it actually does write the hibernation image – I use in 
kernel hibernation, not userspace software suspend, but I think I tried using 
that one as well. Currently I don´t have uswsusp installed, but pm-utils is 
still there. I am not sure whether systemd uses it or does it all by itself 
tough. I configured in-kernel suspend there as well:

shambhala:/etc/pm> cat ./config.d/sleepmodule.conf
SLEEP_MODULE=kernel

Currently initramfs-tools is at 0.127 on this not so regularily updated 
laptop.


I never managed to get around actually looking whats going on here, but I now 
found that I do not have any resume setting in

shambhala:/etc/initramfs-tools> grep -ir "RESUME" .
shambhala:/etc/initramfs-tools#1>

Instead I have it here:

shambhala:/etc/default> grep -i resume grub
GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/sda2 init=/bin/systemd"


shambhala:~> swapon -s
Dateiname   Typ Größe   Benutzt 
Priorität
/dev/sda2   partition   4000180 0   -1

shambhala:~> lsblk /dev/sda2
NAME MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda2   8:20  3,8G  0 part [SWAP]
shambhala:~> LANG=C swapon -s
FilenameTypeSizeUsed
Priority
/dev/sda2   partition   4000180 0   -1


Okay, I will upgrade to the new initramfs-tools and look whether it fixes the 
issue. If not, I may try setting RESUME var to first "auto" and if not working 
still then the device in question to see whether that helps. I welcome any 
other ideas and I am willing to report back what I find.

Ciao,
-- 
Martin

signature.asc
Description: This is a digitally signed message part.

Bug#848682: Process accounting: Using the NETLINK interface, the command TASKSTATS_CMD_GET returns -EINVAL

2016-12-19 Thread Martin Steigerwald

Dear Ben, dear maintainers,

I reported the second issue as:

Bug#848683: Process accounting: Using the NETLINK inface, the command 
TASKSTATS_CMD_GET returns -EINVAL
https://bugs.debian.org/848683

I forgot to attach the test program from Gerlof. I attach it now.

Thanks,
-- 
Martin Steigerwald  | Trainer

teamix GmbH
Südwestpark 43
90449 Nürnberg

Tel.:  +49 911 30999 55 | Fax: +49 911 30999 99
mail: martin.steigerw...@teamix.de | web:  http://www.teamix.de | blog: 
http://blog.teamix.de

Amtsgericht Nürnberg, HRB 18320 | Geschäftsführer: Oliver Kügow, Richard Müller

teamix Support Hotline: +49 911 30999-112
 
 *** Bitte liken Sie uns auf Facebook: facebook.com/teamix ***

#include 
#include 
#include 
#include 
#include 
#include 

#define ACCTFILE	"/tmp/mypacct"

main()
{
	int  fd;
	char buf[1024];

	if ( (fd = open(ACCTFILE, O_RDWR|O_CREAT|O_TRUNC, 0777)) == -1)
	{
		perror("Open " ACCTFILE);
		exit(1);
	}

	if (acct(ACCTFILE) == -1)
	{
		perror("Switch on accounting");
		exit(1);
	}

	if ( fork() == 0 )	// fork new process
		exit(0);	// child process: finish


	// parent process:
	//	wait for child to finish

	wait((int *)0);

	// 	read the process accounting record of the finished child

	while (read(fd, buf, sizeof buf) == 0)
	{
		printf("No process accounting record yet\n");
		sleep(1);
	}

	printf("Yah, found a process accounting record!\n");
}

Bug#848683: Process accounting: Using the NETLINK inface, the command TASKSTATS_CMD_GET returns -EINVAL

2016-12-19 Thread Martin Steigerwald

Source: linux
Severity: normal

Dear Ben, dear maintainers,

starting from a Debian bug report of mine, Gerlof Langeveld, developer
of system and process monitor atop¹, found two issues with process
accounting². I also started an LKML thread about these³.

[1] http://atoptool.nl/
[2] #833997 atop: process accounting does not work:
https://bugs.debian.org/833997
[3] [REGRESSION] Two issues that prevent process accounting (taskstats) from
working correctly: https://lkml.org/lkml/2016/12/19/182

I am reporting the two issues separately.

I am currently not running Debian a kernel, but Gerlof verified the issue with
Debian kernel. Pprocess accounting works with 3.16, but fails with 4.8 and
4.7 at least. I think it also fails with earlier versions, but I do not
know exactly since which version.

I reported the first issue as:

Bug#848682: process accounting sometimes does not work
https://bugs.debian.org/848682


2) When using the NETLINK inface, the command TASKSTATS_CMD_GET 
consequently returns -EINVAL.

Bug 190711 - Process accounting: Using the NETLINK inface, the command 
TASKSTATS_CMD_GET returns -EINVAL
https://bugzilla.kernel.org/show_bug.cgi?id=190711

The code that is used by the atopacctd daemon is based on the demo code 
'getdelays.c' that can be found in the kernel source code tree
(/linux/Documentation/accounting/getdelays.c). Also this 'getdelays' 
program does not work any more (also -EINVAL on the same call)
with the newer kernels. I really spent a lot of time on this issue to 
get the code running (there are many places in the kernel code where
-EINVAL for this call can be given), but I did not succeed. It is really 
an incompatibility introduced by the kernel code.
It would be nice if the kernel maintainers provide a working version of 
the getdelays program in the kernel source tree.

I only experience this problem on Debian8 with a 4.8 kernel (virtual 
machine with 4 cores).
On CentOS7 with a 4.8 kernel it works fine (physical machine with 4 cores).

I will anyhow adapt atopacctd for this issue that it detects and logs 
the -EINVAL and terminates.
The current version of atopacctd keeps running which is not useful at all.


Marc Haber, maintainer of atop package, Gerlof Langeveld, developer of atop
and I are currently discussing workarounds with atop and/or systemd service
fail for the time till upstream kernels with this issues fixed are shipped
by distributions. Still it would be nice to remove those work-arounds and
have the kernel work correctly again at some time in the future.

Thanks,
Martin


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.14-tp520-btrfstrim+ (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#848682: process accounting sometimes does not work

2016-12-19 Thread Martin Steigerwald

Source: linux
Severity: normal

Dear Ben, dear maintainers,

starting from a Debian bug report of mine, Gerlof Langeveld, developer
of system and process monitor atop¹, found two issues with process
accounting². I also started an LKML thread about these³.

[1] http://atoptool.nl/
[2] #833997 atop: process accounting does not work:
https://bugs.debian.org/833997
[3] [REGRESSION] Two issues that prevent process accounting (taskstats) from
working correctly: https://lkml.org/lkml/2016/12/19/182

I am reporting the two issues separately.

I am currently not running Debian a kernel, but Gerlof verified the issue with
Debian kernel. Pprocess accounting works with 3.16, but fails with 4.8 and
4.7 at least. I think it also fails with earlier versions, but I do not
know exactly since which version.


1) Sometimes process accounting does not work at all.

Bug 190271 - process accounting sometimes does not work 
https://bugzilla.kernel.org/show_bug.cgi?id=190271

The acct() system call (to activate process accounting) return value 0, 
which means that process accounting is activated successfully.
However, no process accounting records are written whatsoever. This 
situation can be reproduced with the program 'acctdemo.c'
that you can find as attachment. When this program gives the message 
"found a process accounting record!", the situation is okay
and process accounting works fine to the file '/tmp/mypacct'. When the 
message 'No process accounting record yet' is repeatedly given,
process accounting does not work and will not work at all. It might be 
that you have to start this program several times before you get
this situation (preferably start/finish lots of processes in the mean time).
This problem is probably caused by a new mechanism introduced in the 
kernel code (/linux/kernel/acct.c) that is called 'slow accounting'
and has to be solved in the kernel code.

I experience this problem on Debian8 with a 4.8 kernel and on CentOS7 
with a 4.8 kernel.

Thanks,
Martin

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.14-tp520-btrfstrim+ (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#847204: Related bugs regarding systemctl status nfs-kernel-server

2016-12-07 Thread Martin Steigerwald

Hello Riccardo,

Bug#847204: nfs-kernel-server: `systemctl status` incorrectly reports server 
"active" even if not started

and

Bug#843063: systemd: does not show failed nfs mount when nfs server not 
available on booting the client

are likely related to one another.

Seems status reporting is completely broken regarding systemd service 
definition. Your choosing of nfs-kernel-server may be better fit tough than my 
choosing of systemd package, but lets see what maintainers say about this.

Thanks,

-- 
Martin Steigerwald  | Trainer

teamix GmbH
Südwestpark 43
90449 Nürnberg

Tel.:  +49 911 30999 55 | Fax: +49 911 30999 99
mail: martin.steigerw...@teamix.de | web:  http://www.teamix.de | blog: 
http://blog.teamix.de

Amtsgericht Nürnberg, HRB 18320 | Geschäftsführer: Oliver Kügow, Richard Müller

teamix Support Hotline: +49 911 30999-112
 
 *** Bitte liken Sie uns auf Facebook: facebook.com/teamix ***

Bug#807017: nfsiostat: superfluous linebreaks in output

2015-12-04 Thread Martin Steigerwald

Package: nfs-common
Version: 1:1.2.8-9
Severity: minor
Tags: patch

With nfsiostat 1 (on different machine, but with same nfs-common version, I also
verified the issue happens on my laptop as well, but unmounted NFS again) I get:

akademie2://kurs mounted on /mnt/kurs:

   op/s rpc bklog
   0.00
   0.00
read:
  ops/skB/s   kB/op retrans avg RTT (ms)
avg exe (ms)
  0.000
  0.000
  0.000
   0 (0.0%)
  0.000
  0.000
write:
  ops/skB/s   kB/op retrans avg RTT (ms)
avg exe (ms)
  0.000
  0.000
  0.000
   0 (0.0%)
  0.000
  0.000


And I bet it is supposed to look more like this:

akademie2://kurs mounted on /mnt/kurs:

   op/s rpc bklog
   0.000.00
read:  
  ops/skB/s   kB/op retrans avg RTT (ms)
avg exe (ms)
  0.000   0.000   0.0000 (0.0%)   0.000 
  0.000
write: 
  ops/skB/s   kB/op retrans avg RTT (ms)
avg exe (ms)
  0.000   0.000   0.0000 (0.0%)   0.000 
  0.000


I attach a patch with a bugfix inspired by:

http://stackoverflow.com/questions/493386/how-to-print-in-python-without-newline-or-space

the print ("something), variant did not work, so I used sys.stdout.write.



Bugreporting script returned with error on my machine, but it is not necessary
for this bug report.


merkaba:~#1> /usr/share/bug/nfs-common/script
/usr/share/bug/nfs-common/script: 4: /usr/share/bug/nfs-common/script: 3: Bad 
file descriptor


I may report upstream at a later time.

Thanks,
Martin



-- 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
-- /etc/default/nfs-common --
NEED_STATD=
STATDOPTS=
NEED_IDMAPD=
NEED_GSSD=
-- /etc/idmapd.conf --
[General]
Verbosity = 0
Pipefs-Directory = /run/rpc_pipefs
[Mapping]
Nobody-User = nobody
Nobody-Group = nogroup
-- /etc/fstab --
not relevant.
-- /proc/mounts --

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.3.0-tp520-btrfstrim+ (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages nfs-common depends on:
ii  adduser 3.113+nmu3
ii  initscripts 2.88dsf-59.2
ii  libc6   2.21-1
ii  libcap2 1:2.24-12
ii  libcomerr2  1.42.13-1
ii  libdevmapper1.02.1  2:1.02.110-1
ii  libevent-2.0-5  2.0.21-stable-2+b1
ii  libgssapi-krb5-21.13.2+dfsg-4
ii  libk5crypto31.13.2+dfsg-4
ii  libkeyutils11.5.9-8
ii  libkrb5-3   1.13.2+dfsg-4
ii  libmount1   2.27.1-1
ii  libnfsidmap20.25-5
ii  libtirpc1   0.2.5-1
ii  libwrap07.6.q-25
ii  lsb-base9.20150917
ii  rpcbind 0.2.3-0.2
ii  ucf 3.0031

Versions of packages nfs-common recommends:
ii  python  2.7.9-1

Versions of packages nfs-common suggests:
pn  open-iscsi  
pn  watchdog

-- no debconf information
--- /usr/sbin/nfsiostat.orig	2014-08-13 02:55:59.0 +0200
+++ /usr/sbin/nfsiostat	2015-12-04 10:27:00.270935431 +0100
@@ -358,8 +358,8 @@ class DeviceData:
 
-print('\t\t%7.3f' % (ops / sample_time))
-print('\t%7.3f' % (kilobytes / sample_time))
-print('\t%7.3f' % kb_per_op)
-print(' %7d (%3.1f%%)' % (retrans, retrans_percent))
-print('\t%7.3f' % rtt_per_op)
-print('\t%7.3f' % exe_per_op)
+sys.stdout.write('%7.3f' % (ops / sample_time))
+sys.stdout.write('\t\t%7.3f' % (kilobytes / sample_time))
+sys.stdout.write('\t\t%7.3f' % kb_per_op)
+sys.stdout.write('\t %7d (%3.1f%%)' % (retrans, retrans_percent))
+sys.stdout.write('\t\t%7.3f' % rtt_per_op)
+print('\t\t%7.3f' % exe_per_op)
 
@@ -394,4 +394,4 @@ class DeviceData:
 print('   op/s\t\trpc bklog')
-print('%7.2f' % (sends / sample_time))
-print('\t%7.2f' % backlog)
+sys.stdout.write('%7.2f' % (sends / sample_time))
+print('\t\t%7.2f' % backlog)

Re: Bug#776383: system hangs from btrfs

2015-01-27 Thread Martin Steigerwald

Hello!

Am Dienstag, 27. Januar 2015, 15:43:01 schrieb chrysn:
> Package: src:linux
> Version: 3.16.7-ckt2-1
> Severity: normal
> 
> under conditions i can not narrow down further[1], all processes that
> try to access a given mounted btrfs file system freeze. this affects
> even processes like `ps u` called by a user not at home in the affected
> file system inside the first read to an opened /proc/8119/cmdline file.

I suggest you to report this upstream.

There are at least two known BTRFS hang issues even with 3.19 kernel being 
reported on the BTRFS upstream mailing list at vger.kernel.org.

See this thread:

3.19-rc5: Bug 91911: [REGRESSION] rm command hangs big time with deleting 
a lot of files at once

(and bugzilla.kernel.org bug with that number)

3.15 and 3.16 had another hang issue that should be fixed with 3.17 and 
hopefully also with a 3.16 update see:

fix for the infamous deadlock [1] 
https://btrfs.wiki.kernel.org/index.php/Changelog#v3.17_.28Oct_2014.29

[1] 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9e0af23764344f7f1b68e4eefbe7dc865018b63d

(I think there are some other related commits fixing hanging along 
compressed write, like with compress=lzo mount option, I think they may be 
already in the 3.16 kernel you are using from the package.)


Also a general recommendation for me, leave enough free space. Ideally so 
much that BTRFS can still allocate new chunks from unreserved space, see:

[Bug 90401] New: btrfs kworker thread uses up 100% of a Sandybridge core 
for minutes on random write into big file


I am not sure whether any of the mentioned bugs are similar to what you 
see as I didn´t compare the backtraces. If the backtrace looks different 
than any of those in the bug reports and related mail threads, I strongly 
recommend that you report a bug upstream with bugzilla.kernel.org

I think it can help the debian kernel team tremendously to be able to 
cherry-pick an upstream patch, but for that one needs to be written or 
exist already :).  I am not a member of the Debian kernel team, I just 
monitor the debian-kernel mailinglist and use BTRFS since several years 
already on an increasing amount of systems.

That just as a few pointers that you may use to find your way to move along 
with the bug you have.

If you choose to report upstream, do some

echo "t" > /proc/sysrq-trigger

and cut attach the correspondending output of /var/log/kern.log to the 
upstream bug report.

Ciao,,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

signature.asc
Description: This is a digitally signed message part.

Bug#752381: initramfs-tools: does not activate logical volume - two obversations

2015-01-18 Thread Martin Steigerwald

Am Sonntag, 18. Januar 2015, 15:25:52 schrieb Ben Hutchings:
> Control: notfound -1 0.115~bpo70+1
> 
> On Mon, 23 Jun 2014 10:34:02 +0200 Martin Steigerwald  
wrote:
> > Hi!
> > 
> > I bzr diff on /boot/grub/grub.cfg revealed â but already from last week
> > as I upgraded to the newer backport initramfs-tools, where booting still
> > worked> 
> > okay:
> >  menuentry 'Debian GNU/Linux, mit Linux 3.2.0-4-686-pae' --class debian --
> > 
> > class gnu-linux --class gnu --class os {
> > 
> > load_video
> > insmod gzio
> > 
> > @@ -67,7 +90,7 @@
> > 
> > set root='(hd0,msdos1)'
> > search --no-floppy --fs-uuid --set=root [UUID]
> > echo'Linux 3.2.0-4-686-pae wird geladen â¦'
> > 
> > -   linux   /vmlinuz-3.2.0-4-686-pae
> > root=/dev/mapper/mondschein-debian ro +   linux  
> > /vmlinuz-3.2.0-4-686-pae root=UUID=[UUID ro
> > 
> > echo'Initiale Ramdisk wird geladen â¦'
> > initrd  /initrd.img-3.2.0-4-686-pae
> >  
> >  }
> 
> [...]
> 
> The 'UUID=...' syntax is not supported for root on an LV.  You *must*
> use the /dev/mapper device name so that the lvm2 script can work out
> which VG to activate.  (It is not safe in general to activate all
> visible VGs.)

Its not me using a UUID, its update-grub. In /boot/grub/grub.cfg I have:

linux   /vmlinuz-3.16-0.bpo.3-686-pae root=UUID=[some UUID]

yet in /etc/fstab I have:

/dev/mondschein/debian  /  ext4defaults 0 1

In /etc/default/grub I do not set the root= parameter manually. In fact I 
have:

GRUB_CMDLINE_LINUX_DEFAULT=""
GRUB_CMDLINE_LINUX=""

So I do not see where I tell grub to use a UUID. For reference here is the 
complete grub configuration:

# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
#   info -f grub -n 'Simple configuration'

GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT=""
GRUB_CMDLINE_LINUX=""

# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"

# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
#GRUB_GFXMODE=640x480

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true

# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"

# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"

On Sid tough update-grub creates this:

root=/dev/mapper/sata-debian

which does seem to fit what you say initramfs-tools requires (except that by 
default it adds both devices to BTRFS RAID 1, see below about bug 747653).

Please re-open and if you really think its not initramfs-tools bug, reassign 
to grub-pc for having it use /dev/VG/LV syntax instead. Or advise on another 
solution. I can also keep the work-around of course, but its important to make 
sure that in Jessie this setup will work without any additional work-around. 
And if UUIDs are not supported for LVM, I think this deserves a promiment 
mention somewhere as well. Cause not booting due to not activing a logical 
volume is not so nice to the user.

This may be solved there with a patch similar to what upstream provided:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747653#25

I did not yet come around to build grub-pc myself into /usr/local and test 
this patch.

Ciao,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

signature.asc
Description: This is a digitally signed message part.

Re: Bug#775014: nfs-common: Degraded performance on nfs4 clients after upgrade to Jessie

2015-01-11 Thread Martin Steigerwald

As I am interested in NFS performance issues due to my work I copied my work 
address in.

Am Sonntag, 11. Januar 2015, 01:16:03 schrieben Sie:
> El Dissabte, 10 de gener de 2015, a les 19:30:12, Martin Steigerwald va
> escriure:
> [...]
> 
> > I suggest you upgrade to 3.16 bpo kernel. Maybe that already makes a
> > difference. And additionally there is greater chance you get security
> > updates on that one, cause AFAIK older bpo kernels are not maintained
> > anymore.
> 
> It's in one of the main server of my institute and it's not easy. Anyway, I
> have programed it to do it soon. Thanks for the suggestion.
> 
> [...]
> 
> > > cami:/recursos /home/recursos nfs4
> > > rw,sync,nodev,noatime,vers=4.0,rsize=65536,wsize=65536,namlen=255,soft,p
> > > ro
> > > t
> > > o=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.8,local_lo
> > > ck
> > > =n one,addr=192.168.1.254 0 0
> > 
> > What is this on the wheezy machine?
> 
> all the servers are wheezy. The clients are Jessie.
> 
> > Look in grep nfs /proc/mounts or nfsstat -m
> > 
> > I suggest not to manually tune this. Current kernels use good default
> > values. I have seen rsize and wsize of up to 1048576.
> > 
> > Additionally are they all the same hardware, same network cards? If not,
> > what is the fast system using and what is the slow system using?
> 
> well, I have worked on this issue and i have found some conclusions:
> 
> - now, with modern kernels (and nfs4) it has no sense to set rsize and
> wsize. The negotiation between client and server do the best one. So, all
> the pages in the net are outdated.

Hehe, my own training slides where outdated as well – for years. We found out 
about it on one of my Linux performance analysis & tuning trainings as 
participants of the training measures NFS performance with dd with and without 
tuning and it was actually better without tuning. cat /proc/mounts – /etc/mtab 
wasn´t a symlink to it back then – revealed the difference. Thats where I found 
that 1048576 value for both rsize and wsize, instead of the 8192 or 32768 I 
recommended to set.

> - the sync parameter works totally different (client side) in a 3.2 kernel
> than 3.16 (also 3.12 or 3.8) . I'm talking for a similar hardware (Gigabyte
> NIC, similar cpu, etc) but on a 100 Mb network) from ~7MB/s (kernel 3.2 vs
> 63,8 kB/s >3.8). In another environment with a Giga network the rates are (
> ~145 kB/s vs ~70,3 MB/s)

Interesting. For all I know "sync" should be quite okay with NFSv3 and 
upwards. With NFSv2 it was very slow.

> - no significant differences in with wsize. At least that I had found. But
> the default autonegotiation works very well.
> 
> - I still don't understand why, although I have a good hardware in the work,
> when my clients do:
> 
> $ dd if=/dev/zero of=myrandom bs=4096 count=7
> 
> obtains about ~70MB/s
> 
> and if I execute the same in the server I obtain 167 MB/s. About 2.5 time
> slower

Do you mean a local dd versus a dd on the client on the NFS mount?

Also note that dd may not be the best measurement tool depending on your 
workload and that you will have caching effects with dd unless you use 
oflag=direct, which I never tested with NFS mounts, or at least to correct the 
measured time with conv=fsync (I think).

There are some nice slides from Greg Banks from SGI about NFS performance. I 
can dig out the URL to it when they are still available online next week at 
work. They are from 2008, but were much more up to date than many other things 
I found on the net. Most of it is not only outdated, but plain wrong 
meanwhile.

> I still consider this issue important, I think that a lot of people that 
> upgrade to Jessie with nfs mounts will found some problem. but this is just 
> MHO.

I wonder tough whether there is a high probability for a "fix" for wheezy, as 
jessie is shortly before release and its not a bug in itself, but a 
performance issue. And: It may be fixed by just upgrading the kernel to the 
3.16 bpo one.

Ciao,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

signature.asc
Description: This is a digitally signed message part.

Re: Bug#775014: nfs-common: Degraded performance on nfs4 clients after upgrade to Jessie

2015-01-10 Thread Martin Steigerwald

I am no debian kernel maintainer, but as I have seen this, some suggestions to 
try:

Am Samstag, 10. Januar 2015, 01:59:50 schrieb Leopold Palomo-Avellaneda:
> Package: nfs-common
> Version: 1:1.2.8-9
> Severity: important
> 
> I have a typical environment with a nfs server and some clients with home
> there, or shared resources. In the server I have a Wheezy (in one server
> with 3.12-0.bpo.1-amd64 version and in other 3.2.63). My clients basically
> are Wheezy but I'm preparing to Jessie and I wanted to test the upgrade.

I suggest you upgrade to 3.16 bpo kernel. Maybe that already makes a 
difference. And additionally there is greater chance you get security updates 
on that one, cause AFAIK older bpo kernels are not maintained anymore.

> I have realized that in the two cases that I have tested (at home and work)
> both, with the same parameters (fstab) that worked "normal" with Wheezy,
> now, they have an horrible performance in write operations. I'm having
> differences of several order of magnitude (37,9 KB/s Jessie vs 17,4 MB/s)
> 
> For instance:
> Wheezy machine:
> $ dd if=/dev/zero of=myrandom bs=1024 count=1000
[…]
> 1024000 octets (1,0 MB) copiats, 0,0590127 s, 17,4 MB/s
> 
> Jessie machine
> $ dd if=/dev/zero of=myrandom bs=1024 count=1000
[…]
> 1024000 octets (1,0 MB) copiats, 27,0021 s, 37,9 kB/s
> 
> I hope that the kernel developers have changed some default parameter and I
> have it wrong. But, with this version of the kernel, my nfs clients cannot
> work well.
> 
> I'm open to make any test or provide any needed information.
> 
> -- Package-specific info:
[…]
> -- /etc/fstab --
> #nfs4
> cami:/recursos   /home/recursos   
> nfs4  
auto,rw,nodev,sync,_netdev,retry=10,rsize=65536,wsize=65536,soft,noat
> ime,intr   0 0 -- /proc/mounts --
> cami:/recursos /home/recursos nfs4
> rw,sync,nodev,noatime,vers=4.0,rsize=65536,wsize=65536,namlen=255,soft,prot
> o=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.8,local_lock=n
> one,addr=192.168.1.254 0 0

What is this on the wheezy machine?

Look in grep nfs /proc/mounts or nfsstat -m

I suggest not to manually tune this. Current kernels use good default values. 
I have seen rsize and wsize of up to 1048576.

Additionally are they all the same hardware, same network cards? If not, what 
is the fast system using and what is the slow system using?

> -- System Information:
> Debian Release: 8.0
>   APT prefers testing
>   APT policy: (500, 'testing'), (1, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
[…]
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7


--
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/5287189.XHHTq6vgt5@merkaba

Bug#752381: initramfs-tools: does not activate logical volume - two obversations

2014-06-23 Thread Martin Steigerwald

Hi!

I bzr diff on /boot/grub/grub.cfg revealed – but already from last week as I 
upgraded to the newer backport initramfs-tools, where booting still worked
okay:

 menuentry 'Debian GNU/Linux, mit Linux 3.2.0-4-686-pae' --class debian --
class gnu-linux --class gnu --class os {
load_video
insmod gzio
@@ -67,7 +90,7 @@
set root='(hd0,msdos1)'
search --no-floppy --fs-uuid --set=root [UUID]
echo'Linux 3.2.0-4-686-pae wird geladen …'
-   linux   /vmlinuz-3.2.0-4-686-pae root=/dev/mapper/mondschein-debian ro  
+   linux   /vmlinuz-3.2.0-4-686-pae root=UUID=[UUID ro  
echo'Initiale Ramdisk wird geladen …'
initrd  /initrd.img-3.2.0-4-686-pae
 }
@@ -79,7 +102,7 @@
set root='(hd0,msdos1)'
search --no-floppy --fs-uuid --set=root [UUID]
echo'Linux 3.2.0-4-686-pae wird geladen …'
-   linux   /vmlinuz-3.2.0-4-686-pae root=/dev/mapper/mondschein-debian ro 
single 
+   linux   /vmlinuz-3.2.0-4-686-pae root=UUID=[UUID] ro single 
echo'Initiale Ramdisk wird geladen …'
initrd  /initrd.img-3.2.0-4-686-pae
 }


And:

Booting today also failed with 3.2.0 kernel so the issue seems to have
nothing to do with the newer version of the 3.14 backport kernel.

Ciao,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

signature.asc
Description: This is a digitally signed message part.

Bug#752381: initramfs-tools: does not activate logical volume before trying to mount root filesystem on LVM

2014-06-23 Thread Martin Steigerwald

Package: initramfs-tools
Version: 0.115~bpo70+1
Severity: important

What did I do:

Today I installed backports version of open-vm-dkms and upgraded to most
recent 3.14 backport kernel from a previous version of it I installed due
to using BTRFS with skinny meta data on one partition.


Current results:

After this the machine failed to boot. It didn´t find the root filesystem
by its UUID. I typed "vgchange -ay" in initramfs and then Ctrl-D and then
it booted. This used to work without manual interaction before.

To make it boot consistently I added as a work-around:

mondschein:~> cat /etc/initramfs-tools/scripts/local-top/lvm-manual 
#!/bin/sh

PREREQ="lvm"
prereqs()
{
echo $PREREQ
}

case $1 in
prereqs)
prereqs
exit 0;
esac

. /scripts/functions

log_begin_msg "Activitating logical volumes (as it does not seem to be done 
automatically at the moment)."

vgchange -ay

log_end_msg


which I had handy as I use a similar workaround for enabling BTRFS RAID 1
boot on my laptop, which does not work as default.

This worked after actually chmod'ing +x it :)


Expected results:

Machine boots without manual adaptions to InitRD.


Additional information:

The machine still boots from an Ext4 filesystem. The BTRFS filesystem is
mounted later on by fstab.

There is a lvm and a BTRFS script in InitRD already, but the lvm script did
not seem to work properly:

mondschein:~> lsinitramfs /boot/initrd.img-3.14-0.bpo.1-686-pae | grep script
scripts
scripts/functions
scripts/nfs
scripts/init-bottom
scripts/init-bottom/udev
scripts/init-bottom/ORDER
scripts/local-premount
scripts/local-premount/btrfs
scripts/local-premount/resume
scripts/local-premount/ORDER
scripts/local
scripts/local-top
scripts/local-top/lvm-manual
scripts/local-top/lvm2
scripts/local-top/ORDER
scripts/init-top
scripts/init-top/blacklist
scripts/init-top/keymap
scripts/init-top/udev
scripts/init-top/ORDER
scripts/init-top/all_generic_ide


I thought it was an update to initramfs-tools causing this, but these have
been upgraded last week already:

Start-Date: 2014-06-12  11:46:49
Commandline: apt-get install -t wheezy-backports 
linux-image-3.14-0.bpo.1-686-pae linux-headers-3.14-0.bpo.1-686-pae btrfs-tools
Install: linux-headers-3.14-0.bpo.1-686-pae:i386 (3.14.5-1~bpo70+1), 
linux-image-3.14-0.bpo.1-686-pae:i386 (3.14.5-1~bpo70+1), 
linux-compiler-gcc-4.6-x
86:i386 (3.14.5-1~bpo70+1, automatic), btrfs-tools:i386 (3.14.1-1~bpo70+1), 
liblzo2-2:i386 (2.06-1, automatic), linux-kbuild-3.14:i386 (3.14-1~bpo70+1,
 automatic), linux-headers-3.14-0.bpo.1-common:i386 (3.14.5-1~bpo70+1, 
automatic)
Upgrade: initramfs-tools:i386 (0.109.1, 0.115~bpo70+1)
End-Date: 2014-06-12  11:48:06


And there rebooting the machine worked out of the box.

So maybe something in open-vm-tools or open-vm-dkms from wheezy-backports
interacts with InitRD script stuff in a way that breaks boot. But OTOH
I see no open-vm related scripts in above lsinitramfs output.

Thanks,
Martin

-- Package-specific info:
-- initramfs sizes
-rw-r--r-- 1 root root 13M Jun 23 09:58 /boot/initrd.img-3.14-0.bpo.1-686-pae
-rw-r--r-- 1 root root 11M Jun 23 09:58 /boot/initrd.img-3.2.0-4-686-pae
-- /proc/cmdline
BOOT_IMAGE=/vmlinuz-3.14-0.bpo.1-686-pae 
root=UUID=a8e69cdf-f016-4f07-8d2d-d975881d2095 ro

-- resume
RESUME=/dev/sda2
-- /proc/filesystems
btrfs
ext3
ext2
ext4

-- lsmod
Module  Size  Used by
coretemp   12734  0 
crc32_pclmul   12809  0 
crc32c_intel   12624  0 
vmw_balloon12502  0 
irda   90367  0 
parport_pc 25991  0 
crc_ccitt  12331  1 irda
parport35207  1 parport_pc
aesni_intel17934  0 
vmwgfx142296  0 
ttm59829  1 vmwgfx
aes_i586   16647  1 aesni_intel
xts12583  1 aesni_intel
lrw12686  1 aesni_intel
gf128mul   12834  2 lrw,xts
ablk_helper12508  1 aesni_intel
cryptd 14125  1 ablk_helper
psmouse85040  0 
drm   198349  2 ttm,vmwgfx
evdev  17172  0 
serio_raw  12737  0 
pcspkr 12531  0 
i2c_piix4  12592  0 
i2c_core   23454  2 drm,i2c_piix4
battery12949  0 
processor  27575  0 
button 12824  0 
thermal_sys22946  1 processor
ac 12588  0 
shpchp 30673  0 
ext4  454558  4 
crc16  12327  1 ext4
mbcache12938  1 ext4
jbd2   77040  1 ext4
crc32c 12576  1 
btrfs 852360  1 
xor25716  1 btrfs
raid6_pq   95207  1 btrfs
dm_mod 78695  20 
sg 25573  0 
sd_mod 43628  5 
sr_mod 21563  0 
crc_t10dif 12399  1 sd_mod
c

Bug#697360: tp-smapi-source: does not recognize 3.7 kernel headers although they are installed

2013-01-08 Thread Martin Steigerwald

Am Sonntag, 6. Januar 2013 schrieb Evgeni Golov:
> On Sun, Jan 06, 2013 at 02:16:37PM +0100, Martin Steigerwald wrote:
> > > > But the does not recognize the kernel headers issue seems to
> > > > persist.
> > > 
> > > Yeah, but thats a bug in m-a: http://bugs.debian.org/697269, merging.
> > > :) As hoped, no bug in tp-smapi here :)
> > 
> > Thanks for looking into it :)
> 
> Can you try this one?
> http://people.debian.org/~evgeni/tmp/module-assistant_0.11.4+nmu1_all.deb

Yes, this does work (on a different box which showed exactly the same issue).

Thanks,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7


-- 
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/201301081051.05990.mar...@lichtvoll.de

Re: Processed: BTRFS raid configurations do not work out of the box

2012-07-24 Thread Martin Steigerwald

- Ursprüngliche Mail -
> Processing commands for cont...@bugs.debian.org:
> 
> > reassign 634658 initramfs-tools 0.107
> Bug #634658 {Done: Daniel Baumann
> } [btrfs-tools] please
> support raid configurations automatically
> Bug #653632 {Done: Daniel Baumann
> } [btrfs-tools] please
> support raid configurations automatically
> Bug reassigned from package 'btrfs-tools' to 'initramfs-tools'.
> Bug reassigned from package 'btrfs-tools' to 'initramfs-tools'.
> No longer marked as found in versions btrfs-tools/0.19+2005-2 and
> btrfs-tools/0.19+20100601-3.
> No longer marked as found in versions btrfs-tools/0.19+2005-2 and
> btrfs-tools/0.19+20100601-3.
> No longer marked as fixed in versions btrfs-tools/0.19+20120328-3.
> No longer marked as fixed in versions btrfs-tools/0.19+20120328-3.
> Bug #634658 {Done: Daniel Baumann
> } [initramfs-tools] please
> support raid configurations automatically
> Bug #653632 {Done: Daniel Baumann
> } [initramfs-tools] please
> support raid configurations automatically
> Marked as found in versions initramfs-tools/0.107.
> Marked as found in versions initramfs-tools/0.107.
> > thanks
> Stopping processing here.

Sorry, this was not what I intended by reassigning. I can try to undo it and 
fix it up by reassign to btrfs-tools, using found / notfound and so on if you 
want.

Thanks,
-- 
Martin Steigerwald - teamix GmbH - http://www.teamix.de
gpg: 19E3 8D42 896F D004 08AC A0CA 1E10 C593 0399 AE90


--
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/1426970139.903290.1343138619355.javamail.r...@teamix.de

Bug#679094: linux-image-3.4-trunk-amd64: 3.2, 3.3 and 3.4 debian kernels lack latencytop support

2012-06-27 Thread Martin Steigerwald

Am Mittwoch, 27. Juni 2012 schrieb Ben Hutchings:
> On Tue, 2012-06-26 at 12:46 +0200, Martin Steigerwald wrote:
> [...]
> 
> > The current Debian kernels all lack latencytop support:
> [...]
> 
> > Please consider activating this support again.
> 
> What do you mean, 'again'?

I thought this was once working out of the box, but maybe that was at a time 
where I compiled my own kernels and had it enabled.

> > Otherwise someone who wants to use latencytop needs to recompile the
> > kernel which greatly reduces the usefulness of the latencytop package.
> 
> This costs 1680 or 3360 bytes of non-paged memory for every thread in
> the system (depending on word size), even if the feature is never
> actually used.  On my laptop, for example, this would be about a
> megabyte.  I really don't think this is a good idea.

I found out that it will need the framepointer stuff which makes the kernel 
slightly larger and slower only after writing the bug report.

While I do not care that much about the megabyte given current memory sizes, I 
am concerned about the "slightly slower". And then its declared as kernel 
hacking feature in the configuration anyway. And for older / embedded machines 
1 MiB might be much.

So I can understand your reasoning. Feel free to close as won't fix or 
"dependent / waiting for upstream fix" if thats possible.

> It is probably possible to change the way the latency records are kept
> so that this memory is allocated only when needed, but I'm unlikely to
> find the time to do that.

Care to elaborate on that one a bit. I am willing to open a upstream bug 
report about that and include your idea and a reference to this debian bug 
report.

Thanks,
-- 
Martin Steigerwald - teamix GmbH - http://www.teamix.de
gpg: 19E3 8D42 896F D004 08AC A0CA 1E10 C593 0399 AE90

-- 
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/201206271034.43139...@teamix.de

Bug#679094: linux-image-3.4-trunk-amd64: 3.2, 3.3 and 3.4 debian kernels lack latencytop support

2012-06-26 Thread Martin Steigerwald

Package: linux-2.6
Version: 3.4.1-1~experimental.1
Severity: normal

Dear Maintainer,

On reporting

latencytop: fails with error "no protocol specified" I found:
http://bugs.debian.org/679091


I found:

ms@mango:~> sux
Passwort: 
xauth:  file /root/.Xauthority does not exist
bash: Kann die Prozessgruppe des Terminals nicht setzen (-1).: Unpassender 
IOCTL (I/O-Control) für das Gerät
bash: Keine Job Steuerung in dieser Shell.
mango:/home/ms# latencytop
mount: none already mounted or /sys/kernel/debug/ busy
mount: according to mtab, none is already mounted on /sys/kernel/debug
Please enable the CONFIG_LATENCYTOP configuration in your kernel.
Exiting...


The current Debian kernels all lack latencytop support:

mango:~# grep LATENCY /boot/config-*
/boot/config-3.2.0-2-amd64:CONFIG_HAVE_LATENCYTOP_SUPPORT=y
/boot/config-3.2.0-2-amd64:# CONFIG_LATENCYTOP is not set
/boot/config-3.3.0-trunk-amd64:CONFIG_HAVE_LATENCYTOP_SUPPORT=y
/boot/config-3.3.0-trunk-amd64:# CONFIG_LATENCYTOP is not set
/boot/config-3.4-trunk-amd64:CONFIG_HAVE_LATENCYTOP_SUPPORT=y
/boot/config-3.4-trunk-amd64:# CONFIG_LATENCYTOP is not set


Please consider activating this support again.

Otherwise someone who wants to use latencytop needs to recompile the
kernel which greatly reduces the usefulness of the latencytop package.

Thanks,
Martin

-- Package-specific info:
** Version:
Linux version 3.4-trunk-amd64 (Debian 3.4.1-1~experimental.1) 
(debian-kernel@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-1) ) #1 SMP 
Wed Jun 6 10:34:53 CEST 2012

** Command line:
BOOT_IMAGE=/vmlinuz-3.4-trunk-amd64 
root=UUID=459c3940-f915-460f-a673-386121d7a8c6 ro resume=/dev/sda7 
no_console_suspend

** Tainted: WO (4608)
 * Taint on warning.
 * Out-of-tree module has been loaded.

** Kernel log:
[ 8225.257334] e1000e :00:19.0: irq 40 for MSI/MSI-X
[ 8225.257337] snd_hda_intel :00:1b.0: irq 43 for MSI/MSI-X
[ 8225.257376] ehci_hcd :00:1d.0: setting latency timer to 64
[ 8225.257389] usb usb2: root hub lost power or was reset
[ 8225.257396] pci :00:1e.0: setting latency timer to 64
[ 8225.257413] ahci :00:1f.2: setting latency timer to 64
[ 8225.261287] ehci_hcd :00:1d.0: cache line size of 32 is not supported
[ 8225.306523] parport_pc 00:0a: activated
[ 8225.306774] serial 00:0b: activated
[ 8225.577530] ata8: SATA link down (SStatus 0 SControl 300)
[ 8225.577561] ata7: SATA link down (SStatus 0 SControl 300)
[ 8225.577591] ata5: SATA link down (SStatus 0 SControl 300)
[ 8225.613435] usb 1-1: reset high-speed USB device number 2 using ehci_hcd
[ 8225.749017] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 8225.749107] ata6: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 8225.749137] ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 8225.752692] ata4.00: configured for UDMA/100
[ 8225.755299] ata3.00: configured for UDMA/133
[ 8225.755417] sd 2:0:0:0: [sda] Starting disk
[ 8225.757292] ata6.00: configured for UDMA/133
[ 8225.757367] sd 5:0:0:0: [sdb] Starting disk
[ 8225.856806] usb 2-1: reset high-speed USB device number 2 using ehci_hcd
[ 8226.060330] usb 1-1.4: reset high-speed USB device number 3 using ehci_hcd
[ 8227.038062] usb 2-1.8: reset low-speed USB device number 4 using ehci_hcd
[ 8227.576710] usb 2-1.7: reset low-speed USB device number 3 using ehci_hcd
[ 8227.870701] PM: restore of devices complete after 2624.032 msecs
[ 8227.870807] PM: Image restored successfully.
[ 8227.870809] Restarting tasks ... done.
[ 8227.873014] PM: Basic memory bitmaps freed
[ 8228.008570] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: 
Rx
[ 8903.147658] scsi_verify_blk_ioctl: 444 callbacks suppressed
[ 8903.147664] mdadm: sending ioctl 1261 to a partition!
[ 8903.147668] mdadm: sending ioctl 1261 to a partition!
[ 8903.294210] mdadm: sending ioctl 1261 to a partition!
[ 8903.294217] mdadm: sending ioctl 1261 to a partition!
[ 8903.385724] mdadm: sending ioctl 1261 to a partition!
[ 8903.385728] mdadm: sending ioctl 1261 to a partition!
[ 8903.489773] mdadm: sending ioctl 1261 to a partition!
[ 8903.489780] mdadm: sending ioctl 1261 to a partition!
[ 8903.649346] mdadm: sending ioctl 1261 to a partition!
[ 8903.649350] mdadm: sending ioctl 1261 to a partition!
[ 8908.319036] scsi_verify_blk_ioctl: 44 callbacks suppressed
[ 8908.319039] mdadm: sending ioctl 1261 to a partition!
[ 8908.319041] mdadm: sending ioctl 1261 to a partition!
[ 8908.415940] mdadm: sending ioctl 1261 to a partition!
[ 8908.415947] mdadm: sending ioctl 1261 to a partition!
[ 8908.884496] JFS: nTxBlock = 8192, nTxLock = 65536
[ 8908.935072] NTFS driver 2.1.30 [Flags: R/W MODULE].
[ 8908.995222] QNX4 filesystem 0.2.3 registered.
[ 8909.024033] fuse init (API version 7.18)
[ 8910.918371] blockdev: sending ioctl 125d to a partition!
[ 8910.918377] blockdev: sending ioctl 125d to a partition!
[ 8910.931572] blockdev: sending ioctl 125d to a partition!
[ 8910.931579] blockdev: sending ioctl 125d to a partition!
[ 8912.293901] blockdev:

Bug#663433: closed by Bastian Blank (Bug#663433: fixed in linux-2.6 3.2.10-1)

2012-03-14 Thread Martin Steigerwald

Am Dienstag, 13. März 2012 schrieben Sie:
> This is an automatic notification regarding your Bug report
> which was filed against the linux-2.6 package:
> 
> #663433: udev: does not load acpiphp on ThinkPad T520 although it is
> needed for ExpressCard hotplugging

Many thanks for fixing this issue.

Ciao,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7



--
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/201203141530.07550.mar...@lichtvoll.de

Re: Bug#663433: udev: does not load acpiphp on ThinkPad T520 although it is needed for ExpressCard hotplugging

2012-03-11 Thread Martin Steigerwald

Am Sonntag, 11. März 2012 schrieb Marco d'Itri:
> On Mar 11, Martin Steigerwald  wrote:
> > So please advice. Is it sufficient for ask for module aliases being
> > added upstream? If I know how I can provide the necessary info for
> > my ThinkPad T520.
> 
> I am not familiar with ExpressCard, so I do not know exactly what is
> needed.

No problem. Maybe someone from the Debian kernel team knows. If not I can 
also ask upstream.

Sorry for not dropping cont...@bugs.debian.org.

Thanks,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7


--
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/201203111055.07406.mar...@lichtvoll.de

Re: Bug#663433: udev: does not load acpiphp on ThinkPad T520 although it is needed for ExpressCard hotplugging

2012-03-11 Thread Martin Steigerwald

Am Sonntag, 11. März 2012 schrieb Marco d'Itri:
> reassign 663433 linux-2.6
> thanks
> 
> On Mar 11, Martin Steigerwald  wrote:
> > I reported it upstream on kernel.org back then, but maybe it is more
> > of a userspace, of a udev issue, cause when the module is loaded
> > hot plugging of Express Cards does work as expected.
> 
> The module does not provide any aliases for autoloading.

Thanks for that ultra quick answer. I am willing to reopen the bug report 
at kernel.org if something should be changed upstream and I precisely 
understand what it is.

So please advice. Is it sufficient for ask for module aliases being added 
upstream? If I know how I can provide the necessary info for my ThinkPad 
T520.

Thanks and have a nice sunday,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7


--
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/201203111052.29225.mar...@lichtvoll.de

Bug#644236: installation fails when rpcbind is disabled, although nfs-common is disabled there too

2011-10-04 Thread Martin Steigerwald

Package: nfs-common
Version: 1:1.2.5-2
Severity: important

Dear Maintainer,

I have found a bug on upgrading nfs-common that might be nfs-common
init script header or insserv related:


   * What led up to the situation?

Upgrading nfs-common when nfs-common and (!) rpcbind is disabled in
insserv.

merkaba:~> LANG=C apt-get upgrade
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following packages have been kept back:
  kmymoney kmymoney-common tryton-client
0 upgraded, 0 newly installed, 0 to remove and 3 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue [Y/n]? 
Setting up nfs-common (1:1.2.5-2) ...
insserv: Service rpcbind has to be enabled to start service nfs-common
insserv: exiting now!
update-rc.d: error: insserv rejected the script header
dpkg: error processing nfs-common (--configure):
 subprocess installed post-installation script returned error exit status 1
configured to not write apport reports
  Errors were encountered while processing:
 nfs-common
E: Sub-process /usr/bin/dpkg returned an error code (1)


   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Explicetely disabling nfs-common again does not help:

merkaba:~> insserv -r nfs-common
merkaba:~> LANG=C apt-get upgrade  
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following packages have been kept back:
  kmymoney kmymoney-common tryton-client
0 upgraded, 0 newly installed, 0 to remove and 3 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue [Y/n]? 
Setting up nfs-common (1:1.2.5-2) ...
insserv: Service rpcbind has to be enabled to start service nfs-common
insserv: exiting now!
update-rc.d: error: insserv rejected the script header
dpkg: error processing nfs-common (--configure):
 subprocess installed post-installation script returned error exit status 1
configured to not write apport reports
  Errors were encountered while processing:
 nfs-common
E: Sub-process /usr/bin/dpkg returned an error code (1)


   * What was the outcome of this action?

The installation failed.


   * What outcome did you expect instead?

It should have succeeded. This is on a laptop where I only use NFS
on demand. I do not want to have it running when I do not use it.

I think this is a valid usage scenario.

Thus when nfs-common *and* rpcbind are disabled in insserv installation
should still succeed.

This might be a bug in insserv. If so please reassign.


   * Workaround to have apt upgrade nfs-common

Temporarily enabling both nfs-common and rpcbind lets nfs-common upgrade
smoothly:

merkaba:~#100> insserv rpcbind 
merkaba:~> insserv nfs-common
merkaba:~> LANG=C apt-get upgrade
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following packages have been kept back:
  kmymoney kmymoney-common tryton-client
0 upgraded, 0 newly installed, 0 to remove and 3 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue [Y/n]? 
Setting up nfs-common (1:1.2.5-2) ...
Stopping NFS common utilities: idmapd statd.
Starting NFS common utilities: statd
Not starting: portmapper is not running ... (warning).
merkaba:~> insserv -r nfs-common
merkaba:~> insserv -r rpcbind   
merkaba:~>

Bug script failed due to rpcbind not running, but I do not think
it matters for this bugreport. If you want to have output of it,
please tell.

Thanks,
Martin

*** End of the template - remove these lines ***


-- Package-specific info:
-- rpcinfo --

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (120, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages nfs-common depends on:
ii  adduser 3.113
ii  initscripts 2.88dsf-13.11
ii  libc6   2.13-21  
ii  libcap2 1:2.22-1 
ii  libcomerr2  1.42~WIP-2011-09-25-1
ii  libdevmapper1.02.1  2:1.02.65-1  
ii  libevent-1.4-2  1.4.14b-stable-1 
ii  libgssapi-krb5-21.9.1+dfsg-3 
ii  libgssglue1 0.3-3
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

Bug#625603: bug script does not work

2011-05-09 Thread Martin Steigerwald

Am Mittwoch, 4. Mai 2011, 19:20:43 schrieb Luk Claes:
> On 05/04/2011 03:44 PM, Martin Steigerwald wrote:
> > Please select tags: (one at a time) [none]
> > Gathering additional data, this may take a while...
> > rpcinfo: can't contact portmapper: rpcinfo: RPC: Authentication error;
> > why = Client credential too weak The package bug script
> > /usr/share/bug/nfs-common/script exited with an error status (return
> > code = 256). Do you still want to file a report? [y|N|q|?]?
> 
> Any reason why you don't allow connections from unpriviledged ports on
> localhost to portmapper? This might very well be related to the other
> bug you filed...

No. I was not aware that I did, but you are right, I had NFS services without 
LOCAL in /etc/hosts.allow. But now I changed it and even commented out the NFS 
entries from /etc/hosts.allow completely and it still does not work.

Now I just have:

shambhala:/etc> tail -8 hosts.allow 
ALL: LOCAL
sshd   : ALL
#portmap: LOCAL 10.0.0.0/16 172.21.0.0/16
#mountd : LOCAL 10.0.0.0/16 172.21.0.0/16
#lockd  : LOCAL 10.0.0.0/16 172.21.0.0/16
#statd  : LOCAL 10.0.0.0/16 172.21.0.0/16
#rquotad: LOCAL 10.0.0.0/16 172.21.0.0/16

Any hints where else to look?

Thanks,
-- 
Martin Steigerwald
Trainer / Consultant / Systems Engineer

team(ix) GmbH
Solide IT-Infrastruktur
Südwestpark 35
90449 Nürnberg

fon:   +49 (911) 30999- 0
fax:   +49 (911) 30999-99
mail:  m...@teamix.de
web:   http://www.teamix.de
vcf:   http://www.teamix.de/vcf/ms.vcf
gpg:   19E3 8D42 896F D004 08AC
   A0CA 1E10 C593 0399 AE90

Amtsgericht Nürnberg, HRB 18320
Geschäftsführer: Oliver Kügow, Richard Müller


signature.asc
Description: This is a digitally signed message part.

Bug#625603: bug script does not work

2011-05-04 Thread Martin Steigerwald

Package: nfs-common
Version: 1:1.2.3-2
Severity: normal

Please select tags: (one at a time) [none] 
Gathering additional data, this may take a while...
rpcinfo: can't contact portmapper: rpcinfo: RPC: Authentication error; why = 
Client credential too weak
The package bug script /usr/share/bug/nfs-common/script exited with an error 
status (return code = 256). Do you still want to file a report? [y|N|q|?]?

Thanks.

-- Package-specific info:
-- rpcinfo --

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (450, 'testing'), (400, 'unstable'), (110, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.38.5-tp42-snapshot-resv-size-dirty (PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages nfs-common depends on:
ii  adduser  3.112+nmu2  add and remove users and groups
ii  initscripts  2.88dsf-13.5scripts for initializing and shutt
ii  libc62.11.2-11   Embedded GNU C Library: Shared lib
ii  libcap2  1:2.20-1support for getting/setting POSIX.
ii  libcomerr2   1.41.12-2   common error description library
ii  libevent-1.4-2   1.4.13-stable-1 An asynchronous event notification
ii  libgssapi-krb5-2 1.9+dfsg-1+b1   MIT Kerberos runtime libraries - k
ii  libgssglue1  0.2-2   mechanism-switch gssapi library
ii  libk5crypto3 1.9+dfsg-1+b1   MIT Kerberos runtime libraries - C
ii  libkrb5-31.9+dfsg-1+b1   MIT Kerberos runtime libraries
ii  libnfsidmap2 0.24-1  An nfs idmapping library
ii  libtirpc10.2.1-1 transport-independent RPC library
ii  libwrap0 7.6.q-19Wietse Venema's TCP wrappers libra
ii  lsb-base 3.2-27  Linux Standard Base 3.2 init scrip
ii  netbase  4.45Basic TCP/IP networking system
ii  rpcbind  0.2.0-6 converts RPC program numbers into 
ii  ucf  3.0025+nmu2 Update Configuration File: preserv

Versions of packages nfs-common recommends:
ii  python2.6.6-14   interactive high-level object-orie

nfs-common suggests no packages.

-- Configuration Files:
/etc/init.d/nfs-common changed:
DESC="NFS common utilities"
DEFAULTFILE=/etc/default/nfs-common
PREFIX=
NEED_STATD=
NEED_IDMAPD=
NEED_GSSD=
PIPEFS_MOUNTPOINT=/var/lib/nfs/rpc_pipefs
RPCGSSDOPTS=
if [ -f $DEFAULTFILE ]; then
. $DEFAULTFILE
fi
. /lib/lsb/init-functions
[ -x $PREFIX/sbin/rpc.statd ] || exit 0
AUTO_NEED_IDMAPD=no
AUTO_NEED_GSSD=no
if [ -f /etc/fstab ]; then
exec 9<&0 /dev/tcp/localhost/111) 2>/dev/null
RET=$?
if [ $RET != 0 ]; then
echo
log_warning_msg "Not starting: portmap daemon is not running"
exit 0
fi
start-stop-daemon --start --oknodo --quiet \
--pidfile /var/run/rpc.statd.pid \
--exec $PREFIX/sbin/rpc.statd -- $STATDOPTS
RET=$?
if [ $RET != 0 ]; then
log_end_msg $RET
exit $RET
else
mkdir -p /lib/init/rw/sendsigs.omit.d
rm -f /lib/init/rw/sendsigs.omit.d/statd
ln -s /var/run/rpc.statd.pid /lib/init/rw/sendsigs.omit.d/statd
fi
fi
# Don't start idmapd and gssd if we don't have them (say, if /usr is not
# up yet).
[ -x /usr/sbin/rpc.idmapd ] || NEED_IDMAPD=no
[ -x /usr/sbin/rpc.gssd   ] || NEED_GSSD=no
if [ "$NEED_IDMAPD" = yes ] || [ "$NEED_GSSD" = yes ]
then
do_modprobe sunrpc
do_modprobe nfs
do_modprobe nfsd
if do_mount rpc_pipefs $PIPEFS_MOUNTPOINT
then
if [ "$NEED_IDMAPD" = yes ]
then
log_progress_msg "idmapd"
start-stop-daemon --start --oknodo --quiet \
--exec /usr/sbin/rpc.idmapd
RET=$?
if [ $RET != 0 ]; then
log_end_msg $RET
exit $RET
fi
fi
if [ "$NEED_GSSD" = yes ]
then
do_modprobe rpcsec_gss_krb5
log_progress_msg "gssd"
# we need this available; better to fail now than
# mysteriously on the first mount
if ! grep -q -E '^nfs[   ]' /etc/services; then
log_action_end_msg 1 "broken /etc/services, please see 
/usr/share/doc/nfs-common/README.Debian.nfsv4"
exit 1
fi
start-stop-daemon --start --oknodo --quiet \
--exec /usr/sbin/rpc.gssd

Bug#625601: mount.nfs complains about statd is not running while it is running

2011-05-04 Thread Martin Steigerwald

Package: nfs-common
Version: 1:1.2.3-2
Severity: important

rpcinfo: can't contact portmapper: rpcinfo: RPC: Authentication error; why = 
Client credential too weak
The package bug script /usr/share/bug/nfs-common/script exited with an error 
status (return code = 256). Do you still want to file a report? [y|N|q|?]?

reporting nevertheless.

I start nfs client services:

shambhala:~> /etc/init.d/nfs-common stop
Stopping NFS common utilities: idmapd statd.
shambhala:~> /etc/init.d/rpcbind stop
Stopping rpcbind daemon
shambhala:~> /etc/init.d/rpcbind start
Starting rpcbind daemon
shambhala:~> rpcinfo -p
   program vers proto   port  service
104   tcp111  portmapper
103   tcp111  portmapper
102   tcp111  portmapper
104   udp111  portmapper
103   udp111  portmapper
102   udp111  portmapper
shambhala:~> /etc/init.d/nfs-common start
Starting NFS common utilities: statd idmapd.
shambhala:~> rpcinfo -p
   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  37575  status
1000241   tcp  54562  status
shambhala:~> ps aux | grep statd | grep -v grep
statd13555  0.0  0.0   2268  1012 ?Ss   15:37   0:00 /sbin/rpc.statd


I mount an export:

shambhala:~> mount -t nfs -o vers=3 172.21.101.9:/vol/nfstest /mnt/zeit
/bin/sh: Illegal option -p
mount.nfs: rpc.statd is not running but is required for remote locking.
mount.nfs: Either use '-o nolock' to keep locks local, or start statd.
mount.nfs: an incorrect mount option was specified

(I reported the bashism in /usr/sbin/start-statd separately.)


I have in daemon.log:

shambhala:~> tail -3 /var/log/daemon.log
May  4 15:37:35 localhost rpc.statd[13555]: Version 1.2.3 starting
May  4 15:37:35 localhost sm-notify[13556]: Version 1.2.3 starting
May  4 15:37:35 localhost sm-notify[13556]: Already notifying clients; Exiting!

sm-notify does not appear to be running:

shambhala:~> ps aux | egrep "(rpc|sm-notify)" | grep -v grep
root  1906  0.0  0.0  0 0 ?S<   13:55   0:00 [rpciod]
root 13544  0.0  0.0   2204   932 ?Ss   15:37   0:00 /sbin/rpcbind 
-w
statd13555  0.0  0.0   2268  1012 ?Ss   15:37   0:00 /sbin/rpc.statd
root 13568  0.0  0.0   2492   536 ?Ss   15:37   0:00 
/usr/sbin/rpc.idmapd

Thanks.

-- Package-specific info:
-- rpcinfo --

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (450, 'testing'), (400, 'unstable'), (110, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.38.5-tp42-snapshot-resv-size-dirty (PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages nfs-common depends on:
ii  adduser  3.112+nmu2  add and remove users and groups
ii  initscripts  2.88dsf-13.5scripts for initializing and shutt
ii  libc62.11.2-11   Embedded GNU C Library: Shared lib
ii  libcap2  1:2.20-1support for getting/setting POSIX.
ii  libcomerr2   1.41.12-2   common error description library
ii  libevent-1.4-2   1.4.13-stable-1 An asynchronous event notification
ii  libgssapi-krb5-2 1.9+dfsg-1+b1   MIT Kerberos runtime libraries - k
ii  libgssglue1  0.2-2   mechanism-switch gssapi library
ii  libk5crypto3 1.9+dfsg-1+b1   MIT Kerberos runtime libraries - C
ii  libkrb5-31.9+dfsg-1+b1   MIT Kerberos runtime libraries
ii  libnfsidmap2 0.24-1  An nfs idmapping library
ii  libtirpc10.2.1-1 transport-independent RPC library
ii  libwrap0 7.6.q-19Wietse Venema's TCP wrappers libra
ii  lsb-base 3.2-27  Linux Standard Base 3.2 init scrip
ii  netbase  4.45Basic TCP/IP networking system
ii  rpcbind  0.2.0-6 converts RPC program numbers into 
ii  ucf  3.0025+nmu2 Update Configuration File: preserv

Versions of packages nfs-common recommends:
ii  python2.6.6-14   interactive high-level object-orie

nfs-common suggests no packages.

-- Configuration Files:
/etc/init.d/nfs-common changed:
DESC="NFS common utilities"
DEFAULTFILE=/etc/default/nfs-common
PREFIX=
NEED_STATD=
NEED_IDMAPD=
NEED_GSSD=
PIPEFS_MOUNTPOINT=/var/lib/nfs/rpc_pipefs
RPCGSSDOPTS=
if [ -f $DEFAULTFILE ]; then
. $DEFAULTFILE
fi
. /lib/lsb/init-functions
[ -x $PREFIX/sbin/rpc.statd ] || exit 0
AUTO_NEED_IDMAPD=no
AUTO_NEED_GSSD=no
if [ -f /etc/fstab ]; then
exec 9<&0 /dev/tcp/localhost/111) 2>/dev/null
RET=$?

Bug#625600: bashism in /usr/sbin/start-statd

2011-05-04 Thread Martin Steigerwald

Package: nfs-common
Version: 1:1.2.3-2
Severity: normal

rpcinfo: can't contact portmapper: rpcinfo: RPC: Authentication error; why = 
Client credential too weak
The package bug script /usr/share/bug/nfs-common/script exited with an error 
status (return code = 256). Do you still want to file a report? [y|N|q|?]?

reporting nevertheless.


shambhala:~> mount -t nfs -o vers=3 172.21.101.9:/vol/nfstest /mnt/zeit
/bin/sh: Illegal option -p
[...]

shambhala:~> head -1 /usr/sbin/start-statd   
#!/bin/sh -p

shambhala:~> ls -l /bin/sh 
lrwxrwxrwx 1 root root 4 20. Dez 10:35 /bin/sh -> dash

Without -p the error message does not appear.

-- Package-specific info:
-- rpcinfo --

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (450, 'testing'), (400, 'unstable'), (110, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.38.5-tp42-snapshot-resv-size-dirty (PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages nfs-common depends on:
ii  adduser  3.112+nmu2  add and remove users and groups
ii  initscripts  2.88dsf-13.5scripts for initializing and shutt
ii  libc62.11.2-11   Embedded GNU C Library: Shared lib
ii  libcap2  1:2.20-1support for getting/setting POSIX.
ii  libcomerr2   1.41.12-2   common error description library
ii  libevent-1.4-2   1.4.13-stable-1 An asynchronous event notification
ii  libgssapi-krb5-2 1.9+dfsg-1+b1   MIT Kerberos runtime libraries - k
ii  libgssglue1  0.2-2   mechanism-switch gssapi library
ii  libk5crypto3 1.9+dfsg-1+b1   MIT Kerberos runtime libraries - C
ii  libkrb5-31.9+dfsg-1+b1   MIT Kerberos runtime libraries
ii  libnfsidmap2 0.24-1  An nfs idmapping library
ii  libtirpc10.2.1-1 transport-independent RPC library
ii  libwrap0 7.6.q-19Wietse Venema's TCP wrappers libra
ii  lsb-base 3.2-27  Linux Standard Base 3.2 init scrip
ii  netbase  4.45Basic TCP/IP networking system
ii  rpcbind  0.2.0-6 converts RPC program numbers into 
ii  ucf  3.0025+nmu2 Update Configuration File: preserv

Versions of packages nfs-common recommends:
ii  python2.6.6-14   interactive high-level object-orie

nfs-common suggests no packages.

-- Configuration Files:
/etc/init.d/nfs-common changed:
DESC="NFS common utilities"
DEFAULTFILE=/etc/default/nfs-common
PREFIX=
NEED_STATD=
NEED_IDMAPD=
NEED_GSSD=
PIPEFS_MOUNTPOINT=/var/lib/nfs/rpc_pipefs
RPCGSSDOPTS=
if [ -f $DEFAULTFILE ]; then
. $DEFAULTFILE
fi
. /lib/lsb/init-functions
[ -x $PREFIX/sbin/rpc.statd ] || exit 0
AUTO_NEED_IDMAPD=no
AUTO_NEED_GSSD=no
if [ -f /etc/fstab ]; then
exec 9<&0 /dev/tcp/localhost/111) 2>/dev/null
RET=$?
if [ $RET != 0 ]; then
echo
log_warning_msg "Not starting: portmap daemon is not running"
exit 0
fi
start-stop-daemon --start --oknodo --quiet \
--pidfile /var/run/rpc.statd.pid \
--exec $PREFIX/sbin/rpc.statd -- $STATDOPTS
RET=$?
if [ $RET != 0 ]; then
log_end_msg $RET
exit $RET
else
mkdir -p /lib/init/rw/sendsigs.omit.d
rm -f /lib/init/rw/sendsigs.omit.d/statd
ln -s /var/run/rpc.statd.pid /lib/init/rw/sendsigs.omit.d/statd
fi
fi
# Don't start idmapd and gssd if we don't have them (say, if /usr is not
# up yet).
[ -x /usr/sbin/rpc.idmapd ] || NEED_IDMAPD=no
[ -x /usr/sbin/rpc.gssd   ] || NEED_GSSD=no
if [ "$NEED_IDMAPD" = yes ] || [ "$NEED_GSSD" = yes ]
then
do_modprobe sunrpc
do_modprobe nfs
do_modprobe nfsd
if do_mount rpc_pipefs $PIPEFS_MOUNTPOINT
then
if [ "$NEED_IDMAPD" = yes ]
then
log_progress_msg "idmapd"
start-stop-daemon --start --oknodo --quiet \
--exec /usr/sbin/rpc.idmapd
RET=$?
if [ $RET != 0 ]; then
log_end_msg $RET
exit $RET
fi
fi
if [ "$NEED_GSSD" = yes ]
then
do_modprobe rpcsec_gss_krb5
log_progress_msg "gssd"
# we need this available; better to fail now than
# mysteriously on the first mount
if ! grep -q -E '^nfs[   ]' /etc/services; then
log_action_end_msg 1 "broken /etc/service

Bug#588517: /usr/sbin/mkinitramfs: 331: lzop -9: not found while updating a initramfs for kernel 2.6.34.1

2010-07-12 Thread Martin Steigerwald

Am Freitag 09 Juli 2010 schrieb Michael Prokop:
> * Martin Steigerwald  [Fri Jul 09, 2010 at 
11:52:58AM +0200]:
> > shambhala:~> update-initramfs -u -k
> > 2.6.34.1-tp42-toi-3.1.1.1-04990-g3a7d1f4 update-initramfs:
> > Generating /boot/initrd.img-2.6.34.1-tp42-toi-3.1.1.1-04990-g3a7d1f4
> > W: mdadm: /etc/mdadm/mdadm.conf defines no arrays.
> > W: mdadm: no arrays defined in configuration file.
> > TuxOnIce user interface is disabled, skipping...
> > /usr/sbin/mkinitramfs: 331: lzop -9: not found
> > update-initramfs: failed for
> > /boot/initrd.img-2.6.34.1-tp42-toi-3.1.1.1-04990-g3a7d1f4
> 
> [...]
> 
> Thanks, verified, will provide a fix.
> 
> The problem is the (lack of) wordsplitting of compress="lzop -9".

Is it just that fix?

shambhala:~> diff -u -p1 /usr/sbin/mkinitramfs-2010-07-12 
/usr/sbin/mkinitramfs  
--- /usr/sbin/mkinitramfs-2010-07-122010-07-06 12:58:32.0 
+0200
+++ /usr/sbin/mkinitramfs   2010-07-12 22:08:39.103083590 +0200
@@ -324,3 +324,3 @@ eval `
cpio --quiet --dereference -o -H newc 4>&-; echo "ec2=$?;" 
>&4
-   } | "${compress}" >"${outfile}"
+   } | ${compress} >"${outfile}"
echo "ec3=$?;" >&4

Seems to work here. Seems to be one escaping to much ;-).

Regards,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7


signature.asc
Description: This is a digitally signed message part.

Bug#588517: /usr/sbin/mkinitramfs: 331: lzop -9: not found while updating a initramfs for kernel 2.6.34.1

2010-07-09 Thread Martin Steigerwald

Package: initramfs-tools
Version: 0.97.2
Severity: important

On updating the initramfs during todays apt-get dist-upgrade I got:

shambhala:~> update-initramfs -u -k 2.6.34.1-tp42-toi-3.1.1.1-04990-g3a7d1f4
update-initramfs: Generating 
/boot/initrd.img-2.6.34.1-tp42-toi-3.1.1.1-04990-g3a7d1f4
W: mdadm: /etc/mdadm/mdadm.conf defines no arrays.
W: mdadm: no arrays defined in configuration file.
TuxOnIce user interface is disabled, skipping...
/usr/sbin/mkinitramfs: 331: lzop -9: not found
update-initramfs: failed for 
/boot/initrd.img-2.6.34.1-tp42-toi-3.1.1.1-04990-g3a7d1f4

lzop is installed and working however:

shambhala:~#1> which lzop
/usr/bin/lzop
shambhala:~> cp /etc/fstab /tmp
shambhala:~> ls -l /tmp/fstab
-rw-r--r-- 1 root root 1100  9. Jul 11:40 /tmp/fstab
shambhala:~> lzop -9 /tmp/fstab
shambhala:~> ls -l /tmp/fstab.lzo 
-rw-r--r-- 1 root root 722  9. Jul 11:40 /tmp/fstab.lzo

Here is the original output of the apt-get dist-upgrade I ran -
since creating an LZOP based initramfs worked before, I think
it has something to do with the update to initramfs-tools 0.97.2:

shambhala:~#130> apt-get dist-upgrade
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut   
Status-Informationen einlesen... Fertig
Berechne Upgrade (Paketaktualisierung) ...Fertig
Die folgenden NEUEN Pakete werden installiert:
  libcanberra-gtk-module libcanberra-gtk0 libcanberra0 libpodofo0.8.0 libtdb1
Die folgenden Pakete sind zurückgehalten worden:
  libakonadi-kde4
Die folgenden Pakete werden aktualisiert:
  chromium-browser chromium-browser-inspector chromium-browser-l10n 
initramfs-tools krename libqalculate5
  notification-daemon qalc xterm
9 aktualisiert, 5 neu installiert, 0 zu entfernen und 1 nicht aktualisiert.
Es müssen 16,3MB an Archiven heruntergeladen werden.
Nach dieser Operation werden 2.007kB Plattenplatz zusätzlich benutzt.
Möchten Sie fortfahren [J/n]? 
Hole:1 http://ftp.de.debian.org sid/main chromium-browser-l10n 
5.0.375.99~r51029-3 [1.977kB]
Hole:2 http://ftp.de.debian.org sid/main chromium-browser-inspector 
5.0.375.99~r51029-3 [889kB]
Hole:3 http://ftp.de.debian.org sid/main chromium-browser 5.0.375.99~r51029-3 
[10,5MB]
Hole:4 http://ftp.de.debian.org squeeze/main initramfs-tools 0.97.2 [86,2kB]

Hole:5 http://ftp.de.debian.org squeeze/main libpodofo0.8.0 0.8.0+svn20100512-1 
[547kB] 
Hole:6 http://ftp.de.debian.org squeeze/main krename 4.0.4-2 [419kB]

Hole:7 http://ftp.de.debian.org squeeze/main libtdb1 1.2.1-2+b1 [31,3kB]

Hole:8 http://ftp.de.debian.org squeeze/main libcanberra0 0.24-1 [38,9kB]   

Hole:9 http://ftp.de.debian.org squeeze/main libcanberra-gtk0 0.24-1 [17,4kB]   

Hole:10 http://ftp.de.debian.org squeeze/main libcanberra-gtk-module 0.24-1 
[16,0kB]
Hole:11 http://ftp.de.debian.org squeeze/main libqalculate5 0.9.7-2 [1.013kB]   

Hole:12 http://ftp.de.debian.org squeeze/main notification-daemon 0.5.0-2 
[82,1kB]  
Hole:13 http://ftp.de.debian.org squeeze/main qalc 0.9.7-2 [111kB]  

Hole:14 http://ftp.de.debian.org squeeze/main xterm 261-1 [528kB]   

Es wurden 16,3MB in 11s geholt (1.473kB/s)  

Lesen der Paket-Felder... Erledigt
Lesen des Paket-Status... Erledigt
Laden der Bug-Reports... Erledigt 
»Found/Fixed«-Informationen werden ausgewertet ... Erledigt
Lese Changelogs... Fertig
(Lese Datenbank ... 350197 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereiten zum Ersetzen von chromium-browser-l10n 5.0.375.99~r51029-2 (durch 
.../chromium-browser-l10n_5.0.375.99~r51029-3_all.deb) ...
Entpacke Ersatz für chromium-browser-l10n ...
Vorbereiten zum Ersetzen von chromium-browser-inspector 5.0.375.99~r51029-2 
(durch .../chromium-browser-inspector_5.0.375.99~r51029-3_all.deb) ...
Entpacke Ersatz für chromium-browser-inspector ...
Vorbereiten zum Ersetzen von chromium-browser 5.0.375.99~r51029-2 (durch 
.../chromium-browser_5.0.375.99~r51029-3_i386.deb) ...
Entpacke Ersatz für chromium-browser ...
Vorbereiten zum Ersetzen von initramfs-tools 0.97 (durch 
.../initramfs-tools_0.97.2_all.deb) ...
Entpacke Ersatz für initramfs-tools ...
Wähle vormals abgewähltes Paket libpodofo0.8.0.
Entpacke libpodofo0.8.0 (aus .../libpodofo0.8.0_0.8.0+svn20100512-1_i386.deb) 
...
Vorbereiten zum Ersetzen von krename 4.0.3-1 (durch 
.../krename_4.0.4-2_i386.deb) ...
Entpacke Ersatz für krename ...
Wähle vormals abgewähltes Paket libtdb1.
Entpacke libtdb1 (aus .../libtdb1_1.2.1-2+b1_i386.deb) ...
Wähle vormals abgewähltes Paket libcanberra0.
Entpacke libcanberra0 (aus .../libcanberra0

Bug#379660: patch is integrated in 2.6.17.7

2006-07-26 Thread Martin Steigerwald


Hello,

finally there it is.

So you can close this report as soon as you merged 2.6.17.7 ;-)

Regards,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#379660: please consider fixing repeated slight corruption with XFS by applying a small patch

2006-07-24 Thread Martin Steigerwald

Package: linux-image-2.6.17-1-686
Version: 2.6.17-4
Severity: important

Please consider fixing repeated slight corruption with XFS by applaying
a small patch:

http://bugzilla.kernel.org/show_bug.cgi?id=6757#c8

It fixes the slight corruption I had on my IBM ThinkPad T23 and works
stable here.

I hope it will get into the next stable kernel release for 2.6.17. It
has already been included in 2.6.18 development branch.

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17.1-tp23-sws2-2.2.6-xfs-fix
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)

Versions of packages linux-image-2.6.17-1-686 depends on:
ii  initramfs-tools [linux-initra 0.69b  tools for generating an initramfs
ii  module-init-tools 3.2.2-3tools for managing Linux kernel mo

Versions of packages linux-image-2.6.17-1-686 recommends:
pn  libc6-i686 (no description available)

-- debconf information:
  linux-image-2.6.17-1-686/preinst/bootloader-initrd-2.6.17-1-686: true
  linux-image-2.6.17-1-686/postinst/old-dir-initrd-link-2.6.17-1-686: true
  linux-image-2.6.17-1-686/postinst/bootloader-test-error-2.6.17-1-686:
  linux-image-2.6.17-1-686/postinst/old-initrd-link-2.6.17-1-686: true
  linux-image-2.6.17-1-686/preinst/lilo-has-ramdisk:
  linux-image-2.6.17-1-686/postinst/depmod-error-2.6.17-1-686: false
  linux-image-2.6.17-1-686/prerm/removing-running-kernel-2.6.17-1-686: true
  linux-image-2.6.17-1-686/preinst/overwriting-modules-2.6.17-1-686: true
  linux-image-2.6.17-1-686/preinst/lilo-initrd-2.6.17-1-686: true
  linux-image-2.6.17-1-686/preinst/failed-to-move-modules-2.6.17-1-686:
  linux-image-2.6.17-1-686/postinst/create-kimage-link-2.6.17-1-686: true
  linux-image-2.6.17-1-686/postinst/kimage-is-a-directory:
  linux-image-2.6.17-1-686/postinst/old-system-map-link-2.6.17-1-686: true
  linux-image-2.6.17-1-686/preinst/elilo-initrd-2.6.17-1-686: true
  linux-image-2.6.17-1-686/preinst/already-running-this-2.6.17-1-686:
  linux-image-2.6.17-1-686/preinst/abort-overwrite-2.6.17-1-686:
  linux-image-2.6.17-1-686/postinst/bootloader-error-2.6.17-1-686:
  linux-image-2.6.17-1-686/preinst/initrd-2.6.17-1-686:
  linux-image-2.6.17-1-686/postinst/depmod-error-initrd-2.6.17-1-686: false
  linux-image-2.6.17-1-686/preinst/abort-install-2.6.17-1-686:
  linux-image-2.6.17-1-686/prerm/would-invalidate-boot-loader-2.6.17-1-686: true


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#341498: does not find valid filesystem label from fstab LABEL= option

2005-12-01 Thread Martin Steigerwald

Am Mittwoch 30 November 2005 23:59 schrieb Jonas Smedegaard:
> On Wed, 30 Nov 2005 23:40:04 +0100
>
> Martin Steigerwald <[EMAIL PROTECTED]> wrote:
> > The offending line in /etc/fstab is:
> >
> > LABEL=debian   /   xfs
> > defaults0 1
> >
> > This bug may or may not be related to: bug #337168 and bug #337415.
>
> Sounds like #337065 - could you please check...

Hello Jonas,

well I cannot use a UUID either with yaird and replacing "LABEL=debian" by 
"/dev/disk/by-label/debian" seems to work, so the bug I reported  appears 
to be similar to #337065.

I have no reiserfs oder ext3 root partition to test whether it would work 
with other filesystems.

Regards,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de

-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#337065: yaird does not work with labels on XFS either

2005-12-01 Thread Martin Steigerwald


Hello,

see bug #341498.

Regards,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#341498: does not find valid filesystem label from fstab LABEL= option

2005-11-30 Thread Martin Steigerwald

Package: yaird
Version: 0.0.11-12
Severity: normal

Sending manually via KMail as I missed switching report bug SMTP server 
from master.debian.org to bugs.debian.org as indicated in the changelog 
of latest reportbug package.


Hello,

yaird doesn't seem to work with a label for the root filesystem:

Richte linux-image-2.6.14-2-686 ein (2.6.14-4) ...
Using /usr/sbin/mkinitrd.yaird to build the
ramdisk.
Full list of probed ramdisk generating tools :
/usr/sbin/mkinitrd /usr/sbin/mkinitrd.yaird
/usr/sbin/mkinitramfs.
yaird error: label 'debian' not found
(/etc/fstab:6) (fatal)
Failed to create initrd image.
dpkg: Fehler beim Bearbeiten von
linux-image-2.6.14-2-686 (--configure):
 Unterprozess post-installation script gab den
Fehlerwert 2 zurück
Fehler traten auf beim Bearbeiten von:
 linux-image-2.6.14-2-686
E: Sub-process /usr/bin/dpkg returned an error
code (1)

The offending line in /etc/fstab is:

LABEL=debian   /   xfs defaults0   
1

This line works perfectly fine since ages and also worked with previous 
mkinitrd
tool.

The label seems to be fine:

[EMAIL PROTECTED]:/ -> xfs_admin -l /dev/hda5
label = "debian"

As soon as I replace the offending line in /etc/fstab by

/dev/hda5   /   xfs defaults0   
1

yaird seems to work correctly.

This bug may or may not be related to: bug #337168 and bug #337415. I 
reported
it cause for me it seems to be a different problem as yaird seems to get 
the
label name correctly (no "/" that is reduced to ""), but it still doesn't 
find
the label.

Regards,
Martin


-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14.2-tp23
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)

Versions of packages yaird depends on:
ii  cpio 2.6-9   GNU cpio -- a program to 
manage ar
ii  dash 0.5.2-8 The Debian Almquist Shell
ii  libc62.3.5-8 GNU C Library: Shared 
libraries an
ii  libhtml-template-perl2.6-2   HTML::Template : A module for 
usin
ii  libparse-recdescent-perl 1.94.free-1 Generates recursive-descent 
parser
ii  perl 5.8.7-7 Larry Wall's Practical 
Extraction 

yaird recommends no packages.

-- no debconf information

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de

Re: whole lot of ACPI problems with self compiled kernel

2005-02-10 Thread Martin Steigerwald

Am Dienstag, 8. Februar 2005 23:25 schrieb martin f krafft:
> also sprach Martin Steigerwald <[EMAIL PROTECTED]> [2005.01.22.0901 
+0100]:
> > 2) suspend-to-disk doesn't work at all. I get
> >
> > "swsusp: FATAL: cannot find swap device, try swapon -a"
>
> FYI:
>
>   http://marc.theaimsgroup.com/?l=linux-kernel&m=110789536921510&w=2

Hallo Martin,

Danke für die Info.

Hmmm, ich bilde mir ein, das auch mit einem Vanilla-Kernel probiert zu 
haben? Geht es bei Dir mit einem Vanilla-Kernel? Bist Du mittlerweile mit 
dem Thema weitergekommen?

Das ist echt noch eine große Baustelle bei Linux.

Grüße,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de

Bug#291354: Bug reproducable on IBM ThinkPad T23 and IBM ThinkPad R51

2005-01-21 Thread Martin Steigerwald


Hello,

I can reproduce this bug with an IBM ThinkPad T23 and an IBM ThinkPad R51.

I am using kernel-image-2.6.10-1-686, version 2.6.10-4.

Kernel 2.6.9 didn't work at all on my IBM ThinkPad T23 (similar bug as I 
reported for 2.6.8 in bug #282905). Didn't test on the IBM ThinkPad R51 
yet.

Regards,
-- 
Martin 'Helios' Steigerwald


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#282905: Works okay with kernel-image-2.6.8-1-686, version 2.6.8-10

2005-01-18 Thread Martin Steigerwald


Hello,

this works okay with

kernel-image-2.6.8-1-686, version 2.6.8-10

again.

It still doesn't work with:

kernel-image-2.6.9-1-686, version 2.6.9-3

but that should become a new bug report if I find time, before 2.6.10 is 
out for Debian.

Regards,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#272523: Not really fixed

2004-10-15 Thread Martin Steigerwald


Hello,

well in further tests I had two more cases where it didn't boot like 
described before. During my last tests where 4-5 boots with version 
2.6.8-4 worked flawlessly I had no AVM PCMCIA ISDN Fritzcard in my 
laptop. In the two cases where it didn't work again I had the AVM PCMCIA 
ISDN Fritzcard back in. But in a third case - directly afterwards - it 
still did work with the card plugged into the PCMCIA slot. 

So this does not seem to be fixed completely. 

Its difficult to find a pattern in all of this.

This how the AVM card is detected:

Oct 15 21:59:11 localhost kernel: HiSax: Card 1 Protocol EDSS1 Id=HiSax 
(0)
Oct 15 21:59:11 localhost kernel: HiSax: AVM A1 PCMCIA driver Rev. 2.9.2.5
Oct 15 21:59:11 localhost kernel: AVM A1 PCMCIA: io 0x140 irq 3 model 1 
version 2
Oct 15 21:59:11 localhost kernel: AVM A1 PCMCIA: ISAC version (0): 
2086/2186 V1.1
Oct 15 21:59:11 localhost kernel: AVM A1 PCMCIA: HSCX version A: V2.1  B: 
V2.1
Oct 15 21:59:11 localhost kernel: AVM A1 (PCMCIA): IRQ 3 count 2
Oct 15 21:59:11 localhost kernel: AVM A1 (PCMCIA): IRQ 3 count 6
Oct 15 21:59:11 localhost kernel: HiSax: DSS1 Rev. 2.32.2.3
Oct 15 21:59:11 localhost kernel: HiSax: 2 channels added
Oct 15 21:59:11 localhost kernel: HiSax: MAX_WAITING_CALLS added
Oct 15 21:59:11 localhost kernel: HiSax: if_command 6 called with invalid 
driverId 0!
Oct 15 21:59:11 localhost kernel: HiSax: if_command 6 called with invalid 
driverId 0!

Regards,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de

Bug#272523: Seems to be fixed with 2.6.8-1 (Version: 2.6.8-4)

2004-10-15 Thread Martin Steigerwald


Hello,

now I tried it with kernel-image-2.6.8-1-686 (version 2.6.8-4) and this 
one seems to work okay! I tried booting it 4-5 times and in all cases it 
was successful.

So it seems that this bug was fixed with version 2.6.8-4.

Regards, 
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de

Bug#272523: Booting without vga=791 parameters yields further information

2004-09-29 Thread Martin Steigerwald


Hello,

now I tried booting the kernel from the package kernel-image-2.6.8-1-686 
(version 2.6.8-3) without the "vga=791" parameter like this:

title   Debian GNU/Linux, kernel 2.6.8-1-686
root(hd0,4)
kernel  /boot/vmlinuz-2.6.8-1-686 root=/dev/hda5 ro
initrd  /boot/initrd.img-2.6.8-1-686
savedefault
boot

This way I at least some output from the kernel, before it stops. I wrote 
down everything I could see on the screen, since I do not know which part 
of the informations might be relevant for tracing this bug:

-
Local APIC disabled by BIOS - reenabling.
Found and enabled local APIC!
Initializing CPU#0
PID hash table entries: 2048 (order 11: 16384 bytes)
Detected 1132.524 MHz processor
Using pmtmr for high-res timesource
Console: colour VGA+ 80x25
Dentry cache has table entries: 65536 (order: 5, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 381056k/392640k available (1542k kernel code, 10840k reserved, 
684k data, 148k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... 
ok
Calibrating delay loop... 2244.60 BogoMIPS
Security Scaffold v1.0.0 initialized
Mount-cache hash table entries: 512 (oder: 0, 4096 bytes)
CPU: L1 I cache: 16k, L1 D dache: 16k
CPU: L2 cache: 512k
Intel machine check architecture supported
Intel machine check reporting supported
CPU: Intel Mobile Intel(R) Pentium(R) III CPU - M  1133MHz stepping 04
Enabling fast FPU save and restore... done
Enabling unmasked SIMD FPU exception support... done
Checking 'htl' instruction... OK
-

Here is stops. The machine does not react to Ctrl-Alt-Del. Nothing 
happens.

I press the power button for some time to switch off the machine. And then 
I booted with 2.6.7-1 again.

Hope that this helps a bit. 

Regards,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de

Bug#272523: Now it booted once, but still does not boot most of the time

2004-09-23 Thread Martin Steigerwald


Hello,

I now installed GRUB under Debian and now kernel-image.2.6.8-1-686 
(version 2.6.8-3) booted once, and then even K3b recognized the Teac DVD 
writer in the laptop - this didn't work with version 2.6.8-1 and 2. But  
I tried three more times and it didn't boot again.

Now I am using 2.6.7-1-686 again. This one sometimes also does not boot, 
but I have more look getting it to boot than 2.6.8-1, version 2.6.8-3. I 
never had any problems to boot with 2.6.8-1, version 2.6.8-2 and 2.6.8-1, 
but with these K3b isn't able to use the DVD burner.

This is the GRUB configuration I use now:

title  Debian GNU/Linux, kernel 2.6.8-1-686 
root  (hd0,4)
kernel  /boot/vmlinuz-2.6.8-1-686 root=/dev/hda5 ro vga=791 
initrd  /boot/initrd.img-2.6.8-1-686
savedefault
boot

title  Debian GNU/Linux, kernel 2.6.7-1-686 
root  (hd0,4)
kernel  /boot/vmlinuz-2.6.7-1-686 root=/dev/hda5 ro vga=791 
initrd  /boot/initrd.img-2.6.7-1-686
savedefault
boot

This is the versions of the grub package I use: 
0.95+cvs20040624-8 

Probably also important: Grub bootloader, kernel images and initrd files 
are located on a XFS partition. But before I used the GRUB installation 
from SuSE and this one is located on Reiserfs. Still the Debian kernel 
always was on that XFS partition. 

If you need any further tests, please let me know. I have 2.6.6, 2.6.7, 
2.6.8, including version 2.6.8-3 (now installed) and 2.6.8-2, available 
locally right now. 

Regards,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de

Bug#272523: kernel-image-2.6.8-1-686: Kernel doesn't boot on IBM ThinkPad T23 laptop

2004-09-20 Thread Martin Steigerwald

Package: kernel-image-2.6.8-1-686
Version: 2.6.8-3
Severity: important

KMail has problems directly sending a reportbug e-mail file including 
headers (see: http://bugs.kde.org/show_bug.cgi?id=89882). I did not find 
an easy way to add these two headers manually, mutt is not set up and my 
ISP's SMTP requires SMTP AUTH:

X-Reportbug-Version: 2.63
X-Debbugs-Cc: [EMAIL PROTECTED]


Hello,

The kernel from this package doesn't boot on my IBM ThinkPad T23 laptop 
with 1.13 GHz Mobile Pentium 3 and 384 MB RAM. After GRUB loads the 
kernel and the screen is blanked it will stay blank. I waited some 
minutes, but nothing happens. This also happened sometimes with 2.6.7, 
but most of the time it works. I never had this problem with 2.6.6. 
Earlier versions of the 2.6.8 kernel-image packages (2.6.8-1 and 2.6.8-2) 
worked correctly, but CD burning with "K3b" did only work as "root" on 
this configuration. I updated to the latest 2.6.8 kernel-image package to 
see if it fixes that problem and to see whether ACPI works better. But 
well my machine won't boot with it.

Since I ran Kernel 2.6.7 I installed a Teac DVD burner, model DV-W24EW. 
The installation of that device may be related to the problem, as I 
didn't experience any boot problems with 2.6.7 before. However I am able 
to burn CDs and DVDs just fine with this burner (with 2.6.7) provided 
that 2.6.7 does boot (which is most of the time).

This is what I use in GRUB to start the Debian Linux system:

###Don't change this comment - YaST2 identifier: Original name: linux###
title Debian Linux
kernel (hd0,4)/vmlinuz root=/dev/hda5 vga=791
initrd (hd0,4)/initrd.img

This is from a GRUB installed by SUSE Linux 9.1, I didn't get around 
setting up a Debian GRUB installation yet.

This is the PCI hardware in my system:

[EMAIL PROTECTED]:/home/martin -> lspci
:00:00.0 Host bridge: Intel Corp. 82830 830 Chipset Host Bridge (rev 
04)
:00:01.0 PCI bridge: Intel Corp. 82830 830 Chipset AGP Bridge (rev 04)
:00:1d.0 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #1) (rev 02)
:00:1d.1 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #2) (rev 02)
:00:1d.2 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #3) (rev 02)
:00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev 42)
:00:1f.0 ISA bridge: Intel Corp. 82801CAM ISA Bridge (LPC) (rev 02)
:00:1f.1 IDE interface: Intel Corp. 82801CAM IDE U100 (rev 02)
:00:1f.3 SMBus: Intel Corp. 82801CA/CAM SMBus Controller (rev 02)
:00:1f.5 Multimedia audio controller: Intel Corp. 82801CA/CAM AC'97 
Audio Controller (rev 02)
:01:00.0 VGA compatible controller: S3 Inc. SuperSavage IX/C SDR (rev 
05)
:02:00.0 CardBus bridge: Texas Instruments PCI1420
:02:00.1 CardBus bridge: Texas Instruments PCI1420
:02:02.0 Communication controller: Lucent Microelectronics WinModem 
56k (rev 01)
:02:08.0 Ethernet controller: Intel Corp. 82801CAM (ICH3) PRO/100 VE 
(LOM) Ethernet Controller (rev42)

If you need any further information and tests, please let me know.

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.7-1-686
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]

Versions of packages kernel-image-2.6.8-1-686 depends on:
ii  coreutils [fileutils] 5.2.1-2The GNU core utilities
ii  fileutils 5.2.1-2The GNU file management 
utilities 
ii  initrd-tools  0.1.73 tools to create initrd image 
for p
ii  module-init-tools 3.1-pre5-6 tools for managing Linux 
kernel mo

-- no debconf information

Regards,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de

51 matches

Mail list logo