Доброго времени суток, с Новым Годом! Собственно, несколько недель назад собрал себе ядро с модулем 8188eu от KanuX с Github, поставил ядро, настроил в NetworkManager AP и спокойно пользовался раздающимся через свисток по квартире инетом, с ноутом в режиме сервера и торрентосмотрелки, как вдруг, после очередных обновлений пакетов с автообновлением initrd и последующего ребута в ту же версию ядра, AP поломалось. NM-applet постоянно пытается подключиться к моей сети, но - «Соединение разорванно».

iwconfig:

wlan0 unassociated Nickname:«<WIFI@REALTEK>» Mode:Managed Frequency=2.462 GHz Access Point: Not-Associated Sensitivity:0/0 Retry:off RTS thr:off Fragment thr:off Power Management:off Link Quality:0 Signal level:0 Noise level:0 Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0

ip a:

wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2312 qdisc mq state DORMANT group default qlen 1000 link/ether 00:1c:05:81:97:0f brd ff:ff:ff:ff:ff:ff

dmesg | grep 8188:

[ 61.585866] 8188eu: module is from the staging directory, the quality is unknown, you have been warned. [ 61.850073] usbcore: registered new interface driver 8188eu [ 112.324084] 8188eu 5-1.2:1.0 wlan0: Current addr: 00 1c 05 81 97 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 112.324092] 8188eu 5-1.2:1.0 wlan0: Expected addr: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 113.306127] ==> rtl8188e_iol_efuse_patch

cat /etc/issue:

Debian GNU/Linux trixie/sid

cat /etc/apt/apt.conf:

APT::Default-Release «unstable»; APT::Install-Recommends «false»;

uname -r:

6.5.2-zen-060502-generic++

Вот так, только что работало и перестало. На том же ядре. Почему NM не может сделать UP для wlan0? Я давно сижу на Сиде и видывал немало, но чтоб такая мистика случалась припомнить не могу. Подскажите, куда копать?

Имею старенький ноут для экспериментов и обкатки ПО
inxi -Fxz:

( читать дальше... )

