# [HOWTO] Szybszy bootup systemu [baselayout-1.11.14-r6]

## mziab

Witam!

Dzisiejszego dnia eksperymentowałem nieco z różnymi patchami. W wyniku moich działań udało mi się skrócić o połowę (ok. 1 minuty -> 34 sekundy) czas startu mojego systemu. Pomyślałem więc, że podzielę z wami moim spostrzeżeniami. Zaczynajmy więc.

Na początek pozwolę sobie zauważyć, że poniższe patche nakładałem na baselayout-1.9.4-r6, najnowszą stabilną wersję. Wszystkie patche poniżej zawarte zostały stworzone przez Paula Pacheco. Ja tylko je przerobiłem, by się nakładały.

1) Prawdziwe równoległe uruchamianie usług

Tutaj przyda się nam patch, który znalazłem tutaj. Niestety, wersja, która rzekomo ma działać z używanym przeze mnie baselayoutem, zwyczajnie się nie nakłada. Spędziłem więc dłuższą chwilę na jej ręcznym aplikowaniu. Przy okazji usunąłem parę zbędnych komentarzy. Efekt mojej pracy dostaniecie tutaj. A poczytać o tym wynalazku i ściągnąć wersję dla nowszego baselayout możecie tu. Nie muszę chyba mówić, że patch najlepiej działa, gdy w /etc/conf.d/rc jest:

```
RC_PARALLEL_STARTUP="yes"
```

  :Smile: 

Patch nakładamy wpisując:

```
cd /

patch -p0 </sciezka/do/parallel-mziab.patch
```

Jedynym nieprzyjemnym efektem ubocznym było u mnie "nieczekanie" ntp-client i ddclient na połączenie się neostrady. Używam skryptu startowego /etc/init.d/adsl znalezionego kiedyś na http://gentoo.pl. Stąd pewnie problemy. W każdym razie, przerzuciłem te usługi do /etc/conf.d/local.start, żeby były uruchamiane odpowiednio później. Podejrzewam, że masywność przyśpieszenia na moim komputerze jest spowodowana przez to, że wcześniej synchronizacja neostrady zatrzymywała bootup na dobrych 20 sekund.

2) Szybsze uruchamianie xdm'a

"Bohaterem" tego podpunktu jest alternatywny skrypt startowy dla xdm'a o nazwie fastxdm. Ściągnięty z tego linka plik umieszczamy w /etc/init.d/fastxdm, a potem wywołujemy 

```
chmod +x /etc/init.d/fastxdm
```

. Potrzebna(?) jest też drobna zmiana w pliku /usr/X11R6/lib/X11/xdm/Xservers, gdzie do ścieżki Xservera dopisujemy argument vt7. Następnie każemy systemowi włączać fastxdm zamiast xdm'a:

```
rc-update del xdm

rc-update add fastxdm default
```

Dodatkowe wyjaśnienia tutaj.

Dzięki temu zabiegowi włącza się wcześniej, a nie na samym końcu, jak w standardowej konfiguracji. Słyszałem jednak, że w sporadycznych przypadkach mogą wystąpić problemy. Takowych u mnie nie stwierdziłem.

3) Inteligentniejsze odświeżanie zależności modułów

Jako, że odświeżanie zależności modułów za każdym uruchomieniem jest bezsensem, raczej można bezpiecznie zaoszczędzić tych kilka sekund. To oto rozwiązanie  jest najelegantszym, jakie widziałem. Jak zwykle, część patcha nie chciała się nakładać. Tym razem sprawa była dość prosta. Poprawiona wersja do ściągnięcia tutaj. Wersję dla nowszego baselayout znajdziecie w tym miejscu.

Na wszelki wypadek powiem, ze patch nakładamy w ten sposób:

```
cd /

patch -p0 </sciezka/do/modules-update.patch
```

4) Skrócenie czasu probe'owania IDE

Standardowe zachowanie kernela to probowanie bodajże 83 razy interfejsu IDE, z opóźnieniem 50ms za każdą próbą. Nowoczesne urządzenia nie wymagają tak długiego oczekiwania. Ten patch pozwala podać ile ma trwać oczekiwanie. Aplikujemy go na źródła:

```
cd /usr/src/linux

patch -p1 </sciezka/do/ide-delay-2.6.8-rc2.patch
```

.

Rekompilujemy kernel i dopisujemy:

```
ide-delay=x
```

w lilo.conf do append. Następnie należy uruchomić lilo.

U mnie wpis wygląda następująco:

```
append="ide-delay=2 video=vesafb-tng:ywrap,mtrr,1024x768-16@85"
```

Jak widzicie zmniejszyłem oczekiwanie do 2ms. Wynik? Wszystkie urządzenia są prawidłowo wykrywane, a system włącza się o jakieś 3-4 sekundy szybciej. Czysty zysk  :Smile:  Więcej o patchu możecie poczytać tu. Ściągniecie tam też inną jego wersję, która po prostu zmienia 50ms na 5ms. Moim zdaniem używana przeze mnie wersja jest lepsza, bo o ile nie podano bootloaderowi symbolu ide-delay, używana jest stara, bezpieczna wartość.

Mam nadzieję, że moje "wykopaliska" przydadzą się komuś. Enjoy  :Smile: 

Dla chcących zrobić wszystko "the Gentoo way":

* http://mziab.200.pl/gentoo/ebuild/

Zmodyfikowane ebuildy baselayout z nałożonymi patchami z pkt 1 i 3, dla najnowszych wersji z x86 i ~x86/~amd64 i amd64.

Uprasza się o testy  :Smile: 

Aby włączyć właściwą funkcjonalność, należy zastosować flagę speedup.

W planach:

- dodać patch przyśpieszający sprawdzanie environmentu

- punkt dotyczący readahead

P.S. Używać na własne ryzyko. U mnie działa całkiem zgrabnie, ale YMMV.

UPDATE 2005.04.10: Dodany punkt 4, instrukcje patchowania, ebuildy i poprawiony patch do modułów.

UPDATE 2005.04.12: Ebuild dla baselayout-1.11.10-r7

UPDATE 2005.04.13: Ebuild dla baselayout 1.9.4-r7 (amd64)

UPDATE 2005.04.21: Ebuild dla baselayout 1.11.11-r1 (~x86)

UPDATE 2005.04.27: Ebuild dla baselayout 1.11.11-r2 (~x86)

UPDATE 2005.04.29: Ebuild dla baselayout 1.11.11-r3 (~x86)

UPDATE 2005.05.17: Ebuild dla baselayout 1.11.12 (~x86)

UPDATE 2005.05.18: Ebuild dla baselayout 1.11.12-r1 (~x86)

UPDATE 2005.05.25: Ebuild dla baselayout 1.11.12-r2 (~x86)

UPDATE 2005.05.28: Ebuild dla baselayout 1.11.12-r4 (~x86)

UPDATE 2005.06.09: Ebuild dla baselayout 1.11.12-r4 (x86)

UPDATE 2005.07.23: Ebuild dla baselayout 1.11.13 (x86)

UPDATE 2005.08.25: Ebuild dla baselayout 1.11.13-r1 (x86)

UPDATE 2005.11.08: Ebuild dla baselayout 1.11.13-r2 (~x86)

UPDATE 2006.01.17: Ebuild dla baselayout 1.11.14 (x86)

UPDATE 2006.01.22: Ebuild dla baselayout 1.11.14-r2 (x86)

UPDATE 2006.01.27: Ebuild dla baselayout 1.11.14-r3 (x86)

UPDATE 2006.03.03: Ebuild dla baselayout 1.11.14-r6 (x86)

----------

## januzi

u mnie chodzi jak trzeba, okolo 25 sekund szybciej

dobra robota Michał

----------

## Dawid159

Odnośnie punktu 1  :Smile:  Czy w baselayout-1.11.10-r6 działa to już poprawnie czy nadal trzeba szukać patcha ?  :Very Happy: 

EDIT: Jeszcze taka mala uwaga  :Smile:  Skoro piszesz poradnik How-To to napisz jeszcze jak nakładać poszczególne patche  :Smile:  Niektórzy użytkownicy mogą mieć z tym problemy  :Wink: 

----------

## mziab

Najnowszy patch (z lutego) jest dla wersji 1.11.9-r1. Nie jestem w stanie potwierdzić jak jest z wymienioną przez Ciebie wersją, gdyż nie używam jej  :Smile: . Mógłbym rzucić okiem, gdybyś wysłał mi pliki, które zmienia patch.

----------

## Dawid159

Żaden problem  :Smile:  Jak nic nie pomylilem to pliki znajdują się tutaj

----------

## mziab

Sprawdziłem... Patch z mojego poprzedniego posta nakłada się na twoją wersję. Czy działa to już inne pytanie  :Smile: 

----------

## Dawid159

Hmmm

