# Baselayout 2 / OpenRC

## jordan83

Ho appena letto nella Gentoo Weekly News questo paragrafo:

 *Quote:*   

> It has recently been announced on Planet Gentoo by Roy Marples that baselayout-2 has neared completion. The current versions of baselayout are written in bash, which, although powerful, is relatively slow. UberLord has been converting RC from bash to C, which has resulted in a tremendous speed increase (init completion in a mere 2 seconds). The conversion from bash to C also removes the requirement of bash, which is a boon for embedded devices.

 

Mitico!  :Smile: 

Era ora che si abbandonasse bash... Finalmente (forse) i tempi di avvio saranno comparabili con quelli di Windows (fresh install s'intende  :Mr. Green:  ... poi col tempo s'inchioda...).

Gentoo è già rapidissima ora così com'è, confrontandola con il 99% delle altre distribuzioni. Chissà col nuovo baselayout  :Wink: 

// edit by lavish: modificato il titolo del thread da "Baselayout 2" a "Baselayout 2 / OpenRC"

----------

## djinnZ

Non mi piace per niente. Vuol dire uno stacco definitivo dalla compatibilità con le altre distribuzioni. (questa è una cosa che va di sicuro in package.mask, se non altro è la prima volta che penso di usarlo seriamente)

la cosa che più mi spaventa è il rischio di vedere aumentare le dipendenze dell'init verso un sistema sempre più winzozz style ed a partizione unica.

Anche se rc è un chiodo lo preferisco così com'è.

----------

## crisandbea

 *djinnZ wrote:*   

> Non mi piace per niente. Vuol dire uno stacco definitivo dalla compatibilità con le altre distribuzioni. (questa è una cosa che va di sicuro in package.mask, se non altro è la prima volta che penso di usarlo seriamente)
> 
> la cosa che più mi spaventa è il rischio di vedere aumentare le dipendenze dell'init verso un sistema sempre più winzozz style ed a partizione unica.
> 
> Anche se rc è un chiodo lo preferisco così com'è.

 

non sparerei a zero cosi su una cosa che non avendola provata non si può giudicare, però potresti aver ragione, ma anche avere torto, anche perchè : *Quote:*   

> 
> 
> I honestly don't know. I did look at init-ng a long long time ago and it was fast. However it also didn't do as much (in terms of bring up all the things I use) and was also very error prone. It may have changed now.    The only real speed advantage now is that einit and init-ng don't use shell scripts unless they have to. baselayout-2 is still based on shell scripts because that is what unix admins kind of expect so it's easy to write an init script.    This is one of baselayout's bigest advantages over the others - because the entire init script is shell based you have the all the commands at your disposal for defining dependencies, like so for our clock init script.  
> 
>  depend() {  case "${CLOCK_ADJTIME}" in  "") before *;;  /etc/*) need checkroot;;  *) need localmount;;  esac  }    or say this from syslog-ng    depend() {  # Make networking dependency conditional on configuration  case $(sed 's/#.*//' /etc/syslog-ng/syslog-ng.conf) in  *source*tcp*|*source*udp*|*destination*tcp*|*destination*udp*)  need net ;;  esac  need clock hostname localmount  provide logger  }  
> ...

 

ciauz

----------

## riverdragon

Credo tu abbia un po' equivocato, o forse ho capito poco io.

Baselayout dovrebbe essere solo di gentoo, e la versione 1.X gestisce l'avvio dei servizi tramite bash; ora invece con la versione 2 la gestione è in c, mentre gli init scripts rimangono uguali a prima; altra cosa che ho letto, ora il sistema si basa su sh anziché su bash a tutto vantaggio dei tempi di esecuzione.

Qui il comunicato sul blog dello sviluppatore.

Se ho capito male fatemelo sapere  :Smile: 

EDIT: Comunque mi allieta questo commento nella pagina linkata *Quote:*   

> Works great on amd64! Swear it shaved 10 second off my boot time too!

   :Very Happy: 

----------

## crisandbea

 *riverdragon wrote:*   

> Credo tu abbia un po' equivocato, o forse ho capito poco io.
> 
> Baselayout dovrebbe essere solo di gentoo, e la versione 1.X gestisce l'avvio dei servizi tramite bash; ora invece con la versione 2 la gestione è in c, mentre gli init scripts rimangono uguali a prima; altra cosa che ho letto, ora il sistema si basa su sh anziché su bash a tutto vantaggio dei tempi di esecuzione.
> 
> Qui il comunicato sul blog dello sviluppatore.
> ...

 

direi hai che capito bene    :Laughing: 

----------

## djinnZ

più che altro vedo nero per il futuro, la cosa potrebbe evolvere molto male.

Quanto all'uso di bash per me è stato un errore sin dall'inizio, la maggiore lentezza rispetto ad sh è dovuta principalmente alle funzioni integrate di autocompletamento, hystory etc. che in uno script non servono a niente e riduce la portabilità (vedi le rogne del gruppo di BSD).

Già si incominciano a vedere in giro init-script balordi che richiamano applicativi in /usr (che rende impossibile adottare un partizionamento complesso, con tutte le complicazioni del caso anche nelle live non unionfs/aufs) e temo che una iniziativa del genere possa incoraggiare gli imbecilli (che non mancano mai) e sfuggire al controllo dei devel (nel senso che alcuni progetti potrebbero inziare a pensare di rilasciare applicativi privi di init script basati su un concetto di avvio servizi troppo vicino alla concezione windows, senza lasciare spazio alla possibilità di definire configurazioni alternative).

Basta già pensare a quanti automake/make scritti con i piedi o per niente configurabili ci sono in giro.

per questo non mi piace e mi preoccupa. Nel migliore dei mondi possibili sarebbe una buona idea.

----------

## Cazzantonio

Non so... sono sempre stato dell'idea che la "smanettabilità" vada garantita sempre e comunque...

Se il sistema di init è in bash (o sh che sia) è relativamente semplice accederci e modificarlo, se è in C quantomento bisogna conoscere il C (e ancora potrebbe essere una faticaccia).

