2.6.37-rc7-sched - (засега) краят

Махам EasyTag и системата казва - 3 пакета за ъпгрейд. Добре тогава, хайде:

drago@ubuntu:~$ sudo aptitude update
Get:1 http://security.ubuntu.com lucid-security Release.gpg [198B]
...
Fetched 1,066kB in 8s (121kB/s)
Reading package lists... Done

Current status: 3 updates [+3].
drago@ubuntu:~$ sudo aptitude safe-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading extended state information
Initializing package states... Done
The following packages will be upgraded:
libgudev-1.0-0 libudev0 udev
3 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 637kB of archives. After unpacking 0B will be used.
Do you want to continue? [Y/n/?]
Writing extended state information... Done
Get:1 http://us.archive.ubuntu.com/ubuntu/ lucid-updates/main libudev0 151-12.3 [119kB]
Get:2 http://us.archive.ubuntu.com/ubuntu/ lucid-updates/main udev 151-12.3 [410kB]
Get:3 http://us.archive.ubuntu.com/ubuntu/ lucid-updates/main libgudev-1.0-0 1:151-12.3 [108kB]
Fetched 637kB in 5s (126kB/s)
(Reading database ... 175210 files and directories currently installed.)
Preparing to replace libudev0 151-12.2 (using .../libudev0_151-12.3_i386.deb) ...
Unpacking replacement libudev0 ...
Preparing to replace udev 151-12.2 (using .../udev_151-12.3_i386.deb) ...
Adding `local diversion of /sbin/udevadm to /sbin/udevadm.upgrade'
Unpacking replacement udev ...
Preparing to replace libgudev-1.0-0 1:151-12.2 (using .../libgudev-1.0-0_1%3a151-12.3_i386.deb) ...
Unpacking replacement libgudev-1.0-0 ...
Processing triggers for ureadahead ...
ureadahead will be reprofiled on next reboot
Processing triggers for man-db ...
Setting up libudev0 (151-12.3) ...

Setting up udev (151-12.3) ...
udev start/running, process 8824
Removing `local diversion of /sbin/udevadm to /sbin/udevadm.upgrade'
update-initramfs: deferring update (trigger activated)

Setting up libgudev-1.0-0 (1:151-12.3) ...

Processing triggers for libc-bin ...
ldconfig deferred processing now taking place
Processing triggers for initramfs-tools ...
update-initramfs: Generating /boot/initrd.img-2.6.32-27-generic
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading extended state information
Initializing package states... Done

Current status: 0 updates [-3].

Всичко това много прекрасно, но гледам нещо интересно:

update-initramfs: Generating /boot/initrd.img-2.6.32-27-generic

И така в играта влиза update-initramfs, но защо генерира образ само за последното ядро е странно. Преглеждам списъка с ядра, и най-накрая решавам да почистя висящите "за поколенията" конфигурации на 2.6.32-[22-25] (самите ядра отдавна са махнати):

drago@ubuntu:~$ sudo aptitude purge linux-image-2.6.32-25-generic linux-image-2.6.32-24-generic linux-image-2.6.32-23-generic linux-image-2.6.32-22-generic
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading extended state information
Initializing package states... Done
The following packages will be REMOVED:
linux-image-2.6.32-22-generic{p} linux-image-2.6.32-23-generic{p} linux-image-2.6.32-24-generic{p}
linux-image-2.6.32-25-generic{p}
0 packages upgraded, 0 newly installed, 4 to remove and 0 not upgraded.
Need to get 0B of archives. After unpacking 0B will be used.
Do you want to continue? [Y/n/?]
Writing extended state information... Done
(Reading database ... 183831 files and directories currently installed.)
Removing linux-image-2.6.32-22-generic ...
Purging configuration files for linux-image-2.6.32-22-generic ...
Running postrm hook script /usr/sbin/update-grub.
Generating grub.cfg ...
Found linux image: /boot/vmlinuz-2.6.37-rc7-sched
Found initrd image: /boot/initrd.img-2.6.37-rc7-sched
Found linux image: /boot/vmlinuz-2.6.32-27-generic
Found initrd image: /boot/initrd.img-2.6.32-27-generic
Found linux image: /boot/vmlinuz-2.6.32-26-generic
Found initrd image: /boot/initrd.img-2.6.32-26-generic
Found memtest86+ image: /boot/memtest86+.bin
done

Парчето GRUB се повтаря 4 пъти съответно броя на махнатите ядра. Дотук всичко изглежда прекрасно, всичко което трябва да се случи за 2.6.37-rc7-sched се случва и ето и последния тест:

# shutdown -r now

Не мръдвам и пръст и машината стартира. Епопеята приключи до следващия път с нова компилация на ядро. Вероятно ще зарежа 2.6.37 и неговата стабилизация, така и така няма да има бог знае каква разлика с rc7 и ще чакам излизането на 2.6.38. Там вече "магическия" 200 реда пач ще е включен по подразбиране, ако Линус и компания не решат друго. За мен обаче остава момента на оптимизиране на ядрото, конфигурацията която ползвам е твърде далеч от оптималната за моя частен случай, но пък е преносима на всяка i386 машина под Убунту. Не че това е утешение... Страдам и от бъгове на apparmor 680485 и 670318. За тях обаче не може да се направи много. Както казва John Johansen:

"The upstream kernel does not have the compatibility patches, and never will. So mainline kernels will report this problem, and Ubuntu kernels that have not the patches forward ported yet will report this temporarily."

Освен да докопам пачове и да си пачвам сам ядрото преди компилация на пионерски начала. Интересно дали старите връзки ще свършат работа в случая?

2.6.37-rc7-sched - продължението

Инсталирам на домашната машина. Този път гледам с очите си. Инсталацията минава нормално, с изключение на липсващия /boot/initrd.img-2.6.37-rc7-sched. Е, добре, проба. Очакван резултат - kernel panic.

# update-initramfs -c -k 2.6.37-rc7-sched; shutdown -r now

Същия ефект... хмммм. Прави впечатление обръщението към /dev/sda1. Преглеждам и /boot/grub/grub.cfg и някак се набива на очи несъвпадението между останалите редове с други ядра и прясно инсталираното - липсва ред! Този:

initrd /boot/initrd.img-2.6.37-rc7-sched

Като рут устройство е посочено /dev/sda1, останалите са с UUID. Смело и безотговорно добавям root=UUID= и реда с initrd.img и системата стартира с проклетото ядро. Не беше много трудно, нали?

В заключение: странно как инсталацията на същия пакет на тестовата машина протече без този проблем - всичко гладко и равно като по ноти. Отдавам го на различието на версиите - 10.10 и 10.04. Остава открит въпросът как ще се държи машината при ъпгрейд на ядро или при такъв засягащ ГРУБ, когато бут параметрите се преконфигурират - нали съм изменил конфигурацията не там където трябва.

2.6.37-rc7-sched

След 5 до 7 компилации, от които 2 завършили с грешка, която ме мързеше да ровичкам, останалите - успешни, но завършващи с kernel panic накрая работещо последното ванила ядро release candidate 7 с включен 200 редов пач:

drago@ubuntu:~/tmp$ ll
total 43412
drwxr-xr-x 25 drago users 4096 2010-12-23 12:57 linux-2.6.37-rc7/
-rw-r--r-- 1 drago users 7125842 2010-12-23 12:58 linux-headers-2.6.37-rc7-sched_2.6.37-rc7-sched-10.00.Custom_i386.deb
-rw-r--r-- 1 drago users 37312506 2010-12-23 12:56 linux-image-2.6.37-rc7-sched_2.6.37-rc7-sched-10.00.Custom_i386.deb
drago@ubuntu:~/tmp$ uname -a
Linux ubuntu 2.6.37-rc7-sched #1 SMP Thu Dec 23 11:57:11 EST 2010 i686 GNU/Linux

ПП В къщи така и така работи bash групирането на процесите, любопитен съм какво ще стане като наложа и двете върху една машина. Предстои довечера... stay tunned.

ППП "Успешни" компилации!? Издънки на етап компилиране на виндовс(R) драйвер за нещо си, който просто махам от конфигурацията, при формиране на дебиан пакета поради бъг в kernel-package, за който се налага ъпгрейд от PPA до 12.036-~ppa и определено писналите ми kernel panic, които в крайна сметка няма как да определя като "успешни"...

