that was yesterday…

сряда, юни 24th, 2009

10.00 a.m. – няма ток в collocation центъра

16.00 p.m. – dmesg | grep sda:

ReiserFS: sda1: warning: vs-13060: reiserfs_update_sd: stat data of object [91527 91528 0x0 SD] (nlink == 1) not found (pos 1) – (очертава се денят да е дълъг)

17.00 p.m.:

umount /dev/sda1
reiserfsck –check /dev/sda1

Checking internal tree..finished
Comparing bitmaps..finished
Fatal corruptions were found, Semantic pass skipped
1 found corruptions
###########

17.30 p.m.:

reiserfsck –scan-whole-partition –rebuild-tree /dev/sda1 – и стискам палци

17.30 – 23:00 p.m.

три бири в приятна компания :)

едно уиски докато чакам да минем от 80% на 100%

23;10 p.m.

###########
reiserfsck finished at Tue Jun 23 23:09:32 2009
###########

23:15 p.m.:

yum upgrade

00:30 p.m. – welcome to the machine :)


linux convert jpg to pdf

понеделник, юни 15th, 2009

Преди няколко дни ми се наложи да редактирам pdf файл направен от някаква скенер програмка на Xerox, която обединява всички сканирани страници в един общ файл. Проблемът е, че както и да му подадеш листа, във файла в последствие някои от страниците са обърнати на 180°. Rotate от самия pdf reader не върши работа, защото завърта всичко глобално. Така че се налага да разбием файла така да се каже на съставните му части и да обърнем страниците, които имат нужда от това. Варианти да се направи това има няколко. Може да стане и графично с The GIMP,  и в command line с convert, който е част от ImageMagick.

Графично това става по следния начин:

  • отваряме желания pdf файл с GIMP
  • в менюто import from pdf избираме Select All (или Select Range ако искаме да обърнем само първите три страници да речем)
  • Open Pages As Images

и на края естествено Import така GIMP отваря всяка (или всяка посочена) страница като отделна картинка, която можем да редактираме и запишем в желания формат.

gimp-pdf-import

Втория и според мен много по-лесен начин е този с convert, като просто трябва да изпълним следното:

convert input.pdf image_%03d.tiff

или

convert input.pdf image_%03d.jpg

ако предпочитаме jpg изходни файлове, като „%03d“ означава, че в името ще имаме image_ последвано от 3 цифри, предхождани от нули от рода 001, 002 или в крайна сметка image_00x.jpg. И ако картинката, която има нужда от завъртане е 003, то стигаме до:

convert -rotate 180 image_003.jpg output.jpg

На края остава да съединим картинките и да получим първоначалния файл, но вече без страници, които са с с главата надолу :), като това става по следния начин:

convert *jpg modified.pdf

като така получаваме pdf файл, в който всяка входяща картинка е на отделна страница.

Това естествено съвсем не е всичко, което можем да направим с convert. Повече може да се види тук или в man-а.

Забележка:
Последната стъпка поне на този етап не работи и няма да работи във Fedora 11. Повече тук.

Tool of the Day – dmidecode

вторник, февруари 17th, 2009

Понякога се налага да добием информация за хардуера на дадена машина. Причини много.  Ако машината е наоколо винаги може да се отвори и да се провери. Но ако е през два-три етажа, или в офиса във Варна, или пък колокирана в нечие сървърно това не е опция. Още повече, че за да се отвори дадена машина, първо трябва да се спре. Когато става дума за десктоп станция, това не е проблем, но ако става дума за сървър нещата стоят по друг начин. Dmidecode върши работа и в двата случая. Цитат от страницата на проекта:

Dmidecode reports information about your system’s hardware as described in your system BIOS according to the SMBIOS/DMI standard . This information typically includes system manufacturer, model name, serial number, BIOS version, asset tag as well as a lot of other details of varying level of interest and reliability depending on the manufacturer. This will often include usage status for the CPU sockets, expansion slots (e.g. AGP, PCI, ISA) and memory module slots, and the list of I/O ports (e.g. serial, parallel, USB).

С други думи програмата чете това, което й казва BIOS-a. Ако той лъже, и тя ще излъже. Така че за съжаление не може да се вярва на изхода на 100%. Тествах я на близо 10-на машини, на повечето, от които знам с точност хардуерните характеристики и не сгреши никъде, така че лично аз й имам достатъчно доверие.