```
localhost / # patch -p0 < /home/dawid/OH/parallel-mziab.patch

patching file /sbin/depscan.sh

Hunk #1 succeeded at 13 (offset -2 lines).

patching file /sbin/rc

Hunk #1 succeeded at 429 (offset 76 lines).

Hunk #2 FAILED at 454.

1 out of 2 hunks FAILED -- saving rejects to file /sbin/rc.rej

patching file /sbin/runscript.sh

Hunk #1 FAILED at 268.

1 out of 1 hunk FAILED -- saving rejects to file /sbin/runscript.sh.rej

patching file /lib/rcscripts/sh/rc-services.sh

Hunk #1 FAILED at 397.

Hunk #3 succeeded at 692 (offset 37 lines).

1 out of 3 hunks FAILED -- saving rejects to file /lib/rcscripts/sh/rc-services.sh.rej

```

----------

## mziab

*khem* Patch z mojego poprzedniego posta, a nie z pierwszego w topicu. Ten.

Przy okazji, mógłbym prosić o twoje pliki, które patchuje modules-update.patch? Też sprawdziłbym jak się zachowuje  :Smile: 

Swoją drogą, przydałoby się zeorganizować HOWTO, żeby linki do patchy były wyraźnie wydzielone. I wyszczególnione który jest dla baselayout z x86 i ~x86.

----------

## Piecia

Odnośnie powyżeszego sprawdzaliście bootchart'a ?

----------

## mziab

Myślałem o tym, ale testów dokonywałem późnym wieczorem/nocą  :Smile:  Zastosowałem więc wypróbowaną metodę ze stoperem.

note to self: bootchart  :Smile: 

----------

## n0rbi666

mziab - zaaplikowalem ten patch na baselayout-1.11.10-r6, spatchowalo sie, i z tego co widze to rzeczywiscie szybciej sie uruchamia przy starcie systemu (albo to tylko moje odczucie  :Razz:  ) za chwile sprawdzam dalej co tam wykombinowales  :Smile: 

----------

## arsen

hmm, co do punktu 1 i 3.....jakbyś mogł zrobić ebuilda i patche które wymieniłeś dla baselayout dodać za pomocą epatch......było by prościej i czytelniej dla userów i zgodnie z gentoo  :Smile:  oczywiście wtedy też dokonaj odpowiednich zmian w tekscie. Dokonaj tych zmian i twoje howto wyląduje do wątka z innymi howtami  :Wink: 

----------

## rampage7

gdyby zrobić te ebuildy i np. do love-source włączyć ten patch ide bym nie musiał kombinować jeszcze z patchowaneim kernela to bym się skusił. Narazie moja wiedza mi nie pozwala na to, by przebrnąć przez to howto bezboleśnie  :Smile: 

januzi - miło Cię widzieć również na gentoo forums  :Smile: 

----------

## mziab

arsen: W porządku, rozwiązanie mi się podoba. Chciałem tak zrobić. Jest jednak pewien zasadniczy problem. Istnieje masa różnych wersji baselayout. Utworzenie patchy i ebuildów dla każdej wersji jest z lekka bezsensowne. Sensowniej byłoby chyba walczyć, żeby takie tweaki weszły do oficjalnego baselayout.

----------

## arsen

 *mziab wrote:*   

> arsen: W porządku, rozwiązanie mi się podoba. Chciałem tak zrobić. Jest jednak pewien zasadniczy problem. Istnieje masa różnych wersji baselayout. Utworzenie patchy i ebuildów dla każdej wersji jest z lekka bezsensowne. Sensowniej byłoby chyba walczyć, żeby takie tweaki weszły do oficjalnego baselayout.

 

tylko że wątpie że patche te będą się nakładały na inne wersje baselayout niż tą wersję na którą zostało to napisane.

Ty wspominałeś o wersji 1.9.4-r6, myślę że tego się można trzymać jeśli to działa (a działa bo to przetestowałeś) najwyżej podaj tylko linki do patchy by userzy bardziej zaawansowani mogli sobie to sami ponakładać/poprzerabiać na inne wersje baselayout  :Wink: 

----------

## mziab

Mam doskonały pomysł - dwa ebuildy: jeden dla najnowszego w x86, a drugi dla najnowszego w ~x86. Sądzę, że to salomonowe rozwiązanie. Dziś wieczorem postaram się stworzyć te dwa ebuildy.

Planuję też dopisać jeden nowy podpunkt o readahead, choć po prawdzie mi nie dało to żadnego przyśpieszenia. Są chętni do testowania?  :Smile: 

----------

## n0rbi666

mziab - moge testowac, tylko co readahead ma dac? :> tez szybszy bootup czy moze wogole przyspieszy troche system ? ;]

----------

## arsen

 *mziab wrote:*   

> Mam doskonały pomysł - dwa ebuildy: jeden dla najnowszego w x86, a drugi dla najnowszego w ~x86. Sądzę, że to salomonowe rozwiązanie. Dziś wieczorem postaram się stworzyć te dwa ebuildy......
> 
> 

 

no i brawo, bardzo dobry pomysł  :Smile: , zatem powodzenia  :Wink: 

----------

## quat

spaczowalem wersje baselayout-u 1.11.10-r6 i nie bylo problemow (nie liczac malych przesuniec). czyli patche nakladaja sie gladko. mowie o paczach z bugs.gentoo.org do ktorych odnosniki podales mziab

wrazenia? hmm nie wiem czy jest ogromna roznica. szczerze mowiac to dla mnie jest ona rzedu 3 do 4 sekund. ogolnie system uruchamia mi sie w ok 20 sek. (w zaleznosci gdzie jestem w domu bo wifi nie wszedzie jednakowo odbiera  :Wink:  )

nie uzywam zadnego gdm/xdm/fastxdm czy innego uruchamiacza x-ow.

poza tym zauwazylem ze zaczal robic mala pauze na zaleznoscia modulow. dziwne.

----------

## lazy_bum

27 sekund > 20 sekund.

Zastosowałem tylko 1 i 3. Zastanawiam się tylko na co mi to.... (-: .. z drugiej strony wiem, że nie każde Gentoo stoi na szybkiej maszynie.

----------

## mziab

Za wskazówką arsena dodałem ebuildy dla najnowszych wersji w x86 i ~x86. Jestem otwarty na konstruktywną krytykę i liczę na testy  :Smile:  Na dniach dodam jeszcze jeden patch i być może dopiszę podpunkt o readahead, jeśli będą chętni. I z tego miejsca chciałbym zadać pytanie - kompiluje się komuś readahead-list z portage? Mi nie bardzo  :Sad:  Musiałem zastosować inną implementację.

----------

## Miszczu

Czesc, na poczatku chcialem sie przywitac, jestem nowy, mam gentoo od 2-3 dni i spodobal mi sie, wiec raczej troszke tu zabawie  :Very Happy: 

Niestety mam maly problem, spaczowalem wszystko oprocz xdm, ale patch nie chcial sie nalozyc na baselayout 1.11.10-r6, probowalem zarowno tego przerobionego przez mziaba jak i dostepnego na bug.gentoo.org. Przy starcie systemu pokazuje sie mnostwo komuniaktow o tresci

[code]/lib/rescripts/sh/rc-servicess.sh: line 472: /var/lib/init.d/exitocodes/vixie-cron: No such file or direcotry[/cody]

komunikaty sa identyczne, roznia sie tylko numerem lini, co z tym zrobic ?

----------

## quat

 *Miszczu wrote:*   

> Niestety mam maly problem, spaczowalem wszystko oprocz xdm, ale patch nie chcial sie nalozyc na baselayout 1.11.10-r6, 

 jak pisalem wyzej ja nalozylem na ten baselayout bez problemow patche z bugs.gentoo.org. moze sprobuj je jeszcze raz? nie wiem co moglo sie stac.

ja mialem jedynie kilka przesuniec, ale pacz nalozyl sie bez problemow nie mam bledow.

----------

## mziab

Miszczu: Musiałeś wziąć złą wersję patcha albo grzebałeś coś w skryptach. Najlepiej użyj ebuilda, który zrobiłem. Powinno być łatwiej  :Smile:  A poza tym dziś wyszedł baselayout-1.11.10-r7, nowy ebuild tutaj.

----------

## melk0r

swietna robota! system uruchamia sie zauwazalnie szybciej, nie mierzylem z zegarkiem w reku, ale gdzies ok 10 sekund mniej mu to zabiera, jeszcze raz dzieki za ebuilda!  :Smile: 

----------

## ai

mziab, wlasnie jak skonczylem emergowac r6 to zobaczylem Twojego posta o baselayoucie r7 [; 

za emergowalem to readahead-list i rc-update add readahead-list boot i dziala, cos jeszcze chcesz wiedziec o tym?

----------

## mziab

ai: Uzyskałeś jakiekolwiek przyśpieszenie dzięki readahead? Miałeś problem z circular dependencies?

n0rbi666: Teoretycznie szybsze wczytywanie się systemu. Używa tego bodajże Fedora.

Wczoraj doszedłem do konkluzji, że implementacja readahead, którą można zainstalować z portage, można skompilować, jeśli nałoży się prosty patch na linuxheaders i dopisze jedną linię do w kodzie programu. Niestety, skrypty powodują circular dependencies. Druga implementacja jest ponoć mniej optymalna, ale działa. Znalazłem ją na bugs.gentoo.org. W każdym razie, ani z jedną ani z drugą nie doświadczyłem przyśpieszenia. Być może preloadowałem złe pliki albo za późno. Tworzyłem własne listy plików do preloadowania, lecz to nie pomogło.

Do chcących testować readahead (ten wymienionego wyżej buga albo readahead-list z portage):

Listę plików do wczytania w runlevelu boot można sporządzić w następujący sposób (wymaga strace):

1) Ściągamy te dwa skrypty: grab-open.sh i boot.sh

2) Ściągamy wymagany plik z filtrem.

