The other day, I was working on my senior design project (a kernel project), and I did the good ol’ make/make install/reboot to see my changes. Coming back, expecting my computer to have booted, I found it hung at:
Cannot create link /etc/mtab
perhaps there is a stale lockfile?
Naturally thinking it was my project’s fault (it was), I rebooted into my normal kernel. To my horror, the same error came up. After a period of mini-panic, I ran to Google and at the same time reached for my Gentoo CD (the newest I could find was 2007.0 minimal, but it still works!). I ran e2fsck on both my home and root partitions for good measure, and then mounted my root partition and looked at /etc/mtab*. Apparently, the fact that there was mtab, mtab~, mtab~2205 and mtab~2213 isn’t normal. On recommendation from this obscure post from three years ago, I deleted the extra files (after examining them and noting they were not only extraneous but empty), rebooted, and viola! Problem solved!
Turns out a number of different things I did caused this error several different times. Not exactly sure why, but it always seems to coincide with the boot of or boot after a kernel oops or panic.
External Links
Share and Enjoy:
These icons link to social bookmarking sites where readers can share and discover new web pages.
linux gentoo, linux
At work today, I came upon a startling revelation when I typed in a 20+ character password on our Ubuntu server. I typed in the password, not sure I got it quite right, and got in. I thought I typed it in right, and obviously I did. But I wasn’t sure, since our passwords are complicated. So I exited, typed it in again, but typed it intentionally differently. And It logged in.
As it turns out, after the first 8 characters, I could have put in anything at all, and the login would work. I was shocked that such a strange security issue would come up on a mostly stock-configured Ubuntu 8.04 server. In fact, it was better than stock configured, as I already had to do a bunch of configurations to secure it.
As it turns out, the problem lied with the way PAM was authenticating (or something). I went and checked that my configurations were right (you should have “md5″ in a “password” line where commented to do so in /etc/pam.d/common-password). Then, after doing some more poking around online, I found an Ubuntu forum post that mentioned that in /etc/shadow, if any given password has $1$ at the beginning, it’s using MD5. Upon looking at my shadow file, it turned out that one of my users (the one with the issue) was somehow not using MD5. I don’t quite know how that happened, but I’m going to guess that I configured PAM for MD5 after last setting his password. At least that’s my best guess.
To fix the issue, I just used passwd to change the password for the given user, and it properly took on its MD5 encryption. I hope this proves useful to someone in the future!
Share and Enjoy:
These icons link to social bookmarking sites where readers can share and discover new web pages.
linux linux, security, ubuntu
My senior design project for university has involved a lot of working in the Linux kernel. I’ve found that my primary difficulty with kernel work has been figuring out how the mass of code that already exists works and interacts with each other. It’s mostly very well thought out, but some things take a little time to wrap your head around. One such thing is the kernel’s unified implementation of linked lists.
It’s actually rather ingenious if you think about it, and there are plenty of references that give great explanations of how it all works, so I won’t do that here. The short version is that the list actually acts like an element within another data structure, which allows it to work for all types, rather than having to create new structures and functions for every structure to act like a list. What I recently found myself trying to do was create a queue (first-in-first-out) data structure using the linked lists provided. I decided to go about this after getting a little advice from a couple of fellas over at Stack Overflow. I haven’t fleshed it all out yet, but came to an important realization on how things work. It’s not really all that hard, but it was important enough for me to want to document: because it is a circular, doubly-linked structure, adding an item to the front and back of the list look very similar. In fact, they’re pretty much the same operation, except for where the external head and tail pointers point to. They’re so similar that I spent a bunch of time confused on how it all worked. I suppose that’s my fault for delving in and examining the overly-short elegant code.
The result of this is that their list_add_tail() function (which is commented to be useful for queues) is, in fact, useful for queues. It adds an element linked after the “last” element and before the “first,” given the head of the list. “Last” and “first” are in quotes here because it’s a circular list, so there technically aren’t a first and last, but there are. Anyway, what I still don’t quite understand is how the list_add() function is useful for stacks (also in the comments). Though I’m getting myself slightly confused just thinking about it further, so I’ll end the tirade here.
I guess if there’s one thing I can pass on here, it’s that if there’s comments documenting a series of functions (which the kernel’s include/linux/list.h file does), listen to the comments. I suppose this was a learning experience for me in the end, but I could have saved a bunch of time by just trusting what they said the functions do. On the flip side, if you’re curious, don’t trust them, and want to be sure about what the code is doing, you are always free to dive right in! I’m just convinced that the kernel developers are a lot smarter than I am, at least at this point in my career.
Related Links
Share and Enjoy:
These icons link to social bookmarking sites where readers can share and discover new web pages.
linux kernel, linux