La cosa FONDAMENTALE è che gli initscript rimangano in formato testuale (non file binari) altrimenti diverrebbero immodificabili. Ora come ora chiunque può scriversi un initscript (e io me ne sono scritti parecchi per adeguare l'avvio di alcuni programmi ai miei gusti). Spero la cosa sia garantita anche dopo con la stessa semplicità, altrimenti addio gentoo (mi pare arch abbia nello statuto che il sistema sia il più accessibile possibile...)

----------

## lavish

Come ha ben detto riverdragon, non cambiano gli init script, ma solo il core di baselayout, una cosa che non ha alcun motivo di esser letta  :Smile: 

Quindi non c'e' alcun motivo di preoccuparsi, anzi  :Wink: 

----------

## lavish

Spostato da Forum di discussione italiano a Forum italiano (Italian).

----------

## djinnZ

 *lavish wrote:*   

> Quindi non c'e' alcun motivo di preoccuparsi, anzi 

 

non vedo nero per l'idea di uberlord, che non è una novità, è un annetto buono che gli gira in testa se non erro.

Temo che qualche imbecille possa farsi venire l'idea balzana di sostituire gli initscript con dei binari compilati o includerne le funzion i direttamente nei demoni.

Sarà la mia innata tendenza al pessimismo... unita alla mia mentalità tradizionale che vede male anche anche usare script in perl o in phython in tutto quello  che è direttamente connesso all'init.

----------

## gutter

 *djinnZ wrote:*   

> 
> 
> Sarà la mia innata tendenza al pessimismo... unita alla mia mentalità tradizionale che vede male anche anche usare script in perl o in phython in tutto quello  che è direttamente connesso all'init.

 

Dai non fasciamoci la testa prima di rompercela  :Wink: .

Condivido l'idea di lavish. A mio avviso il tutto potrebbe portare solo dei miglioramenti. Gli init script resteranno sempre degli script anzi dipendendo il baslayout da sh e non da bash l'avvio risulterà più performante. Poi ricordiamo che questo in ogni caso è un beneficio (mi riferisco alla dipendenza da sh) dal momento che è garantita (o per lo meno dovrebbe sicuramente essere meglio di ora) la portabilità da e verso altri unix  :Wink: 

----------

## Cazzantonio

 *lavish wrote:*   

> Come ha ben detto riverdragon, non cambiano gli init script, ma solo il core di baselayout, una cosa che non ha alcun motivo di esser letta 
> 
> Quindi non c'e' alcun motivo di preoccuparsi, anzi 

 

Buono a sapersi... a dire il vero ho fatto il post e DOPO mi sono letto un po' di documentazione...    :Wink: 

Comunque non è tutto chiarissimo. Pare che alcune funzioni saranno portate in C e c'era un discorso secondo cui il vantaggio prestazionale sarà di circa 0,5 secondi per ogni inistscript portato in C...

Boh non sto nemmeno a ricercare dove l'avevo letto, tanto si starà a vedere.

----------

## lavish

WARNING: quanto segue e' relativo alla mia esperienza. Non sto invitando NESSUNO a provare software hardmasked, sia chiaro!

Ho installato ieri sera sys-apps/baselayout-2.0.0_alpha1: funziona perfettamente ed e' all'eye-meter decisamente piu' veloce ad eseguire gli script   :Shocked: 

Complimentoni a UberLord, veramente    :Very Happy: 

----------

## gutter

 *lavish wrote:*   

> 
> 
> Ho installato ieri sera sys-apps/baselayout-2.0.0_alpha1: funziona perfettamente ed e' all'eye-meter decisamente piu' veloce ad eseguire gli script  
> 
> Complimentoni a UberLord, veramente   

 

Interessante, se ho due minuti lo provo su una delle VM di gentoo che  ho.

----------

## riverdragon

Uffa, non dovevi dirmelo, ora sono disperatamente tentato di provarlo!  :Crying or Very sad: 

Almeno dicci che servizi avvii nei due runlevel boot e default.

----------

## lavish

```
0 # rc-update show

                acpid |      default                 

            alsasound |      default                 

             bootmisc | boot                         

              checkfs | boot                         

            checkroot | boot                         

                clock | boot                         

          consolefont | boot                         

                  gpm |      default                 

    hibernate-cleanup | boot                         

             hostname | boot                         

              keymaps | boot                         

                local |      default nonetwork       

           localmount | boot                         

              metalog |      default                 

              modules | boot                         

               net.lo | boot                         

             netmount |      default                 

            rmnologin | boot                         

              urandom | boot                         

           vixie-cron |      default                 

              volumes | boot  
```

----------

## comio

 *lavish wrote:*   

> 
> 
> ```
> 0 # rc-update show
> 
> ...

 

io mi butto nel beta testing... anzi alpha in questo caso! sperem!

ciao

luigi

----------

## riverdragon

Altrettanto, con le dita incrociate!

Un'altra bella cosa che ho letto è che il sysv-init rimane, e può quindi essere sostituito dai vari einit (che proverò), init-ng, eccetera.

----------

## GiRa

 *riverdragon wrote:*   

> Uffa, non dovevi dirmelo, ora sono disperatamente tentato di provarlo! 
> 
> Almeno dicci che servizi avvii nei due runlevel boot e default.

 

Ti conviene preparare una macchina virtuale e copiarci dentro la tua attuale installazione.

Basta un livecd, rsync e vivi tranquillo.

----------

## comio

Primo problema: modules non carica i moduli in /etc/modules.autoload.d

Soluzione: nel bug report 174360

Secondo problema: non riesco a switchare (che  brutto termine...) fra le console una volta che parte X

Soluzione: non so ma probabilmente legato a consolefont (suggerimenti?)

ciao

----------

## lavish

 *comio wrote:*   

> Primo problema: modules non carica i moduli in /etc/modules.autoload.d
> 
> Soluzione: nel bug report 174360

 

Non me ne ero accorto perche' il mio /etc/modules.autoload.d/kernel-2.6 e' vuoto  :Razz: 

 *comio wrote:*   

> Secondo problema: non riesco a switchare (che  brutto termine...) fra le console una volta che parte X
> 
> Soluzione: non so ma probabilmente legato a consolefont (suggerimenti?)

 

No idea.. io ci riesco tranquillamente   :Confused: 

----------

## comio

 *lavish wrote:*   

>  *comio wrote:*   Primo problema: modules non carica i moduli in /etc/modules.autoload.d
> 
> Soluzione: nel bug report 174360 
> 
> Non me ne ero accorto perche' il mio /etc/modules.autoload.d/kernel-2.6 e' vuoto 
> ...

 

Fra le altre cose, quando parte X(gl) si vede distorto ed illegibile (come se avesse caricato i driver xorg invece di quelli ati)... potrebbe essere un problema riconducibile.

Terzo problema: start-stop-daemon non riesce a cambiare utente

Soluzione: patch da bugzilla 174362

EDIT: Il problema pare rientrato facendo fare un ldconfig ed u n env-update... boh

ciao

luigi

----------

## riverdragon

 *GiRa wrote:*   

> Ti conviene preparare una macchina virtuale e copiarci dentro la tua attuale installazione.
> 
> Basta un livecd, rsync e vivi tranquillo.

 In effetti trovatomi davanti alla mia linux box perfettamente funzionante... credo che rinuncerò. Aspetto quantomeno una versione non hard masked.

----------

## comio

Altro problema: env-update fornito dal baselayout è broken (sbaglia ad analizzare i file in /etc/env.d con stesso prefisso).

Soluzione (workaround): usare in bootmisc env-update fornito da portage (trovare la stringa env-update e sostituire con /usr/sbin/env-update)

ciao

luigi

----------

## Scen

Uè comio, ma questi "workaround" lì trovi in giro per il forum o in Bugzilla? IMHO sarebbe più utile dare questi riferimenti (es. vedere bug #NNNNNN o discussione ufficiale url=abcdefg), piuttosto che inserire ogni volta un nuovo messaggio in questa discussione (che rischia di diventare chilometrica e difficile da seguire, a lungo andare). Se il pacchetto è ancora hard-masked e in stato di "alpha", ce n'è ancora di strada da fare.....  :Rolling Eyes: 

Tutto questo rigorosamente IMHO  :Cool: 

----------

## comio

 *Scen wrote:*   

> Uè comio, ma questi "workaround" lì trovi in giro per il forum o in Bugzilla? IMHO sarebbe più utile dare questi riferimenti (es. vedere bug #NNNNNN o discussione ufficiale url=abcdefg), piuttosto che inserire ogni volta un nuovo messaggio in questa discussione (che rischia di diventare chilometrica e difficile da seguire, a lungo andare).
> 
> 

 

Quando ho riferimenti ce li metto  :Wink:  Il workaround era una mia proposta. Ho aperto anche un bug (dopo il messaggio) e a quanto pare il problema ora è stato risolto nel cvs (c'è stata anche un'altra segnalazione).

 *Quote:*   

> 
> 
>  Se il pacchetto è ancora hard-masked e in stato di "alpha", ce n'è ancora di strada da fare..... 
> 
> Tutto questo rigorosamente IMHO 

 

Un motivo in più per segnalare problemi  :Wink:  Lo so che hard-masked, ma qualcuno deve fare un po' di bug-report... altrimenti i bug non vengono scovati e risolti  :Very Happy: 

Unisciti alla causa... smaschera tutti i pacchetti della tua distro  :Wink: 

ciao

luigi

----------

## !equilibrium

WARNING

per chi sta smanettando con il nuovo baselayout-2 e vuole provare l'ebrezza di una "velocità di curvatura maggiore", provate ad abilitare in /etc/conf.d/rc la variabile (si trova in fondo al file, decommentatela o cambiate il valore da NO a YES):

```
svcmount="yes"
```

buona velocità warp a tutti.

p.s.: svcmount è presente anche in baselayout-1   :Wink: 

----------

## riverdragon

```
# Should we mount $svcdir in a ram disk for some speed increase 

# for slower machines, or for the more extreme setups ?

svcmount="no"
```

Vantaggi e svantaggi? Gli init script si potranno modificare ancora o ad ogni riavvio si perderanno le modifiche? Una breve ricerca nel forum non ha aiutato.

----------

## mrfree

!equilibrium... pazzo!   :Shocked: 

Se quello che si legge in giro corrisponde a realtà, il nuovo baselayout permetterà alle nostre gentoo di viaggiare alla cosiddetta velocità di transcurvatura (curvatura 9.9999) attualmente raggiungibile solo da alcune razze aliene quali i Borg o i Kelvan.

Settando svcmount="yes" si potrebbe arrivare alla velocità teorica WARP 10 (velocità infinita)!!! Cito da wikipedia  *Quote:*   

> A Warp 10 un oggetto potrebbe occupare tutti i punti dell'universo contemporaneamente

 

Numero Uno... cosa ne pensa?   :Cool: 

Edit: se non ricordo male solo un uomo ha provato a viaggiare a warp 10, un ufficiale della Voyager... dopo uno strano viaggio nel tempo si trasformò in un improponibile essere anfibio (pare discendente dalla razza umana)... ora lasciamo perdere che nel telefilm l'hanno salvato... qui parliamo della vita reale!!   :Rolling Eyes: 

----------

## comio

 *!equilibrium wrote:*   

> WARNING
> 
> per chi sta smanettando con il nuovo baselayout-2 e vuole provare l'ebrezza di una "velocità di curvatura maggiore", provate ad abilitare in /etc/conf.d/rc la variabile (si trova in fondo al file, decommentatela o cambiate il valore da NO a YES):
> 
> ```
> ...

 

avrò cannato un etc-update... non mi trovo svcmount in /etc/conf.d/rc... :S

ciao

----------

## lavish

 *comio wrote:*   

> avrò cannato un etc-update... non mi trovo svcmount in /etc/conf.d/rc... :S

 

Mi aggrego.. nemmeno un 

```
grep -r -i svcmount /etc/
```

 mi torna qualche risultato   :Confused: 

----------

## mrfree

 *comio wrote:*   

> avrò cannato un etc-update... non mi trovo svcmount in /etc/conf.d/rc...

 

Ecco "l'ultima parte" del file che cerchi 

```
#

# Internal configuration variables

#

# NB:  These are for advanced users, and you should really

#      know what you are doing before changing them!

#

 

# rc-scripts dep-cache directory

#

# NOTE:  Do not remove the next line, as its needed by the baselayout ebuild!

#

#  svcdir="/var/lib/init.d"

svcdir="/var/lib/init.d"

# Should we mount $svcdir in a ram disk for some speed increase 

# for slower machines, or for the more extreme setups ?

svcmount="no"

# FS type that should be used for $svcdir.  Note that you need 

# $svcmount above set to "yes" for this to work ...  Currently 

# tmpfs, ramfs, and ramdisk are supported (tmpfs is the default).

svcfstype="tmpfs"

# Size of $svcdir in KB.  Note that ramfs doesn't support this 

# due to kernel limitations.

svcsize=2048
```

Ho lasciato i commenti volutamente, spero non sia un problema... tanto è poca roba  :Wink: 

----------

## lavish

sul sistema amd64 con baselayout--1.12.9-r2 c'e'

sul sistema x86 con baselayout-2.0.0_alpha1 non c'e' ....

 :Confused: 

----------

## crisandbea

 *lavish wrote:*   

> sul sistema amd64 con baselayout--1.12.9-r2 c'e'
> 
> sul sistema x86 con baselayout-2.0.0_alpha1 non c'e' ....
> 
> 

 

sul mio x86 con  baselayout--1.12.9-r2 c'e'..

ciauz

----------

## comio

 *lavish wrote:*   

> sul sistema amd64 con baselayout--1.12.9-r2 c'e'
> 
> sul sistema x86 con baselayout-2.0.0_alpha1 non c'e' ....
> 
> 

 

Mi sono greppato i sorgenti di baselayout-2.0.0 non ho trovato traccia di svcmount. Secondo me so variabili deprecate e poi dismesse. Secondo me il mount lo fa di default in ram (anche perché per qualche baco non smonta la dir...).

ciao

luigi

----------

## !equilibrium

 *comio wrote:*   

> Secondo me so variabili deprecate e poi dismesse. Secondo me il mount lo fa di default in ram (anche perché per qualche baco non smonta la dir...).

 

ehmmm io avevo testato il baselayout2 alle primissime release, non l'alpha1, per cui ho dato per scontato che fosse un'opzione ancora  valida.

è probabile che il tuo ragionamento sia corretto e che ora sull'alpha1 della release 2 il montaggio in ram sia di default (la qual cosa è facilmente verificabile, basta vedere se 'df' riporta un qualche shared mount point per la dir '/var/lib/init.d').

----------

## lavish

```
none on /lib/rcscripts/init.d type tmpfs (rw,nosuid,nodev,noexec)
```

```
none                  1.0M   44K  980K   5% /lib/rcscripts/init.d
```

 :Surprised: 

----------

## drizztbsd

Sotto linux base (insomma con /bin/sh linkato a /bin/bash) il boost di performance è molto minore che in un linux embedded (con /bin/sh di busybox) o in * bsd (/bin/sh è ash).

Già che state provando l'ebrezza di robe alfa, provate a linkare /bin/sh a /bin/busybox 

```
ln -sf /bin/busybox /bin/sh
```

Fatemi sapere quando viaggia  :Cool: 

DISCLAIMER:

Se non parte qualche servizio può voler dire 2 cose:

lo script di init era buggato e ora è fixxato (ricompilate il pacchetto o copiate l'init da $FILESDIR)

lo script di init è buggato e nessuno ha mai aperto un bug (cercate su bugzilla ed aprite un bug se non è riportato)

P.S. baselayout 2 alfa non è mascherato sotto g/fbsd e funziona benissimo

----------

## !equilibrium

 *Drizzt Do` Urden wrote:*   

> Sotto linux base (insomma con /bin/sh linkato a /bin/bash) il boost di performance è molto minore che in un linux embedded (con /bin/sh di busybox) o in * bsd (/bin/sh è ash).

 

sotto linux (cito) "base" il boost è molto visibile soprattutto su computer datati.

ora provo a linkare busybox a /bin/sh.

/EDIT:

 :Shocked:  è pauroso con busybox.

il mio vecchio notebook non è mai stato così veloce in fase di boot.

----------

## comio

 *!equilibrium wrote:*   

>  *Drizzt Do` Urden wrote:*   Sotto linux base (insomma con /bin/sh linkato a /bin/bash) il boost di performance è molto minore che in un linux embedded (con /bin/sh di busybox) o in * bsd (/bin/sh è ash). 
> 
> sotto linux (cito) "base" il boost è molto visibile soprattutto su computer datati.
> 
> ora provo a linkare busybox a /bin/sh.
> ...

 

a me con busyobx non c'è script che non abbia errori.

ciao

----------

## lavish

Io ho linkato a dash (app-shells/dash) ed e' andato quasi tutto bene!

L'unico "problema" che ho avuto e' stato con /etc/conf.d/net dove usavo:

```
modules=( "iwconfig" )
```

e' bastato sistamrlo in 

```
modules="iwconfig"
```

 (come e' descritto in net.example attuale) ed e' andato tutto liscio   :Smile: 

----------

## lucapost

 *comio wrote:*   

> 
> 
> a me con busyobx non c'è script che non abbia errori.

 

Sul mio notebook ~amd64 con un 

```
ln -sf /bin/busybox /bin/sh
```

è filato proprio tutto liscio...azz quanto è più veloce il boot!!!

Comunque, visto che non sono affatto asperto di queste cose, ci sono controindicazioni a mantenere questo link a busybox?

----------

## comio

 *lucapost wrote:*   

>  *comio wrote:*   
> 
> a me con busyobx non c'è script che non abbia errori. 
> 
> Sul mio notebook ~amd64 con un 
> ...

 

se funziona no  :Wink: 

se non funziona qualcuna.

ciao

----------

## lucapost

ma al primo aggiornamento...

```
emerge ndiswrapper

...

...

...

 * Determining the location of the kernel source code

 * Found kernel source directory:

 *     /usr/src/linux

 * Found kernel object directory:

 *     /lib/modules/2.6.21-gentoo/build

 * Found sources for kernel version:

 *     2.6.21-gentoo

 * Checking for suitable kernel configuration options...                                                                 [ ok ]

>>> Unpacking source...

>>> Unpacking ndiswrapper-1.42.tar.gz to /var/tmp/portage/net-wireless/ndiswrapper-1.42/work

 * Converting ndiswrapper-1.42/driver/Makefile to use M= instead of SUBDIRS= ...                                         [ ok ]

>>> Source unpacked.

>>> Compiling source in /var/tmp/portage/net-wireless/ndiswrapper-1.42/work/ndiswrapper-1.42 ...

gcc -g -Wall -I../driver -o loadndisdriver loadndisdriver.c

 * Preparing ndiswrapper module

make -C /lib/modules/2.6.21-gentoo/build M=/var/tmp/portage/net-wireless/ndiswrapper-1.42/work/ndiswrapper-1.42/driver

make[1]: Entering directory `/usr/src/linux-2.6.21-gentoo'

  LD      /var/tmp/portage/net-wireless/ndiswrapper-1.42/work/ndiswrapper-1.42/driver/built-in.o

ar: invalid option -- s

BusyBox v1.5.0 (2007-03-28 21:58:33 CEST) multi-call binary

Usage: ar [-o] [-v] [-p] [-t] [-x] ARCHIVE FILES

Extract or list FILES from an ar archive

Options:

        -o      Preserve original dates

        -p      Extract to stdout

        -t      List

        -x      Extract

        -v      Verbosely list files processed

make[2]: *** [/var/tmp/portage/net-wireless/ndiswrapper-1.42/work/ndiswrapper-1.42/driver/built-in.o] Error 1

make[1]: *** [_module_/var/tmp/portage/net-wireless/ndiswrapper-1.42/work/ndiswrapper-1.42/driver] Error 2

make[1]: Leaving directory `/usr/src/linux-2.6.21-gentoo'

make: *** [default] Error 2

!!! ERROR: net-wireless/ndiswrapper-1.42 failed.

Call stack:

  ebuild.sh, line 1614:   Called dyn_compile

  ebuild.sh, line 971:   Called qa_call 'src_compile'

  ebuild.sh, line 44:   Called src_compile

  ndiswrapper-1.42.ebuild, line 59:   Called linux-mod_src_compile

  linux-mod.eclass, line 516:   Called die

!!! Unable to make  KSRC=/usr/src/linux KVERS=2.6.21-gentoo KBUILD=/lib/modules/2.6.21-gentoo/build DISABLE_USB=1 -j1 all.

!!! If you need support, post the topmost build error, and the call stack if relevant.

!!! A complete build log is located at '/var/tmp/portage/net-wireless/ndiswrapper-1.42/temp/build.log'.
```

che si risolve con un semplice

```
ln -sf /bin/bash /bin/sh
```

 :Crying or Very sad:   :Crying or Very sad:   :Crying or Very sad: 

----------

## comio

 *lucapost wrote:*   

> ma al primo aggiornamento...
> 
> ```
> emerge ndiswrapper
> 
> ...

 

Quel link è meglio non modificarlo... bisognerebbe vedere se c'è la possibilità di dire a runscript di usare un altro interprete....

ciao

luigi

----------

## Ic3M4n

a me con il link a busybox non parte dbus e comunque ho lo stesso problema segnalato da lucapost.

----------

## lavish

Provate a fare il link a dash invece che busybox  :Smile: 

----------

## comio

 *lavish wrote:*   

> Provate a fare il link a dash invece che busybox 

 

Comunque io non gradisco di dover cambiare la mia shell :S. Cambiare il link è "quick&dirty"...

ciao

----------

## lavish

 *comio wrote:*   

> Comunque io non gradisco di dover cambiare la mia shell :S. Cambiare il link è "quick&dirty"...

 

Secondo me invece sarebbe ottimale avere il sistema stabile con /bin/sh che punta a una shell come dash... gli script che richiedono esplicitamente funzioni aggiuntive di bash dovrebbero richiedere #!/bin/bash , non #!/bin/sh, quindi non la vedo sporca come cosa...

----------

## comio

 *lavish wrote:*   

>  *comio wrote:*   Comunque io non gradisco di dover cambiare la mia shell :S. Cambiare il link è "quick&dirty"... 
> 
> Secondo me invece sarebbe ottimale avere il sistema stabile con /bin/sh che punta a una shell come dash... gli script che richiedono esplicitamente funzioni aggiuntive di bash dovrebbero richiedere #!/bin/bash , non #!/bin/sh, quindi non la vedo sporca come cosa...

 

Io dico semplicemente che la shell da chiamare sia da mettere in una variabile gestita da runscripts. Non credo che costi troppo "parametrizzare" questa cosa.

Il problema di fondo è che in generale gli script sono scritti per bash (o quanto meno sottointendono bash), bisognerebbe mettere nelle linee guida di scrittura di ipotizzare il set ridotto di sh.

ciao

luigi

----------

## cloc3

 *lavish wrote:*   

> Provate a fare il link a dash invece che busybox 

 

in entrambi i casi il primo effetto pratico è che lo spegnimento automatico dolce con pressione del pulsante d'avvio rimane fuori uso.

troppo fastidioso, perché ne faccio uso sistematico sul laptop.

----------

## lucapost

 *lavish wrote:*   

> Provate a fare il link a dash invece che busybox 

 

Anche con questo il boot è decisamente più veloce (almeno ad occhio!) e ndiswrapper compila correttamente!   :Cool: 

ps: si accettano scommesse entro quando dovrò rimettere a posto il link per problemi di altre incompatibilità!  :Laughing: 

----------

## lavish

 *comio wrote:*   

> Io dico semplicemente che la shell da chiamare sia da mettere in una variabile gestita da runscripts. Non credo che costi troppo "parametrizzare" questa cosa.
> 
> Il problema di fondo è che in generale gli script sono scritti per bash (o quanto meno sottointendono bash), bisognerebbe mettere nelle linee guida di scrittura di ipotizzare il set ridotto di sh.

 

Concordo in pieno con te  :Smile: 

Il discorso sul "sarebbe bello se..." non voleva escludere quanto affermi, anzi  :Smile: 

Ciao!

----------

## comio

Comunque, spulciando i sorgenti, basterebbe cambiare le intestazioni nei files *.sh in /lib64/rcscripts/sh/ (in particolare rc-help.sh).

(grep -iRn "exec[a-z]" * nei sorgenti)

```

...

src/runscript.c:298:          execl (RC_SVCDIR "runscript.sh", mycmd, mycmd, myarg1, myarg2,

src/runscript.c:305:          execl (RC_LIBDIR "sh/runscript.sh", mycmd, mycmd, myarg1, myarg2,

src/runscript.c:881:      execl (RCSCRIPT_HELP, RCSCRIPT_HELP, service, (char *) NULL);

src/runscript.c:988:          execl (RCSCRIPT_HELP, RCSCRIPT_HELP, service, (char *) NULL);

src/runscript.c:1097:          execl (RCSCRIPT_HELP, RCSCRIPT_HELP, service, "help", (char *) NULL);

src/runscript.c:1114:      execl (RCSCRIPT_HELP, RCSCRIPT_HELP, service, (char *) NULL);

...

```

----------

## lavish

E' in portage da ieri l'aplha2   :Smile: 

----------

## comio

 *lavish wrote:*   

> E' in portage da ieri l'aplha2  

 

Se è per questo ho già fatto il primo bug-report (del piffero...)  :Very Happy: 

ciao

----------

## lucapost

qua la situazione mi sembra un pò ferma o sbaglio?

----------

## lavish

Continuo a usarlo da un sacco di tempo  :Smile: 

----------

## lucapost

 *lavish wrote:*   

> Continuo a usarlo da un sacco di tempo 

 

su amd64 o x86? inoltre quale versione?

ed il link a /bin/sh è ancora dash? perchè a me con baselayout1 se cambio /bin/sh mi si piantano un sacco di initscript...

----------

## lavish

 *lucapost wrote:*   

>  *lavish wrote:*   Continuo a usarlo da un sacco di tempo  
> 
> su amd64 o x86? inoltre quale versione?
> 
> ed il link a /bin/sh è ancora dash? perchè a me con baselayout1 se cambio /bin/sh mi si piantano un sacco di initscript...

 

Sia su x86 che amd64.

Uso baselayout-2 dalla alpha1 fino ad oggi, con la rc6.

Se con baselayout-1 cambi /bin/sh per puntare a qualcosa di diverso da bash e' OVVIO che ti si piantino gli initscript   :Rolling Eyes: 

----------

## crisandbea

domanda probabilmente a cui già avete risposto, ma lo chiedo uguale    :Laughing:    , 

dopo aver emerso il baselayout2, aggiornato tutti i file che ti chiede di aggiornare emerge,  bisogna fare altro??

ovvero bisogna cambiare manualmente il link  simbolico da 

```
 /bin/sh 
```

 a 

```
/bin/dash 
```

 , a

```
 /bin/busybox 
```

  ??

oppure viene fatto in automatico???

ciauz

----------

## lucapost

 *lavish wrote:*   

> 
> 
> Se con baselayout-1 cambi /bin/sh per puntare a qualcosa di diverso da bash e' OVVIO che ti si piantino gli initscript  

 

la mia era un'affermazione, perdipiù confermata dall'esperienza diretta   :Evil or Very Mad:  , non era una domanda.

comunque ho appena installato la rc6...ed aggiornato un pò di initscript...

devo ancora sistemare qualche cosetta...poi si vedrà....

----------

## lavish

 *crisandbea wrote:*   

> [...]

 

Cambiare il link di /bin/sh a qualcosa di diverso da bash, significa rendere la propria gentoo non ufficialmente supportata.

Baselayout 2 non ha nulla a che vedere direttamente con quel link. Quello che cambia, e' solo la possibilita' di cambiare il link

----------

## crisandbea

 *lavish wrote:*   

>  *crisandbea wrote:*   [...] 
> 
> Cambiare il link di /bin/sh a qualcosa di diverso da bash, significa rendere la propria gentoo non ufficialmente supportata.
> 
> Baselayout 2 non ha nulla a che vedere direttamente con quel link. Quello che cambia, e' solo la possibilita' di cambiare il link

 

ok,  grazie mille per la precisazione.

----------

## lucapost

Da qualche ora sto provando le brezza di baselayout2, ed ora ho un problema riguardo la configurazione dell'interfaccia dialup (tutto ok con baselayout1).

Questa è la sezione di /etc/conf.d/net riguardo alla configurazione dialup:

```
root@jarod 

 ~/> grep -v "#" /etc/conf.d/net

config_ppp0="ppp"

link_ppp0="/dev/ttyUSB0"                

username_ppp0='teleconomy'

password_ppp0='teleconomy'

phone_number_ppp0="7020187187"

dns_servers_ppp0="62.211.69.150"

pppd_ppp0="debug defaultroute lock 115200"

chat_ppp0=" \

        'ABORT' 'BUSY' \

        'ABORT' 'ERROR' \

        'ABORT' 'NO ANSWER' \

        'ABORT' 'NO CARRIER' \

        'ABORT' 'NO DIALTONE' \

        'ABORT' 'Invalid Login' \

        'ABORT' 'Login incorrect' \

        'TIMEOUT' '5' \

        '' 'ATZ' \

        'OK' 'ATDT\T' \

        'TIMEOUT' '60' \

        'CONNECT' '' \

        'TIMEOUT' '5' \

        '~--' '' \

"
```

questa è la sezione riguardo alle interfaccie  ppp del nuovo baselayout2 in /etc/conf.d/net.example:

```
#-----------------------------------------------------------------------------

# PPP

# For PPP support, emerge net-dialup/ppp

# PPP is used for most dialup connections, including ADSL.

# The older ADSL module is documented below, but you are encouraged to try

# this module first.

#

# You need to create the PPP net script yourself. Make it like so

#ln -s net.lo /etc/init.d/net.ppp0

#

# Each PPP interface requires an interface to use as a "Link"

#link_ppp0="/dev/ttyS0"       # Most PPP links will use a serial port

#link_ppp0="eth0"             # PPPoE requires an ethernet interface

#link_ppp0="[itf.]vpi.vci"      # PPPoA requires the ATM VC's address

#link_ppp0="/dev/null"         # ISDN links should have this

#link_ppp0="pty 'your_link_command'"   # PPP links over ssh, rsh, etc

#

# Here you should specify what pppd plugins you want to use

# Available plugins are: pppoe, pppoa, capi, dhcpc, minconn, radius,

#          radattr, radrealms and winbind 

#plugins_ppp0="pppoe"         # Required plugin for PPPoE

#plugins_ppp0="pppoa vc-encaps"      # Required plugin for PPPoA with an option

#plugins_ppp0="capi"         # Required plugin for ISDN

#

# PPP requires at least a username. You can optionally set a password here too

# If you don't, then it will use the password specified in /etc/ppp/*-secrets

# against the specified username

#username_ppp0='user'

#password_ppp0='password'

# NOTE: You can set a blank password like so

#password_ppp0=

#

# The PPP daemon has many options you can specify - although there are many

# and may seem daunting, it is recommended that you read the pppd man page

# before enabling any of them

#pppd_ppp0="

#   maxfail 0   # WARNING: It's not recommended you use this

#         # if you don't specify maxfail then we assume 0

#   updetach    # If not set, "/etc/init.d/net.ppp0 start" will return

#         # immediately,  without waiting the link to come up

#         # for the first time.

#         # Do not use it for dial-on-demand links!

#   debug    # Enables syslog debugging

#   noauth   # Do not require the peer to authenticate itself

#   defaultroute   # Make this PPP interface the default route

#   usepeerdns      # Use the DNS settings provided by PPP

#

# On demand options

#   demand      # Enable dial on demand

#   idle 30      # Link goes down after 30 seconds of inactivity

#   10.112.112.112:10.112.112.113   # Phony IP addresses

#   ipcp-accept-remote   # Accept the peers idea of remote address

#   ipcp-accept-local   # Accept the peers idea of local address

#   holdoff 3    # Wait 3 seconds after link dies before re-starting

#

# Dead peer detection

#   lcp-echo-interval 15   # Send a LCP echo every 15 seconds

#   lcp-echo-failure 3   # Make peer dead after 3 consective

#            # echo-requests

#   

# Compression options - use these to completely disable compression

#   noaccomp noccp nobsdcomp nodeflate nopcomp novj novjccomp

#

# Dial-up settings

#   lock            # Lock serial port

#   115200         # Set the serial port baud rate

#   modem crtscts         # Enable hardware flow control

#   192.168.0.1:192.168.0.2   # Local and remote IP addresses

#"

#

# Dial-up PPP users need to specify at least one telephone number

#phone_number_ppp0="12345689" # Maximum 2 phone numbers are supported

# They will also need a chat script - here's a good one

#chat_ppp0=" \

#   'ABORT' 'BUSY' \

#   'ABORT' 'ERROR' \

#   'ABORT' 'NO ANSWER' \

#   'ABORT' 'NO CARRIER' \

#   'ABORT' 'NO DIALTONE' \

#   'ABORT' 'Invalid Login' \

#   'ABORT' 'Login incorrect' \

#   'TIMEOUT' '5' \

#   '' 'ATZ' \

#   'OK' 'AT' # Put your modem initialization string here \

#   'OK' 'ATDT\T' \

#   'TIMEOUT' '60' \

#   'CONNECT' '' \

#   'TIMEOUT' '5' \

#   '~--' '' \

#"

# If the link require extra configuration - for example wireless or

# RFC 268 bridge - we need to depend on the bridge so they get

# configured correctly.

#RC_NEED_ppp0="net.nas0"

#WARNING: if MTU of the PPP interface is less than 1500 and you use this

#machine as a router, you should add the following rule to your firewall

#

#iptables -I FORWARD 1 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
```

e questo è l'errore:

```
root@jarod 

 ~/> /etc/init.d/net.ppp0 restart

net.ppp0      | * Caching service dependencies ...                                                                                                                              [ ok ]

net.ppp0      | * Bringing up interface ppp0

net.ppp0      | *   Starting pppd in ppp0 ...

net.ppp0      |eval: 8: debug: not found

net.ppp0      |eval: 10: defaultroute: not found

net.ppp0      |eval: 30: lock: not found

net.ppp0      |eval: 31: 115200: not found

net.ppp0      |eval: 34: plugin: not found

net.ppp0      | *   Failed to start PPP                                                                                                                                         [ !! ]

net.ppp0      | * WARNING: net.ppp0 not under our control, aborting

```

il problema sembra essere legato al fatto della nuova sintassi senza parentesi  () .

Infatti quando lancio l'initscript sembra non riconoscere le opzioni che passa la variabile pppd_ppp0.

Secondo me la sintassi della mia configurazione è corretta, ma ahimè non funge. 

Qualcuno sa aiutarmi?

ps: con wvdial tutto ok

----------

## lavish

Fatto il merge del thread aperto da lucapost.

Finche' baselayout-2 non esce dal periodo di testing, continuiamo qui  :Wink: 

----------

## lucapost

esisterà ancora una voce così autorevole?  :Wink: 

----------

## lavish

 *lucapost wrote:*   

> esisterà ancora una voce così autorevole? 

 

Si' visto che, mal che vada, continuera' comunque a svilupparlo esternamente  :Smile: 

----------

## crisandbea

con il baselayout2, come si deve configurare il file 

```
/etc/conf.d/rc
```

 in modo tale che dandogli yes alla seguente opzione

```
RC_PARALLEL="yes"
```

 non aspetti che il dhcpcd su eth0 vada in timeout????

----------

## lucapost

 *crisandbea wrote:*   

> con il baselayout2, come si deve configurare il file 
> 
> ```
> /etc/conf.d/rc
> ```
> ...

 

```
# Some people want a finer grain over hotplug/coldplug. RC_PLUG_SERVICES is a

# list of services that are matched in order, either allowing or not. By

# default we allow services through as RC_COLDPLUG/RC_HOTPLUG has to be yes

# anyway.

# Example - RC_PLUG_SERVICES="net.wlan !net.*"

# This allows net.wlan and any service not matching net.* to be plugged.

RC_PLUG_SERVICES="!*"
```

dovrebbere essere questa la voce.

----------

## LastHope

 *crisandbea wrote:*   

> con il baselayout2, come si deve configurare il file 
> 
> ```
> /etc/conf.d/rc
> ```
> ...

 

OT: io per non aspettare il timeout sul DHCP al boot, utilizzo il fantastico netplug:

```
dani@dani_lap ~/tesiLevner/Latex $ eix netplug

[I] sys-apps/netplug

     Available versions:  1.2.9-r2 1.2.9-r3

     Installed versions:  1.2.9-r3(14:24:24 09/14/07)

     Homepage:            http://www.red-bean.com/~bos/

     Description:         Brings up/down ethernet ports automatically with cable detection

```

----------

## SilverXXX

Anche se è da un pò che non posto continuo a uasre gentoo come sempre (è troppo più semplice da usare, una volta che si impara) e volevo sapere se qualcuno ha fatto prove con init-ng e baselayout2 sulla stessa macchina.

----------

## xdarma

Mi aggiungo alla lista dei curiosi.

Se poi riusciste a "misurare" le prestazioni dei sistemi al boot, per esempio con bootchart, credo fareste un favore a molti.

TIA

----------

## riverdragon

Io ho guadagnato circa cinque secondi, misurazione spannometrica, da grub al prompt testuale; da 28 a 23 secondi. Con un disco a 7200 rpm probabilmente il miglioramento sarebbe maggiore.

----------

## lucapost

Stavo provando a smanettare ancora un un con le shell, ho visto che con il link /bin/sh a /bin/dash mi falliscono un pò di compilazioni (ndiswrapper, ecc), oltre a qualche warning per la sintassi legata a bash di /etc/init.d/cpufreqd:

```
#!/sbin/runscript

# Copyright 1999-2006 Gentoo Foundation

# Distributed under the terms of the GNU General Public License v2

# $Header: /var/cvsroot/gentoo-x86/sys-power/cpufreqd/files/cpufreqd-2.1.1-init.d,v 1.1 2006/07/04 16:34:49 brix Exp $

CONFIGFILE=/etc/cpufreqd.conf

depend() {

        need localmount

        use logger lm_sensors

}

checkconfig() {

        if[b] [[ ! -f ${CONFIGFILE} ]]; then

                eerror "Configuration file ${CONFIGFILE} not found"

                return 1

        fi

        

        if [[ ! -e /proc/cpufreq ]] && [[ ! -e /sys/devices/system/cpu/cpu0/cpufreq ]]; then

                eerror "cpufreqd requires the kernel to be configured with CONFIG_CPU_FREQ"

                return 1

        fi

}

start() {

        checkconfig || return 1

        ebegin "Starting CPU Frequency Daemon"

        start-stop-daemon --start --exec /usr/sbin/cpufreqd -- \

                -f ${CONFIGFILE}

        eend ${?}

}

stop() {

        ebegin "Stopping CPU Frequency Daemon"

        start-stop-daemon --stop --exec /usr/sbin/cpufreqd

        eend ${?}

}
```

e quindi l'errore

```
 ~/> /etc/init.d/cpufreqd restart

cpufreqd      | * Caching service dependencies ...                                                                                                                              [ ok ]

cpufreqd      | * Stopping CPU Frequency Daemon ...                                                                                                                             [ ok ]

cpufreqd      |/lib64/rc/sh/runscript.sh: 91: [[: not found

cpufreqd      |/lib64/rc/sh/runscript.sh: 91: [[: not found

cpufreqd      | * Starting CPU Frequency Daemon ... 
```

da qui deduco che a dash non gli piace la sintassi con la doppia quadra sui condizionali..., ma comunque non è grave, l'errore per ora lo trovo solo in questo script.

Comunque sarebbe figo che gli sviluppatori dei vari initscript uniformassero un pò meglio la sintassi per rendere compatibili altre shell.

Ora, per quel che mi riguarda, a me interessa solo che gli initscript utilizzino /bin/dash, ovviamente per velocizzare i runlevel di boot e default.

Quindi sto pensando di modificare la prima riga di /lib64/rc/sh/runscript.sh, cioè al posto di

```
#!/bin/sh   
```

metterci

```
#!/bin/dash  
```

Secondo me è un'ottimo compromesso, che ne pensate?

----------

## lavish

 *lucapost wrote:*   

> Secondo me è un'ottimo compromesso, che ne pensate?

 

No, e' una cosa pessima.

Gli script che usano #!/bin/sh dovrebbero essere conformi alle specifiche posix per sh, mentre quelli che usano bashism dovrebbero usare #!/bin/bash. Fine della storia.

Altre soluzioni o compromessi non ce ne sono.

----------

## lucapost

Sono d'accordo.

A questo punto ci sono un sacco di script che cominciano con #!/bin/sh che non rispettano lo standard posix? 

Sbaglio o questo è un problema della sintassi che piace solo a bash?

----------

## lavish

 *lucapost wrote:*   

> A questo punto ci sono un sacco di script che cominciano con #!/bin/sh che non rispettano lo standard posix?

 

Esatto...

 *lucapost wrote:*   

> Sbaglio o questo è un problema della sintassi che piace solo a bash?

 

Yep, sono i cosiddetti bashism.

----------

## lucapost

[OT]

ho appena scoperto che le ultime release di ubuntu utilizzano dash come shell di default

[OT]

----------

## lavish

 *lucapost wrote:*   

> [OT]
> 
> ho appena scoperto che le ultime release di ubuntu utilizzano dash come shell di default
> 
> [OT]

 

false

Dash e' la shell a cui punta /bin/sh.

La shell di default e' bash  :Wink: 

----------

## lucapost

yep, in effetti $SHELL è impostata su /bin/bash   :Confused: 

ma uno script dash è sempre compatibile con posix?

----------

## lavish

 *lucapost wrote:*   

> yep, in effetti $SHELL è impostata su /bin/bash  
> 
> ma uno script dash è sempre compatibile con posix?

 

man dash  :Wink: 

----------

## lucapost

 *man dash wrote:*   

> Only features designated by POSIX, plus a few Berkeley extensions, are
> 
> being incorporated into this shell.

 

vediamo se riesco a trovare quali sono queste Berkeley extensions....cercherò....

Ora ho un'altro problemino, ho scoperto che non funge il boot interattivo, per capirci meglio, quando durante l'avvio degli initsciprt premo ctrl+i, ottengo il solito menù a 4 opzioni, ma se premo 4 e quindi provo a fare il login come singolo utente, non accetta l'immissione della password.

Non è che non riconosce la password, ma non compare proprio la riga"Password: ", e devo riavviare brutalmente il piccì.

Capita solo a me?

----------

## riverdragon

Due cose interessanti che ho trovato girando in cerca di notizie:

1 nuovo target/split per baselayout2? Non ho ben capito dove questo OpenRC, o come si chiamerà, si inserisca.

2 per chi ha seguito la guida per la gestione energetica del wiki, ecco dove è finito il file "softlevel" che risultava introvabile.

EDIT: ho fatto un paio di prove modificando il link /bin/sh, e facendo ripartire a mano gli script di init: con busybox già i primi tentativi danno errore, e sono sempre errori di sintassi dei comandi; con dash, aggiornando un paio di ebuild alla loro versione ~x86 funziona tutto alla stessa velocità di bash (23 secondi al boot testuale, 1 minuto e qualche secondo a gnome caricato), con il problema che "source /etc/profile" all'avvio di xdm non funziona. Se non avete consigli particolari (ad esempio, chi ha provato busybox l'ha fatto con la versione stabile -1.7*- o quella in test -1.8*-?), intanto quindi tengo bash.

----------

## !equilibrium

 *riverdragon wrote:*   

> nuovo target/split per baselayout2? Non ho ben capito dove questo OpenRC, o come si chiamerà, si inserisca.

 

che intendi?

----------

## lucapost

Lancio il  kernel al boot con l'opzione quiet, login manager non li ho, quindi prendo il tempo da quando parte in runlevel di boot a quando il framebuffer è pronto per il login. Ho fatto tre prove per shell, questi che seguono i risultati in media:

bash: 12,5 secondi

dash: 11.2 secondi

----------

## riverdragon

 *!equilibrium wrote:*   

> che intendi?

 Hai letto il post di uberlord raggiungibile cliccando su "1"?

La frase in questione è  *roy marples wrote:*   

> Basically baselayout will be split into two entities. Firstly, the bit that lays out the initial file system and provides the core system files shall remain as baselayout. The rest of it (ie, rc, init scripts, etc) will be forked off into a new package called OpenRC (working title).

 

----------

## !equilibrium

 *riverdragon wrote:*   

> Hai letto il post di uberlord raggiungibile cliccando su "1"?

 

certo

 *riverdragon wrote:*   

> La frase in questione è  *roy marples wrote:*   Basically baselayout will be split into two entities. Firstly, the bit that lays out the initial file system and provides the core system files shall remain as baselayout. The rest of it (ie, rc, init scripts, etc) will be forked off into a new package called OpenRC (working title). 

 

e continuo a non capire il senso della tua frase originaria "Non ho ben capito dove questo OpenRC si inserisca".

esattamente *cosa intendi* con il termine "inserire" ?

----------

## riverdragon

Che ruolo svolge, e in che parte dell'init interviene (prima o dopo baselayout, lo sostituisce... ecc)?

----------

## !equilibrium

 *riverdragon wrote:*   

> Che ruolo svolge, e in che parte dell'init interviene (prima o dopo baselayout, lo sostituisce... ecc)?

 

Oo'

è scritto nella stessa frase di Roy che hai incollato:

 *Quote:*   

> Basically baselayout will be split into two entities. Firstly, the bit that lays out the initial file system and provides the core system files shall remain as baselayout. The rest of it (ie, rc, init scripts, etc) will be forked off into a new package called OpenRC (working title).

 

cioè l'attuale baselayout viene suddiviso in 2 parti:

- baselayout (il core e la parte che genera il filesystem iniziale)

- OpenRC (tutto il resto: rc, scripts ecc)

----------

## lucapost

anche se non esistono ancora gli ebuild ne di baselayout-core ne di openrc, si conosce già il nome di qualche alternativa a quest'ultimo?

----------

## MeMyselfAndI

un'alternativa a una cosa che non e' ancora stata rilasciata ? Mi sembri un po precoce

----------

## riverdragon

 *!equilibrium wrote:*   

> cioè l'attuale baselayout viene suddiviso in 2 parti:
> 
> - baselayout (il core e la parte che genera il filesystem iniziale)
> 
> - OpenRC (tutto il resto: rc, scripts ecc)

 Allora devo ripassare come funziona il core di baselayout, ero convinto che tutto quello che facesse fosse avviare gli initscript.  :Rolling Eyes: 

----------

## CarloJekko

 *lavish wrote:*   

>  *lucapost wrote:*   [OT]
> 
> ho appena scoperto che le ultime release di ubuntu utilizzano dash come shell di default
> 
> [OT] 
> ...

 

/bin/sh punta a dash ... forse è per questo che si è velocizzata nell'avvio...

Io l'ho riportato a bash (non fungevano troppi script)... Ma basta parlare du Ubuntu :d

----------

## topper_harley

Qualcuno di voi utilizza openrc dall'openrc overlay disponibile tramite layman?

Io ho rimpiazzato baselayout con openrc e funziona perfettamente, ma ci sono un sacco di ebuild in portage che richiedono baselayout (module-init-tools, udev ecc.).

Qualche idea? Ovviamente mascherare baselayout non basta...

----------

## MeMyselfAndI

aspettare che gli altri ebuild vengano modificati.... sempre che tu non lo voglia fare a mano/e testare tutti gli eventuali errori

----------

## flocchini

lo richiedono come dipendenza o per funzionare?

nel primo caso c'e' il package provided che non mi piace niente come soluzione ma 'e sempre un'alternativa per le dipendenze irrisolvibili

----------

## topper_harley

 *flocchini wrote:*   

> lo richiedono come dipendenza o per funzionare?
> 
> nel primo caso c'e' il package provided che non mi piace niente come soluzione ma 'e sempre un'alternativa per le dipendenze irrisolvibili

 

Gia', ma usare package.provided mi impedirebbe di installare/aggiornare openrc.

L'ideale sarebbe creare un "virtual/baselayout" e creare uno script che sostituisca tuttle le incombenze nel tree e rifaccia il digest degli ebuild modificati dopo ogni sync... Mi viene gia' il mal di pancia...

----------

## riverdragon

 *topper_harley wrote:*   

> Io ho rimpiazzato baselayout con openrc e funziona perfettamente, ma ci sono un sacco di ebuild in portage che richiedono baselayout (module-init-tools, udev ecc.).

 Rimpiazzato? Non so da te, ma qui l'ebuild di openrc chiede baselayout "con versione non minore di 2.0" e baselayout-2 chiede openrc. Le due cose non sono mutuamente esclusive.

----------

## lucapost

Ho appena installato da layman openrc. Fila che è una meraviglia!

Ho dovuto comunque risolvere questo bug, è bastato l'upgrade a udev-118-r2.

PS: Sarebbe interessante che qualche mod aggiornasse il titolo del thread con qualche riferimento al nome Openrc!

PPS: Auguri a Uberlord!

/edit

ho visto che c'è un nuovo initscript:

```
 ~> qfile /etc/init.d/swap 

sys-apps/openrc (/etc/init.d/swap)
```

Non avendo una partizione di swap, mi sono permesso di toglierlo dal runlevel di boot  :Razz: 

----------

## lavish

 *lucapost wrote:*   

> PS: Sarebbe interessante che qualche mod aggiornasse il titolo del thread con qualche riferimento al nome Openrc!

 

done  :Wink: 

Auguri anche da parte mia a UberLord! Ieri e' diventato papà  :Smile: 

----------

## djinnZ

 :Shocked:  e vi sembra una bella notizia? Tra pappine e pannolini la vedo nera per i tempi di openrc.

----------

## riverdragon

Dalla foto sul suo blog sembra che anche uberlord stesso sia in dolce attesa  :Laughing: 

Anyway, qui funziona anche nonostante sia in versione 0.1, quindi posso portare un po' di pazienza.

----------

## HoX

Qualcuno potrebbe aiutarmi a capire perché non riesco ad emergere baselayout2?

Tutto questo vostro parlare mi ha messo curiosità, ma quando provo ad emergerlo:

 *Quote:*   

> 
> 
> # emerge -pv sys-apps/baselayout
> 
> These are the packages that would be merged, in order:
> ...

 

----------

## riverdragon

Devi saltare il blocco, prova con

```
quickpkg baselayout

emerge -C baselayout

emerge -av baselayout
```

----------

## lucapost

Dopo aver scaricato l'overlay da layman, devi mettere pacchetto e dipendenze in keywords:

```
 ~> cat /etc/portage/package.keywords/baselayout 

sys-apps/baselayout

sys-apps/makedev

sys-apps/openrc

=sys-fs/udev-118-r2
```

poi rimuovi il vecchio baselayout ed installi openrc:

```
emerge -C baselayout ; emerge openrc
```

quindi aggiorni i file di configurazione:

```
dispatch-conf 
```

et voilà!

----------

## Peach

whatabout this?

```
[blocks B     ] <sys-fs/udev-118-r2 (is blocking sys-apps/openrc-9999)
```

aggiornando da baselayout-2.0.0_rc6-r1 a baselayout-2.0.0

----------

## lucapost

Dall'ebuild di openrc:

```
 ~> grep udev /usr/portage/sys-apps/openrc/openrc-9999.ebuild 

        !<sys-fs/udev-118-r2"
```

Quindi quella dipendenza la puoi risolvere con:

```
echo ">=sys-fs/udev-118-r2"  >> /etc/portage/package.keywords && emerge openrc
```

Occhio che potrebbero esserci da aggiornare anche cmake, makedev,...

Fai un controllo con

```
emerge -pv openrc
```

Sul mio notebook funziona tutto bene con:

```
[I] sys-apps/openrc (0.2.1-r1@04/07/2008): OpenRC manages the services, startup and shutdown of a host

[I] sys-fs/udev (118-r3@04/06/2008): Linux dynamic and persistent device naming support (aka userspace devfs)

[I] sys-apps/baselayout (2.0.0@04/05/2008): Filesystem baselayout and init scripts

```

Mandi.

----------

## Peach

@lucapost: nessun problema con il nuovo udev? è giusto questo che mi preoccupa

----------

## crisandbea

 *Peach wrote:*   

> @lucapost: nessun problema con il nuovo udev? è giusto questo che mi preoccupa

 

io uso addirittura la 118-r3 di udev, e per ora nessun problema, lo uso da circa due settimane.

ciauz

----------

## lucapost

Confermo nessun problema con udev-118-r3,

----------

## Peach

 *lucapost wrote:*   

> Confermo nessun problema con udev-118-r3,

 

sto usando udev-119 e nessun problema s'è presentato.

l'unica grana ce l'ho con il demone di spamassassin (spamd) che non vuole saperne di partire:

```
# /etc/init.d/spamd start

 * Starting spamd ...

 * start-stop-daemon: /usr/sbin/spamd is a script

 * start-stop-daemon: and should be started, stopped or signalled with 

 * start-stop-daemon: --exec /usr/bin/perl -w /usr/sbin/spamd

 * start-stop-daemon: or you should specify a pidfile or process name

 * Failed to start spamd                                                                            [ !! ]

 * ERROR: spamd failed to start
```

----------

## lucapost

potrei sbagliarmi, ma secondo me quell'initscript non rispetta gli standard posix...

----------

## Peach

 *lucapost wrote:*   

> potrei sbagliarmi, ma secondo me quell'initscript non rispetta gli standard posix...

 

ecco come non detto:

https://bugs.gentoo.org/show_bug.cgi?id=178772

Roy spiega che l'errore è chiaro  :Smile: 

ora vedo se la versione unstable fixa questo problema o se devo farlo a manina per il momento.

EDIT: risolto guardando a questo post: https://forums.gentoo.org/viewtopic-p-4996442.html#4996442

ma è un workaround, niente di finale.

----------

## Peach

all'avvio subito dopo init ho

```
waitpid: interrupted system call
```

però non mi sembra di avere problemi di altro genere

questo con baselayout 2.0.0 e openrc 9999 (installato il 9 aprile)

----------

## Cazzantonio

Con il nuovo openrc accade che la root venga montata due volte. Queste voci compaiono nell'output di df:

```
Filesystem    Type Dimens. Usati Disp. Uso% Montato su

rootfs      rootfs    7,4G  2,6G  4,5G  37% /

/dev/root     ext3    7,4G  2,6G  4,5G  37% /
```

in /proc/mounts invece solo la seconda voce ha le opzioni di mount corrette come da fstab:

```
rootfs / rootfs rw 0 0

/dev/root / ext3 rw,noatime,nodiratime,data=ordered 0 0
```

Non ho ancora capito se la cosa sia un bug o sia voluta, comunque il sistema pare funzionare correttamente.

----------

## Peach

 *Cazzantonio wrote:*   

> Con il nuovo openrc accade che la root venga montata due volte. 

 

idem per quanto mi riguarda

in più ora sono passato dall'svn snapshot alla versione 0.2.2 di openrc ma l'errore che citavo poco sopra è rimasto.

----------

## nikko96

Nel mio caso passando a baselayout-2, senza usare l'overlay ma solo le versioni unstable

di baselayout e openrc,non ho incontrato problemi di sorta, fino ad ora    :Laughing: 

Solo per le splashutils ho dovuto smascherare la versione contenente la patch per baselayout-2.

Queste sono gli ebuild:

```

nikilux@nikko ~ $ emerge -pv baselayout openrc udev

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild   R   ] sys-apps/baselayout-2.0.0  USE="-build" 0 kB

[ebuild   R   ] sys-apps/openrc-0.2.2  USE="ncurses pam unicode -debug" 0 kB

[ebuild   R   ] sys-fs/udev-119  USE="(-selinux)" 0 kB
```

----------

## djinnZ

poiché non ho molto tempo per fare prove (sai la novità) e mi servirebbe modificare alcune cosette nell'rc vorrei capire una cosa:

mi conviene investire nel baselayout2 perchè presto sarà adottato o è meglio che mi dedico all'attuale (tenete conto che ho solo macchine hardened stabili di base, quindi su alcune cose sono indietro rispetto alle versioni "normali") in attesa che il nodo venga sciolto o tagliato?

Novità sul fronte einit init-ng e compagnia?

----------

## riverdragon

Qui su x86 desktop stabile + package.keywords nessun problema reale da segnalare.

Initng non fa nuove release da novembre, einit non ne fa da febbraio...  :Crying or Very sad: 

----------

## djinnZ

Intendevo novità sul fronte gentoo, ne supporteranno qualcuno, ne scartano definitivamente altri...

qualcuno ha iniziato a remare, efficacemente, contro il lavoro di uberlord quindi potrebbe rimanere in layout per sempre...

prospettive di passaggio nel ramo stabile...

se devo perder tempo tanto vale farlo per qualcosa che non stia per morire, chiedo un consiglio su dove investire non lumi sugli eventuali problemi  :Smile: 

----------

## riverdragon

Ah, non avevo capito! Perché dici che qualcuno rema efficacemente contro uberlord?

----------

## djinnZ

 *riverdragon wrote:*   

> Ah, non avevo capito! Perché dici che qualcuno rema efficacemente contro uberlord?

 Per quel che so io no ma non mi stupirebbe se ci fosse.

Ed in generale vorrei capire su cosa conviene investire.

Al momento init-ng non parla di implementare il fallback (che poi è quello che mi interessa) ed einit mi spaventa con quella pretesa di usare xml e dipendere da expat (sono tradizionalista, per me l'init non deve avere altre dipendenze che la libc e la shell).

----------

## fbcyborg

Salve, qualcuno ha provato ad aggiornare openrc?

Io sono passato a baselayout-2 già da più di un mesetto se non ricordo male ed ora mi trovo che la versione che ho attualmente installato di openrc (la 0.3.0-r1) non è più in portage, ma ci sarebbe la 0.4.1-r1.

Ho provato ad installarlo, ma al momento ci sono ancora alcuni blocchi:

```
[ebuild     U ] sys-apps/openrc-0.4.1-r1 [0.3.0-r1] USE="ncurses pam unicode -debug" 142 kB

[blocks B     ] <sys-fs/udev-133 ("<sys-fs/udev-133" is blocking sys-apps/openrc-0.4.1-r1)

[blocks B     ] <sys-apps/sysvinit-2.86-r11 ("<sys-apps/sysvinit-2.86-r11" is blocking sys-apps/openrc-0.4.1-r1)
```

Non so se aspettare che vengano aggiornati gli ebuild in portage o mettere una versione più recente di udev. Nel secondo caso ho paura che magari si incasini qualcosa, mettendo una versione "~" di udev.

Che ne pensate?

----------

## cloc3

 *fbcyborg wrote:*   

> 
> 
> Non so se aspettare che vengano aggiornati gli ebuild in portage o mettere una versione più recente di udev. Nel secondo caso ho paura che magari si incasini qualcosa, mettendo una versione "~" di udev.
> 
> Che ne pensate?

 

secondo me è necessario passare in tilde.

oramai udev ha percorso molto cammino e, sensatamente, le innovazioni sono destinate a diventare progressivamente meno aggressive.

i problemi che puoi attendere, casomai, dovrebbero provenire direttamente da openrc stesso.

se hai deciso di smascherare l'oggetto potenzialmente più instabile, ha meno senso proteggersi dai bachi eventuali di quelli più consolidati.

----------

## fbcyborg

Ok, grazie. Quindi dici che non corro alcun pericolo installando udev-135-r3?

A questo punto, se è come dici tu, vale la pena provare.

A proposito: io da quando ho baselayout-2 non riesco più a far funzionare lo splash-theme al boot. Si vede solo la schermata iniziale e anche premendo F2 non c'è modo di mandarlo in verbose mode.

Ho notato che per installare l'ultima versione di openrc si debba aggiungere al proprio package.keywords le seguenti righe:

```
=sys-fs/udev-135-r3

=sys-apps/hal-0.5.11-r4

=sys-fs/cryptsetup-1.0.6-r2

=sys-apps/sysvinit-2.86-r12
```

----------

## riverdragon

Qui openrc 0.4.1-r1 funziona bene, con le dipendenze ~x86. A meno che tu non abbia partizioni criptate puoi disabilitare la USE crypt da hal e il pacchetto cryptsetup sparisce.

----------

## fbcyborg

Ok, grazie. Ho installato openrc anche sul mio portatile e già ho potuto constatare qualche beneficio a tempo di boot.

Il problema è sempre il solito. Dopo che sono passato al baselayout 2 l'fbcondecor non funziona più. Vedo solo la schermata iniziale, e rimane fissa fino a quando non compare kdm.

----------

## bandreabis

Tornando alle prime pagine del topic.

Ora di default (mentre leggo la discussione non sono sul mio portatile) è attivo il link 

```
ln -sf /bin/busybox /bin/sh
```

 o ancora bash?

----------

## fbcyborg

bash.

Io comunque ho fatto una prova a linkare verso busybox e ho ottenuto una sfilza di errori al boot.

----------

## riverdragon

Anche qui. Ogni tanto mi viene la voglia di forzare qualche giro record al pc facendo tuning estremo, e tento sempre anche con busybox, pur non avendo mai successo. Sarà fanta-informatica, ma da quanto si dice in giro dovrebbe eseguire molto più velocemente di bash; è come avere la ferrari in garage senza poterla accendere.

----------

## lucapost

Utilizzo openrc da diversi mesi e  fila che è una meraviglia...

Il mio /bin/bash punta sempre a /bin/dash.

----------

## fbcyborg

Ma a voi funziona fbcondecor?

----------

## Peach

 *fbcyborg wrote:*   

> Ma a voi funziona fbcondecor?

 

non lo uso

io cmq sono passato da un paio di giorni a openrc-0.4.1-r1 hal-0.5.11-r4 e udev-135-r3

e ora la wifi non mi si avvia automaticamente senza essere nel runlevel default, a cui ho dovuto quindi aggingerla, e ad ogni reboot, mi trova la home (ext3) smontata non correttamente, e via di fsck. Se poi considerate che ho dir_index, argh... aspettare devo  :Twisted Evil: 

----------

## fbcyborg

Eheh... dal momento che non mi funziona più non lo uso nemmeno io!  :Very Happy: 

Io invece sono passato da ieri a openrc-0.4.1-r1 hal-0.5.11-r4 e udev-135-r3 e quello, mi sembra (per ora) l'unico problema che ho riscontrato.

Per la wifi, io uso wicd e ci pensa lui a gestire tutto. Inoltre, ho messo netplug per non far alzare l'interfaccia eth0 al boot, almeno così non perde tempo con il dhcp.

----------

## Peach

 *Peach wrote:*   

> io cmq sono passato da un paio di giorni a openrc-0.4.1-r1 hal-0.5.11-r4 e udev-135-r3
> 
> e ora la wifi non mi si avvia automaticamente senza essere nel runlevel default, a cui ho dovuto quindi aggingerla, e ad ogni reboot, mi trova la home (ext3) smontata non correttamente, e via di fsck. Se poi considerate che ho dir_index, argh... aspettare devo 

 

allora il discorso della home era per colpa mia, openrc non c'entra

invece confermo il discorso della rete

ho installato netplug e ho eth1 (lan) e eth2 (wifi)

con openrc3 senza avere questi due device in default, venivano startati automaticamente, ma segnati come "inactive"

Ora non vengono startati neanche con il cavo di rete inserito.

questo è un bel problema, perché dal momento in cui addo uno dei due servizi a default tutti i servizi di rete iniziano a dipendere da questi, quindi se la rete LAN (che è quella più problematica) non ha cavo, devo startare la wifi a mano, ma tutti gli altri servizi non vengono startati perché dipendenti da eth1... insomma un gran casino

qualcuno ha lo stesso problema ?

perché apparte startare a mano, non trovo soluzione  :Twisted Evil: 

PS spero si sia capito il problema

----------

## Apetrini

Io ora sono tornato a openrc-0.3.0-r1 poiche col 0.4.1 xorg non mi rilevava lo schermo... (startx dava un errore tipo: No screen device, ma dai log di Xorg non emergeva nulla).

Mah...

----------

## Ic3M4n

@Peach: con openrc-4 netplug installato e net.eth0, net.eth1 nel runlevel di default tutto funziona correttamente. se non vuoi avere up entrambe le periferiche devi inserire in /etc/rc.conf rc_depend_strict="NO"

come spiegato tra i commenti:

```

# Do we allow any started service in the runlevel to satisfy the depedency

# or do we want all of them regardless of state? For example, if net.eth0

# and net.eth1 are in the default runlevel then with rc_depend_strict="NO"

# both will be started, but services that depend on 'net' will work if either

# one comes up. With rc_depend_strict="YES" we would require them both to

# come up.

```

inoltre nel file /etc/conf.d/net io ho:

```
#prefer wired over wireless

metric_eth0="100"

metric_eth1="150"

```

ovvero: se il cavo di rete è collegato usa eth0, altrimenti eth1

----------

## Peach

 *Ic3M4n wrote:*   

> @Peach: con openrc-4 netplug installato e net.eth0, net.eth1 nel runlevel di default tutto funziona correttamente. se non vuoi avere up entrambe le periferiche devi inserire in /etc/rc.conf rc_depend_strict="NO"
> 
> come spiegato tra i commenti:
> 
> ```
> ...

 

e se nessuna delle due si collega? 

con rc_depend_strict=NO i servizi che dipendono da queste vengono startati comunque, no?

anche se lo mettessi a YES, il fatto che c'è una connessione di rete attiva, dovrebbe startare tutti i servizi di rete, anche se l'altra è inactive. Non mettendo le due connessioni in default i servizi di rete funzionano come dovrebbero, il problema è che le connessioni di rete non vengono startate automaticamente perché non sono in default.

non mi sembra il funzionamento corretto..  :Confused: 

[edit] cmq ora ho scritto in ml di openrc e vediamo che dice roy.

----------

## Ic3M4n

mmm, da quanto ne so io tutte le connessioni che vuoi attive dovresti metterle in default. Teoricamente se nessuna si collega dovrebbero andare su lo stesso i servizi in quanto net.lo garantisce i servizi di base. Non ho mai provato a toglierle dal runlevel di default, ho sempre avuto questa configurazione con il vecchio baselayout e mi sono sempre trovato bene. L'unico problema che avevo avuto era a causa del dhcp che allungava i tempi di accesso alla rete di svariati secondi. risolto emergendo netplug che manda il tutto in background.

[Edit] scusa... se tu non metti una connessione in default ed un'altra garantisce gli stessi servizi (net.lo) come potrebbe essere avviata?

----------

## Peach

 *Ic3M4n wrote:*   

> [Edit] scusa... se tu non metti una connessione in default ed un'altra garantisce gli stessi servizi (net.lo) come potrebbe essere avviata?

 

con netplug

cmq ora l'hotplugging (cioè la possiblitità di startare un servizio indipendentemente dalla sua presenza in un runlevel) dalla 3 alla 4 è stato disabilitato di default, riporto le parole di Roy:

si riferisce a rc.conf

 *Roy Marples wrote:*   

> Ah, you're missing this
> 
> rc_hotplug="*"
> 
> or
> ...

 

----------

## oRDeX

Da ieri sono passato anche io a openrc-0.4.2   :Cool: 

Sembra funzionare tutto bene a parte per un paio di cosette..prima però vi dico che utilizzo swap e home cryptate ed lvm, quindi mi è necessario utilizzare l'initramfs (la creo con genkernel per semplicità).

I problemi che attualmente riscontro sono:

1) Se faccio il boot con parametri tali da abilitare il fb, l'avvio si blocca nel momento in cui dovrebbe iniziare la procdura dell'initramfs (non so in che modo possa aver influito openrc, forse nella costruzione dell'initram stesso?), se invece faccio il boot con vga=normal, tutto procede liscio.

2) Nel momento in cui parte il servizio lvm viene stampato questo warning:

 *Quote:*   

> 
> 
> lvm                |*   lvm uses addon code which is deprecated
> 
> lvm                |*   and may not be available in the future.
> ...

 

Quindi,prima che arrivi questo futuro, sarà il caso di provvedere  :Smile: 

(Comunque sia il servizio lvm parte senza far nulla, dato che fa tutto l'initram).

----------

## fbcyborg

Ciao, 

posso immaginare che il tuo problema sia legato anche al mio problema del fatto che non funziona più l'fbcondecor. Da quando ho openrc non va più e faccio il boot in "console mode".

Per quanto riguarda il tuo secondo problema, anche io ho quei messaggi al boot. 

Prima utilizzavo RAID +  LVM2, ora solo RAID ed il problema si presentava prima e si presenta tutt'ora. 

Infatti ora ho solo i seguenti messaggi al boot relativamente al RAID:

```
device-mapper uses addon code which is deprecated

and may not be available in the future

mdraid uses addon code which is deprecated

and may not be available in the future
```

Penso sia un problema di opzioni passate ai moduli in fase di caricamento o qualcosa di simile.

----------

## oRDeX

Quindi, più che un messaggio per noi è un messaggio per gli sviluppatori di dm/lvm   :Crying or Very sad: 

----------

## fbcyborg

Sinceramente non saprei. Mi sembra un messaggio tipo quello che ti avverte che SMBFS è deprecato e potrebbe non essere più messo nei futuri kernel, e ti consigliano di passare a CIFS.

Quindi la cosa ancora non mi è chiara, se devo essere io a fare qualche modifica.

----------

## oRDeX

Analizzando un attimino gli initscript ho notato che solo queli di lvm e device-mapper utilizzano funzioni chiamate "start_addon" e "stop_addon".

Comunque sia sono initscript per baselayout-2.

Ora vorrei sapere dove sono definite queste due funzioni..nonmi pare ci sia alcuna inclusione nei due initscript

EDIT:

Non avevo letto che l'interprete fosse /sbin/runscript

EDIT2:

Dopo vari giri e varie googlate ho capito questo:

le funzioni start_addon e stop_addon sono state inserite negli initscript con il fine di rendere questi compatibili con baselayout-2.

Ora baselayout-2 (openRC) dice che tale metodo è deprecato...Penso solo che questo sia stato un workaround dei mantainer di device-mapper, lvm e quant'altro per avere più tempo per riscrivere gli interi script di init e tutto ciò che è collegato ad essi.

Conclusione: Bisogna attendere che nelle nuove versioni vengano inseriti gli initscript nuovi (Spero di aver capito per davvero come stanno le cose   :Very Happy:  )

----------

## lucapost

Notizie nuove http://roy.marples.name/node/466.

----------

## cloc3

 *lucapost wrote:*   

> Notizie nuove http://roy.marples.name/node/466.

 

praticamente un ritorno al futuro.

 *Quote:*   

> 
> 
>  I want to use dhclient with ifplugd/wpa_supplicant.
> 
>  You have two options here - keep on using the exiting network modules or script ifplugd/wpa_supplicant yourself.
> ...

 

se non capisco male, la morale è: visto che i tradizionali strumenti dhdlient + ifplugd/wpa_supplicant funzionano benissimo, non si capisce perché intestardirsi a fare cose complicate come Network Manager.

sono daccordo. io odio Network Manager, e fin che posso gli accrocchi di rete me li costruisco da solo che almeno so come li ho fatti.

detto altrimenti: usate Gentoo, perché sotto non ci sono c*****e.

----------

## lucapost

NetworkManager fa davvero caccare, pero' wicd non e' cosi' male...

io non utilizzo nessuno dei due, solo /etc/conf.d/net!

----------

## nomadsoul

 *Cazzantonio wrote:*   

> Non so... sono sempre stato dell'idea che la "smanettabilità" vada garantita sempre e comunque...
> 
> Se il sistema di init è in bash (o sh che sia) è relativamente semplice accederci e modificarlo, se è in C quantomento bisogna conoscere il C (e ancora potrebbe essere una faticaccia).
> 
> 

 

Perchè bash è una cosa innata?

----------

## cloc3

 *nomadsoul wrote:*   

> 
> 
> Perchè bash è una cosa innata?

 

certo. hai dubbi?

----------

## oRDeX

Forse non ho ben capito la situazione..Ma il fatto che la bash sia l'interprete dei comandi, quindi essenziale componente del SO per garantire il funzionamento nel suo complesso, perche` dovrebbe influire sul linguaggio in cui sono scritti altre componenti dell'SO stesso?

Anzi, openrc, quale componente critica (imho), e` giusto che venga scritta in un linguaggio tale per cui questa riesca a portare a termine i suoi compiti in modo efficiente.

mi sa che siamo un po` OT adesso.

----------

## cloc3

 *oRDeX wrote:*   

> 
> 
> mi sa che siamo un po` OT adesso.

 

più che altro, il quote di nomadsoul riprende un dibattito piuttosto datato,che risale a quando openrc era ancora un progetto in fieri.

il problema della trasparenza e della usabilità di openrc, tuttavia, non mi sembra nè datato nè fuori tema. le osservazioni linkate da lucapost riportano l'autocritica dell'autore su questo preciso argomento.

```

Here's some of the cons:

...

Hard to extend - only I really know how the network modules work

Has own dependency code separate to OpenRC

```

sono esattamente i problemi causati dall'abbandono della via maestra. L'efficenza del codice C implica complicazioni e sacrifici. Con ciò non che si debba tornare indietro, ma bisogna procedere con buon senso, curando l'integrazione nel sistema. Per questo mi piace la conclusione finale: pensare i moduli come interfacce verso elementi di basso livello collaudati, non come mastodonti ingombranti che buttano il preesistente per reinventare la ruota.

----------

## oRDeX

Eccoci quà!

```

[ebuild     U ] sys-apps/openrc-0.4.3 [0.4.2]

```

----------

## fbcyborg

Io l'ho aggiornato ma ogni volta all'avvio mi dice "Superblock last time write is in the future. FIXED" per ogni array di dischi raid.

----------

## lucapost

[semi OT]

http://roy.marples.name/projects/self/blog/2009/04/28

IMHO, stà facendo un ottimo lavoro.

Anche il prossimo futuro promette bene.

[/semi OT]

----------

## riverdragon

Sul mio sistema vedo che dhcpcd non è installato, quali programmi lo usano?

----------

## oRDeX

Ci sono altre alternative per quella componente, quindi è probabile che tu abbia una di quelle

----------

## riverdragon

Io ho net-misc/networkmanager che richiede net-misc/dhcdbd, e questo richiede net-misc/dhcp, nessuna possibilità di alternative.

EDIT: networkmanager-0.7 aggiunge dhcpcd tra le dipendenze.

----------

