We are in the process of migrating this forum. A new space will be available soon. We are sorry for the inconvenience.

udhcpc Sending discover... Lease failed


krzysztof_surowiec
26-08-2009, 08:43
Witam

Mam ten sam problem z komunikatem
udhcpc: Sending discover...
Lease failed
U mnie wygląda to tak. Instaluje czysty system automatycznie z ovh np Debian Lenny 5.0 32bit. Po instalacji system wstaje bez problemu z netboot ovh kernel 2.6.28.4. Przełączam sobie na vKVM, aby zobaczyć boota dokładniej. Odpala się lilo, wybieram jedną pozycję linux, kernel się ładuje bez problemu z hd, po czym zatrzymuje się na wyżej wymienionym problemie i tak już zostaje. Zaznaczam, że NIC nie zmieniałem w kernelu, ani w obrazie ramdysku iscsi.img. Problem pojawia mi się tak przynajmniej wygląda tylko przy restarcie poprzez KVM, przy netboocie na hd lub z jajka ovh raczej startuje bez problemu.
Jakieś nowe pomysły??
Dzięki

Dinth
24-08-2009, 21:08
Dzieki za pomoc. Problem rozwiazany, wprawdzie drugi interface mam na dummy0 a nie eth0:0 ale moze byc.

[edit]
Jednak to jeszcze nie koniec klopotow chyba niestety. W sumie nie wiem czy jest to spowodowane przez zla konfiguracje interfaceow sieciowych, ale przed cala ta sytuacja apache dzialal, a teraz niestety nie chce ruszyc.
Kod:
 * apache2 has detected a syntax error in your configuration files:
[Mon Aug 24 21:27:52 2009] [crit] (22)Invalid argument: alloc_listener: failed to get a socket for (null)
Syntax error on line 9 of /etc/apache2/vhosts.d/00_default_ssl_vhost.conf:
Listen setup failed
Gdy dodam w Listen rowniez ktores z IP dostaje
Kod:
* apache2 has detected a syntax error in your configuration files:
[Mon Aug 24 21:30:56 2009] [crit] (22)Invalid argument: alloc_listener: failed to get a socket for A.B.C.D
Syntax error on line 9 of /etc/apache2/vhosts.d/00_default_ssl_vhost.conf:
Listen setup failed

nixi
24-08-2009, 09:58
Odpowiedź zacząłem pisać zainim przeedytowałeś poprzedni post, dlatego nie zauważyłem modyfikacji
Jednak wcześniej ewidentnie miałeś problem, żeby przejść szczęśliwie przez initrd...

Tak, na tym etapie, to teraz pozostaje Ci już tylko poprawić skrypty startowe. Skoro ip-failover nie działa, to monitoring pewnie automatycznie po jakimś czasie przełącza w rescue. Jak rozumiem, gdy wywołasz "ifconfig" to w ogóle nie widzisz interfejsu eth0:0? Jeśli tak, to najpierw wklep ręcznie ifconfig eth0:0 87.98.X.X netmask 255.255.255.255, gdzie 87.98.X.X to Twój adres ip-failover - powinno zadziałać. Jeśli teraz będzie w porządku, to zmodyfikuj odpowiednio skrypty i gotowe.

ollerm
24-08-2009, 09:43
Cytat Napisał Dinth
a takze skaskowalem /etc/init.d/net.dummy0
teraz wiesz czemu nie masz ip fail-over?

dziwne ze sam sie przełacza, moze jest problem z SANem? w dmesgu coś masz ciekawego?

Dinth
24-08-2009, 08:30
@nixi: nie zrozumiales mnie. Serwer zbootowal poprawnie juz przy ostatnim moim poscie. Niestety jest dostepne tylko 1 ip i 1 interface sieciowy (nie ma w ogole w ifconfigu eth0:0 i ip na ktorym mam niestety wszystkie uslugi sieciowe). Czyli problem jednak musi byc gdzies w /etc.

Co wiecej serwer po ok kilkudziesieciu minutach od zbootowania sam przeskakuje w tryb rescue.

nixi
23-08-2009, 23:00
Jeśli dobrze zrozumiałem, to oni mieli całkiem inny problem - po aktualizacji zginął ze skryptów startowych wpis statycznego adresu, a zamiast tego uruchamiał się klient dhcp.