3) Uruchamiamy boot.sh przekierowując wyjście do pliku.

4) Przydałoby się zostawić tylko linie, które są nazwami plików.

```
 a=$(<readahead.early.files ); echo "$a" |xargs ls -1 2>/dev/null  > readahead.early.files
```

5) Można się pokusić o usunięcie duplikatów:

```
sort readahead.early.files | uniq >nowa_lista
```

Z kolei listę plików do wczytania w default najlepiej wygenerować skryptem pythona (wymaga lsof). Najlepiej włączyć go po świeżym zalogowaniu do systemu, by uniknąć dodawania zbędnych plików do listy.

By readahead-list z portage się kompilował musiałem nałożyć ten patch na moje linuxheaders (używam wersji 2.6.8.1-r4). W samym programie brakuje jednego include.

Dlatego otwieramy plik filelist-order.cxx i dopisujemy gdzieś bliżej początku:

```
#include <assert.h>
```

Szczerze mówiąc, sądzę, że druga implementacja sprawia same kłopoty i nie warto jej używać  :Smile:  Wersja z bugs.gentoo.org kompiluje się bez żadnych cudacznych patchy na linux-headers i poprawiania kodu. Aby z jej właśnie skorzystać, należy pobrać skrypty init: readahead_early i readahead. Następnie sporządzone listy należy wrzucić odpowiednio do /etc/readahead.early.files i /etc/readahead.files.

Uff, mam nadzieję, że rozjaśniłem parę kwestii dotyczących readhead. Bardzo chętnie odpowiem na pytania, gdyby były jakieś kłopoty. Jeśli znajdą się chętni, zrobię odpowiednie ebuildy i dołączę do HOWTO.

----------

## ai

podczas bylejakiej kompilacji, pod koniec mam cos takiego :

```
>>> Regenerating /etc/ld.so.cache...

 * Caching service dependencies ...

 *  Services 'checkroot' and 'readahead-list' have circular

 *  dependency of type 'ibefore';  continuing...                          [ ok ]

```

szczerze mowiac, to tego nie rozumiem

----------

## mziab

 *ai wrote:*   

> podczas bylejakiej kompilacji, pod koniec mam cos takiego :
> 
> ```
> >>> Regenerating /etc/ld.so.cache...
> 
> ...

 

To jeden z powodów mojej nienawiści do tej wersji skryptu  :Smile:  Po prostu zarówno checkroot i readahead-list mają w zależnościach:

```
before *
```

Gdyż w zamierzeniu oba powinny być wczytywane przed wszystkimi innymi skryptami. Prostym obejściem jest zamienienie tej linii w readahead-list na:

```
need checkroot
```

Nie jest to jednak zbyt dobre rozwiązanie, gdyż w praktyce nieco za bardzo opóźnia readahead. Może ktoś ma pomysł jak to inaczej rozwiązać?  :Smile: 

----------

## n0rbi666

oki, 2 pytanka 

czy jak wczesniej mialem baselayout r6 spatchowane modules-update.patch, a teraz zrobilem ebuilda z r7 z USE="speedup" , to czy musze jeszcze raz patchowac tym patchem na moduly? 

i czy patch na jaderko w celu skroceina probkowania ide bedzie smigal z kernelem 2.6.11 ? ew 2.6.12 ?  :Wink: 

----------

## mziab

 *n0rbi666 wrote:*   

> oki, 2 pytanka 
> 
> czy jak wczesniej mialem baselayout r6 spatchowane modules-update.patch, a teraz zrobilem ebuilda z r7 z USE="speedup" , to czy musze jeszcze raz patchowac tym patchem na moduly? 
> 
> i czy patch na jaderko w celu skroceina probkowania ide bedzie smigal z kernelem 2.6.11 ? ew 2.6.12 ? 

 

Przecież głównym feature'em tego ebuilda jest właśnie patchowanie  :Smile:  Wniosek: Nie ma potrzeby, patche z pkt 1 i 3 zostaną nałożone automatycznie, jeśli zrobisz emerge wersji r7, używając mojego ebuilda.

A patch na kernel powinien działać bez problemów. Ja sprawdzałem na 2.6.10. To mimo wszystko prosty patch, więc w razie czego można nawet samemu nanieść niezbędne zmiany.

----------

## pwe

@mziab a z a64 działa to? jak dopisze do ebuildów ~amd64 ?

dzieki

----------

## mziab

 *pwe wrote:*   

> @mziab a z a64 działa to? jak dopisze do ebuildów ~amd64 ?
> 
> dzieki

 

pwe: W 1.11.10-r7 nie trzeba nawet nic zmieniać, w keywords ma ~amd64. Postaram się jeszcze dodać ebuild dla 1.9.4-r7, który jest dostępny tylko dla arch amd64. Proszę o chwilę cierpliwości  :Smile: 

Update: Ebuild dla wersji 1.9.4-r7 dla arch amd64 dostępny tutaj

----------

## OBenY

Wow, fajne to - z 50 sekund na 31  :Smile:  To jest to  :Smile: 

----------

## n0rbi666

u mnie spatchowalem wlasnie kernela 2.6.11, nie spatchowal sie tylko ide.txt  :Wink: 

a zysk:

uruchamianie systemu

standart : 27 sekund

baselayout + speedup - 24

patch na kernela (ide-delay=5)- 20 sekund

niezle niezle  :Smile: 

----------

## pwe

mam takie pytanko może sie dziwne wydac ale  :Smile: 

Od którego momentu liczycie czas? od gruba? od power on? i do kiedy? do końca boota czy móze do pulpitu?  :Smile:  ciekawy jestem:)

----------

## mziab

Ja liczyłem od wybrania kernela w lilo do pojawienia się logowania w xdm.

----------

## pwe

aha to ja mam 30sek. pobawic sie pobawie ale dopiero w weekend. Teraz nauka i w wolnych chwilach samba.

----------

## n0rbi666

ja licze od : wybor kernela w lilo do pojawienia sie login na konsoli (nie uzywam xdm)

----------

## pwe

 *n0rbi666 wrote:*   

> ja licze od : wybor kernela w lilo do pojawienia sie login na konsoli (nie uzywam xdm)

 

ja również i powiem Ci ze ta lubie  :Smile: 

----------

## skiera

Zapodałem tego ebuilda do baselayout 1.11.10-r7 i zmienilem skrypcik z xdm na xdmfast, rzeczywiście widać przyspieszenie startu systemu. Jest radość. Dzięki mziab.

----------

## damjanek

pytanko: idzie jakos opoznic przelaczanie z tty8, na 7, az do wybranego przeze mnie momentu ? (mowie o fastxdm, bo przelacza mi to bardzo wczesnie, a mnie sie to nie podoba)

----------

## Zwierzak

Ja narazie jestem w stanie tego instalowania ale za chwile wsystko powinno się zkończyć i wtedy zobacze jak polepszy się start mojego systemu  :Smile: 

EDIT:

LOL, gratulacje to działa, start mojego systemu trwa teraz ok 23 sec do uruchomienia x'ów, a same x'y się uruchamiaja ok 3 sec

----------

## grzewho

działa. u mnie szybciej o jakies 4-5 sekund.

czy jest szansa, że łata ide trafi to jakiegoś jądra typu love czy nitro ? @fallow ?  :Smile: 

aha, podpisuje sie pod dodaniem readahead do howto

----------

## mziab

Dzisiejszego pięknego dzionka wyszedł nowy baselayout, a nawet dwie wersje - 1.11.11 i 1.11.11-r1. W związku z tym fanów ~x86 zapraszam po ebuild

Jeśli zaś chodzi o readahead, postaram się w najbliższym czasie dopisać stosowny podpunkt do HOWTO. Byłbym bardziej umotywowany, gdybym wiedział, że komuś to faktycznie przyśpieszyło system  :Smile: 

grzewho: Z tym pytanie to nie do mnie, tylko do odpowiednich osobistości  :Smile:  Myślę łata miałaby spore szanse na dołączenie, szczególnie, że jest raczej bezpieczna w użyciu.

----------

## sekretarz

Polecam też 2 linki z bugsow: https://bugs.gentoo.org/show_bug.cgi?id=69579 i https://bugs.gentoo.org/show_bug.cgi?id=64724.

----------

## Zwierzak

Jak miło, nowa paczka straciła 2kB na rozmiarze. Juz instaluje.

BTW. dzieki za odwalanie trak dobrej roboty, bez tego HowTo nigdy by mi sie nie udalo tak przyspieszyc startu mojego linuksa  :Wink: 

BTW2. A może by tak napisac na www.gentoo-wiki.com ?

----------

## ai

 *sekretarz wrote:*   

> Polecam też 2 linki z bugsow: https://bugs.gentoo.org/show_bug.cgi?id=69579 i https://bugs.gentoo.org/show_bug.cgi?id=64724.

 

to widac, ze sie ostro za to wzieli  :Smile:  Fajnie [;

----------

## mziab

Nowy dzień, nowy baselayout (1.11.11-r2). Do ściągnięcia w stałym miejscu.

----------

## OBenY

Moze lepiejby bylo (bardziej Gentoowsko) nazwac flage speedup inaczej - offensive - zgodnie z globalnymi use... Co Wy na to, taki maly zabieg  :Smile: 

----------

## mziab

Obawiam się, że z offensive chodzi o coś innego, konkretnie o treści, które mogą godzić w czyjeś uczucia. Nie sądzę więc, żeby zmienianie nazwy flagi miało jakikolwiek sens. Co innego, gdyby była globalna flaga o nazwie experimental czy też unstable.

UPDATE: baselayout ver++ -> baselayout_speedup ver++  :Smile:  nuff' said

----------

## keman

Super, własnie zainstalowałem Twój baselayout, i z 34sek, szedłem do 18  :Smile: 

A dodam, ze mam dośc sporo rzeczy, jak vmware, cups, i sporo modułów do załadowania  :Smile: 

Zaraz zaisntaluje jeszcze na P2 w garażu  :Very Happy: 

Szkoda tylko, że Twojego baselayutu, niema w Portage, bowiem troche utrudnia to robienie emerge -uDv world....

I moja mała sugetsia, a nawet dwie, IMHO w nazwie topicu, mógłbyś pisać jaka jest aktualna wersja Twojego baselayountu, zawsze było by wogodniej sprawdzić czy ukazała się nowa, bez konieczności wchodzenia do topicu.

Pozdrawiam, waluigi

----------

## Belliash

 *keman wrote:*   

> Super, własnie zainstalowałem Twój baselayout, i z 34sek, szedłem do 18 
> 
> A dodam, ze mam dośc sporo rzeczy, jak vmware, cups, i sporo modułów do załadowania 
> 
> Zaraz zaisntaluje jeszcze na P2 w garażu 
> ...

 

Zamaskuj se baselayout to nie bedzie go upgrade'owalo  :Wink: .

----------

## n0rbi666

https://forums.gentoo.org/viewtopic-t-331844-postdays-0-postorder-asc-start-0.html -> to chyba nawet na temat, bawcie sie, ja probowalem i z ~22 sekund zjechalo do ~15, ale jeszcze jakies bledy mialem i musze jeszcze sie temu dokladniej pzrygladnac  :Cool: 

----------

## mziab

Pozwolę sobie wspomnieć o odkryciu, którego dokonałem tutaj. Chodzi konkretnie o readhead z Ubuntu. O ile readahead.c prawie niczym się nie różni od tego, który wcześnie pokazywałem, archiwum posiada plik fileordering.c, który ponoć służy do układania plików w optymalny sposób na dysku. Prawdę mówiąc, jeszcze nie testowałem na sobie. Ktoś mógłby rzucić okiem na kod i powiedzieć czy program jest bezpieczny?

----------

## mziab

*bump*

Dzisiaj wydano nową wersję baselayout - 1.11.12. Zapraszam do ściągnięcia nowego baselayout_speedup.

----------

## pwe

nie wykluczone ze to moja wina ale przy tym najnowszym baselayoucie mam

```
>>> md5 files   ;-) files/modules-update-1.9.4.patch

>>> md5 files   ;-) files/digest-baselayout-1.9.4-r7

>>> md5 src_uri ;-) rc-scripts-1.6.12.tar.bz2

/usr/lib/portage/bin/ebuild.sh: line 1686: /usr/local/portage/sys-apps/baselayout/baselayout-1.11.12.ebuild: Permission denied

```

mam standardowy teraz z portage 

```
sys-apps/baselayout

      Latest version available: 1.11.12

      Latest version installed: 1.11.12

```

----------

## bacouch

Chyba twoja bo u mnie wszytko ladnie dziala. A na pewno robisz to z pod roota ?

----------

## pwe

 *bacouch wrote:*   

> A na pewno robisz to z pod roota ?

  hehe tak  :Wink: 

----------

## mziab

pwe: Spróbuj teraz, zmieniłem uprawnienia plików.

----------

## pwe

mziab to samo :/ ciekawe co robie nie tak, bo to wychodzi moja wina skoro inym dziala

----------

## mziab

Może spróbuj wyrzucić wszystko oprócz samego ebuilda i patchy, a potem sam zrób digest.

----------

## pwe

juz robilem, digest, pozniej merge itp i nic.

----------

## OBenY

mi dziala, wiec masz cos skopane, pwe.

----------

## mziab

Devowie nie spoczęli na laurach. Dziś uraczyli nas nową wersją baselayout - 1.11.12-r1. Przygotowałem nowy baselayout_speedup.

----------

## bacouch

Ze tak spytam, czy przy tej wersji dziala glx nvidii?

----------

## pwe

 *bacouch wrote:*   

> Ze tak spytam, czy przy tej wersji dziala glx nvidii?

 

hehehe ja poczekam troche zanim odmaskuje  :Very Happy:  a mziaba nie dziala mi :/

----------

## mziab

 *pwe wrote:*   

> hehehe ja poczekam troche zanim odmaskuje  a mziaba nie dziala mi :/

 

Pozwolę sobie zadać jedno podstawowe pytanie. Inne ebuildy z overlaya działają?

----------

## pwe

hmmm chyba nie!  :Very Happy:  jaja sobie robie, dzialaja dzialaja, kadu, kernele mam, i jeszcze ze dwie rzeczy

ps to nowke sprobuje wieczorem, teraz na gentoo nie jestem a ściagam cos ważnego wiec nie moge (AAv2.4)

----------

## bacouch

 *bacouch wrote:*   

> Ze tak spytam, czy przy tej wersji dziala glx nvidii?

 Jezeli ktos chce wiedziec to wlasnie sprawdzilem i nie dziala.

----------

## univac^

Właśnie, mi się też X'y się nie uruchamiają, Server Aborted  :Smile: 

----------

## keman

Hmmm, a dlaczego glx niedziałą ?

Bo własnie przesiadłem się na najnowszą wersje, mziab'owego ebuilsa, i niestety iksy niestartuje  :Sad: 

Pozdrawiam, waluigi

----------

## mziab

O ile mi wiadomo błąd występuje także w "czystej" wersji baselayout. Ktoś mógłby to potwierdzić?

----------

## univac^

Mi na czystej działa

----------

## mziab

Hmm, mógłbym zobaczyć lsmod spod "czystego" baselayout i spod mojego? Mam wrażenie, że z jakiegoś powodu nie jest wczytywany moduł nvidia.

----------

## pwe

coś mi tu smierdzi :/ ja dziśiejszego baselayota nie sprawdzalem (brak czasu) ale wczorajsza mi nie dzialala, wiec i dziś bedzie tak samo pewnie. to w taki razie co devovie poprawili od wczoraj? ładniej się "nie uruchamia" ?  :Wink:   :Wink: 

----------

## univac^

u mnie na świeżym baselayoucie i Twoim nvidia ładuje sie wraz z startx...

----------

## mziab

Będzie trzeba się temu dokładniej przyjrzeć. Tymczasem spróbujmy w taki sposób: spróbuj wyłączać patche w moim ebuildzie, zakomentowując epatch. Istnieje szansa, że jeden z nich jest winowajcą.

----------

## wuja

Hmmm....nie zdążyłem z Twojego, właśnie wróciłem z Twojego na czysty - nie działały X-y a nie chcę OpenGl z X.org

```
wojtek@KQ ~ $ lsmod

Module                  Size  Used by

snd_pcm_oss            50592  0

snd_mixer_oss          18048  2 snd_pcm_oss

usbcore               106552  1

nvidia               3916092  12

snd_intel8x0           29312  1

