I’ve been wanting to venture into the realm of scripting with Perl for quite a few years, but always find a better use using PHP & Bash. However, this was changed not too long ago when I was looking to write a Bash script to find every Linux kernel on a machine. Of course I was trying to do this in Bash, and there were two methods: 1) easy – use arrays to store various information and loop through the arrays, or 2) hard – do everything in one for/while/if block and make the code near unmanageable and unreadable.
Ultimately I chose option #1, but that posed another issue…for some reason I was unable to populate the array I needed. The array was usable (no errors saying the variable was undefined), the data I wanted to store was visible through the while and if loops, but for some reason no matter what I tried, I couldn’t store the data.
Then, one day, a friend of mine mentioned doing this in Perl. Originally I was set off by this because I wanted it to run on every Linux machine there was (Bash seems to be the most popular shell). But, when he mentioned that most systems come with Perl installed, it dawned on me. So, I wrote this script to fetch every detected kernel & initrd (ramdisk) found on ext2, 3 and 4 partitions.One main reason for this, and it’s also the reason why I wrote it, is because when you install a new system GRUB won’t always pick up other partitions/kernels/etc… This is also why I had it output results in GRUB menu.list format. This is a common issue for me when using Gentoo or Arch Linux on a multi-boot system. This can also be helpful though if you have multiple kernels and want to be able to boot into any of them you choose.
There are a few restrictions to this:
- Perl must be installed
- This does not work for VPSes (cannot guarantee VMs, but have reports it doesn’t)
- Requires super user rights to use (due to use of “fdisk -l”)
I want to address both #2 & #3. Most VPS containers I’ve ran across do not have actual mount points. You can test this by simply doing cat /etc/fstab, and compare that to cat /etc/mtab. This in turn means that there is no output available for fdisk, because that parses the /proc filesystem. When you try to run this through a VPS, you will get a message saying that /proc can’t be opened, and then an error check. I’ve had reports say that it does not work in virtual machines, but no real details provided. However, if /proc is unreadable, then it assumes you’re running a VPS or VM.
As for point #3, the comment itself gives a vague reason as to why. If you try to run “fdisk -l” as a normal user the output is generally empty (I have yet to run into a time where it’s proven otherwise). This script parses the output of fdisk -l to read each /dev/xdy# line (i.e.: /dev/sda1) and is the backbone to this script. Outside of this, the script also mounts & unmounts any partitions that don’t already have a mount point.
There’s no real reason for any editing of the script by default, but for the most part it’s commented pretty well. To see what the actual output looks like, I provided it in a pastebin: http://pastebin.com/HGZj5vVc
This only works for ext2/3/4 formatted drives because those are the ones I am used to working with. Others such as NFS & ReiserFS I am unsure if they need extra work for the mount points. If you wish to remove this restriction (or change it), edit line 111.
In the future I plan on supporting the newer GRUB format.