За мен най-полезната опция е -t, –type TYPE. Като съответните възможности са:

DMI TYPES
The SMBIOS specification defines the following DMI types:

Type   Information
—————————————-
0   BIOS
1   System
2   Base Board
3   Chassis
4   Processor
5   Memory Controller
6   Memory Module
7   Cache
8   Port Connector
9   System Slots
10   On Board Devices
11   OEM Strings
12   System Configuration Options
13   BIOS Language
14   Group Associations
15   System Event Log
16   Physical Memory Array
17   Memory Device
18   32-bit Memory Error
19   Memory Array Mapped Address
20   Memory Device Mapped Address
21   Built-in Pointing Device
22   Portable Battery
23   System Reset
24   Hardware Security
25   System Power Controls
26   Voltage Probe
27   Cooling Device
28   Temperature Probe
29   Electrical Current Probe
30   Out-of-band Remote Access
31   Boot Integrity Services
32   System Boot
33   64-bit Memory Error
34   Management Device
35   Management Device Component
36   Management Device Threshold Data
37   Memory Channel
38   IPMI Device
39   Power Supply

Съответно, ако ни интересува какво е дъното:

[root@Galactica ~]# dmidecode -t 2
# dmidecode 2.9
SMBIOS 2.3 present.

Handle 0×0002, DMI type 2, 8 bytes
Base Board Information
Manufacturer: ASUSTeK Computer INC.
Product Name: P5L-MX
Version: Rev x.xx
Serial Number: MB-1234567890

Aко искаме да добавим RAM памет на дадена машина dmidecode отново е наш пръв приятел:

[root@Pegasus ~]# dmidecode -t 16
# dmidecode 2.7
SMBIOS 2.33 present.

Handle 0×0016, DMI type 16, 15 bytes.
Physical Memory Array
Location: System Board Or Motherboard
Use: System Memory
Error Correction Type: Single-bit ECC
Maximum Capacity: 16 GB
Error Information Handle: Not Provided
Number Of Devices: 4

т.е. системата поддържа до 16 GB памет.
В момента имаме:

[root@Pegasus ~]# cat /proc/meminfo | grep MemTotal
MemTotal: 2059224 kB

като те са разпределени по следния начин:

[root@Pegasus ~]# dmidecode -t 17
# dmidecode 2.7
SMBIOS 2.33 present.

Handle 0×0017, DMI type 17, 27 bytes.
Memory Device
Array Handle: 0×0016
Error Information Handle: No Error
Total Width: 72 bits
Data Width: 64 bits
Size: 1024 MB
Form Factor: DIMM
Set: 1
Locator: DIMM#1A
Bank Locator: Bank 1

Type: DDR
Type Detail: Synchronous
Speed: 400 MHz (2.5 ns)
Manufacturer: Not Specified
Serial Number: Not Specified
Asset Tag: Not Specified
Part Number: Not Specified

Handle 0×0018, DMI type 17, 27 bytes.
Memory Device
Array Handle: 0×0016
Error Information Handle: No Error
Total Width: Unknown
Data Width: Unknown
Size: No Module Installed
Form Factor: DIMM
Set: 1
Locator: DIMM#2A
Bank Locator: Bank 2
Type: DDR
Type Detail: Synchronous
Speed: 400 MHz (2.5 ns)
Manufacturer: Not Specified
Serial Number: Not Specified
Asset Tag: Not Specified
Part Number: Not Specified

Handle 0x001B, DMI type 17, 27 bytes.
Memory Device
Array Handle: 0×0016
Error Information Handle: No Error
Total Width: 72 bits
Data Width: 64 bits
Size: 1024 MB
Form Factor: DIMM
Set: 1
Locator: DIMM#1B
Bank Locator: Bank 1

Type: DDR
Type Detail: Synchronous
Speed: 400 MHz (2.5 ns)
Manufacturer: Not Specified
Serial Number: Not Specified
Asset Tag: Not Specified
Part Number: Not Specified

т.е. знаем точно какво и на кой слот има, което е предостатъчна информация да си направим сметката за upgrade.

dmidecode е част от RedHat базираните дистрибуции CentOS и Fedora по подразбиране.

Допълнителна информация:
man dmidecode

Fedora 10 / KDE 4.2

