błąd podczas kompilacji jądra 2.6.33.1

szarki432 - 27-03-2010 12:33
Witam.

Jądro kompilowałem według tego: http://kutek.jogger.pl/2007/06/29/ho...-pod-debianem/.

Zainstalowałem potrzebne pakiety: apt-get install fakeroot kernel-package libncurses5-dev bzip wget build-essential Przy kompilacji zatrzymałem się na poleceniu: fakeroot make-kpkg --initrd --append-to-version=-custom kernel_image kernel_headers Po jakiś 40 minutach pojawił się błąd, coś w stylu (nie pamiętam dokładnie):
includes/linux/version.sh
wersje jąder się nie zgadzają, popraw to i kontynuuj.
i parę linijek dalej
*** make... błąd 2 Proszę o pomoc.

Aha jeszcze mam takie pytanie, czy mogę podczas ściągania obrazu (iso) Debiana dla amd64 wybrać aby było już najnowsze jądro w nm? Czy to kwestia przypadku?

Mam procesor Intel Pentium Dual-Core E2140, czy lepszy jest Debian amd64 czy ia64?

soniak - 27-03-2010 13:02
Według mnie, a nie jestem specem tylko początkującym olej poradnik, o którym piszesz, a skorzystaj z: http://czlug.icis.pcz.pl/materialy/kernel/howto/.

Sam z niego korzystałem i nie miałem takich błędów, o których wspominasz. Powodzenia :)

shagrin - 27-03-2010 14:08
Czy to nie był błąd związany z plikiem:
include/linux/version.h Jeśli tak zerknij na:
https://bugs.launchpad.net/ubuntu/+s...ge/+bug/498747
Może pomoże.

