The every day things from Thalamus' life.

Thalamus' Blog

27 May, 2011

Uncompressing and reading initrd image

Filed under: ComputerStuff_en — Thalamus @ 15:01
mkdir /tmp/unpack
cp /boot/initramfs-2.6.32-131.0.15.el6.x86_64.img /tmp/unpack
mv initramfs-2.6.32-131.0.15.el6.x86_64.img /tmp/unpack/initramfs-2.6.32-131.0.15.el6.x86_64.img.gz
cd /tmp/unpack
gzip -d initramfs-2.6.32-131.0.15.el6.x86_64.img.gz 
cpio -i --make-directories < initramfs-2.6.32-131.0.15.el6.x86_64.img

What if … I edited something and want to use the edited … revert it by :

find ./ | cpio -H newc -o > /tmp/initrd.cpio
gzip /tmp/initrd.cpio
mv /tmp/initrd.cpio.gz /boot/my_initrd-2.6.32-131.0.15.el6.x86_64.img

( I always keep the originals for rollback purposes – I ain’t perfect … )

• • •
 

23 May, 2011

Persistent devices with udev

Filed under: ComputerStuff_en — Thalamus @ 08:50

Descided to have a look into ‘udev’ – have silently ignored it for years, since I haven’t had any real need to learn it. Tape devices I’m used to address directly, and it still work. Putting udev to use – to address the default devices like ‘changer’ and ‘tape’ would be nice though.

As server platform – I prefer CentOS, on the desktop Fedora. As of this writing, my server is running CentOS 5.X, and Fedora 15 i just to be released. Between these distros there is quite alot of years with development. Once should make a note of that on Fedora pr. example – the ‘udevinfo’ i replaced with ‘udevadm’.

On the older CentOS

# udevinfo -a -p /sys/class/scsi_generic/sg2

Would yeald something link …

  looking at device '/class/scsi_generic/sg2':
    KERNEL=="sg2"
    SUBSYSTEM=="scsi_generic"
    SYSFS{dev}=="21:2"
 
  looking at parent device '/devices/pci0000:00/0000:00:1e.0/0000:02:0d.0/host2/target2:0:1/2:0:1:0':
    ID=="2:0:1:0"
    BUS=="scsi"
    DRIVER=="st"
    SYSFS{ioerr_cnt}=="0x1"
    SYSFS{iodone_cnt}=="0x2b"
    SYSFS{iorequest_cnt}=="0x2b"
....
....

Running on a newer distro – using ‘udevadm’ – a one-liner will not do.

# udevadm info -q path -n /dev/cdrom

– it give me something like this :

/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sr0

Solution – make a one-line wrapper. I called mine ‘udevinfo’ šŸ™‚

# udevadm info -a -p $(devadm info -q path -n $1)

Running this …

# udevadm info -a -p $(udevadm info -q /dev/cdrom)

… more or less the same syntax as devinfo gave me earlier.

  looking at device '/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sr0':
    KERNEL=="sr0"
    SUBSYSTEM=="block"
    DRIVER==""
    ATTR{range}=="1"
    ATTR{ext_range}=="1"
    ATTR{removable}=="1"
    ATTR{ro}=="0"
    ATTR{size}=="8581504"

So – now … back to my goal – making /dev/tape, /dev/changer and /dev/tape_norewind out of the generic scsi devices I had.
For details about udev itself – this is a good read …

http://www.reactivated.net/writing_udev_rules.html

My devices was sg0 (changer), sg2 first ultrium drive. My final addition to /etc/udev/rules.d was this file which I called ’11-mytapedevices.rules’.

KERNEL=="sg0", BUS=="scsi", SYSFS{model}=="C7145", SYMLINK+="changer"
KERNEL=="st0", BUS=="scsi", SYSFS{model}=="ULTRIUM-TD1", NAME="tape", GROUP="tape"
KERNEL=="nst0", BUS=="scsi", SYSFS{model}=="ULTRIUM-TD1", NAME="tape_norewind", GROUP="tape"

Another example – I have 2 USB Pen drives – one Kingston and one Unnamed. To distinguish them both I choose to use the ATTR{serial}. This is from the Fedora install, so, SYSFS is now named ATTR.

KERNEL=="sd*", SUBSYSTEM=="block", ATTRS{serial}=="93675AC2", SYMLINK+="orange_disk%n", OPTIONS+="all_partitions"
KERNEL=="sd*", SUBSYSTEM=="block", ATTRS{serial}=="0018F30C9FF7F9910104069D", SYMLINK+="black_disk%n", OPTIONS+="all_partitions"

The device names are generated by the color of the units themselves.

• • •
 

19 May, 2011

Uninstalling without actually unistalling – RedHat Package Manager.

Filed under: ComputerStuff_en — Thalamus @ 08:40

There has been times where I wanted to reinstall or force a package – to reinstall itself. There are several ways to do this. But, one – less known I think is that it is possible to delete the package from the RPM database without uninstalling it.

# rpm --justdb -e "packagename.rpm"

This makes it easier to reinstall the package – since RPM will not complain that it is already installed and alike. There are some sane uses for it as well. Say that you install something from source – overwriting the original RPM installed files. You probably should just delete the file from the RPM db in these cases.

Another trick that can sometime be useful is using query format.

$ rpm -q --qf '%-20{NAME}\t%10{VERSION}\n' "package.rpm" "package.rpm"

Would give you the name and version – separated by ‘tabulator’ in the output – great for scripting by awk, perl and alike.

• • •
 

16 May, 2011

Testing an upgrade with manually downloaded RPMS

Filed under: ComputerStuff_en — Thalamus @ 13:34

From time to time – there has been that I’ve needed to upgrade something that I haven’t really felt 100% sure would work. I tend as long as possible to recompile myself new RPMS from source … if possible. But, second best thing is if there is someone that has already done it for me. By default, except for kernel packages I tend to use

# rpm -Uvh "packagename.rpm"

… again – DON’T use ‘-Uvh’ for kernels – it will upgrade install of installing. And if that kernel fails – well, the old one is not there anymore !!
This is normally a OK way to do it – but, there is a slightly better way. Run a ‘test’ of the ‘-Uvh’ – before actually running the command.

# rpm --test -Uvh "packagename.rpm"

– This should NOT give any feedback/errors, then your set. OFC, it doesn’t tell you if the package itself is going to work … just the upgrade process šŸ™‚

• • •
 

2 May, 2011

WARNING: mismatch_cnt is not 0 on /dev/md1

Filed under: ComputerStuff_en — Thalamus @ 16:36

Got an error message from /etc/cron.weekly/99-raid-check today.
Have had this error before – a long time ago, fixed it – but, didn’t make any notes about the procedure … here it is :

# cat /sys/block/md1/md/mismatch_cnt
# 128
# echo repair >/sys/block/md1/md/sync_action

wait for the raid to repair itself … you can watch its progress by issuing

# watch cat /proc/mdstat

Once it has completed – run a new ‘check’.

# echo check >/sys/block/md1/md/sync_action
# watch cat /proc/mdstat
# cat /sys/block/md1/md/mismatch_cnt
# 0

Success !

… sidenote – you might want to crank up the speed for this by raising the minimum_speed limit ..

# cat /proc/sys/dev/raid/speed_limit_max
# 200000
# cat /proc/sys/dev/raid/speed_limit_min
# 1000
# echo 50000 >/proc/sys/dev/raid/speed_limit_min
• • •