[27466] in Athena Bugs
Re: OpenAFS sometimes fails to start on Lucid
daemon@ATHENA.MIT.EDU (Geoffrey Thomas)
Thu Jun 24 12:16:18 2010
Date: Thu, 24 Jun 2010 12:16:16 -0400 (EDT)
From: Geoffrey Thomas <geofft@mit.edu>
To: Evan Broder <broder@mit.edu>
In-Reply-To: <AANLkTin0gUDsYH4DnAkbyX8Gs36ycbAersW_TzTIIt8Z@mail.gmail.com>
Message-ID: <alpine.DEB.1.10.1006241215430.22801@dr-wily.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: bugs@mit.edu
Errors-To: bugs-bounces@mit.edu
networking.conf, network-interface.conf, and
network-interface-security.conf.
--
Geoffrey Thomas
geofft@mit.edu
On Thu, 24 Jun 2010, Evan Broder wrote:
> What do you have that matches /etc/init/net*?
>
> - Evan
>
> On Thu, Jun 24, 2010 at 12:04 PM, Geoffrey Thomas <geofft@mit.edu> wrote:
>> 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
>>>>>>
>>>>
>>
>
