Void and Null

Внезапно закъсах за място на линукския дял и проведеното разследване показа, че имам 300МВ *неща* в /var/spool/clientmqueue Дълги са по около килобайт и са толкова много че rm не иска да ги трие
# rm * /bin/rm: Argument list too long.
# ls |wc -l 92562

Ето какво представлява едно от тези *неща*:
cat dfm2C0t6aE007318

}
Помня че едно време си играх с arpwatch и той имаше някаква опция да праща отчети при смяна на MAC адрес по пощата, ама това не си е отчет ами просто някакъв дъмп от print_r() функцията в PHP. Шаш Изтриха се де:

# rm *0
# rm *1
# rm *2
.....
Сега да открия какво е оставило такива спомени там

Това го има на няколко места в нета, но на всичките по нещо куцаше, така че реших да напиша как стана при мен.
1) В ядрото трябва да имате:
CONFIG_UFS_FS (Filesystems -> Miscellanious -> UFS filesystem support) - можете да го сложите като модул, но ако искате по-късно автоматично монтиране от fstab, ще трябва да го вкарате в ядрото. Ако го сложите като модул, във fstab ще опишете файловата система с noauto (иначе mount протестира че няма такава файлова система ufs - поне при мен не си зарежда автоматично модула) и в rc.local си добавете “modprobe ufs”
CONFIG_BSD_DISKLABEL (Filesystems -> Partition types -> Advanced partition selection -> PC BIOS -> BSD disklabel) - това няма опция за компилиране на модул - само директно в ядрото

2) Ако ядрото ви е наред, време е да откриете точно кое устройство ви носи UFS файловата система.

dmesg | grep bsd

Ще се види нещо като:

sdb1: <bsd: sdb6 sdb7 >

Тук Linux вижда 1 устройство - sdb1, но FreBSD си има по-особена организация на файловите системи. Вероятно сте запознати с това, така че ще ви го спестя. Да видим как са разпознати от boot процеса на Linux - sdb6 и sdb7.
Едното ми е swap дяла, а другото root на файловата система. Ако се съмнявам кое кое е, ще пробвам по отделно:

3) Монтиране с mount:
- изберете типа на UFS - при съвременните BSD-та (или поне на FreeBSD7) е ufs2

# mount -r -t ufs -o ufstype=ufs2 /dev/sdb6 /mnt/bsd/
# ls /mnt/bsd
COPYRIGHT boot compat dist etc lib media proc root sys usr
bin cdrom dev entropy home libexec mnt rescue sbin tmp var

Уцелих от първия път

4) Описване в /etc/fstab

/dev/sdb6 /mnt/bsd ufs ro,ufstype=ufs2 0 0

По желание можете да сложите
noauto - ако сте компилирали ufs support на модул вместо директно в ядрото
users - за монтиране от обикновени потребители без root привилегии

Всеки мрази проблеми. От всякакво естество. А най-отвратително е когато проблема уж се реши, а се оказва че само е отложен/разсеян/заобиколен/подтиснат…
Проблема е че LAN картата на случайни интервали от време спира да работи и единствения начин да се пусне е рестарт на машината. В dmesg имам:

NETDEV WATCHDOG: eth0: transmit timed out

LAN картата е Realtek 8139. Текуща версия на ядрото - 2.6.25.6, но проблема съществува във всички 2.6.х
В нета са изписани хиляди мнения по въпроса - никой не може да каже точно какво е. Навсякъде се повтаря ‘грешка в драйвъра на картата’. На места пишат че от 2.6.24 нагоре проблема е оправен - да, ама не. На места пишат че Windows записвал някакви шитни в паметта на картата, които пречат на други операционни системи да активират картата. Глупости, защото във FreeBSD нямам проблеми. Всъщност проблема се появява дори след рестарт от FreeBSD към Линукс.
Ето някои мои наблюдения върху феномена:
1) Грешката се появява само след рестарт от друга операционна система към Линукс.
2) Картата се изключва в абсолютно случаен момент от време - не зависи от мрежовото натоварване, от температурата или от фазата на Венера.
3) Ако се рестартира машината след получаване на грешката, има шанс това пак да се случи. Единствената застраховка - гарантирано че мрежата няма да изчезне - да се мине през пълен shut down. През какъвто и да е рестарт (топъл, студен) или стоп на машината да се мине, има шанс следващия път проблема пак да се появи.