Упс...

Докато няма какво да се прави - търся "linux kernel patch 200 lines". Първи резултат:

www.phoronix.com/scan.php?page=article&item=linux_2637_video&num=1

Кликам на вълшебната връзка (patch) във втория параграф и попадам на емайл линия:

marc.info/?l=linux-kernel&m=128978361700898&w=2

Оттук-оттам поразглеждам кода и решавам да запиша всичко под трите тирета:

---
Documentation/kernel-parameters.txt | 2
...

и до подписа (който не знае подписът за всеки емайл клиент започва с две тирета).

Междувременно съм се запалил по UASP (USB Attached SCSI) драйвера в ядрото ( www.opennet.ru/opennews/art.shtml?num=28987) и се занимавам с компилация, дърпайки го "от извора" github.com/ltuikov/linux-2.6, като междувременно научавам git, това, че ползвайки Убунту указания не винаги помага при положение че git клонинга не е от Убунту/Дебиан, а ванила, при което указанията blog.avirtualhome.com/2010/11/06/how-to-compile-a-ubuntu-10-10-maverick-kernel/ не стават и си караме по стария начин www.howtoforge.com/kernel_compilation_ubuntu без разбира се да забравяме благините на Убунту/Дебиан като make-kpkg. Докато цялата тази работа се случва обаче ми свършва мястото на диска (глупава нова работа! Да работиш в линух виртуална машина на виндовс(R) хост си е просто извращение!) и трябва да увелича диска, дяла, файловата система, нов суоп дял, нов UUID...) В крайна сметка

drago@ubuntu:~$ uname -a
Linux ubuntu 2.6.37-rc5-uasp #1 SMP Mon Dec 20 13:16:35 EST 2010 i686 GNU/Linux
drago@ubuntu:~$ sudo modprobe uas
[sudo] password for drago:
drago@ubuntu:~$ lsmod | grep uas
uas 7100 0

И голяма работа ще кажете вий и аз веднага ще се съглася. UASP драйвера работи с USB 3.0, което нямам. Цялото упражнение за нищо, загубено време и т.н.? Може би, но за четящите този пост, не за моя милост. Изтърквам здраво ръждата която съм хванал по въпроса прекомпилиране на ядро взето то от git или от друго. И като ми падне >= USB 3.0 комп познайте... Най-голямата изненада обаче идва най-накрая:

drago@ubuntu:~/tmp/source$ patch -p1 < /home/drago/Desktop/200_lines.patch.txt
patching file include/linux/sched.h
patching file kernel/sched.c
patching file kernel/fork.c
patching file drivers/tty/tty_io.c
Hunk #1 succeeded at 3169 (offset 9 lines).
patching file kernel/sched_autogroup.h
patching file kernel/sched_autogroup.c
patching file kernel/sysctl.c
patching file init/Kconfig
Hunk #1 succeeded at 741 (offset 13 lines).
patching file Documentation/kernel-parameters.txt

Опит за пач просто за спорта работи!?! И то с файл, който чисто наслуки съм копирал от някъде си... Излиза вече мога да разпозная пач просто като го видя в емайл! Във всеки случай горкото чисто ново ядро трябва да се прекомпилира, преди да работи и час...

Compile wireshark in Ubuntu 10.04

Download source from http://www.wireshark.org/download.html

Now the version is 1.8.0, procedure still works, but there are some additional bits added, as example using c-ares, GNU ADNS and SMI MIB libraries.

$ tar -jxf wireshark-1.2.10.tar.bz2

# read INSTALL and check dependencies
$ pkg-config glib-2.0 --modversion
$ glib-config --version
$ gtk-config --version

# install dependencies
$ sudo aptitude install --add-user-tag wir libgtk2.0-dev
$ pkg-config glib-2.0 --modversion # confirm that it's working now
$ glib-config --version
$ pkg-config gtk+-2.0 --modversion

Good, let's install the rest of dependencies.
$ sudo aptitude install --add-user-tag wir libgtk2.0-dev libpcap0.8-dev bison flex libssl-dev libgnutls-dev libpcre3-dev libadns1-dev libc-ares-dev libsmi2-dev # I have libpcap0.8 installed already, you may need to install it as well.

