Quick recovery of Linux boot (Grub) or Windows MBR

One of the common problems in Linux installations is to lose or damage the the boot loader (Grub), specially if on the same machine coexists other OS from Microsoft family.

On the other side, while you are testing Linux you can loose your Windows Boot.

I used to repair this kind of problems in the old-school way: Booting a Linux liveCD+mount HD partition+chroot+install grub+cross fingers. But this is not a method recommended for novice users…

Recently I’ve discovered an utility that is designed specially for this! The utility is called Boot Repair CD (you have to burn the ISO to a CD or USB) and after booting, an assistant will appear and magically solve your boot problems :)

Boot Repair Disk (Easy way)

Boot Repair Disk (Easy way)

Even they will help you if the utility can’t repair your boot area:

Launch Boot-Repair, then click the “Recommended repair” button. When repair is finished, note the URL (paste.ubuntu.com/XXXXX) that appears on a paper, then reboot and check if you recovered access to your OSs. If the repair did not succeed, indicate the URL to boot.repair@gmail.com in order to get help.

For advanced users, it also have a bunch of options related to Grub and MBR:

Boot Repair Disk (Advanced mode)

Boot Repair Disk (Advanced mode)

Give it a try!

Set date on all your JPG photos from EXIF data

I don’t know if it’s a normal situation or it is one of that things that only happens to me: All my photos had lost their original timestamp. So all files have the same date (the date when files were copied from the old hard disk) and it’s a mess when you have gigs of photos from travels, family, events, animals, etc. without its original shoot date.

So I adapted this little script that reads EXIF data from JPGs recursively into folders and sets timestamp on the files accordingly. Easy!

All you need is the exiv2 tool (quickly available on your distro repos) and run this little script: (Remember to chmod it to a+x or 755).

Resize a mounted Linux partition

Today I’ve learnt that a Linux partition (which is mounted) can be grown “a la brava” (means “the hard way” in Catalan) directly modifying it through Fdisk and then resizing with resize2fs. That’s it….

With my own conservative way I’d boot the machine into Gparted (A very useful small distro that boots into Gparted directly), resize the partition (unmounted), and then reboot again.

The only condition is that the partition which has to be grown is the last one. If not… things get more complicated (or not, if the last partition is a swap one, which can be erased and recreated without problems). Other condition is that particion can only be grown (not shrink).

The process it’s easy:

  • First grow the disk physically (can be a VM disk, a new bigger disk just cloned, or simply a partition that does’nt fill the entire disk).
  • With Fdisk, remove the partition.
  • Without exiting Fdisk, create a new partition. Carefully note that the first sector match the previous first sector. The last sector can be the end of the disk i.e.
  • Verify/toggle Boot flag, must be activated.
  • Save and exit. Cross your fingers and reboot.
  • Once rebooted, grow the filesystem with resize2fs.

 

Bye backups… hi ZFS snapshots!

Today an entire folder disappeared from my Owncloud instance. It is an entire mystery why has disappeared. And I haven’t backups since owncloud data supposedly is synced between all client computers…

But, who wants backups when you have ZFS snapshots? I have all my private Owncloud data into a ZFS volume, and a cron job that do snapshots at midnight. Unlike Solaris, ZFS on Linux doesn’t have snapshotting natively so we have to use this set of pretty scripts: zfs-auto-snapshot

ZFS snapshots can be accessed like if they were a regular filesystem and they show you the files as it were just at the snapshot moment. The good thing is that the space occupied is *very* low (only stores changed data like it were an incremental backup).

So you only have to copy the missing data from the snapshot folder into the original place.

zfs list shows us all the datastores, mountpoints and snapshots:

 

We want to restore the latest snapshot from May 12th at 04:25am. First we have to ensure that snapshots are visible to us. We’ll set RomaniHD/Magatzem datastore to show snapshots. It will be located hidden on the datastore root (/datastore/.zfs)

 

Voilà, we have a virtual copy of our datastore of the last week:

Now we have to enter the desired folder (day) and copy the contents into the correct place.

In my case, I restored Owncloud data, so after copying the missing data I had to do a content refresh. First become www-data user and tell owncloud to refresh its entire data folder:

 

Streaming audio to two different targets (or networks)

It may sound strange, but one radio station (or somebody) may want to stream audio to two different networks. I had this special need in Boca Ràdio (a local Radio Station from Barcelona) because this station broadcasts through a provider and also broadcasts into Guifi.net (A community based, open and neutral network).

So, the box that transcode analog audio coming from the station’s sound mixer, it has to send it to:

  • Streaming provider in Shoutcast format
  • Localhost in Icecast format. In the same box there is an Icecast server listening to Guifi network clients. (Note that Icecast server may be running on another location).

I utilize this little transcoder: Darkice that reads configuration from /etc/darkice.cfg and sends analog audio coming from the Soundboard to the specified targets and in the specified format. It is available in Debian repo.

Configuring Icecast server is pretty straightforward but be sure that this items are properly configured: