[27464] in Athena Bugs

home help back first fref pref prev next nref lref last post

Re: OpenAFS sometimes fails to start on Lucid

daemon@ATHENA.MIT.EDU (Geoffrey Thomas)
Thu Jun 24 12:05:28 2010

Date: Thu, 24 Jun 2010 12:04:44 -0400 (EDT)
From: Geoffrey Thomas <geofft@mit.edu>
To: Evan Broder <broder@mit.edu>
In-Reply-To: <AANLkTilY430RqRkeMXgJAsiQOA89TX0nZSJU4O_XUW70@mail.gmail.com>
Message-ID: <alpine.DEB.1.10.1006241201030.28707@dr-wily.mit.edu>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED;
	BOUNDARY="-1257051904-1046872712-1277395484=:28707"
Cc: bugs@mit.edu
Errors-To: bugs-bounces@mit.edu

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---1257051904-1046872712-1277395484=:28707
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

Well, 'ifconfig' definitely lists lo as up, and certainly wlan0 is up by 
the time I log in -- my dotfiles attempt to kinit geofft from a keytab and 
aklog, and the first step succeeds. I used wireless-tools-udeb in d-i as 
described in <http://geofft.mit.edu/blog/post/109>, which caused 
/etc/network/interfaces to magically know about wireless. I've attached it 
in case you're curious.

If it's relevant, this is a system with nothing installed in the d-i 
tasksel screen, and a subset of debathena-standard.

-- 
Geoffrey Thomas
geofft@mit.edu

On Thu, 24 Jun 2010, Evan Broder wrote:

> It looks like the sysvinit scripts aren't ever running. As far as I
> can tell, they should get triggered by the rc-sysinit job (which runs
> telinit RUNLEVEL, which emits an runlevel RUNLEVEL event, which
> triggers the rc job).
>
> rc-sysinit triggers on filesystem and net-device-up IFACE=lo. In your
> boot log, I see a filesystem event get thrown, but I don't see any
> net-device-up events.
>
> So...what did you do to your networking config?
>
> - Evan
>
> On Thu, Jun 24, 2010 at 1:57 AM, Geoffrey Thomas <geofft@mit.edu> wrote:
>> Evan suggested I boot my kernel with --debug to enable Upstart debugging. As
>> far as I can see, the primary thing this does is make the boot process more
>> verbose, but not talk about SysV jobs. I just had another failed start of
>> SysV initscripts: /var/log/boot.log is attached, for what it's worth. I can
>> send a normal /var/log/boot.log if you'd like but it doesn't really look any
>> different.
>>
>> Is there anything else that starting Upstart with --debug should get me?
>> Certainly at _shutdown_ there's a lot of spew about jobs including openafs,
>> but it scrolls by too quickly to record or understand, and unfortunately
>> this isn't really a machine that I can hook up anything resembling a serial
>> cable to (unless ttyUSB0 is initialized early enough to pull this off?). But
>> if there's something else I can query at runtime about the status of jobs,
>> that may be more useful.
>>
>> --
>> Geoffrey Thomas
>> geofft@mit.edu
>>
>> On Sun, 20 Jun 2010, Geoffrey Thomas wrote:
>>
>>> To follow up on this, the /mit automounter also failed to start. My
>>> current runing theory is that occasionally Upstart's init decides that
>>> starting legacy /etc/rc*.d jobs is beneath its station and just doesn't.
>>>
>>> --
>>> Geoffrey Thomas
>>> geofft@mit.edu
>>>
>>> On Wed, 16 Jun 2010, Geoffrey Thomas wrote:
>>>
>>>> I have essentially Ubuntu Server (10.04/Lucid) running on my laptop, with
>>>> wireless configured in /etc/network/interfaces to automatically start, and
>>>> with the default Ubuntu splash and debathena-openafs-config installed. Once
>>>> every several boots, openafs-client just won't have started (aklog will fail
>>>> with an error indicating it's not running), and there's no evidence in
>>>> /var/log/boot.log that it ever tried, not even "Starting AFS services:".
>>>> /etc/init.d/openafs-client and /etc/rc2.d/S25openafs-client look fine, as do
>>>> /etc/openafs/afs.conf{,.client}. What's going on?
>>>>
>>>> If it's relevant, this might be more likely when I've been rebooting a
>>>> lot (to test grub config); perhaps I've also held down shift during the
>>>> boot, but that really really shouldn't be relevant for userspace
>>>> initialization.
>>>>
>>>> --
>>>> Geoffrey Thomas
>>>> geofft@mit.edu
>>>>
>>
>
---1257051904-1046872712-1277395484=:28707
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=etc-network-interfaces
Content-Transfer-Encoding: BASE64
Content-ID: <alpine.DEB.1.10.1006241204440.28707@dr-wily.mit.edu>
Content-Description: 
Content-Disposition: attachment; filename=etc-network-interfaces

IyBUaGlzIGZpbGUgZGVzY3JpYmVzIHRoZSBuZXR3b3JrIGludGVyZmFjZXMg
YXZhaWxhYmxlIG9uIHlvdXIgc3lzdGVtDQojIGFuZCBob3cgdG8gYWN0aXZh
dGUgdGhlbS4gRm9yIG1vcmUgaW5mb3JtYXRpb24sIHNlZSBpbnRlcmZhY2Vz
KDUpLg0KDQojIFRoZSBsb29wYmFjayBuZXR3b3JrIGludGVyZmFjZQ0KYXV0
byBsbw0KaWZhY2UgbG8gaW5ldCBsb29wYmFjaw0KDQojIFRoZSBwcmltYXJ5
IG5ldHdvcmsgaW50ZXJmYWNlDQphdXRvIHdsYW4wDQppZmFjZSB3bGFuMCBp
bmV0IGRoY3ANCgkjIHdpcmVsZXNzLSogb3B0aW9ucyBhcmUgaW1wbGVtZW50
ZWQgYnkgdGhlIHdpcmVsZXNzLXRvb2xzIHBhY2thZ2UNCgl3aXJlbGVzcy1t
b2RlIG1hbmFnZWQNCgl3aXJlbGVzcy1lc3NpZCBNSVQNCg==

---1257051904-1046872712-1277395484=:28707--

home help back first fref pref prev next nref lref last post