[gentoo-dev] baselayout-1.11.12-r2 request for testers

[gentoo-dev] baselayout-1.11.12-r2 request for testers

[Mike Frysinger]

yes, it's finally that time ... after months of hearing us say 'we want to get 
new baselayout stable asap', we're serious

so can people please try out baselayout-1.11.12-r2+ and see if they notice any 
regressions ?  the 'best' tests are simply rebooting and seeing if your 
system comes up :)

common gotchas:
- many config options have moved from /etc/rc.conf into /etc/conf.d/ files
- /etc/hostname and /etc/*domainname have been moved into /etc/conf.d/ files
- the net scripts have been completely rewritten thanks to UberLord ... old 
config styles should work fine, but it's best if you update 
your /etc/conf.d/net syntax ... just review /etc/conf.d/net.example or this 
URL: http://dev.gentoo.org/~uberlord/net-book/

somethings to note ...
regressions with lvm/lvm2/evms will not be considered ... they have had all 
their code forked into the respective packages and thus are no longer part of 
baselayout ... bugs with those packages should be taken up with their 
respective maintainers
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] baselayout-1.11.12-r2 request for testers

[Daniel Goller]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mike Frysinger wrote:
| yes, it's finally that time ... after months of hearing us say 'we
want to get
| new baselayout stable asap', we're serious
|
| so can people please try out baselayout-1.11.12-r2+ and see if they
notice any
| regressions ?  the 'best' tests are simply rebooting and seeing if your
| system comes up :)
|
| common gotchas:
| - many config options have moved from /etc/rc.conf into /etc/conf.d/ files
| - /etc/hostname and /etc/*domainname have been moved into /etc/conf.d/
files
| - the net scripts have been completely rewritten thanks to UberLord
... old
| config styles should work fine, but it's best if you update
| your /etc/conf.d/net syntax ... just review /etc/conf.d/net.example or
this
| URL: http://dev.gentoo.org/~uberlord/net-book/
|
| somethings to note ...
| regressions with lvm/lvm2/evms will not be considered ... they have
had all
| their code forked into the respective packages and thus are no longer
part of
| baselayout ... bugs with those packages should be taken up with their
| respective maintainers
| -mike
booted for me on ~x86 no raid/lvm/lvm2/evms to help you there

hope this helps
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFClQ7TUpKYMelfdYERAk15AJ0fiaIuY8cGjezr0br0p3NRC6fAIgCghtBt
8nGxZXiQT1/nMrFq0uy/QRY=
=eznV
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] baselayout-1.11.12-r2 request for testers

[Paul Varner]

On Wed, 2005-05-25 at 18:20 -0400, Mike Frysinger wrote:
> yes, it's finally that time ... after months of hearing us say 'we want to get 
> new baselayout stable asap', we're serious
> 
> so can people please try out baselayout-1.11.12-r2+ and see if they notice any 
> regressions ?  the 'best' tests are simply rebooting and seeing if your 
> system comes up :)
> 

Works fine here on a fairly basic ~x86 desktop.

Regards,
Paul
-- 
My Gentoo stuff: http://varnerfamily.org/pvarner/gentoo
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] baselayout-1.11.12-r2 request for testers

[Rumen Yotov]

[-- Attachment #1: Type: text/plain, Size: 732 bytes --]

Paul Varner wrote:

>On Wed, 2005-05-25 at 18:20 -0400, Mike Frysinger wrote:
>  
>
>>yes, it's finally that time ... after months of hearing us say 'we want to get 
>>new baselayout stable asap', we're serious
>>
>>so can people please try out baselayout-1.11.12-r2+ and see if they notice any 
>>regressions ?  the 'best' tests are simply rebooting and seeing if your 
>>system comes up :)
>>
>>    
>>
>
>Works fine here on a fairly basic ~x86 desktop.
>
>Regards,
>Paul
>  
>
Hi,
Using mostly stable system with some (baselayout incl.) testing packages.
Migration went OK, except for a warning about missing /etc/init.d/serial.
See commented entries for serial in my /etc/inittab file, will check.
Otherwise it all works.
Rumen

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3397 bytes --]

[gentoo-dev] Re: baselayout-1.11.12-r2 request for testers

[Duncan]

Mike Frysinger posted <200505251820.02637.vapier@gentoo.org>, excerpted
below,  on Wed, 25 May 2005 18:20:02 -0400:

> can people please try out baselayout-1.11.12-r2+ and see if they notice any 
> regressions ?  the 'best' tests are simply rebooting and seeing if your 
> system comes up :)

I've been running baselayout-1.11.12+ since it went ~amd64.  It has been
very smooth going, far more so than previous versions, where net,
specifically macchanger, wasn't working right without module script
tweaking (that was bugged and eventually fixed).

Hmm..  I /did/ have issues with parallel startup a couple revisions back. 
I had disabled that and haven't reenabled it yet.  I suppose I should do
that and bug it now, if it still fails.  It /was/ working at one point.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: baselayout-1.11.12-r2 request for testers

[Roy Marples]

[-- Attachment #1: Type: text/plain, Size: 784 bytes --]

On Thu, 2005-05-26 at 02:08 -0700, Duncan wrote:
> Hmm..  I /did/ have issues with parallel startup a couple revisions back. 
> I had disabled that and haven't reenabled it yet.  I suppose I should do
> that and bug it now, if it still fails.  It /was/ working at one point.

There may still be issues with parallel startup. It doesn't really
startup in parallel and it's not much faster, so if any bugs do come up
then we'll probably recommend turning it off.

baselayout-1.12.0-alpha3 will have much improved parallel startup thanks
to Paul Pacheco patch (bug #69854) which is essentially a re-write of
the code so we're not that interested in fixing parallel startup in
baselayout-1.11.x at this time.

-- 
Roy Marples <uberlord@gentoo.org>
Gentoo Linux Developer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: Re: baselayout-1.11.12-r2 request for testers

[Duncan]

Roy Marples posted <1117110163.21483.11.camel@uberlaptop.ubernet>,
excerpted below,  on Thu, 26 May 2005 13:22:43 +0100:

> On Thu, 2005-05-26 at 02:08 -0700, Duncan wrote:
>> Hmm..  I /did/ have issues with parallel startup a couple revisions
>> back. I had disabled that and haven't reenabled it yet.  I suppose I
>> should do that and bug it now, if it still fails.  It /was/ working at
>> one point.
> 
> There may still be issues with parallel startup. It doesn't really startup
> in parallel and it's not much faster, so if any bugs do come up then we'll
> probably recommend turning it off.
> 
> baselayout-1.12.0-alpha3 will have much improved parallel startup thanks
> to Paul Pacheco patch (bug #69854) which is essentially a re-write of the
> code so we're not that interested in fixing parallel startup in
> baselayout-1.11.x at this time.

OK, cool!  Gives me an excuse to not worry about it for a bit longer.  <g>
(I had found pretty much exactly what you mentioned, that it wasn't much
faster anyway, the reason I hadn't squawked when it failed and I had to
turn it off.)

That's good, since I read I have new KDE to worry about next week, and
I've a couple things to trace b4 then (unsermake doesn't seem to be
engaging, here, for some reason, and it'd be real nice if I could figure
out how to get the old configcache patch working (locally, anyway) again
with the split sandbox, since the portage upgrade with that integrated
doesn't seem to be on the immediate horizon.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] baselayout-1.11.12-r2 request for testers

[Aaron Walker]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mike Frysinger wrote:
> yes, it's finally that time ... after months of hearing us say 'we want to get 
> new baselayout stable asap', we're serious
> 
> so can people please try out baselayout-1.11.12-r2+ and see if they notice any 
> regressions ?  the 'best' tests are simply rebooting and seeing if your 
> system comes up :)

Does it support wireless devices that don't support essid scanning yet?

I'm currently having to use baselayout-1.10.4 (which was removed from portage
ages ago) as my BCM4306 802.11b/g chip (used via ndiswrapper) doesn't support
essid scanning.
- --
No small art is it to sleep: it is necessary for that purpose to keep
awake all day.
		-- Nietzsche

Aaron Walker <ka0ttic@gentoo.org>
[ BSD | cron | forensics | shell-tools | commonbox | netmon | vim | web-apps ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFClZ0YC3poscuANHARAsZpAJ4s94Qufzd11OK6K0r+pj/QRwh7GACfaHrq
PYC9Wm914fB1y/ZeALFAnIM=
=UJcg
-----END PGP SIGNATURE-----

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] baselayout-1.11.12-r2 request for testers

[Roy Marples]

[-- Attachment #1: Type: text/plain, Size: 905 bytes --]

On Thu, 2005-05-26 at 05:55 -0400, Aaron Walker wrote:
> Does it support wireless devices that don't support essid scanning yet?
> 
> I'm currently having to use baselayout-1.10.4 (which was removed from portage
> ages ago) as my BCM4306 802.11b/g chip (used via ndiswrapper) doesn't support
> essid scanning.

It should do. Basically if your card does not support scanning then you
have a few choices

1) Hard code the ESSID - this only works when you only use one AP
2) Hard code a list of ESSID's - this works fine as long as you only use
the AP's in the list. However, it's slow as it attempts to connect to
each in the specified order.
3) Use the ESSID "ANY" - this forces the driver to associate with an AP
that it chooses - you have no control over which one it selects.

If not, pester me in IRC so I can fix it.

-- 
Roy Marples <uberlord@gentoo.org>
Gentoo Linux Developer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] baselayout-1.11.12-r2 request for testers

[Roy Marples]

[-- Attachment #1: Type: text/plain, Size: 905 bytes --]

On Thu, 2005-05-26 at 05:55 -0400, Aaron Walker wrote:
> Does it support wireless devices that don't support essid scanning yet?
> 
> I'm currently having to use baselayout-1.10.4 (which was removed from portage
> ages ago) as my BCM4306 802.11b/g chip (used via ndiswrapper) doesn't support
> essid scanning.

It should do. Basically if your card does not support scanning then you
have a few choices

1) Hard code the ESSID - this only works when you only use one AP
2) Hard code a list of ESSID's - this works fine as long as you only use
the AP's in the list. However, it's slow as it attempts to connect to
each in the specified order.
3) Use the ESSID "ANY" - this forces the driver to associate with an AP
that it chooses - you have no control over which one it selects.

If not, pester me in IRC so I can fix it.

-- 
Roy Marples <uberlord@gentoo.org>
Gentoo Linux Developer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] baselayout-1.11.12-r2 request for testers

[Jonas Geiregat]

Mike Frysinger wrote:

>yes, it's finally that time ... after months of hearing us say 'we want to get 
>new baselayout stable asap', we're serious
>
>so can people please try out baselayout-1.11.12-r2+ and see if they notice any 
>regressions ?  the 'best' tests are simply rebooting and seeing if your 
>system comes up :)
>
>common gotchas:
>- many config options have moved from /etc/rc.conf into /etc/conf.d/ files
>- /etc/hostname and /etc/*domainname have been moved into /etc/conf.d/ files
>- the net scripts have been completely rewritten thanks to UberLord ... old 
>config styles should work fine, but it's best if you update 
>your /etc/conf.d/net syntax ... just review /etc/conf.d/net.example or this 
>URL: http://dev.gentoo.org/~uberlord/net-book/
>
>somethings to note ...
>regressions with lvm/lvm2/evms will not be considered ... they have had all 
>their code forked into the respective packages and thus are no longer part of 
>baselayout ... bugs with those packages should be taken up with their 
>respective maintainers
>-mike
>  
>
I get a message * /sbin/rc cannot start until runlevel boot has completed
this is an a ppc platform...
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] baselayout-1.11.12-r2 request for testers

[Mike Frysinger]

On Thursday 26 May 2005 07:45 am, Jonas Geiregat wrote:
> I get a message * /sbin/rc cannot start until runlevel boot has completed
> this is an a ppc platform...

search bugzilla, this has come up ... i think it's because of some init script 
you have in the boot runlevel when it should be in the default runlevel ...
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] baselayout-1.11.12-r2 request for testers

[Jonas Geiregat]

Mike Frysinger wrote:

>On Thursday 26 May 2005 07:45 am, Jonas Geiregat wrote:
>  
>
>>I get a message * /sbin/rc cannot start until runlevel boot has completed
>>this is an a ppc platform...
>>    
>>
>
>search bugzilla, this has come up ... i think it's because of some init script 
>you have in the boot runlevel when it should be in the default runlevel ...
>-mike
>  
>
I've searched bugzilla nothing found about this ...
hail to bugzilla
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] baselayout-1.11.12-r2 request for testers

[Mike Frysinger]

On Wednesday 25 May 2005 10:49 pm, Jonas Geiregat wrote:
> Mike Frysinger wrote:
> >On Thursday 26 May 2005 07:45 am, Jonas Geiregat wrote:
> >>I get a message * /sbin/rc cannot start until runlevel boot has completed
> >>this is an a ppc platform...
> >
> >search bugzilla, this has come up ... i think it's because of some init
> > script you have in the boot runlevel when it should be in the default
> > runlevel ... -mike
>
> I've searched bugzilla nothing found about this ...
> hail to bugzilla

search harder :P

if that fails, look at Bug 91534

if that fails, remove net.eth* from boot runlevel
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] baselayout-1.11.12-r2 request for testers

[Rene Zbinden]

works perfectly here. good work. I like the new network setup.

when do you thing it changes from ~x86 to x86.

On Thursday 26 May 2005 00:20, Mike Frysinger wrote:
> yes, it's finally that time ... after months of hearing us say 'we want to
> get new baselayout stable asap', we're serious
>
> so can people please try out baselayout-1.11.12-r2+ and see if they notice
> any regressions ?  the 'best' tests are simply rebooting and seeing if your
> system comes up :)
>
> common gotchas:
> - many config options have moved from /etc/rc.conf into /etc/conf.d/ files
> - /etc/hostname and /etc/*domainname have been moved into /etc/conf.d/
> files - the net scripts have been completely rewritten thanks to UberLord
> ... old config styles should work fine, but it's best if you update
> your /etc/conf.d/net syntax ... just review /etc/conf.d/net.example or this
> URL: http://dev.gentoo.org/~uberlord/net-book/
>
> somethings to note ...
> regressions with lvm/lvm2/evms will not be considered ... they have had all
> their code forked into the respective packages and thus are no longer part
> of baselayout ... bugs with those packages should be taken up with their
> respective maintainers
> -mike

-- 
cheers,
reen
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: baselayout-1.11.12-r2 request for testers

[Thomas Kirchner]

[-- Attachment #1: Type: text/plain, Size: 409 bytes --]

* On May 25 18:20, Mike Frysinger (gentoo-dev@lists.gentoo.org) wrote:
> so can people please try out baselayout-1.11.12-r2+ and see if they 
> notice any regressions ?  the 'best' tests are simply rebooting and 
> seeing if your system comes up :)

Working great here on ~x86, aside from the initial oops with 1.11.12-r0 
causing X to bomb from the /dev issue.  The other changes have been nice.
Tom

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] baselayout-1.11.12-r2 request for testers

[Kevin F. Quinn]

On 26/5/2005 0:20:02, Mike Frysinger (vapier@gentoo.org) wrote:
> files - the net scripts have been completely rewritten thanks to UberLord

Ahh; what fun - that was the stuff I'd tweaked the most :/
The new network stuff is much better, but I do have one hiccough.

I'm trying it on a laptop that connects to various different networks depending on the weather.  I figured this would be a useful test as it's a less common configuration.  It connects mostly via different docking stations.  I use udev to rename ethernet devices according to MAC address (the ethernet devices are in the docking stations).  Hotplug then runs the appropriately named network script via net.agent to start the service.  Critically, the various net.* scripts are therefore -not- in any runlevel.

This hotplugging of the network devices all kicks off early on - well before the boot level has finished.  The new /sbin/runscript.sh simply drops the addition of the network device if the boot level hasn't finished - leaving me with no network (or at least, a network that has to be started manually).  For now, I've commented out the check in /sbin/runscript.sh, and it all works ok.  I don't know what this will break; obviously the check wasn't added just for laughs!


On a somewhat related matter, I have bluetooth stuff installed, which is also started by hotplug/pcmcia.  In order to prevent it being stopped by changing runlevels, I've made a softlink to net.bluetooth and started that in my hotplug config instead of 'bluetooth'.  Bit of a hack, relying on the fact /sbin/rc does not automatically stop anything that begins with "net.".  Is there a tidier way to prevent /sbin/rc from messing with services started & stopped via hotplug?



-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] baselayout-1.11.12-r2 request for testers

[Roy Marples]

[-- Attachment #1: Type: text/plain, Size: 2109 bytes --]

On Thu, 2005-05-26 at 15:04 +0200, Kevin F. Quinn wrote:
> I'm trying it on a laptop that connects to various different networks
>  depending on the weather.  I figured this would be a useful test as
>  it's a less common configuration.  It connects mostly via different
>  docking stations.  I use udev to rename ethernet devices according to
>  MAC address (the ethernet devices are in the docking stations). 
>  Hotplug then runs the appropriately named network script via net.agent
>  to start the service.  Critically, the various net.* scripts are
>  therefore -not- in any runlevel.
> 
> This hotplugging of the network devices all kicks off early on - well
>  before the boot level has finished.  The new /sbin/runscript.sh simply
>  drops the addition of the network device if the boot level hasn't
>  finished - leaving me with no network (or at least, a network that has
>  to be started manually).  For now, I've commented out the check in
>  /sbin/runscript.sh, and it all works ok.  I don't know what this will
>  break; obviously the check wasn't added just for laughs!
> 


emerge ifplugd and get that to monitor your interfaces. It will bring
them up/down when a cable is inserted/removed.
You'll probably have to tell it to not fail if the interfaces don't
exist as you're using udev to rename them.

A better solution would be to allow configuration via MAC address, which
we may put into baselayout-1.12.0

> 
> On a somewhat related matter, I have bluetooth stuff installed, which
>  is also started by hotplug/pcmcia.  In order to prevent it being
>  stopped by changing runlevels, I've made a softlink to net.bluetooth
>  and started that in my hotplug config instead of 'bluetooth'.  Bit of
>  a hack, relying on the fact /sbin/rc does not automatically stop
>  anything that begins with "net.".  Is there a tidier way to prevent
>  /sbin/rc from messing with services started & stopped via hotplug?
> 
> 
> 

Try experimenting with the RC_STRICT_NET_CHECKING in /etc/conf.d/rc

-- 
Roy Marples <uberlord@gentoo.org>
Gentoo Linux Developer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] baselayout-1.11.12-r2 request for testers

[Kevin F. Quinn]

On 26/5/2005 15:33:10, Roy Marples (uberlord@gentoo.org) wrote:
> On Thu, 2005-05-26 at 15:04 +0200, Kevin F. Quinn wrote:
> > I'm trying it on a laptop that connects to various different networks
> >  depending on the weather.  I figured this would be a useful test as
> >  it's a less common configuration.  It connects mostly via different
> >  docking stations.  I use udev to rename ethernet devices according to
> >  MAC address (the ethernet devices are in the docking stations). 
> >  Hotplug then runs the appropriately named network script via net.agent
> >  to start the service.  Critically, the various net.* scripts are
> >  therefore -not- in any runlevel.
> > 
> > This hotplugging of the network devices all kicks off early on - well
> >  before the boot level has finished.  The new /sbin/runscript.sh simply
> >  drops the addition of the network device if the boot level hasn't
> >  finished - leaving me with no network (or at least, a network that has
> >  to be started manually).  For now, I've commented out the check in
> >  /sbin/runscript.sh, and it all works ok.  I don't know what this will
> >  break; obviously the check wasn't added just for laughs!
> > 
> 
> 
> emerge ifplugd and get that to monitor your interfaces. It will bring
> them up/down when a cable is inserted/removed.
> You'll probably have to tell it to not fail if the interfaces don't
> exist as you're using udev to rename them.
> 
> A better solution would be to allow configuration via MAC address, which
> we may put into baselayout-1.12.0

Thanks for the suggestions.  I didn't want to go the ifplugd route as the interfaces don't appear/disappear while the system is running.  I've thought a bit about this, and it occurs to me that what I really want is for the hotplug-initiated scripts that runscript.sh doesn't want to do at boot, deferred to default (rather than just dropped).

I've implemented this in a simple fashion:

========
--- runscript.sh.orig   2005-05-26 20:02:37.000000000 +0200
+++ runscript.sh    2005-05-26 20:06:28.000000000 +0200
@@ -45,8 +45,9 @@
 # has completed
 if [[ ${NETSERVICE} == "yes" && ${IFACE} != "lo" ]] ; then
    if [[ -z ${mylevel} || ${mylevel} == ${BOOTLEVEL} ]] ; then
-       eerror "$0: cannot start until the runlevel "${BOOTLEVEL}" has completed"
-       exit 1
+       echo $* >> ${svcdir}/deferred
+       ewarn "$0: deferring, service not suitable for runlevel "${BOOTLEVEL}"."
+       exit 0
    fi
 fi
========


with the following in /etc/init.d/deferred:


========
#!/sbin/runscript
# Copyright 1999-2005 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

dodeferred() {
    local myline myservice
    if [[ -f ${svcdir}/deferred ]]; then
        while read myline; do
            myservice=${myline%% *}
            ${myservice} $1
        done < ${svcdir}/deferred
    fi
}

start() {
    dodeferred start
}

stop() {
    dodeferred stop
    /bin/rm -f ${svcdir}/deferred
}

restart() {
    dodeferred restart
}
========

'rc-update add deferred default' ensures the deferred startups happen when the default runlevel is entered, and are not done if the kernel parameters indicate startup shouldn't continue past the boot runlevel.  Continuing manually to the default level catches the deferred startups automatically.

The 'deferred' script above doesn't deal with runscript options (--quiet etc), and it may be better to do the 'rm ${svcdir}/deferred' somehwere else, but it illustrates the idea.

> > On a somewhat related matter, I have bluetooth stuff installed, which
> >  is also started by hotplug/pcmcia.  In order to prevent it being
> >  stopped by changing runlevels, I've made a softlink to net.bluetooth
> >  and started that in my hotplug config instead of 'bluetooth'.  Bit of
> >  a hack, relying on the fact /sbin/rc does not automatically stop
> >  anything that begins with "net.".  Is there a tidier way to prevent
> >  /sbin/rc from messing with services started & stopped via hotplug?
> 
> Try experimenting with the RC_STRICT_NET_CHECKING in /etc/conf.d/rc

My problem here (such that it is) is that the only way for a service to survive a runtime level transition, if it is started by hotplug, is to call it 'net.<something>'.  Deferring it (as above) solves the transition problem. Of course, it might be worth having a "not-at-boot" indication feature for init scripts, rather than having them named net.<something> :)

Kev.



-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] baselayout-1.11.12-r2 request for testers

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 757 bytes --]

On Wed, 2005-05-25 at 18:20 -0400, Mike Frysinger wrote:
> - the net scripts have been completely rewritten thanks to UberLord ... old 
> config styles should work fine, but it's best if you update 
> your /etc/conf.d/net syntax ... just review /etc/conf.d/net.example or this 
> URL: http://dev.gentoo.org/~uberlord/net-book/

Since DHCP is assumed by default if there is no configuration, how does
one disable DHCP easily *without* specifying an IP address?

I'm asking because I will need to modify the livecd-tools scripts to
take into account a way to disable DHCP when either "nodhcp" or
"nodetect" are passed to the release media.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] baselayout-1.11.12-r2 request for testers

[Mike Frysinger]

On Thursday 26 May 2005 10:04 am, Chris Gianelloni wrote:
> I'm asking because I will need to modify the livecd-tools scripts to
> take into account a way to disable DHCP when either "nodhcp" or
> "nodetect" are passed to the release media.

speaking of livecd updates, someone pointed out on a bug that we shouldnt need 
to check CDBOOT anymore in the volume addon code (lvm/lvm2/evms/raid/etc) ... 
the livecd should set RC_VOLUME_ORDER to "" ... maybe we can do this in the 
ebuild ?
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] baselayout-1.11.12-r2 request for testers

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 859 bytes --]

On Thu, 2005-05-26 at 10:50 -0400, Mike Frysinger wrote:
> On Thursday 26 May 2005 10:04 am, Chris Gianelloni wrote:
> > I'm asking because I will need to modify the livecd-tools scripts to
> > take into account a way to disable DHCP when either "nodhcp" or
> > "nodetect" are passed to the release media.
> 
> speaking of livecd updates, someone pointed out on a bug that we shouldnt need 
> to check CDBOOT anymore in the volume addon code (lvm/lvm2/evms/raid/etc) ... 
> the livecd should set RC_VOLUME_ORDER to "" ... maybe we can do this in the 
> ebuild ?

What ebuild?  baselayout?

Where would the livecd set RC_VOLUME_ORDER?  Why should it?

Sorry if I'm not up on this stuff, but this is the first I've heard of
any of this.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] baselayout-1.11.12-r2 request for testers

[Mike Frysinger]

On Thursday 26 May 2005 11:12 am, Chris Gianelloni wrote:
> On Thu, 2005-05-26 at 10:50 -0400, Mike Frysinger wrote:
> > On Thursday 26 May 2005 10:04 am, Chris Gianelloni wrote:
> > > I'm asking because I will need to modify the livecd-tools scripts to
> > > take into account a way to disable DHCP when either "nodhcp" or
> > > "nodetect" are passed to the release media.
> >
> > speaking of livecd updates, someone pointed out on a bug that we shouldnt
> > need to check CDBOOT anymore in the volume addon code
> > (lvm/lvm2/evms/raid/etc) ... the livecd should set RC_VOLUME_ORDER to ""
> > ... maybe we can do this in the ebuild ?
>
> What ebuild?  baselayout?

yes, when USE=livecd

> Where would the livecd set RC_VOLUME_ORDER?

it would reset $S/etc/conf.d/rc

> Why should it? 

instead of having to do [[ -z ${CDBOOT} ]] all the time ... the lvm/emvs/raid 
have been removed from baselayout and placed into sep addon modules ... but 
only modules listed in RC_VOLUME_ORDER will be automagically sourced by 
baselayout at boot

so instead of checking $CDBOOT in all the modules, we could just have the 
livecd say 'dont check volume addon modules'
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] baselayout-1.11.12-r2 request for testers

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 1518 bytes --]

On Thu, 2005-05-26 at 12:08 -0400, Mike Frysinger wrote:
> On Thursday 26 May 2005 11:12 am, Chris Gianelloni wrote:
> > On Thu, 2005-05-26 at 10:50 -0400, Mike Frysinger wrote:
> > > On Thursday 26 May 2005 10:04 am, Chris Gianelloni wrote:
> > > > I'm asking because I will need to modify the livecd-tools scripts to
> > > > take into account a way to disable DHCP when either "nodhcp" or
> > > > "nodetect" are passed to the release media.
> > >
> > > speaking of livecd updates, someone pointed out on a bug that we shouldnt
> > > need to check CDBOOT anymore in the volume addon code
> > > (lvm/lvm2/evms/raid/etc) ... the livecd should set RC_VOLUME_ORDER to ""
> > > ... maybe we can do this in the ebuild ?
> >
> > What ebuild?  baselayout?
> 
> yes, when USE=livecd
> 
> > Where would the livecd set RC_VOLUME_ORDER?
> 
> it would reset $S/etc/conf.d/rc
> 
> > Why should it? 
> 
> instead of having to do [[ -z ${CDBOOT} ]] all the time ... the lvm/emvs/raid 
> have been removed from baselayout and placed into sep addon modules ... but 
> only modules listed in RC_VOLUME_ORDER will be automagically sourced by 
> baselayout at boot
> 
> so instead of checking $CDBOOT in all the modules, we could just have the 
> livecd say 'dont check volume addon modules'

Where would the livecd say this?

Also, what if we *want* the livecd to check the volume addon modules?

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] baselayout-1.11.12-r2 request for testers

[Mike Frysinger]

On Friday 27 May 2005 09:40 am, Chris Gianelloni wrote:
> Where would the livecd say this?

all the code i referenced was from inside baselayout ... and the livecd 
wouldnt do it, when you emerge baselayout with USE=livecd, the config file 
would be setup

> Also, what if we *want* the livecd to check the volume addon modules?

Not My Problem ?  the volume code has *always* been disabled in baselayout for 
livecds, nothing is changing ... plus, the startup code is for people who 
have configured crap already ... you dont exactly have config files on a 
livecd for your volumes :p
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] baselayout-1.11.12-r2 request for testers

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 1214 bytes --]

On Fri, 2005-05-27 at 11:13 -0400, Mike Frysinger wrote:
> On Friday 27 May 2005 09:40 am, Chris Gianelloni wrote:
> > Where would the livecd say this?
> 
> all the code i referenced was from inside baselayout ... and the livecd 
> wouldnt do it, when you emerge baselayout with USE=livecd, the config file 
> would be setup

OK... except we don't remerge baselayout anymore... it could be done, of
course...

> > Also, what if we *want* the livecd to check the volume addon modules?
> 
> Not My Problem ?  the volume code has *always* been disabled in baselayout for 
> livecds, nothing is changing ... plus, the startup code is for people who 
> have configured crap already ... you dont exactly have config files on a 
> livecd for your volumes :p

Makes sense to me... I guess this doesn't have anything to do with the
volume scanning done on the livecd... I really don't understand what any
of the lvm/evms junk does anyway... and I'm sure you understand it much
better than I do, so I'll take your word for it... and if something
breaks, I know where to send the bugs... *grin*

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] baselayout-1.11.12-r2 request for testers

[Daniel Goller]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mike Frysinger wrote:
| On Thursday 26 May 2005 10:04 am, Chris Gianelloni wrote:
|
|>I'm asking because I will need to modify the livecd-tools scripts to
|>take into account a way to disable DHCP when either "nodhcp" or
|>"nodetect" are passed to the release media.
|
|
| speaking of livecd updates, someone pointed out on a bug that we
shouldnt need
| to check CDBOOT anymore in the volume addon code
(lvm/lvm2/evms/raid/etc) ...
| the livecd should set RC_VOLUME_ORDER to "" ... maybe we can do this
in the
| ebuild ?
| -mike
you mean so i will not have to use 'gentoo nolvm2' on the next livecd on
my system?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFClpC1UpKYMelfdYERAvk4AJ97G2q1ljGW9ylewKnZUIFENE/IpACdGB4M
2e1c2PBp24V6oqul6UWBZRQ=
=+Jl1
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] baselayout-1.11.12-r2 request for testers

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 1060 bytes --]

On Thu, 2005-05-26 at 22:15 -0500, Daniel Goller wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Mike Frysinger wrote:
> | On Thursday 26 May 2005 10:04 am, Chris Gianelloni wrote:
> |
> |>I'm asking because I will need to modify the livecd-tools scripts to
> |>take into account a way to disable DHCP when either "nodhcp" or
> |>"nodetect" are passed to the release media.
> |
> |
> | speaking of livecd updates, someone pointed out on a bug that we
> shouldnt need
> | to check CDBOOT anymore in the volume addon code
> (lvm/lvm2/evms/raid/etc) ...
> | the livecd should set RC_VOLUME_ORDER to "" ... maybe we can do this
> in the
> | ebuild ?
> | -mike
> you mean so i will not have to use 'gentoo nolvm2' on the next livecd on
> my system?

That had nothing to do with the init scripts, so these changes would no
affect that in any way.  All of the no* commands affect things that are
specific to the livecd.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] baselayout-1.11.12-r2 request for testers

[Daniel Goller]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chris Gianelloni wrote:
| On Thu, 2005-05-26 at 22:15 -0500, Daniel Goller wrote:
|
|>-----BEGIN PGP SIGNED MESSAGE-----
|>Hash: SHA1
|>
|>Mike Frysinger wrote:
|>| On Thursday 26 May 2005 10:04 am, Chris Gianelloni wrote:
|>|
|>|>I'm asking because I will need to modify the livecd-tools scripts to
|>|>take into account a way to disable DHCP when either "nodhcp" or
|>|>"nodetect" are passed to the release media.
|>|
|>|
|>| speaking of livecd updates, someone pointed out on a bug that we
|>shouldnt need
|>| to check CDBOOT anymore in the volume addon code
|>(lvm/lvm2/evms/raid/etc) ...
|>| the livecd should set RC_VOLUME_ORDER to "" ... maybe we can do this
|>in the
|>| ebuild ?
|>| -mike
|>you mean so i will not have to use 'gentoo nolvm2' on the next livecd on
|>my system?
|
|
| That had nothing to do with the init scripts, so these changes would no
| affect that in any way.  All of the no* commands affect things that are
| specific to the livecd.
|
then i'll have to make sure to test as many of the next livecd release
candidates to see if it still requires me to specify that or not

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCmJZSUpKYMelfdYERAidpAJ4iy8x1IFFijFBSWnVAz0g7r90lmQCfch5C
8Xbt4qqCbmMBs2UOKefq3+o=
=6mRj
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] baselayout-1.11.12-r2 request for testers

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 1074 bytes --]

On Sat, 2005-05-28 at 11:03 -0500, Daniel Goller wrote:
> |>you mean so i will not have to use 'gentoo nolvm2' on the next livecd on
> |>my system?
> |
> |
> | That had nothing to do with the init scripts, so these changes would no
> | affect that in any way.  All of the no* commands affect things that are
> | specific to the livecd.
> |
> then i'll have to make sure to test as many of the next livecd release
> candidates to see if it still requires me to specify that or not

It won't.  We're turning off all of the volume management in the initrd
by default.  This means all of them (dmraid, evms, lvm2) will be
available, but not enabled.  You will be required to do* if you want
them on, since they caused problems for some people, much as how doscsi
is not enabled by default.

I'm also working on making a nice little document of all the do* no*
commands available on the releases, so troubleshooting should be a bit
easier for us all.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] baselayout-1.11.12-r2 request for testers

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 603 bytes --]

On Wed, 2005-05-25 at 18:20 -0400, Mike Frysinger wrote:
> - the net scripts have been completely rewritten thanks to UberLord ... old 
> config styles should work fine, but it's best if you update 
> your /etc/conf.d/net syntax ... just review /etc/conf.d/net.example or this 
> URL: http://dev.gentoo.org/~uberlord/net-book/

OK... nevermind... I just figured out that I need to:

echo 'config_eth0=( "null" )' >> /etc/conf.d/net

to disable DHCP.

Uberlord:  excellent docs... =]

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: baselayout-1.11.12-r2 request for testers

[Marek Więcek]

Mike Frysinger wrote:

> so can people please try out baselayout-1.11.12-r2+ and see if they notice any 
> regressions ?  the 'best' tests are simply rebooting and seeing if your 
> system comes up :)

I have just migrated to baselayout-1.11.12-r4 and everything went
smoothly. Arch x86 with some ~x86 application.

-- 
Marek Więcek

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] baselayout-1.11.12-r2 request for testers

[Mike Frysinger]

On Wednesday 25 May 2005 06:20 pm, Mike Frysinger wrote:
> yes, it's finally that time ... after months of hearing us say 'we want to
> get new baselayout stable asap', we're serious

last chance !

can someone forward the original e-mail here to gentoo-user ?
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] baselayout-1.11.12-r2 request for testers

[Joel Martin]

[-- Attachment #1: Type: text/plain, Size: 508 bytes --]

Works for me. One x86 laptop with wireless and one x86 desktop also
with wireless.

--
Joel Martin (kanaka)

Mike Frysinger wrote:	[Wed Jun 01 2005, 09:59:11PM EDT]
> On Wednesday 25 May 2005 06:20 pm, Mike Frysinger wrote:
> > yes, it's finally that time ... after months of hearing us say 'we want to
> > get new baselayout stable asap', we're serious
> 
> last chance !
> 
> can someone forward the original e-mail here to gentoo-user ?
> -mike
> -- 
> gentoo-dev@gentoo.org mailing list

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] baselayout-1.11.12-r2 request for testers

[Paul Varner]

On Wed, 2005-06-01 at 21:59 -0400, Mike Frysinger wrote:
> On Wednesday 25 May 2005 06:20 pm, Mike Frysinger wrote:
> > yes, it's finally that time ... after months of hearing us say 'we want to
> > get new baselayout stable asap', we're serious
> 
> last chance !
> 
> can someone forward the original e-mail here to gentoo-user ?

The comments back from gentoo-user have been that it works fine.  One
was a glowing endorsement of all the changes.

Regards,
Paul
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] baselayout-1.11.12-r2 request for testers

[Mike Frysinger]

On Wednesday 01 June 2005 09:59 pm, Mike Frysinger wrote:
> On Wednesday 25 May 2005 06:20 pm, Mike Frysinger wrote:
> > yes, it's finally that time ... after months of hearing us say 'we want
> > to get new baselayout stable asap', we're serious
>
> last chance !

and it's done
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] baselayout-1.11.12-r2 request for testers

[Lance Albertson]

[-- Attachment #1: Type: text/plain, Size: 676 bytes --]

On Wed, 2005-06-08 at 22:47 -0400, Mike Frysinger wrote:
> On Wednesday 01 June 2005 09:59 pm, Mike Frysinger wrote:
> > On Wednesday 25 May 2005 06:20 pm, Mike Frysinger wrote:
> > > yes, it's finally that time ... after months of hearing us say 'we want
> > > to get new baselayout stable asap', we're serious
> >
> > last chance !
> 
> and it's done

NOooo1!!!!1111!!!

;-)

Thanks for working on that upgrade!
-- 
Lance Albertson <ramereth@gentoo.org>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: baselayout-1.11.12-r2 request for testers

[Kevin Bryan]

Mike Frysinger <vapier <at> gentoo.org> writes:
> 
> yes, it's finally that time ... after months of hearing us say 'we want to get 
> new baselayout stable asap', we're serious
> 
> so can people please try out baselayout-1.11.12-r2+ and see if they notice any 
> regressions ?  the 'best' tests are simply rebooting and seeing if your 
> system comes up :)
> 


I've been running the 1.11.x series since .8 with no problems (except the
parallel thing that was mentioned before).  Good work!  

I just wanted to share some of the coolness of the new scripts:

Let's say you have a wireless network that uses BlueSocket login.  It's rather
annoying to have to load a web browser before you can start using the
connection.  I wrote a little perl script to submit the form and call it from
postup().  (Email me if you want the script.)

A second bit of logic I added to postup() was to merge the settings from my
wireless card into the bonding interface.  This works as follows: 

    local ESSID=$( wireless_get_essid eth1 )
    if [ "${IFACE}" == "bond0" ] ; then
        echo "ESSID: $ESSID" 
        if [ -z "$(eval echo \${config_${ESSID}})" ] || 
           [ "$(eval echo \${config_${ESSID}})" == "dhcp" ] ; then
            dhcpcd -t 5 bond0
        else
            echo $(eval echo "\${config_${ESSID}}")
            ifconfig ${IFACE} $(eval echo "\${config_${ESSID}}")
            (route -n | grep -q "^0.0.0.0") && route del default
            route add $(eval echo "\${routes_${ESSID}}")
        fi
    fi

Note that I also have these lines for the bond0 interface:
slaves_bond0="eth0 eth1"
config_bond0=( "null" ) # I'll configure this later

The astute reader will notice that I got a little lazy and didn't use the
dhcpcd_xxx variables for that condition, but that wouldn't be too hard to hack
in there.

The end result of this is I can seemlessly go back and forth between the wired
and wireless worlds without losing network connections.  It's great to be on
wireless, start a download, plug into the wired, and then get an immediate speed
boost!

Here's another hint for wireless users:  Test your card's ability to respond to
iwconfig <card> txpower <val> commands.  Then put whatever the max value is into
the /etc/conf.d/wireless preassociate() function.  This should have a noticable
effect on your ability to connect to networks.

Thanks for making this all this possible!

--Kevin



-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] baselayout-1.11.12-r2 request for testers

[Lars Kneschke]

Mike Frysinger <vapier@gentoo.org> schrieb: 
>yes, it's finally that time ... after months of hearing us say 'we want to
>get 
>new baselayout stable asap', we're serious

I just tested with a LVM system and it worked like it should be.

I have one problem. When i boot my laptop with no network card connected,
the boot process hangs until the dhcp client(dhcpcd) times out. This was not
the case with the older version of baselayout. 

And this is not nice! :-)

Lars
--
need Groupware         ==> http://www.egroupware.org
hosted eGroupWare   ==> http://www.officespot.de
eGroupWare Training ==> http://www.outdoor-training.de/egroupware
Open Business Club  ==>  https://www.openbc.com/hp/Lars_Kneschke/



-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] baselayout-1.11.12-r2 request for testers

[Peter Cech]

On Thu, May 26, 2005 at 07:10:18AM +0000, Lars Kneschke wrote:
> Mike Frysinger <vapier@gentoo.org> schrieb: 
> >yes, it's finally that time ... after months of hearing us say 'we want to
> >get 
> >new baselayout stable asap', we're serious
> 
> I just tested with a LVM system and it worked like it should be.
> 
> I have one problem. When i boot my laptop with no network card connected,
> the boot process hangs until the dhcp client(dhcpcd) times out. This was not
> the case with the older version of baselayout. 

Try to uncomment preup() function for /etc/conf.d/net. Link detection
was not very reliable in my case, but it might be just because I'm using
software suspend.

Regards,

Peter Cech
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] baselayout-1.11.12-r2 request for testers

[Benjamin Smee]

[-- Attachment #1: Type: text/plain, Size: 567 bytes --]

lo,

On Thursday 26 May 2005 08:35, Peter Cech wrote:
[snip]
> Try to uncomment preup() function for /etc/conf.d/net. Link detection
> was not very reliable in my case, but it might be just because I'm using
> software suspend.

software suspend works perfectly with this. The problem is more likely to be 
that your card is not supported by either ethtool or mii-tool, though that in 
itself is unlikely as almost every NIC I am aware is supported by one or the 
other.

-- 
Benjamin Smee (strerror)
497F 5E98 1FA0 C313 EA0B 08C7 004A 66ED 448B E78C

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: [gentoo-dev] baselayout-1.11.12-r2 request for testers

[Lars Kneschke]

Peter Cech <cech@upc.uniba.sk> schrieb: 

>Try to uncomment preup() function for /etc/conf.d/net. Link detection
>was not very reliable in my case, but it might be just because I'm using
>software suspend.

That is working like a charm! It's booting now as fast as before. Thanks!

Lars
--
need Groupware         ==> http://www.egroupware.org
hosted eGroupWare   ==> http://www.officespot.de
eGroupWare Training ==> http://www.outdoor-training.de/egroupware
Open Business Club  ==>  https://www.openbc.com/hp/Lars_Kneschke/



-- 
gentoo-dev@gentoo.org mailing list