На места намирам препоръка да се изключи tcp segmentation offload (каквото и да значи):

ethtool -K eth0 tso off

Не върши работа.

Някой казват че проблема е свързан с ACPI и препоръчват в процеса на boot-ване да се добави стринга “noacpi”. Не работи.

Най-тъпото е че Проблема (мисля че си заслужи главната буква) не може да се дебъгне с никакви конвенционални средства. Току изглежда че някаква магическа мантра помага - мрежата не пада… и след Х часа/дни/седмици пак се издъни.

А на всичкото отгоре DNS-a на доставчика ми внезапно спря да прави resolve на ivanatora.info.

От няколко дни съм вкъщи с native-installed FreeBSD 7.0. Как стана това - взех си нов хард (WD3200AAKS), хвана ме летния саклет… и айде
Инсталацията мина горе-долу като инсталация на Slackware. Малко се видях в чудо с местния еквивалент на fdisk - FreeBSD-то се инсталира на част от цял partition, който се нарича slice. Т.е. partitions се състоят от по-малки дялове - slices. Инструмента за разделянето на диска си има автоматични настройки, но само като видях как ми разхвърля мястото в 3-4 mount points ми стана лошо и взех операцията на ръчно. Всъщност много хора подкрепят гъвкавото разпределение на файловата система - един partition за /home, един за /var, един за /usr и т.н… но до сега съм имал повече проблеми с такова разпределение, от колкото ползи.
Повече четете надолу:
(more…)

Отдавна използвам aterm и до сега само едно ме е дразнело - настройката на прозрачността. Днес попаднах на едно решение, което ми обърна идеите и прозрачността се получи по най-подходящия начин. Да караме едно по едно
До скоро това ми бяха настройките на aterm:
aterm*colorMode: true
aterm*tinting: #79b6d5
aterm*transparent:true
aterm*foreground: #9eff6f
aterm*geometry:83x35
aterm*truetintingType: True
aterm*title: AteRm
aterm*saveLines: 1000
aterm*font: -rfx-courier-medium-*-*-*-14-*-*-*-*-*-*-cp1251

Прозрачността се осъществяваше чрез ‘tinting’ (предаване на нюанс). Естествено тинтването може да изчезне, като остава само най-важния ред - aterm*transparent:true. По този начин се вади абсолютно прозрачна конзола, като текста се пише с нормални букви. Проблема е че ако отзад имате шарен тапет, буквите на места се сливат с него и въобще не е удобно.
Какво прави тинтинга? Накратко казано на всеки пиксел се придава нюанс (цвета се определя с aterm*tinting: #79b6d5). След това може да се направи някаква допълнителна трансформация на ефекта с aterm*truetintingType. Получават се доста шарени резултати. Ако тапета е относително едноцветен или не е много контрастен, ефекта е уникален. Ако обаче тапета е шарен… целия ефект се превръща от плюс в един голям минус
Понякога се налага и цялостна промяна на конфигурацията - tint-ващ цвят и режим - когато тапета се смени с нов, чиято цветова гама е неподходяща.
Решението на проблема е tinting-а да се изключи изцяло. Всичко свързано с tinting се маха и се добавя един-единствен ред:
aterm*shading:40
Това задава потъмняване на областта на конзолата без добавяне на специални ефекти. Получава се универсална прозрачност, която може да бъде използвана с всякакви тапети. Предполагам, че това може да се получи и с tinting, ако се използва черен цвят и подходящия режим, но със shading ми се струва по-елегантно и подходящо.
Ето един шот с новата прозрачност. Оцветяването е от vim: