Andrew Benton wrote:
> On Thu, 15 Sep 2011 21:46:08 +0100 Matthew Burgess
> wrote:
>
>> So, based on the above, 5 is definitely something to look into I
>> think. If that doesn't pan out, then I think option 2 is the next
>> 'least worst'.
>
> Or you could set the time with a bootscript.
Only i
Bruce Dubbs wrote:
> Bryan Kadzban wrote:
>
>> Or sysconfig, or wherever similar scripts are put in Bruce's new setup.
>
> Just to mention the layout, what I have is:
>
> /lib/services (network service scripts)
> /lib/lsb(symlink to /lib/services/, init-functions)
>
> /etc/sysconfig
DJ Lucas wrote:
>
> Bryan Kadzban wrote:
>
>> Although, hmm. Either way here, there's a possible problem, with
>> symlinks for disk devices. If the USB ID file isn't present, then
>> it's possible that the /etc/fstab entry for /usr refers to a
>> symlink that relies on this file. Of course
On Fri, 16 Sep 2011 19:30:58 +0100
Matthew Burgess wrote:
>
> And, as mentioned before, you want to run the alsactl restore stuff on
> device discovery in order to support hot pluggable sound devices. If
> it's done as a one-shot bootscript, manual configuration would be needed
> if you plugg
On 16/09/2011 19:09, Bruce Dubbs wrote:
> Andrew Benton wrote:
>> On Thu, 15 Sep 2011 21:46:08 +0100
>> Matthew Burgess wrote:
>>
>>> So, based on the above, 5 is definitely something to look into I think.
>>>If that doesn't pan out, then I think option 2 is the next 'least worst'.
>>>
>>
>> O
Andrew Benton wrote:
> On Thu, 15 Sep 2011 21:46:08 +0100
> Matthew Burgess wrote:
>
>> So, based on the above, 5 is definitely something to look into I think.
>> If that doesn't pan out, then I think option 2 is the next 'least worst'.
>>
>
> Or you could set the time with a bootscript. Same
Bryan Kadzban wrote:
>Nathan Coulson wrote:
>> Another thought (one I have not actually tested, forgive me if It's
>> not possible) is trigger only block devices in the first pass, then
>> try devices/subsystems on the 2nd pass?
>
>DJ Lucas wrote:
>> Can we not simply re-trigger all known aff
On Thu, 15 Sep 2011 21:46:08 +0100
Matthew Burgess wrote:
> So, based on the above, 5 is definitely something to look into I think.
> If that doesn't pan out, then I think option 2 is the next 'least worst'.
>
Or you could set the time with a bootscript. Same with alsactl restore.
run them a
Bryan Kadzban wrote:
> Or sysconfig, or wherever similar scripts are put in Bruce's new setup.
Just to mention the layout, what I have is:
/lib/services (network service scripts)
/lib/lsb(symlink to /lib/services/, init-functions)
/etc/sysconfig (All config files here, no subdirector
Nathan Coulson wrote:
> Another thought (one I have not actually tested, forgive me if It's
> not possible) is trigger only block devices in the first pass, then
> try devices/subsystems on the 2nd pass?
DJ Lucas wrote:
> Can we not simply re-trigger all known affected subsystems with a
> subsys
On 09/15/2011 02:38 PM, Bruce Dubbs wrote:
> References are threads starting at:
> http://www.linuxfromscratch.org/pipermail/lfs-dev/2011-August/064960.html
> http://linuxfromscratch.org/pipermail/lfs-dev/2011-September/065130.html
>
> We are in a Catch-22 situation with udev_retry. Here's a rundo
On Thu, Sep 15, 2011 at 2:49 PM, Bruce Dubbs wrote:
> Matthew Burgess wrote:
>> On 15/09/2011 20:38, Bruce Dubbs wrote:
>>
>>
>>
>>> There are options about what to do right now:
>>>
>>> 1. Leave in the warning message and optionally write something about it
>>> in the book.
>>
>> We try, genera
Matthew Burgess wrote:
> On 15/09/2011 20:38, Bruce Dubbs wrote:
>
>
>
>> There are options about what to do right now:
>>
>> 1. Leave in the warning message and optionally write something about it
>> in the book.
>
> We try, generally, to accomodate changes in upstream programs. I'll
> defe
On 15/09/2011 20:38, Bruce Dubbs wrote:
> There are options about what to do right now:
>
> 1. Leave in the warning message and optionally write something about it
> in the book.
We try, generally, to accomodate changes in upstream programs. I'll
defer to upstream's views on the fact that bl
On 15/09/2011 20:38, Bruce Dubbs wrote:
> There are options about what to do right now:
>
> 1. Leave in the warning message and optionally write something about it
> in the book.
We try, generally, to accomodate changes in upstream programs. I'll
defer to upstream's views on the fact that bl
15 matches
Mail list logo