U Ciebie zacina się ewidentnie na initrd, nie dochodzi do wykonania skrytptów startowych, gdyż główna partycja nie jest jeszcze podmontowana.

Konkretniej, w tym fragmencie skryptu znajdującego się w initrd:
Kod:
cd /
mount -nt proc proc proc
rootdev=$(cat proc/sys/kernel/real-root-dev)
cmdline=$(cat /proc/cmdline)
umount -n proc
if [ $rootdev != 256 ]; then
        mount_root
        cd mnt
        mount
        pivot_root . initrd
fi
umount -n initrd
Kolejny fragment - interesuje nas "mount_root()", który wywołuje następnie "ifup_dhcp_iscsi()", wygląda on tak:
Kod:
ifup_dhcp_iscsi() {
        /sbin/ifconfig eth0 0.0.0.0 up
        /sbin/udhcpc -q
        # iscsistart done by udhcpc config script
}

upload_iscsid() {
        [ -f "/mnt/sbin/iscsid" ] || return
        RET=`md5sum /mnt/sbin/iscsid`
        #echo "'${RET%%  /mnt/sbin/iscsid}'"
        [ "f62ba3b6e34e1d6b0c94f4c585bcf1cf" = "${RET%%  /mnt/sbin/iscsid}" ] && return
        echo "Updating iscsi tools."
        mount -o remount,rw /dev2/root2 /mnt
        ncftpget 213.186.33.9 /mnt/sbin/ made-in-ovh/dedie/iscsi/iscsid made-in-ovh/dedie/iscsi/iscsiadm
        echo "2.0-870" > /mnt/etc/iscsi/version
}

mount_root() {
        local sysfs=

        mount -nt proc proc proc
        mount_tmpfs dev2
        if mount -nt sysfs sysfs sys > /dev/null 2>&1; then
                sysfs=yes
        fi

        ifup_dhcp_iscsi

        # test if /mnt is already mounted
        LIST=`mount -t nfs`
        if [ -z "$LIST" ]; then
                get_device
                mount_device
                upload_iscsid
        fi

        if [ $sysfs ]; then
                umount -n sys
        fi
        umount -n dev2
        umount -n proc
}
Właśnie w odpowiedzi na "/sbin/ifconfig eth0 0.0.0.0 up" widzisz komunikat "SIOCSIFFLAGS: Invalid argument"
A potem już lepiej być raczej nie może...

Dla mnie coś z jądrem jest źle - no chyba, że obraz initrd się jakoś spieprzył (ale nie sądze). Dla pewności sprawdź go za pomocą cramfsck. Wogóle warto sobie do niego zajrzeć, zobaczyć jak to wszystko jest zrobione i ewentualnie na własne potrzeby coś zmodyfikować

Dinth
23-08-2009, 21:46
tez o tym myslalem, tylko ze jadro bylo nie ruszane od czasu instalacji a wczesniej przez kilka rebootow bootowalo go.

tu ludzie maja podobny problem, niestety ich rozwiazania mi nie pomagaja albo ja nie do konca rozumiem tlumaczenie ich w google translate.
http://forum.ovh.com/showthread.php?t=41141
http://translate.google.pl/translate...istory_state0=

[edit]

Pomylka. cos pomoglo co robilem, nie wiem sam co, bo po kilka rzeczy naraz robilem. Kernela jednak nie rekompilowalem.
W kazdym razie pomoglo o tyle o ile. eth0 dziala, eth0:0 ciagle nie. przez co mam 2 ip (akurat to wazniejsze) niedostepne.

nixi
23-08-2009, 21:05
Problemy masz jeszcze na etapie wykonywania skryptu /sbin/init który znajduje się w obrazie startowego ramdysku (initrd-iscsi.img lub jakoś podobnie się to nazywa). W tym przypadku dla mnie jest to ewidentnie kwestia konfiguracji jądra: albo obsługa karty sieciowej, protokołu TCP/IP oraz iSCSI powinna być wkompilowana bezpośrednio w jądro, albo wprowadzasz potrzebne moduły do wspomnianego wcześniej obrazu initrd i modyfikujesz skrypt, aby ładował je na samym początku - zanim przejdzie dalej. Dlatego czegoś ewidentnie brakuje.