snd_ac97_codec         74616  1 snd_intel8x0

snd_pcm                85896  3 snd_pcm_oss,snd_intel8x0,snd_ac97_codec

snd_timer              22660  1 snd_pcm

snd                    49124  6 snd_pcm_oss,snd_mixer_oss,snd_intel8x0,snd_ac97_codec,snd_pcm,snd_timer

snd_page_alloc          7556  2 snd_intel8x0,snd_pcm
```

Aha, na wczorajszym czystym też glx nie działalo a Twojego nie sprawdzałem - nie zdążyłem:D

----------

## univac^

Hmm skompilowałem bez jednego patcha potem bez drugiego ale to samo, X'y nie startują na vanilli jest ok.

----------

## bacouch

Mam rozwiazanie: plik /sbin/rc, linia 263 zamienic

```
 -o noexec...
```

na 

```
 -o exec
```

 i wszystko ladnie smiga nawet z patchami mziaba.

----------

## keman

 *univac^ wrote:*   

> Hmm skompilowałem bez jednego patcha potem bez drugiego ale to samo, X'y nie startują na vanilli jest ok.

 

A u mnie i na  vanilli iksy niewstają.

Początkowo, zrekompilowałem nawet jajko, i nvidie, ale nic...

Pozdrawiam, waluigi

----------

## univac^

U mnie też już wszystko ładnie śmiga.  :Smile: 

----------

## mziab

Zaktualizowałem tarball. Jakimś cudem opuściłem jednego patcha z oryginalnej wersji  :Embarassed:  W każdym razie, teraz powinno być dobrze  :Smile: 

----------

## bacouch

Mziab w swoim najnowszym ebuildzie zapomniales umiescic 

```
<    # Mount /dev with -o exec #92921

<    epatch "${FILESDIR}"/${P}-exec-dev.patch

< 