понеделник, февруари 9th, 2009

KDE 4.2 излезе на 27-ми януари, но все още го няма като официален stable update за Fedora. Пакетите са минали през koji и вече са в updates-testing. Аз понеже нямах търпение да чакам update-нах когато ги нямаше и там, като ползвах ето това хранилище, което се поддържа от Rex Dieter, който се грижи основно за поддръжката и създаването на KDE пакетите за Fedora и RHEL. Там има инструкции, но ето ги все пак и тук.

Създаваме файл /etc/yum.repos.d/kde.repo със следното съдържание:

# kde.repo, v2.1

[kde]
name=kde
mirrorlist=http://apt.kde-redhat.org/apt/kde-redhat/fedora/mirrors-stable
gpgkey=http://apt.kde-redhat.org/apt/kde-redhat/kde-redhat.RPM-GPG-KEY
#gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-kde-redhat
enabled=1

[kde-testing]
name=kde-testing
mirrorlist=http://apt.kde-redhat.org/apt/kde-redhat/fedora/mirrors-testing
gpgkey=http://apt.kde-redhat.org/apt/kde-redhat/kde-redhat.RPM-GPG-KEY
#gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-kde-redhat
enabled=0

[kde-unstable]
name=kde-unstable
mirrorlist=http://apt.kde-redhat.org/apt/kde-redhat/fedora/mirrors-unstable
gpgkey=http://apt.kde-redhat.org/apt/kde-redhat/kde-redhat.RPM-GPG-KEY
#gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-kde-redhat
enabled=0

след което изпълняваме:

yum --enablerepo=kde-testing groupupdate "KDE (K Desktop Environment)"

След като пакетите вече ги има в updates-testing, същия ефект може да се постигне и по следния начин:

yum --enablerepo=updates-testing groupupdate "KDE (K Desktop Environment)"

По принцип проблеми с failed dependencies при мен нямаше, но това не е гаранция, че ще бъде така при всеки. Така че, който реши да не чака и действа по горния начин, трябва да си има едно на ум за възможни проблеми.
Като цяло KDE 4.2 се държи много по-стабилно от 4.1 и е несравнимо по-добре от 4.0. Засега всичко при мен работи според очакванията.

CentOS Drivers

сряда, февруари 4th, 2009

Както стана дума и в предното ми писание има хардуер, който не работи от раз (out of the box) под CentOS, къде поради проблем с лицензи, къде по друга причина. На този линк в wiki.centos.org може да се види списък на подобен род хардуер, както и списък на драйверите, които са включени в текущото ядро по подразбиране.

Освен широкоизвестните проблеми с видео драйверите, другите най-често срещани проблеми са с тези за мрежови устройства. На тях и ще се спра, понеже в последните дни доста често ми се налагаше да търся драйвер за този или онзи чип. Някои от модулите, които ще спомена са част от линукс ядрото на по-късен етап (както съм споменал преди седмица за r8169), но текущото ядро в CentOS 5.2 е 2.6.18, в което те липсват. За проблемните чипове на Realtek вече стана дума – в линка по-горе има доста добре систематизирана информация по въпроса /тествани дъна, карти и т.н./

Днес имах проблем с неразпознат чип на Marvel, за който е нужен sk98lin module. Него го няма в хранилищата, на които съм се спрял аз – epel и rpmforge. Намерих го като kmod driver на следния адрес:
http://centos.toracat.org/ajb/CentOS-5/

Ето и пълен списък на модулите там:

kmod package	kmod version	kernel-2.6.18-128.el5 ver
============	===========	=========================

atl1		1.2.40.3	n/a

atl1e		1.0.1.0		n/a

atyfb		1.1		n/a

e1000		8.0.9-NAPI	7.3.20-k2-NAPI

e1000e		0.5.11.2-NAPI	0.3.3.3-k4

et131x		1.2.3		n/a

forcedeth	0.62		present but no version # stated

ieee1394	1.0.0		n/a

igb		1.3.8.6		1.2.45-k2

r8101		1.011.00-NAPI	n/a

r8168		8.010.00-NAPI	n/a

r8169		6.009.00-NAPI	2.3LK-NAPI

			            /--  skge 1.6
sk98lin		10.70.1.3       --<
				    \--  sky2 1.14

tulip		1.1.13-NAPI	1.1.13
Stop ACTA