Под Ubuntu 16.04/Debian stretch/sid.Dualboot.
Собираю ядра из linux-stable.git и zen-kernel и все прекрасно работало (в смысле drm-intel) модесеттинг (i915.modeset=1 i915.enable_execlist=0) включался,аппаратное ускорение с mesa
dri,куб в compiz крутится...До выхода в свет ветки ядра 4.3.х в которой что-то поломали в стеке drm-intel и модесеттинг больше не работает!Т.е. при попытке загрузки с параметрами i915.modeset=1 i915.enable_execlist=0 случается черный экран и тишина.Ядра ветки 4.3.х грузятся только с nomodeset,но при этом не включается аппаратное ускорение mesa dri а включается gallium llvmpipe,CPU на 100% c compiz и любое видео жутко тормозит.(( А ядра ветки 4.2.х загружаются корректно.
Если кто-нибудь сталкивался с таким явлением на i915 + linux 4.3.x или знает,как победить черный экран при загрузке,прошу,помогите включить модесеттинг!

Собственно,искал замену BFQ.Очень хвалят VR,но он вроде под Android?Можно ли его прикрутить к последним исходникам linux c kernel.org и где взять?Неделю искал - не нашел,может кто-нибудь пробовал более успешно?...

Последнее время,в Debian,с переходом на очередной Stable релиз «Wheezy»,пропала возможность создавать Live-USB сборки с режимом сохранения состояния (Persistent Mode) при помощи простой распаковки содержимого дистрибутивного или кастомного образа на подготовленный раздел флешки,установки загрузчика и последующего создания в корне устройства самого файла сохранённых состояний - live-rw,отформатированного в ext3 FS или другую ext* FS по вкусу.Мне вот давеча понадобилось,вот и столкнулся с такой проблемой...Persistent просто не работал!Поиски в Гугле внятного решения не дали,так что пришлось разбираться самому и о результате этих разбирательств было решено написать этот трэд. Собственно,решение пришло после проверки содержимого пакетов live* текущего Wheezy и oldstable Squeeze, и оказалось зарыто в конфиге /usr/share/initramfs-tools/scripts/live из live-boot-initramfs-tools прежнего oldstable и ненешних «обновленных» версий для stable/testing/sid/experimental,так как в версии oldstable имеется набор прямых директив на использование конкретного файла сохраненных состояний в корне загрузочного устройства:

( читать дальше... )

а в более новых версиях в этом конфиге лишь указание читать конфиг /lib/live/boot.sh,в котором только:

( читать дальше... )

и это,естейственно,не работает,поскольку имеется ввиду не файл live-rw,а в лучшем случае раздел с такой меткой... Выходом из положения,здесь является даунгрейд пакета live-boot-initramfs-tools до oldstable версии или всей ветки live*,если потребуется,с предварительной заморозкой пакета udev текущей версии.Исходя из предположения,что вы делаете свою сборку LiveCD/DVD/USB на базе рабочей системы или хотя бы временно установили дистрибутивную поставку на подготовленный сборочный раздел и находитесь в целевой системе,хотя бы в CHROOT-e...:

echo "udev hold" | sudo dpkg --set-selections

wget http://ftp.ru.debian.org/debian/pool/main/u/udev/udev_164-3_i386.deb
mkdir pkg
atool -X pkg udev_164-3_i386.deb
cd pkg/lib/udev
ls
sudo rsync -var path_id usb_id input_id /lib/udev
sudo nano /usr/share/initramfs/hooks/udev
...

...
cp /lib/udev/hotplug.functions $DESTDIR/lib/udev/
cp /lib/udev/hwdb.bin $DESTDIR/lib/udev/
cp /lib/udev/usb-db $DESTDIR/lib/udev/
cp /lib/udev/pci-db $DESTDIR/lib/udev/
for program in firmware.agent hwdb.bin usb-db pci-db ata_id edd_id scsi_id path_id usb_id input_id; do
  copy_exec /lib/udev/$program /lib/udev
done
copy_exec /sbin/blkid /sbin
...

sudo update-initramfs -vuk all

cp -vf /boot/initrd.img-`uname -r` /media/$YOUR_USB_LABEL/live/initrd.img
cp -vf /boot/vmlinuz-`uname -r` /media/$YOUR_USB_LABEL/live/vmlinuz

mv -vf /media/$YOUR_USB_LABEL/live/filesystem.squashfs
dd if=/dev/zero of=sfs.img bs=1M count=9000
mkfs.ext4 -F sfs.img
tune2fs -r 0 -m 0 -c 0 sfs.img
sudo modprobe loop
sudo mount -o rw sfs.img /mnt
sudo rm -rf /mnt/*
sudo unsquashfs -f -d /mnt *.squashfs
sudo rm -f /mnt/boot/vmlinuz* /mnt/boot/initrd.img*
sudo cp -vf /boot/initrd.img-`uname -r` /mnt/boot
sudo cp -vf /boot/vmlinuz-`uname -r` /mnt/boot
mv -vf *.squashfs fs.sfs.old
sudo mksquashfs /mnt filesystem.squashfs
mv -vf filesystem.squashfs /media/$YOUR_USB_LABEL/live
sudo umount /mnt
rm -f fs.sfs.old sfs.img

Собственно,хотелось декораций консоли - FBcondecor,но с красивым Plymouth при загрузке,широкой поддержки Reiser4,BFS,BFQ,Numa,возможности записи на разделы UFS2 & HFS+,AUFS,PAE,ну и Boot Logo в виде спиралек Debian. Поиски не давали чего-либо готового,годного к использованию,а под дистрибутивные исходники ядра,либо не было в наличии нужных патчей,либо было невозможно их применить.Должен признать,что считал проект Zen распавшимся на форки Liquorix & Pf-kernel,создавшими у меня не очень приятное впечатление из-за своей урезанности,ИМХО... Однако,обнаружил живой и здравствующий Zen-Kernel на GitHub и сразу получилось всё и сразу:

#!/bin/sh
rm -rf zen*
sleep 2
git clone git://github.com/damentz/zen-kernel zen-kernel
sleep 2
wget -O reiser4-for-3.13.6.patch.gz 'http://sourceforge.net/projects/reiser4/files/reiser4-for-linux-3.x/reiser4-for-3.13.6.patch.gz/download'
sleep 2
gunzip reiser4-for-3.13.6.patch.gz
cd zen*
sleep 2
patch -p1 < ../reiser4-for-3.13.6.patch
sleep 2
cp -vf /boot/config-`uname -r` .config
sleep 2
make menuconfig
echo "Если все включил,так и будем собирать ведро,а если нет - жми CTRL+C !!! "
sleep 8
fakeroot make-kpkg -j3 --initrd --revision=3.13.8 --uc --us kernel_image kernel_headers

Итак:

1.Правильно прописать ревизию при сборке ядра (3.13.8-zen+) не получается из-за Debian Policy, ругающихся на дефис или что-то-там-ещё...ЧЯДНТ?В итоге на выходе получаются пакеты с именами: linux-headers-3.13.8-zen+_3.13.8_i386.deb & linux-image-3.13.8-zen+_3.13.8_i386.deb - причём в составе linux-headers* имеется файл linux-headers.revision с неправильной версией ревизии и, как следствие,начинаются проблемы при пересборке модулей ядра с помощью DKMS.Решается просто:

sudo dpkg -x linux-headers-3.13.8-zen+_3.13.8_i386.deb pkg
sudo mkdir pkg/DEBIAN
sudo dpkg -e linux-headers-3.13.8-zen+_3.13.8_i386.deb pkg/DEBIAN
echo "3.13.8-zen+" | sudo tee pkg/usr/src/linux-headers-3.13.8-zen+/linux-headers.revision
sudo rm -f linux-headers-3.13.8-zen+_3.13.8_i386.deb
sudo dpkg-deb -b pkg linux-headers-3.13.8-zen+_3.13.8_i386.deb
sudo rm -rf pkg/*

2.В пакете самого ядра - linux-image-3.13.8-zen+_3.13.8_i386.deb - создаются ссылки lib/modules/3.13.8-zen+/{build,source} на локальный репозиторий git - исходный каталог сборки zen-kernel,а это ещё большая проблема для DKMS. Решается так же просто:

sudo dpkg -x linux-image-3.13.8-zen+_3.13.8_i386.deb pkg
sudo mkdir pkg/DEBIAN
sudo dpkg -e linux-image-3.13.8-zen+_3.13.8_i386.deb pkg/DEBIAN
sudo rm -f pkg/lib/modules/3.13.8-zen+/build
sudo rm -f pkg/lib/modules/3.13.8-zen+/source
sudo mkdir /usr/src/linux-headers-3.13.8-zen+
sudo ln -sfs /usr/src/linux-headers-3.13.8-zen+ pkg/lib/modules/3.13.8-zen+/build
sudo ln -sfs /usr/src/linux-headers-3.13.8-zen+ pkg/lib/modules/3.13.8-zen+/source
sudo rm -f linux-image-3.13.8-zen+_3.13.8_i386.deb
sudo dpkg-deb -b pkg linux-image-3.13.8-zen+_3.13.8_i386.deb
sudo rm -rf pkg/* && sudo rm -f /usr/src/linux-headers-3.13.8-zen+
sudo dpkg -i *.deb