```

tak by wszystko ladnie dzialalo bez naprawiania recznie  :Smile:  .

----------

## karaluch

Dobra wszystko ok - widze ze wszyscy sa zadowoleni ale ....

... co ze stabilnoscia?

W moim przypadku na gentoo stawiam serwer, Athlon 1.2GHz 256SDRAM fajnie jaby po restarcie wstawal szybciej ale martwie sie ze przez to moge zmniejszyc jego stabilnosc, czy kiedys mieliscie jakies problemy po zastosowaniu tych skryptow? czy musieliscie cos naprawiac? Moj serwer ma chodzic bezawaryjnie jak mnie nie bedzie, co najwyzej z rebootami to miesiac/dwa i taram sie zrobic go tak abym nie musial ingerowac w serwerze za granicy.

Czy moze ktos odpowiedziec na moje pytanie, czy wogole jest sens stosowac te skrypty w tym przypadku? Pozdro

----------

## mziab

karaluch: Dwie sprawy... Po pierwsze, włączają się te same procesy, tylko trochę szybciej. Nie widzę powodu, dla którego miałyby się inaczej zachowywać. Jest to zdecydowanie bardziej bezpieczne niż zachwalany przez wielu initng, gdzie prawie na pewno coś się sypnie. Mogę ze spokojnym sumieniem każdemu polecić tę zmodyfikowaną wersję baselayout.

I druga sprawa, na serwerach nie ma to po prostu sensu. Powiem ogólniej, nie ma to sensu na maszynach, które mają być cały czas włączone i rzadko rebootowane. Załóżmy, że nawet oszczędziłbyś minutę na starcie systemu, a restartujesz co miesiąc. W ciągu roku oszczędzisz całych 12 minut  :Smile:  Myślę, że nie opłaca się w ogóle grzebać. Co innego, jeśli tak jak ja, używałbyś komputera w zastosowaniach domowych. Restartuję komputer przynajmniej raz dziennie i nierzadko w sporym pośpiechu (chcąc posłuchać muzyki tuż przed wyjściem na zajęcia  :Smile: ), więc w moim przypadku ma to spore znaczenie. U mnie te pół minuty, które oszczędzam przekłada się, matematycznie rzecz biorąc, na kilka ładnych godzin rocznie.

Podsumowując, jeśli chcesz, możesz użyć tego ebuilda. Nie powinien mieć żadnego wpływu na stabilność systemu. W tych zastosowaniach mom skromnym zdaniem nie liczy się szybkość startu. Póki system nie włącza się dłużej niż kwadrans, da się wszystko znieść  :Smile: 

----------

## OBenY

Ja rowniez nie doswiadczylem najmniejszych problemow z baselayoutem mziaba, lecz na maszynach produkcyjnych nie odwazylbym sie go dawac, nie to, ze nie ufam Mziabowi, czy cos z tych rzeczy, tylko ze zbyt mi zalezy na tym by system byl maksymalnie mozliwie 'generic' oraz dobrze przetestowany. Pozatym na maszynach serverowych wisi mi czy system sie uruchamia mitute czy dwie, bo i tak staram sie z uptime nie schodzic ponizej 50 dni  :Smile:  Chyba ze kernel sie dzirawy robi oraz jakis element systemu pilnie potrzebuje updata - np. glibc.

Karaluch, pozatym ciekawy pomysl - stawianie servera na AMD  :Smile:  Zycze powodzenia, nie tyle ze nie lubie AMD, ile nigdy nie sprawdzilo sie w warunkach wymagajacych IDEALNEJ stabilnosci, nie udalo mi sie na AMD uzyskac uptima przebijacego 30 dni, chyba, ze na zanizonym taktowaniu, czy jakims wzmocnionym chlodzeniu  :Smile:  Na Intelach po prostu maszyny dzialaja bezawaryjnie. Tak czy siak, powodzenia.

Cos czuje, ze flamewar'a wywolalem... oby nie  :Razz: 

----------

## mziab

Nowy dzień, nowa wersja.

----------

## OBenY

swietna robota mziab, tak trzymaj, bardzo mi sie to podoba  :Smile: 

----------

## AcidWeb

Bardzo fajny speedup :> Oby tak dalej...

----------

## arach

a ja jestem ciekawy jak wyglada szybkosc tego wobec initng.  :Twisted Evil: 

ps.

mi initng sie nie sypie (chociaz musialem zmodyfikowac skrypt od gpm'a bo zostal napisany w sposob zakladajacy ze obsluga myski jest na static w jajku a ja mam w modulach wszystko co nie jest niezbedne do uruchomienia systemu :> )

----------

## OBenY

Initng rozwala predkosciowo to, co zrobil mziab niemalze dwu-, czy nawet trzy-krotnie, ale mnie osobiscie bardziej podoba sie, zwykly baselayout polatany przez mziaba - przynajmniej dziala niezawodnie a daje tez niezlego speedupa  :Smile:  Initng za czasow 0.0.7rev89 nie nadawal sie do uzywania, system sie nie zawsze restartowal, wylaczal, potrafil bez powodu sie zawiesic w czasie bootowania.

----------

## mziab

Ech, ledwo człowieka nie ma niecałe 2 dni przy pececie, a wydają dwie nowe wersje baselayout  :Smile:  Zapraszam do ściągnięcia baselayout-1.11.12-r4.

----------

## mziab

*BUMP* Dzisiaj wersja 1.11.12-r4 stała się wersją stabilną. Przy okazji dodano jeden nowy patch. Po nowy baselayout_speedup zapraszam tutaj.

----------

## keman

Niestety, ale patch pozwalajacy dostosowac ide-deley nie działa z 2.6.12 (przynajmniej z nitro-sources), a z tego co widziałem, w tworzonym przez fallowa,  love-sources, patch ten się znajduje.

Skąd więc wytrzasnąć ten patch, na 2.6.12  :Question: 

Pozdrawiam, waluigi

----------

## n0rbi666

nakladal ktos latke na baselayout na 1.12.0_pre1-r1 ? z 1.11.13 sie udalo, ale tutaj sie boje ryzykowac  :Mr. Green: 

poczekam do jutra - jak nikt nie odpowie, to sam sprawdze  :Cool: 

----------

## mziab

Wróciłem z wyjazdu i już zuploadowałem nowy ebuild. Znajdziecie go tutaj, jak zwykle zresztą. Sorry for the delay  :Smile: 

Z tego co mi wiadomo, oba patche są już nałożone w 1.12.0_pre1-r1, w nieco rozbudowanych wersjach. Dowody: tutaj i tutaj. Wraz z ustabilizowaniem się 1.12.0 baselayout_speedup stanie się więc niepotrzebny.

Z kolei, jeśli chodzi o ide-delay.patch, sam nakładałem go wspomagając się wiggle. Widzę jednak,  że martin.k przystosował patcha do nowszej wersji kernela. Można go pobrać stąd. Gdy będę miał chwilę wolnego czasu zrobię porządek w tym topicu.

----------

## keman

Ja niestety nie moge używać tego baselayoutu, z powodu dooblowania sie uslugi starting eth0 , ktora czasami powoduje błędy  :Confused: 

Straszna szkoda, bo ten baselayout znacząco przyspieszał bootup  :Sad: 

 Może jest jakieś rozwiązanie tego problemy  :Question: 

Pozdrawiam, waluigi

----------

## Piecia

Witam

Może coś przegapiłem, to z góry wybaczcie.

Jako że na swoim serverze udostępniam /usr/portage i /usr/local/portage innemu komputerowi, wyszedł pewien problem. W jaki sposób na serwerze przekazać emerge by instalował baselayout z /usr/portage a nie jak to robi domyślnie z /usr/local/prtage?

Jeszcze jakiś czas temu emerge ignorował /usr/local/portage pomimo ustawionej PORTDIR_OVERLAY="/usr/local/portage", ale teraz już działa normalnie.

----------

## wuja

 *keman wrote:*   

> Ja niestety nie moge używać tego baselayoutu, z powodu dooblowania sie uslugi starting eth0...

 No właśnie mi się też to zdarza, ale co dziwne nie zawsze (na oko ~60% startów), natomiast zawsze chce dublować urandom.

----------

## Belliash

Zrob lepiej latke dla baselayout v1.12.0_pre3-r2  :Wink: 

Przydalaby sie, zwlaszcza mi  :Razz: .

----------

## mziab

Pozwolę sobie zacytować to, co wcześniej pisałem:

 *mziab wrote:*   

> Z tego co mi wiadomo, oba patche są już nałożone w 1.12.0_pre1-r1, w nieco rozbudowanych wersjach. [...] Wraz z ustabilizowaniem się 1.12.0 baselayout_speedup stanie się więc niepotrzebny.

 

Mówiąc krótko, moja łatka nie jest ci już potrzebna.

----------

## mziab

*bump* Przygotowałem ebuild dla wersji 1.11.13-r1. Znajdziecie go, jak się można domyślić, tutaj.

----------

## mziab

*bump* Po długim czasie bezczynności nareszcie jakieś zmiany w gałęzi 1.11.X  :Smile:  Ebuild dla wersji 1.11.13-r2 (~x86) jest już gotowy i dostępny tam, gdzie zwykle.

----------

## C1REX

Taki mały OT.

Testowałem u siebie initng i trochę mnie zaskoczyło. Od wybrania w grubie do logowania (bez Xów), system wstaje poniżej 10sec. 

Jeszcze nie jest idealnie działający (np. można zapomnieć o działającym fbsplash), ale jeszcze niedawno wcale tego nie dało się używać.

http://www.opensuse.org/SUPER

Jest to SuSE nastawione na szybkość. Trochę zaskakujące jest to, ze w planach mają np. wprowadzenie omawianego initng. A to tylko jedna z wielu rzeczy, jakie mają być zastosowane, by przyspieszyć susła.  Robi się ciekawie : )

Mam nadzieję, że initng jak najszybciej będzie w pełni używalny. Może doświadczenia developerów SUPER w tym pomogą? Oby : )

----------

## naresh

Nie orientujecie sie czy baselayout-1.12.0-pre10 ma tego patcha juz, czy tez musze sie z tym bawic? Przy okazji nie zadzialal mi patch ide-delay. Oto co mu zapisal

 */usr/src/linux/driver/ide/ide.c.rej wrote:*   

> 
> 
> ***************
> 
> *** 196,201 ****
> ...

 

----------

## mziab

 *naresh wrote:*   

> Nie orientujecie sie czy baselayout-1.12.0-pre10 ma tego patcha juz, czy tez musze sie z tym bawic?

 

Jak już pisałem powyżej, gałąź 1.12.0 ma już te patche.

----------

## patpi

 *C1REX wrote:*   

> Jest to SuSE nastawione na szybkość. Trochę zaskakujące jest to, ze w planach mają np. wprowadzenie omawianego initng. A to tylko jedna z wielu rzeczy, jakie mają być zastosowane, by przyspieszyć susła.  Robi się ciekawie : )
> 
> Mam nadzieję, że initng jak najszybciej będzie w pełni używalny. Może doświadczenia developerów SUPER w tym pomogą? Oby : )

 

wedle slow developera KateOS:

 *Quote:*   

> Nowe skrypty będą nowocześniejsze ale z zachowaniem prostoty, czyli funkcjonalne ale napisane tak, żeby każdy mógł je zrozumieć   W tajemnicy powiem, że możliwe iż będzie to initng, ostatnio piszę na niego skrypty i wykonuje testy. W tej chwili bałbym się jeszcze zmienić inita, ponieważ projekt jest we wczesnej fazie rozwoju, ale myślę, że w Kate III będzie już zaadaptowany 

 

Jezeli KateOS 3 rzeczywiscie bedzie mial initng to bedziesz mogl sie przyjrzec skryptom startowym i ew. cos zapozyczyc do siebie...

zródło: http://www.kateos.org/forum/viewtopic.php?t=165

----------

## mziab

Dzisiaj przeglądając forum natrafiłem na dość ciekawy program - preload. Na dobrą sprawę robi to samo, co robił readahead. Istnieje jednak pewna dość istotna różnica. Zawiera daemona, który monitoruje użycie plików. Odpada więc problematyczne tworzenie list plików. Pliki są wczytywane z wyprzedzeniem nie raz przy starcie systemu, ale przez cały czas, małymi porcjami. Dodałem właśnie do runlevela boot. obaczymy jak to się będzie sprawować  :Smile: 

Ebuilda można znaleźć na rsyncu breakmygentoo. Dla waszej przyjemności spakowany ebuild wrzuciłem tutaj.

----------

## edi15ta

 *mziab wrote:*   

>  *naresh wrote:*   Nie orientujecie sie czy baselayout-1.12.0-pre10 ma tego patcha juz, czy tez musze sie z tym bawic? 
> 
> Jak już pisałem powyżej, gałąź 1.12.0 ma już te patche.

 

czy baselayout-1.12.0-pre10  zawiera rowniez fastxdm?

----------

## mziab

 *edi15ta wrote:*   

> czy baselayout-1.12.0-pre10  zawiera rowniez fastxdm?

 

Nie, od kiedy baselayout zawiera skrypt xdm?  :Smile: 

----------

## n0rbi666

W ~x86 pojawił się baselayout-1.11.14 - wobec tego pytanko, czy wspiera on już parallel start ?  :Smile:  jeżeli nie, czy może próbowaeł już ktoś nakładać patcha ? 

i jeszcze coś : http://gentoo-wiki.com/HOWTO_prefetch_files_on_boot - zrobiłem tak, jak jest opisane, i działa - jednak nie sprawdzałem, ile to daje do startu  :Wink: 

----------

## mziab

Dostosowałem patche do najnowszej wersji z x86 czyli 1.11.14. Ebuilda szukajcie tam, gdzie zwykle.

UPDATE: Nowy dzień, nowa wersja baselayout.

UPDATE2: Wersja 1.11.14-r3

----------

## Piecia

 *mziab wrote:*   

> Ebuilda szukajcie tam, gdzie zwykle

 

mziab co się stało z twoją stronką?

----------

## mziab

Mówiąc krótko są problemy z domeną serwera, na którym leży moja strona. Podobno miały zostać rozwiązane w parę dni. Szkoda tylko, że te parę dni trwa już kilka tygodni.

W każdym razie, widzę, że zainteresowanie jest, więc postarałem się o zapasową domenę. Ebuildy znajdziecie tutaj.

----------

## mziab

Nowa wersja do ściągnięcia tutaj.

----------

## lazy_bum

Odnośnie preload.

----------

## kfiaciarka

```

PATCH COMMAND:  patch -p3 -g0 --no-backup-if-mismatch < /usr/local/portage/sys-apps/baselayout/files/baselayout-1.11.14-depscan.patch

============================================

missing header for unified diff at line 3 of patch

can't find file to patch at input line 3

Perhaps you used the wrong -p or --strip option?

The text leading up to this was:

--------------------------

|--- sbin/depscan.sh    2005-07-22 01:24:27.000000000 +0100

|+++ sbin/depscan.sh    2006-03-02 23:31:55.000000000 +0000

--------------------------

No file to patch.  Skipping patch.

2 out of 2 hunks ignored

missing header for unified diff at line 117 of patch

can't find file to patch at input line 117

Perhaps you used the wrong -p or --strip option?

The text leading up to this was:

--------------------------

|--- sbin/rc-services.sh        2005-03-08 16:07:30.000000000 +0000

|+++ sbin/rc-services.sh        2006-03-02 20:28:03.000000000 +0000

--------------------------

No file to patch.  Skipping patch.

1 out of 1 hunk ignored

missing header for unified diff at line 128 of patch

can't find file to patch at input line 128

Perhaps you used the wrong -p or --strip option?

The text leading up to this was:

