Tuesday, August 26, 2014

One line shell script that saved me a lot of work

    Even though I have not been writing about my adventures does not mean they have not been happening. It means I have not been writing. One of the issues that I have been dealing with has to do with plasma-desk deciding it needed 100% of 1 of 8 threads in my laptop. This would have been okay except for the fact it made everything take forever. After googling around for awhile, I found, much to my dismay that it could be cause by any plasmoid. (KDE comes up with such great names.) After ripping all the plasmoids out, I put them in one at a time very gently. I checked each time to make sure that the cpu was not going crazy. It turned out to be the network command and control, and the network monitor plasmoids. So this solved part of the problem.

    Other strange thing were happening with my machine.  There is a really awesome music play KDE has called Amarok. The coolest thing it does is store the location of all my music files, album covers and stats on the music in a Mariadb database. Everytime I cranked up Amarok the entire GUI would crash.  Even the Nvidia driver would have to come back up.  Also, the stable version of chrome  would cause the same problems.

    I have to admit that I like playing with less that stable software on my personal boxes. Side note:  I load CentOS 7 on an HP R4000 with Ntopng and locked down according to the NSA. To include Aide setup on it. I put it out in the dmz to find out what was happening my garden gate, so to speak.  Oh, the point, the R4000 is a single processor 64-bit machine, maxed out at 2 GiB of memory. Everytime I reboot it, I get a warning saying that CentOS does not support the R4000.  The moral  here, is don't believe everything you read.

    So, I was installing test versions of KDE4. I really, wanted to play with 4.13 or 4.14. I did not think the @kde-testing repo was that unstable. I was wrong! I have spent the last weekend ripping out the testing stuff and replacing it with updates. After doing some research on yum, I came up with this script and an example of the output:

yum list installed | sort

tix.x86_64                            1:8.4.3-11.fc20                @anaconda
tk.x86_64                             1:8.5.14-1.fc20                @anaconda
tk-devel.x86_64                     1:8.5.14-1.fc20                @fedora
tkinter.x86_64                        2.7.5-13.fc20                installed
tmpwatch.x86_64                  2.11-4.fc20                            @anaconda
tomcat-el-2.2-api.noarch        7.0.47-1.fc20                @fedora
tomcat-jsp-2.2-api.noarch                7.0.47-1.fc20                @fedora

OK, this was cool, but I only needed the first column. So back to google for a sed script. The second iteration looks like this:

yum list installed | grep kde-test |sed 's/\ / /'|awk '{print $1}'  and the output

dragon.x86_64
granatier.x86_64
jovie-libs.x86_64
juk.x86_64
kaccessible.x86_64
kaccessible-libs.x86_64
kactivities.x86_64
kactivities-libs.x86_64
kactivities-nepomuk.x86_64
kajongg.noarch
kanagram.x86_64
kanagram-libs.x86_64
kapman.x86_64

So my first attempt for a complete script failed,

yum list installed | grep kde-test |sed 's/\ / /'|awk '{print $1}' | sudo yum reinstall 

I got an error stating that reinstall had to follow by an item or list.

    Being the kind person I am, I have a presents on Facebook and Twitter. I hate them both. I decide that the easiest way to prevent have to go on either one of them was to cron some shell scripts of random commentary. While I was writing the shell script for Facebook I had to execute a command inside a shell script. That is when I discovered `command`.  I remember that, and this is the complete script
   
sudo yum reinstall `yum list installed | grep kde-test |sed 's/\ / /'|awk '{print $1}'` -y

Saturday, January 18, 2014

LUKS not Mounting


I've had my share of problem with linux installations before, but the worst are always on my laptop. I did an update using Fedora's new updating tool dnf, and I kept getting scriptlet failures. This was ok after a couple of man pages and rebuilding the rpm data base all was good, at least I thought. I didn't realize anything was a miss until my GUI stopped functioning. So, after a little frustration with no keyboard or mouse, I got to the laptop reboot.
As the laptop came backup, it got stuck on mounting the LUKS partitions. See all my partitions are encrypted besides /boot and /boot/efi. So, no /, no /home, no /var and no swap, nothing was mounting. I pulled out my cell phone and started searching the net for possible solutions. The updates with the scriptlets not running was cause by a miss configured SELinux I found. I found nothing that related to my problem, but I did find a similar description of the situation dealing with thin LVM installations. The work around was to boot the machine with a cd mount the file system and chroot it.

chroot /mnt/sysimage/ /bin/bash, then run dracut -f, exit and reboot. SELinux would have to relabel the partitions and all would be as good as new. Not!
The reason this problem existed was because dracut was never able to update the initramfs with the scriptlet that never ran. Second, dracut if you don't specify the kernel you want the initramfs build for, dracut will build it for the running one.

 Yes, you guessed it first time around, the initramfs was built for the kernel on the install dvd for Fedora 20. After more man pages, and pulling what little hair I have left out, I found the answer. It is “dracut –kver (kernel version) –force”. The command will build the correct initramfs and since it's forced, you will not get any warnings about over writing the old one.