Bug#249315: XFS warning should be displayed more prominently
Omari Stephens [EMAIL PROTECTED] writes: This would probably be an upstream question, but is there no way to check for a null pointer before dereferencing it? I'm not familiar with kernel or AFS coding, but it seems like calling a function on faith with an inconsistent API is asking for problems. Yeah, I find it odd that it fails in the way that it does. The best idea that I've been able to come up with so far is to have afsd do a statfs() of the cache path, if memory cache is not used, and then inspect the f_type value of the returned struct and make sure that it's EXT2_SUPER_MAGIC or EXT3_SUPER_MAGIC. (I'm not sure if any of the other file system types are allowable; that's the conservative approach.) If there were a command-line program that would return the same information, I could just call that in the init script, but I don't know of one. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#249315: XFS warning should be displayed more prominently
Package: openafs-client
Version: 1.3.81-5
Followup-For: Bug #249315
I happily installed openafs-{client,modules-source,krb5}, compiled the module,
and did `modprobe openafs`. When I ran `/etc/init.d/openafs-client start`,
my kernel OOPSed and the something complained that the cache was on an XFS
partition. There are two issues here.
First, I would appreciate if a warning of some sort
showed up in debconf -- I tend not to look under /usr/share/doc/ unless I feel
I need information in the first place.
Secondly, something, somewhere, recognized that the cache was on an XFS
partition, but only warned me after I was unable to do anything. From
re-reading the original report, it appears that this warning has been added
since then. Unfortunately, I don't have a console log from when I tried to
start openafs-client
-- System Information:
Debian Release: 3.1
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.10
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Versions of packages openafs-client depends on:
ii debconf [debconf-2.0] 1.4.48Debian configuration management sy
ii libc6 2.3.2.ds1-21 GNU C Library: Shared libraries an
ii libncurses55.4-4 Shared libraries for terminal hand
ii openafs-modules-2.6.10 1.3.81-5+2.6.10-0 The AFS distributed filesystem- Ke
ii openafs-modules-source 1.3.81-5 The AFS distributed filesystem- Mo
-- debconf information:
* openafs-client/run-client: true
* openafs-client/crypt: true
* openafs-client/cachesize: 5
* openafs-client/cell-info:
* openafs-client/fakestat: true
* openafs-client/afsdb: true
* openafs-client/dynroot: true
* openafs-client/thiscell: athena.mit.edu
* debconf/priority: medium
* debconf/frontend: Dialog
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#249315: XFS warning should be displayed more prominently
xsdg [EMAIL PROTECTED] writes: First, I would appreciate if a warning of some sort showed up in debconf -- I tend not to look under /usr/share/doc/ unless I feel I need information in the first place. There's no winning on this; a debconf warning would get other people annoyed at debconf abuse. There's a general dislike of using debconf to display informational messages. A better place might be to find a way to insert it into the compilation process for the module, since people who are familiar with module builds won't always read README.modules. I'm not sure if there's a good way to do this that doesn't break any other rules about user interactivity and wouldn't break tools like module-assistant. Secondly, something, somewhere, recognized that the cache was on an XFS partition, but only warned me after I was unable to do anything. From re-reading the original report, it appears that this warning has been added since then. The only thing that's changed so far as I know is the documentation in README.modules. I don't believe there's any way of detecting in advance whether the system calls are going to fail, since those details are rather buried in the kernel. I'm not sure what message you might have received about this, or what might have produced it. A grep doesn't seem to turn up anything in the OpenAFS source that would have produced such a warning. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#249315: XFS warning should be displayed more prominently
On Mon, 2005-05-16 at 16:51, Russ Allbery wrote: xsdg [EMAIL PROTECTED] writes: ::snip? SNIP!:: Secondly, something, somewhere, recognized that the cache was on an XFS partition, but only warned me after I was unable to do anything. From re-reading the original report, it appears that this warning has been added since then. The only thing that's changed so far as I know is the documentation in README.modules. I don't believe there's any way of detecting in advance whether the system calls are going to fail, since those details are rather buried in the kernel. This would probably be an upstream question, but is there no way to check for a null pointer before dereferencing it? I'm not familiar with kernel or AFS coding, but it seems like calling a function on faith with an inconsistent API is asking for problems. I'm not sure what message you might have received about this, or what might have produced it. A grep doesn't seem to turn up anything in the OpenAFS source that would have produced such a warning. I'll try to duplicate it over this coming weekend or early-ish next week. --xsdg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#249315: XFS warning should be displayed more prominently
xsdg == xsdg [EMAIL PROTECTED] writes: xsdg First, I would appreciate if a warning of some sort showed xsdg up in debconf -- I tend not to look under /usr/share/doc/ xsdg unless I feel I need information in the first place. I believe this would be against debconf policy or would at least be somewhat sketchy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