--------------------------

|--- sbin/rc    2006-03-02 23:22:31.000000000 +0000

|+++ sbin/rc    2006-03-02 20:28:03.000000000 +0000

--------------------------

No file to patch.  Skipping patch.

1 out of 1 hunk ignored

============================================

PATCH COMMAND:  patch -p4 -g0 --no-backup-if-mismatch < /usr/local/portage/sys-apps/baselayout/files/baselayout-1.11.14-depscan.patch

============================================

missing header for unified diff at line 3 of patch

can't find file to patch at input line 3

Perhaps you used the wrong -p or --strip option?

The text leading up to this was:

--------------------------

|--- sbin/depscan.sh    2005-07-22 01:24:27.000000000 +0100

|+++ sbin/depscan.sh    2006-03-02 23:31:55.000000000 +0000

--------------------------

No file to patch.  Skipping patch.

2 out of 2 hunks ignored

missing header for unified diff at line 117 of patch

can't find file to patch at input line 117

Perhaps you used the wrong -p or --strip option?

The text leading up to this was:

--------------------------

|--- sbin/rc-services.sh        2005-03-08 16:07:30.000000000 +0000

|+++ sbin/rc-services.sh        2006-03-02 20:28:03.000000000 +0000

--------------------------

No file to patch.  Skipping patch.

1 out of 1 hunk ignored

missing header for unified diff at line 128 of patch

can't find file to patch at input line 128

Perhaps you used the wrong -p or --strip option?

The text leading up to this was:

--------------------------

|--- sbin/rc    2006-03-02 23:22:31.000000000 +0000

|+++ sbin/rc    2006-03-02 20:28:03.000000000 +0000

--------------------------

No file to patch.  Skipping patch.

1 out of 1 hunk ignored

```

i to podczas kompilacji

```

sudo emerge baselayout --digest

Calculating dependencies  ...done!

>>> Generating digest file...

<<< rc-scripts-1.6.14.tar.bz2

>>> Generating manifest file...

<<< baselayout-1.11.14-r6.ebuild

<<< files/baselayout-1.11.14-adsl.patch

<<< files/baselayout-1.11.14-depscan.patch

<<< files/baselayout-1.11.14-essidnet.patch

<<< files/baselayout-1.11.14-iwconfig.patch

<<< files/baselayout-1.11.14-udev-sysinit.patch

<<< files/baselayout-1.11.14-udhcpc.patch

<<< files/digest-baselayout-1.11.14-r6

<<< files/modules-update-1.11.14.patch

<<< files/parallel-1.11.14.patch

>>> Computed message digests.

>>> emerge (1 of 1) sys-apps/baselayout-1.11.14-r6 to /

>>> md5 files   ;-) baselayout-1.11.14-r6.ebuild

>>> md5 files   ;-) files/baselayout-1.11.14-essidnet.patch

>>> md5 files   ;-) files/parallel-1.11.14.patch

>>> md5 files   ;-) files/digest-baselayout-1.11.14-r6

>>> md5 files   ;-) files/baselayout-1.11.14-udev-sysinit.patch

>>> md5 files   ;-) files/baselayout-1.11.14-iwconfig.patch

>>> md5 files   ;-) files/baselayout-1.11.14-udhcpc.patch

>>> md5 files   ;-) files/baselayout-1.11.14-depscan.patch

>>> md5 files   ;-) files/baselayout-1.11.14-adsl.patch

>>> md5 files   ;-) files/modules-update-1.11.14.patch

>>> md5 src_uri ;-) rc-scripts-1.6.14.tar.bz2

>>> Unpacking source...

>>> Unpacking rc-scripts-1.6.14.tar.bz2 to /var/tmp/portage/baselayout-1.11.14-r6/work

 * Applying baselayout-1.11.14-essidnet.patch ...                                                                             [ ok ]

 * Applying baselayout-1.11.14-udev-sysinit.patch ...                                                                         [ ok ]

 * Applying baselayout-1.11.14-adsl.patch ...                                                                                 [ ok ]

 * Applying baselayout-1.11.14-iwconfig.patch ...                                                                             [ ok ]

 * Applying baselayout-1.11.14-udhcpc.patch ...                                                                               [ ok ]

 * Applying baselayout-1.11.14-depscan.patch ...

 * Failed Patch: baselayout-1.11.14-depscan.patch !

 *  ( /usr/local/portage/sys-apps/baselayout/files/baselayout-1.11.14-depscan.patch )

 *

 * Include in your bugreport the contents of:

 *

 *   /var/tmp/portage/baselayout-1.11.14-r6/temp/baselayout-1.11.14-depscan.patch-5460.out

```

jakieś sugestie?

----------

## mziab

Coś mi się zdaje, że nie używasz wszystkich plików w mojej paczce z ebuildem. W -r6 zmodyfikowałem tego patcha, by nie sprawiał kłopotów. Skoro używasz oryginalnej wersji, nie ma się co dziwić.

----------

## kfiaciarka

 *mziab wrote:*   

> Coś mi się zdaje, że nie używasz wszystkich plików w mojej paczce z ebuildem. W -r6 zmodyfikowałem tego patcha, by nie sprawiał kłopotów. Skoro używasz oryginalnej wersji, nie ma się co dziwić.

 

to co mam zrobic?

```

sudo emerge /usr/local/portage/sys-apps/baselayout/baselayout-1.11.14-r6.ebuild --digest

emerging by path implies --oneshot... adding --oneshot to options.

*** emerging by path is broken and may not always work!!!

Calculating dependencies  ...done!

>>> Generating digest file...

<<< rc-scripts-1.6.14.tar.bz2

>>> Generating manifest file...

<<< baselayout-1.11.14-r6.ebuild

<<< files/baselayout-1.11.14-adsl.patch

<<< files/baselayout-1.11.14-depscan.patch

<<< files/baselayout-1.11.14-essidnet.patch

<<< files/baselayout-1.11.14-iwconfig.patch

<<< files/baselayout-1.11.14-udev-sysinit.patch

<<< files/baselayout-1.11.14-udhcpc.patch

<<< files/digest-baselayout-1.11.14-r6

<<< files/modules-update-1.11.14.patch

<<< files/parallel-1.11.14.patch

>>> Computed message digests.

>>> emerge (1 of 1) sys-apps/baselayout-1.11.14-r6 to /

>>> md5 files   ;-) baselayout-1.11.14-r6.ebuild

>>> md5 files   ;-) files/baselayout-1.11.14-essidnet.patch

>>> md5 files   ;-) files/parallel-1.11.14.patch

>>> md5 files   ;-) files/digest-baselayout-1.11.14-r6

>>> md5 files   ;-) files/baselayout-1.11.14-udev-sysinit.patch

>>> md5 files   ;-) files/baselayout-1.11.14-iwconfig.patch

>>> md5 files   ;-) files/baselayout-1.11.14-udhcpc.patch

>>> md5 files   ;-) files/baselayout-1.11.14-depscan.patch

>>> md5 files   ;-) files/baselayout-1.11.14-adsl.patch

>>> md5 files   ;-) files/modules-update-1.11.14.patch

>>> md5 src_uri ;-) rc-scripts-1.6.14.tar.bz2

>>> Unpacking source...

>>> Unpacking rc-scripts-1.6.14.tar.bz2 to /var/tmp/portage/baselayout-1.11.14-r6/work

 * Applying baselayout-1.11.14-essidnet.patch ...                                                                             [ ok ]

 * Applying baselayout-1.11.14-udev-sysinit.patch ...                                                                         [ ok ]

 * Applying baselayout-1.11.14-adsl.patch ...                                                                                 [ ok ]

 * Applying baselayout-1.11.14-iwconfig.patch ...                                                                             [ ok ]

 * Applying baselayout-1.11.14-udhcpc.patch ...                                                                               [ ok ]

 * Applying baselayout-1.11.14-depscan.patch ...

 * Failed Patch: baselayout-1.11.14-depscan.patch !

 *  ( /usr/local/portage/sys-apps/baselayout/files/baselayout-1.11.14-depscan.patch )

 *

 * Include in your bugreport the contents of:

 *

 *   /var/tmp/portage/baselayout-1.11.14-r6/temp/baselayout-1.11.14-depscan.patch-2499.out