./configure --with-ssl --with-gnutls --with-c-ares --with-libsmi
# two possible ways from here - traditional make, or Debian/Ubuntu making .deb pakages
Use method #1 for 10.04, this way the compilation completes nowadays in this old Ubuntu version, making debian packages fail because of libraries dependencies.
## 1
$ make; make install # if make is followed by make debian-package the whole compilation runs from the beginning. Skip this step and go to #2 instead

## 2
# add dependencies
$ sudo aptitude install --add-user-tag wir dpatch libtool automake1.9 autoconf autotools-dev libc-ares-dev docbook-xsl libpcre3-dev libcap-dev libgnutls-dev portaudio19-dev libkrb5-dev liblua5.1-0-dev libsmi2-dev libgeoip-dev # adding dependent packages for .deb building

# ...and make
$ make debian-package
Note: Right now there is a bug in 1.8.0, which is fixed in SVN and for 1.8.1, but debian-package fails under 12.04 LTS

# install (packages are one directory up)
$ sudo dpkg -i wireshark wireshark-common tshark

#now clean packages installed to resolve dependencies, but accept the second solution, leaving dependent packages intact:

$ sudo aptitude purge '?user-tag(wir)'

Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading extended state information
Initializing package states... Done
The following packages are BROKEN:
wireshark-common
The following packages will be REMOVED:
autoconf{p}...
...
...
... xtrans-dev{p}
0 packages upgraded, 0 newly installed, 92 to remove and 0 not upgraded.
Need to get 0B of archives. After unpacking 114MB will be freed.
The following packages have unmet dependencies:
wireshark-common: Depends: libc-ares2 (>= 1.7.0) but it is not installable
Depends: libsmi2ldbl but it is not installable
The following actions will resolve these dependencies:

Remove the following packages:
tshark
wireshark
wireshark-common

Score is -463

Accept this solution? [Y/n/q/?] n
The following actions will resolve these dependencies:

Keep the following packages at their current version:
libc-ares2 [1.7.0-1 (lucid, now)]
libsmi2ldbl [0.4.8+dfsg2-2 (lucid, now)]

Score is -19930

Accept this solution? [Y/n/q/?] y

Автоматично публикуване на IRC лог

Постановка на задачата - имаме IRC канал, на който трябва да се води лог, който да е публично достъпен. Вариантът с ръчно записване на лога и ъплоуд беше допустим като тест (макар така и да не се намери тестер). И така първи етап - запускане на лог бот. Използван беше IRC LogBot написан от Neo2k8 с предимството да е прост, да върши едно, и да го върши добре (unix way ;-)) и да е на PERL. Логът бързо порастна до над 1 Mb, като така си стоеше на машината с работещия бот. Преминаваме към втори етап - автоматичен ъплоуд, с нулиране на лога всеки ден. Първият лог беше изпратен на веб-сървъра в оргиналния му вид, всеки следващ ден трябваше да постъпва автоматично. Достъпът до сървъра е ограничен до scp и sftp, така че оставаме в тези рамки на организация на трансфера. Пишем bash скрипт:

#!/bin/sh

this_day = $(date +%F)

/usr/bin/pkill -f L0g_b0t.pl

/bin/mv "#channel_name.txt" $this_day.txt

/usr/bin/lftp -u username,password sftp://domain.org << END_UPLOAD cd www/irc_logs put $this_day.txt chmod 644 $this_day.txt END_UPLOAD /usr/bin/perl L0g_b0t.pl

Добавяме скрипта за изпълнение в cron, малко преди полунощ:

50 23 * * * cd /home/user/log_bot;./daily_logbot.sh

Особености: L0g_b0t.pl трябва да бъде пуснат ръчно, като първия старт се задават параметрите за връзка: IRC server, port, channel, IRC nick, след което трябва да бъде вторично пуснат отново, за да започне работа. Всички параметри се задават задължително, ботът малко подвеждащо показва стойности в квадратни скоби, приличащи на стойности по подразбиране, като всъщност те са само препоръчителни.