BUG in the initscripts -- was udev boot problem
jaqui at telus.net
Thu Dec 30 03:11:38 PST 2004
Nathan Coulson wrote:
> On Wed, 29 Dec 2004 06:00:50 -0800, J. Greenlees <jaqui at telus.net> wrote:
>>Steve Crosby wrote:
>>>Steve Crosby <fost at hotmail.com> wrote in
>>>news:Xns95CFD35C576Ffostlongstrider at 22.214.171.124:
>>>>scripts in runlevels 0 and 6 run with the "stop" parameter. I haven't
>>>>yet found the changelog describing why this change was made however.
>>>and there is no real detail in the changelogs -
>>>Revision 3589 - (view) (download) - [select for diffs]
>>>Modified Sat May 15 18:49:25 2004 UTC (7 months, 2 weeks ago) by winkie
>>>File length: 18979 byte(s)
>>>Diff to previous 3551
>>>Revision 3591 - (view) (download) - [select for diffs]
>>>Modified Sat May 15 19:38:29 2004 UTC (7 months, 2 weeks ago) by winkie
>>>File length: 2473 byte(s)
>>>Diff to previous 3295
>>>Only pass "stop" to scripts in runlevels 0 or 6
>>>looks like it was introduced in the 2.12 release, but I can't find any
>>>details in the archives discussing the reason for this particular change
>>>(not that the change is bad - just that it's not the "expected" behaviour
>>>of "standard" sysvinit)
>>maybe a important note in next book about it, to stop a continuing
>>repeat of this issue from changed initscript?
>>possibly update to site docs?
> Origionally, there were start/stop symlinks in rc0 and rc6, [LFS
> Bootscripts 1.xx], but I moved them over to only using stop symlinks.
> Later when Zack Winkles was added to the team, he changed it back [I
> think he was trying to make more room for symlinks for BLFS, but not
> entirely sure]
my point was that if a change in the package causes an error, or
unexpected behaviour, shouldn't it be mentioned in the book or on the
site to keep everyone fully informed, where possible, prior to
installing and posting for help?
since, other than the initscripts themselves, lfs doesn't maintain the
packages, it's only the initscripts where lfs has control over breakages
/ unexpected behaviour. if lfs makes a change to them that causes this a
note in the documentation can save stress. ;)
only plain text format email accepted.
smaller file size, no virus transfer
no proprietary file formats.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3162 bytes
Desc: S/MIME Cryptographic Signature
More information about the lfs-support