```

co nie tak robie?Last edited by kfiaciarka on Wed Mar 15, 2006 8:32 pm; edited 1 time in total

----------

## mziab

Skasuj sys-apps/baselayout ze swojego overlaya i rozpakuj paczkę z ebuildem. Specjalnie sprawdziłem i wszystko działa jak należy.

Swoją drogą, włączyłeś flagę speedup? To powinno pomóc  :Smile:  Z pewnych przyczyn patch na depscan zakłada, że został nałożony patch parallel.

W zasadzie powinienem to naprawić. Choć z drugiej strony... nie po to używa się tego ebuilda, żeby nie włączać flagi speedup. Bez niej to w końcu zwykły baselayout.

----------

## kfiaciarka

 *mziab wrote:*   

> Skasuj sys-apps/baselayout ze swojego overlaya i rozpakuj paczkę z ebuildem. Specjalnie sprawdziłem i wszystko działa jak należy.
> 
> Swoją drogą, włączyłeś flagę speedup? To powinno pomóc  Z pewnych przyczyn patch na depscan zakłada, że został nałożony patch parallel.
> 
> W zasadzie powinienem to naprawić. Choć z drugiej strony... nie po to używa się tego ebuilda, żeby nie włączać flagi speedup. Bez niej to w końcu zwykły baselayout.

 

U mnie nie działa :Sad:  za żadne skarby:(

USE="speedup" <- mój błąd  :Smile: 

Dzięki! Już idzie!Last edited by kfiaciarka on Wed Mar 15, 2006 8:49 pm; edited 1 time in total

----------

## mziab

Jeszcze raz zapytam, na pewno włączyłeś flagę "speedup"? Sprawdziłem i to właśnie jej brak powoduje błąd w nakładaniu patcha na depscan. O powodach napisałem powyżej zresztą.

----------

## kfiaciarka

 *mziab wrote:*   

> Jeszcze raz zapytam, na pewno włączyłeś flagę "speedup"? Sprawdziłem i to właśnie jej brak powoduje błąd w nakładaniu patcha na depscan. O powodach napisałem powyżej zresztą.

 

Dzięki! Teraz mi system startuje w 40 sekund:) z x'ami ma sie rozumieć :Smile: 

Miodzio!!  :Very Happy: 

----------

## crocop

Czy dla baselayout-1.11.14-r8 mozna uzyc patcha z r6 i czy da to oczekiwanie skutki?

----------

## Yatmai

Skusilem się na baselayout i fastxdm... Prawde powiedziawszy, fastxdm skrócił mi czas z 50s do ~47s, jednak odnośnie baselayout, różnicy nie zauważyłem.

----------

## KeyBi

 *Art.root wrote:*   

> Skusilem się na baselayout i fastxdm... Prawde powiedziawszy, fastxdm skrócił mi czas z 50s do ~47s, jednak odnośnie baselayout, różnicy nie zauważyłem.

 

Ja z tym baselayoutem oraz innymi zabiegami, narazie jednak jeszcze bez fastxdm mam już 40s :]

Sądzę, że warto walczyć...

----------

## Yatmai

A tak na oko, dużo Ci dał Baselayout ? Bo moje ~50s wiąże się z tym, że mam sporo usług powłączanych + reiserfs, a o 3 sekundy walczyć mi się nie chce, bo średno reboot'a robie co ok tydzień, jak zmieniam coś w sprzęcie albo zabardzo namieszłałem w konfiguracji  :Very Happy: 

----------

## KeyBi

Ten baselayout dał mi około ~5-6s. Jest widoczna różnica. Upewnij się, że skompilowałeś go z włączoną flagą speedup. Wynik 40s na moim Duronie 800Mhz, jest dla mnie bardzo zadowalający  :Smile: 

----------

## Yatmai

Flagę speedup mam na bank, co z resztą potwierdził equery  :Wink:  Tak sobie teraz pokojażyłem, że skoro mam nawalone sporo usług to i sporo mogę zyskać... (ech, mam dziś spowolnione myslenie  :Very Happy: ) Spróbuje może baselayout'a z liniii 1.12  :Smile: 

----------

## crocop

 *Art.root wrote:*   

> Skusilem się na baselayout i fastxdm... Prawde powiedziawszy, fastxdm skrócił mi czas z 50s do ~47s, jednak odnośnie baselayout, różnicy nie zauważyłem.

 

A jakiego uzywasz baselayouta? i czy na najnowsze wersje trzeba nakładać jakieś patche?

----------

## Yatmai

Aktualnie baselayout-1.11.14-r6 od mziab'a  :Smile:  Seria 1.12.x jak czytałem ma już w sobe te patche...

Btw. zainstalowałem 1.12.x, to mi się usługi przy starcie posypały, wróciłem do 1.11.14-r6 i czas startu szedł mi do ~40-43s  :Smile: 

----------

## Gabrys

Zainteresowanym przyśpieszaniem startu polecam initng. Mam dwa powody by to robić:

- initng implementuje od początku to, co w inicie trzeba zmieniać, czyli uruchamianie wielu procesów jednocześnie oraz wstawanie iksa przed innymi usłagami

- initng stanie się standardem za jakieś pół roku (tak oceniam)

Ciągle initng wymaga trochę pracy przy używaniu, bo nie posiada wielu skryptów startowych, więc jeśli chcemy np. zainstalować MySQL, to pierwszy raz należy odpalić system z initem i wykonać /etc/init.d/mysql start, który stworzy niezbędne bazy. Potem możemy reboot -> initng i już ngc -u mysql. Trochę to kłopotliwe, ale oceniam, że bardziej przyszłościowe niż używanie demo-beta-patched-najnowszej-wersji software'u, który jest przestarzały (init).

Zachęciłem i ostrzegłem. Spadam stąd. Pozdrawiam

----------

## crocop

Co robie nie tak, ze nie moge za nim wrocic do wersji 1.11.14-r6 baselayout?

Przy probie kompilacji dostaje

```

localhost baselayout # emerge baselayout-1.11.14-r6.ebuild

emerging by path implies --oneshot... adding --oneshot to options.

*** emerging by path is broken and may not always work!!!

Calculating dependencies ...done!

>>> emerge (1 of 1) sys-apps/baselayout-1.11.14-r6 to /

!!! No package digest file found: /usr/portage/sys-apps/baselayout/files/digest-baselayout-1.11.14-r6

!!! Type "ebuild foo.ebuild digest" to generate it.

localhost baselayout # emerge baselayout-1.11.14-r6.ebuild digest

emerging by path implies --oneshot... adding --oneshot to options.

*** emerging by path is broken and may not always work!!!

Calculating dependencies -

emerge: there are no ebuilds to satisfy "digest".

```

----------

## Gabrys

Może daj emerge =sys-apps/baselayout-wersja, skoro

```
*** emerging by path is broken and may not always work!!!
```

----------

## crocop

Zrobiłem tak jak napisles, ale mimo wszytko dalej jest problem z 

```

!!! No package digest file found: /usr/portage/sys-apps/baselayout/files/digest-baselayout-1.11.14-r6

!!! Type "ebuild foo.ebuild digest" to generate it.

```

----------

## KeyBi

Zrób :

```
ebuild /usr/portage/sys-apps/baselayout/files/digest-baselayout-1.11.14-r6.ebuild digest
```

----------

## crocop

W tym katalogu mam takie oto pliki, ale nie ma wsrod nich wersji 14-r6  :Sad: 

```

-rw-r--r-- 1 root    root     256 kwi 17 17:36 digest-baselayout-1.11.13-r2

-rw-r--r-- 1 root    root     256 kwi 17 17:34 digest-baselayout-1.11.14-r8

-rw-r--r-- 1 root    root     256 kwi 24 15:34 digest-baselayout-1.11.15-r1

-rw-r--r-- 1 root    root     256 maj  4 11:18 digest-baselayout-1.11.15-r3

-rw-r--r-- 1 root    root     274 kwi 24 15:08 digest-baselayout-1.12.0_pre18-r1

-rw-r--r-- 1 root    root     274 maj  2 13:13 digest-baselayout-1.12.0_pre19

-rw-r--r-- 1 root    root     274 maj  4 11:18 digest-baselayout-1.12.0_pre19-r2

```

Czy to znaczy ze nie da rady zrobic downgradui do wersji r6 baselayout ( obecnie mam r :Cool: .

----------

## Gabrys

Raczej

ebuild /usr/portage/sys-apps/baselayout/baselayout-1.11.14-r8p.ebuild digest

pliki digest dopiero wtedy powstają

----------

## KeyBi

 *Gabrys wrote:*   

> Raczej
> 
> ebuild /usr/portage/sys-apps/baselayout/baselayout-1.11.14-r8p.ebuild digest
> 
> 

 

Fakt ... mała pomyłka  :Razz: 

----------

## arsen

łatwiej

```

emerge --digest baselayout

```

----------

## crocop

Ok, wszytsko już działa. Dzięki wszystkim za pomoc. Fajnie przyspiesza  :Smile:  Może ktoś wie, czy kdma też da się coś przyspieczyć?

----------

## Gabrys

Link z pierwszego posta nie działa.

------ EDIT -------

Już działa.

----------

## Gabrys

Jakieś plany na przyśpieszanie baselayout-1.12?

----------

## mziab

1.12 zawiera już inne wersje tych patchy. Możesz o tym nawet przeczytać na tej stronie. Ech  :Smile: 

----------

