Professional Musings

Getting backtrack5 to do anything besides blackscreen and kernel panic on this system has been a challenge.
It appears I have two graphics cards? an Intel 915 and a Nvidia 330M
I think this was confusing it somehow, it would start up looking graphical but then go black shortly after it began booting.

I found I could get an emergency shell by adding nosetmode but this did not allow me a gui and backtrack doesn’t appear to have a cli installer option

I made a little more progress by pushing modeset options to the drivers themselves.

The ultimate fix was to set

i915.modeset=1 nouveau.modeset=0

This allowed me to get an actual X window without crashing so I  could install.

After installation I had more problems. A learned a lot of about how the vostro 3400 has a hybrid video card that is “sorta” intel and “sorta” nvidia and VERY unsupported in linux. (i thought we were past these days guys!).

There’s a project to bring support to linux. Or atleast some control:

I tried playing around with this for a while but didn’t have much luck in getting X to work. Its hard to tell how affective it is since when I typed startx I got immediately hit with a black screen and the dreaded blinking capslock and scroll lock (kernel panic)

What ended up finally getting a gui for me, after another 8 hours of fighting with it was this post:

http://www.pskl.us/wp/?p=630

Finally, I found this kernel parameter: i915.modeset=1

they should rename that to “setbrokentofixed=1″

So, put that at the end of your GRUB_CMDLINE_LINUX_DEFAULT in your /etc/default/grub and update-grub!

 

I had done this! It hadn’t done anything! Wait, update-grub? what the hell is this?

I am not as familiar with grub2 as grub1 and had no idea we went back the direction of lilo and i had to run a an additional program after making my changes.

ARRRGGG!

So after doing the steps mentioned above, I have a working X. I’m not sure if i’m happy with running just on intel but i don’t think i have it in me to fight with it more. I may do a reinstall to pull out all the nvidia cruft left over from my trials.

Saw this posted by Tenbits on /r/linux on reddit. Read the rest of this entry »

Seem a couple people both via email and on IRC have this problem:

< robo> hi: on a vm guest running centos .. it shows that / is filled up to 100%. However, if I do a du on / it only shows about half is used.
Any suggestions?

The problem here is not understanding how Linux handles files and data, In linux, a file doesn’t actually get deleted until the number of links to the file is zero. In other words, if you delete it while it’s opened, then that instance of the file will continue to exist (without a directory entry) until every process that has it open is ended – even if you create a new one in the same place.

This is why you see logrotate restart processes after it removes files, that removes that last link to the data allowing it to be cleared up.

Alternatively you can sometimes just blank out a file to reclaim space without having to restart the processes holding the files. something like

:> filename

Will clear the contents of the file but leave the connection to it. This works as long as the process writing to it doesn’t keep track/seek to where it was when it writes again.

First of all, what is screen?

According to the website, “Screen is a full-screen window manager that multiplexes a physical terminal between several processes, typically interactive shells.”. Basically screen lets you run multiple shells that aren’t tied to your active connection. You can disconnect and they stay alive, you can then come back later and reconnect and continue to use them. Screen is used for long running processes you care about seeing the output from, such as viewing log output of a daemon or most commonly a command line IRC client.

I have one server that I am constantly in a screen session in, and I found a tip on parsed.org that makes it a no brainer. Basically whenever you start a shell it calls screen. If screen isn’t running, it starts a new one. This is great for remote systems!


You can use this in your shell dotfile (e.g. ~/.bash_profile, ~/.zshrc) to create a screen session when you log in or reattach to an existing screen:

if [[ $TERM != 'screen' ]] ; then
    if [[ `screen -list | grep -v "No" | awk '$2 { print }' | wc -l` == 0 ]] ; then
        screen
    else
        screen -dr
    fi
fi

A while ago I migrated my email from local hosting to a remote hosted solution. All of my new mail went fine but the old mail was left sitting in a Maildir on my home server. To solved this dilemma I wrote a python script to move it for me. It was much easier then I expected it to be.

#!/usr/bin/env python

import mailbox, imaplib, email, getpass

SERVER = "mail.server.com"
USER  = "dgibbons"
PASSWORD = "xxxxxx"
MAILDIR_PATH = '/path/to/maildir'
mdir = 'INBOX.oldmail' # change to the imap location you want your mail to end up at 

# connect to server
server = imaplib.IMAP4_SSL(SERVER)

# login
server.login(USER, PASSWORD)
server.select()
server.create(mdir)
server.select(mdir)

src_mdir = mailbox.Maildir('MAILDIR_PATH')
for m in src_mdir:
    server.append(mdir,None, email.Utils.parsedate(m.getheader('Date')), ''.join(m.headers)+'\n'+m.fp.read())

If you’re one of the people using Boxee on Ubuntu 64, you probably went through some archaic steps involving the 32bit deb package and getlibs, as described here.  What this doesn’t give you however, is a easy method to make sure your boxee version is update.

So I wrote a small script to check for you.

Basically if you run this and you get no output, you’re running the latest. If you get a message telling you to upgrade, well you should know what to do.

Paste the following into a file and chmod +x it.

CURRENT=$(dpkg -s boxee | awk '/Version/ {print $2}')
if [ $LATEST != $CURRENT ] ; then
echo TIME TO UPGRADE
fi