szarki432 - 30-03-2010 00:44
Dokładnie coś takiego wyskakuje (ostatni fragment):
IHEX2FW firmware/keyspan_pda/xircom_pgs.fw
make[1]: Opuszczenie katalogu `/usr/src/linux-2.6.33.1'
test ! -e scripts/package/builddeb || mv -f scripts/package/builddeb scripts/package/builddeb.kpkg-dist
test ! -e scripts/package/Makefile || test -f scripts/package/Makefile.kpkg-dist || (mv -f scripts/package/Makefile scripts/package/Makefile.kpkg-dist && (echo "# Dummy file "; echo "help:") > scripts/package/Makefile)
COLUMNS=150 dpkg -l 'gcc*' perl dpkg 'libc6*' binutils make dpkg-dev |\
awk '$1 ~ /[hi]i/ { printf("%s-%s\n", $2, $3) }'> debian/buildinfo
uname -a >> debian/buildinfo
echo using the compiler: >> debian/buildinfo
grep LINUX_COMPILER include/linux/compile.h | \
sed -e 's/.*LINUX_COMPILER "//' -e 's/"$//' >> debian/buildinfo
grep: include/linux/compile.h: Nie ma takiego pliku ani katalogu
echo applied kernel patches: >> debian/buildinfo
echo done > debian/stamp/build/kernel
/usr/bin/make -f ./debian/rules debian/stamp/binary/pre-linux-image-2.6.33.1
make[1]: Wejście do katalogu `/usr/src/linux-2.6.33.1'
====== making target debian/stamp/install/linux-image-2.6.33.1 [new prereqs: ]======
This is kernel package version 11.015.
echo "The UTS Release version in include/linux/version.h"; echo " \"\" "; echo "does not match current version:"; echo " \"2.6.33.1\" "; echo "Please correct this."; exit 2
The UTS Release version in include/linux/version.h
""
does not match current version:
"2.6.33.1"
Please correct this.
make[1]: *** [debian/stamp/install/linux-image-2.6.33.1] Błąd 2
make[1]: Opuszczenie katalogu `/usr/src/linux-2.6.33.1'
make: *** [linux-image] Błąd 2 tu cały log: http://www.speedyshare.com/files/216...el_compile.log

robiłem według tego : http://debian.linux.pl/viewtopic.php?p=41656#41656

mój teraźniejszy kernel: Linux debian 2.6.26-2-amd64

Proszę o pomoc

shagrin - 30-03-2010 01:04
Jaką masz wersję kernel-package?
Wydaje mi się, że może to być związane z wersją 11.xx, a może być rozwiązane upgrade'm tej paczki do wersji 12.xx.

Innym wyjściem jest postępowanie wg sposobu opisanego w linku udostepnionym powyżej:
https://bugs.launchpad.net/ubuntu/+s...ge/+bug/498747
Ewentualnie użycie łatki:
http://bugs.debian.org/cgi-bin/bugre...t=1;bug=571716

szarki432 - 30-03-2010 03:10
Zaktualizowałem kernel-package z wersji 11.015 do 12.033 (squeeze)

Podmieniłem ten kod z pliku /usr/share/kernel-package/ruleset/misc/version_vars.mk
UTS_RELEASE_HEADER=$(call doit,if [ -f include/linux/utsrelease.h ]; then \
echo include/linux/utsrelease.h; \
else \
echo include/linux/version.h ; \
fi) Na
UTS_RELEASE_HEADER=$(call doit,if [ -f include/generated/utsrelease.h ]; then \
echo include/generated/utsrelease.h; \
elif [ -f include/linux/utsrelease.h ]; then \
echo include/linux/utsrelease.h; \
else \
echo include/linux/version.h; \
fi) Powstały dwie paczki w /usr/src/ linux-image i linux-headers, zainstalowałem je kolejno i zresetowałem system, ale po wybraniu nowego jądra wgrywa się tylko to:

[ 0.233333] Kernel panic - not syncing : VFS : Unable to mount root fs on unknow-block (0,0)
root (hd0,4)
Filesystem type is ext2fs, partition type 0x83
kernel /boot/vmlinuz-2.6.33.1 root=/dev/hd5 ro quiet
[Linux-bzImage, setup=0x3600, size=0x21b2f0

shagrin - 30-03-2010 09:50
Czy masz pliki:
/boot/initrd.img-2.6.33.1
/boot/vmlinuz-2.6.33.1

szarki432 - 30-03-2010 15:47
Nie mam:
/boot/initrd.img-2.6.33.1 Próbowałem go utworzyć:
mkinitramfs -o /boot/initrd.img-2.6.21 -o 2.6.21 (z wnętrza /usr/src/linux-2.6.33.1/)

Przez kilkanaście sekund od wydania polecenia, widzę że coś pracuje, ale po chwili widzę znowu znak zachęty.

A w /boot/ ten plik nie został utworzony mkinitrd nie działa (nieznana komenda).

raven18 - 30-03-2010 17:58
A np. tak:
mkinitramfs -o /boot/initrd.img-2.6.33.1-custom /lib/modules/2.6.33.1-custom 2.6.33.1-custom - to jest nazwa twego nowo kompilowanego jądra.

shagrin - 30-03-2010 18:28
A może tak:
mkinitramfs -o /boot/initrd.img-2.6.33.1 2.6.33.1

kraluk - 05-04-2010 15:06

Mam procesor Intel Pentium Dual-Core E2140, czy lepszy jest Debian amd64 czy ia64? Że się tak odniosę do tej wypowiedzi.

Ciebie powinno interesować wyłącznie amd64. IA64 to procesory typu Itanium, czyli nie masz czego szukać w tej architekturze w kontekście sprzętu, który opisałeś.

RubinX - 09-04-2010 14:09
Witam.

Nie wiem czy problem wciąż aktualny, ale ja sam męczyłem się z takim samym komunikatem po kompilacji i instalacji nowego jajka. Właśnie znalazłem przyczynę, więc opiszę jak jest u mnie (na Debianie w dystrubucji testing 'squeeze').

Wyjaśnilo się w końcu, to był bug (albo celowe działanie jego twórców, którego ja niestety nie rozumiem :/) w skrypcie postinstalacyjnym.

Po instalacji paczki z jajkiem, np.:
dpkg -i linux-image-2.6.32-3-686-se-c510_2.6.32-9_i386.deb na koniec powinny się automatycznie odpalić skrypty generujace m.in. initrd.img-(...) i aktualizujące konfig gruba.

Winny problemów okazał się skrypt (u mnie w wersji: 0.93.4): /etc/kernel/postinst.d/initramfs-tools #!/bin/sh

# passing the kernel version is required
[ -z "$1" ] && exit 0

# kernel-package passes an extra arg; hack to not run under kernel-package
[ -z "$2" ] || exit 0

# we're good - create initramfs. update runs do_bootloader
update-initramfs -c -t -k "$1" który miał ten dziwny warunek (na czerwono), powodujący natychmiastowe zakończenie skryptu jeśli wywołało się go z drugim argumentem. A że przy debianowej metodzie budowania paczki z jajkiem ten skrypt jest wywoływany z dwoma parametrami, np.: /etc/kernel/postinst.d/initramfs-tools 2.6.32-3-686-se-c510 /boot/vmlinuz-2.6.32-3-686-se-c510 to skrypt zamiast wygenerować /boot/initrd.img-2.6.32-3-686-se-c510, po prostu kończył działanie bez żadnego komunikatu :/.

---
Aby szybko rozwiązać ten problem wystarczy więc:

1. albo wykomentować linię z tym warunkiem w skrypcie initramfs-tools: # kernel-package passes an extra arg; hack to not run under kernel-package
# [ -z "$2" ] || exit 0 2. albo ręcznie wygenerować obraz ramdysku, np.:
update-initramfs -c -t -k "2.6.32-3-686-se-c510" ---
PS.
W nowej wersji pakietu initramfs-tools (0.94.4, który na razie jest w dystrybucji niestabilnej 'sid') problem ten jest już rozwiązany [szczegóły - klik]:
#!/bin/sh

version="$1"
bootopt=""

# passing the kernel version is required
[ -z "${version}" ] && exit 0

# kernel-package passes an extra arg
if [ -n "$2" ]; then
if [ -n "${KERNEL_PACKAGE_VERSION}" ]; then
bootdir=$(dirname "$2")
bootopt="-b ${bootdir}"
else
# official Debian linux-images take care themself
exit 0
fi
fi

# avoid running multiple times
if [ -n "$DEB_MAINT_PARAMS" ]; then
eval set -- "$DEB_MAINT_PARAMS"
if [ -z "$1" ] || [ "$1" != "configure" ]; then
exit 0
fi
fi

# we're good - create initramfs. update runs do_bootloader
update-initramfs -c -t -k "${version}" ${bootopt} Można więc rozwiązać ten problem jeszcze jedną metodą:

3. przez zwykłą podmianę starego skryptu na jego nową wersję (do czasu, aż nowa wersja pakietu oficjalnie nie przejdzie do dystrybucji której używamy).