W konfiguracji systemu umieszczonej w /etc nie masz po co grzebać, to zupełnie nic nie da, daleko jeszcze do etapu zanim te pliki zaczną być przetwarzane. Najpierw initrd musi się szczęśliwie zakończyć...


Co do Twojego systemu to widać, to na pierwszy rzut oka widać dwa problemy (ale pewnie nie jedyne). Przeanalizuj spokojnie konfigurację jądra, odpowiednio zmodyfikuj i przekompiluj.

Kod:
cat: proc/cmdline: No such file or directory
Z jakiegoś powodu nie udało się pomontować /proc. Zastanów się dlaczego...

Kod:
SIOCSIFFLAGS: Invalid argument
Obsługa karty sieciowej zapewne jest w postaci modułu, który oczywiście nie został załadowany i system zupełnie nie wie o istnieniu czegoś takiego jak eth0...

Dinth
23-08-2009, 18:02
Cytat Napisał ollerm
bezmyślnie updatowaleś pliki konfiguracyjne? takie są efkty..

nadpisałeś pewnie plik /etc/conf.d/rc
sprawdź czy masz w nim:
RC_HOTPLUG="yes"
RC_COLDPLUG="yes"
RC_PLUG_SERVICES="" - i tu prawdopodbnie miałeś coś z sieciówkami. tam chyba powinno być net.eth0 lub net.*

pamietam że na RPSie właśnie po updacie tego pliku sie wykrzaczył
Jak widac kazdemu sie moze zdarzyc, szczegolnie jak rutyna mowi ze jezeli system jest tuz po instalacji to wszystkie pliki powinny byc defaultowe, a update defaultowego na defaultowy zaszkodzic nie powinnien. No coz, tu dochodzi jeszcze to iSCSI niestety

Zaraz Twoj sposob przetestuje i dam znac co i jak.
Apropo, sa gdzies dostepne zrodla skryptu ktory OVH wykonuje po instalacji systemu modyfikujac go, ew jakies opisy zmian czy diffy ?

[edit]

niestety nie pomoglo. Dodalem w /etc/conf.d/rc RC_PLUG_Services="!net.*" (znalezione na francuskim forum OVH, choc probowalem tez "net.eth0" jak mowisz), a takze skaskowalem /etc/init.d/net.dummy0 i podsymlinkowalem pod /etc/init.d/net.lo (rowniez znalezione na francuskim forum OVH). Czego mi jeszcze brakuje ?

Kod:
cat: proc/cmdline: No such file or directory
SIOCSIFFLAGS: Invalid argument
SIOCSIFFLAGS: Invalid argument
udhcpc (v0.9.90-pre) started
SIOCSIFFLAGS: Invalid argument
Sending discover...
udhcpc [953]: Sending discover...
Lease failed
Trzy ostatnie linijki powtarzaja sie w kolko.

Moglby ktos wkleic swojego /etc/conf.d/rc i /etc/conf.d/net ?

ollerm
23-08-2009, 17:42
bezmyślnie updatowaleś pliki konfiguracyjne? takie są efkty..

nadpisałeś pewnie plik /etc/conf.d/rc
sprawdź czy masz w nim:
RC_HOTPLUG="yes"
RC_COLDPLUG="yes"
RC_PLUG_SERVICES="" - i tu prawdopodbnie miałeś coś z sieciówkami. tam chyba powinno być net.eth0 lub net.*

pamietam że na RPSie właśnie po updacie tego pliku sie wykrzaczył

Dinth
23-08-2009, 17:23
Zainstalowalem na swoim RPSie czyste Gentoo, oczywiscie na samym poczatku ustawilem flagi w make.conf, emerge --sync; emerge portage; emerge -DuN world; etc-upgrade; pozniej zemergowalem pare rzeczy typu apache, mysql, php, i pare innych drobnostek, zrobilem konto uzytkownika, skonfigurowalem binda.
Robie reboot maszyny... a ta nie wstaje.
Odpalam w vKVM i dostaje zaraz na poczatku initd:
Kod:
udhcpc: Sending discover...
Lease failed
W kolko. Kiedys ktos mowil ze serwer wstaje w ten sposob 15 minut, moj jednak duzo dluzej chodzi i nic nie wstaje. Czyzby etc-update nadpisal cos czego nie powinnien albo emerge --world zupdateowalo cos do iSCSI niepotrzebnie ?