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

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