Recover a Corrupted Partition Table

You ever have one of those days, where you are happily using your Linux laptop, shut it down for transportation, then fire it up and it just doesn’t boot?  I’ll admit that I do all sorts of screwy things on my laptop, so this is probably my own fault, but I figured I’d write it up in the hopes that it helps someone else, and to give a couple shout-outs to helpful resources.

I am running a Lenovo Thinkpad T430s with Red Hat Enterprise Linux 6.4 Server.  I have a 256GB SSD, which has a 512M boot partition, and the rest is a LUKS encrypted PV, with several LVs for my filesystems.

I booted the laptop and received a black screen with only two words in white on it:


Error 17

Yep, that’s it, nothing more. Guessing that “Error 17” is a GRUB error (confirmed by Google),  I grab my trusty RHEL6.4 USB installer (created with livecd-tools), and boot into rescue mode.  A quick fdisk -l shows me a perfectly valid partition layout with a single ~5.5GB partition …. wait, that doesn’t seem right.

So, let me go check my partition table backup that I make periodically.  Heh, yeah right.

I vaguely recall my drive layout was as I described above in the second paragraph, but how the heck am I suppose to confirm if my data is still in place (please let this be just a corrupt partition table!!!), and then figure out the partition boundaries and reconstruct the table?

Googling brought me to a posting on Dedoimedo, which pointed me to the awesome TestDisk utility by CGSecurity.  I grabbed the Linux x86_64 binary package provided by the site, and followed the CGSecurity TestDisk instructions to analyze my disk.  Sure enough, it found the first partition 512MB, and then a second 2MB partition.  I read a little about how TestDisk works, looking for signatures for ext2,ext3,ext4,FAT, btrfs, etc., so I understood that it found my first partition which was ext4, but it didn’t know what to do with my LUKS partition.  I was pretty sure that the first one was correct, though, so I went ahead and let TestDisk write a new partition table.

Then I fired up fdisk -cu , and deleted the 2nd partition, then recreated it starting at the sector following the first partition, and extending to the last sector on the disk.  I was pretty certain that I had used the rest of the disk …. but still added a healthy dose of finger-crossing.

I wrote the disk partition out, rebooted into rescue mode again, found my way to a shell, and attempted to mount the first partition – success!

Next, I proceeded stepwise to access the second partition:

#> cryptsetup isLuks /dev/sda2           #First, test to make sure this is recognized as a LUKS device -- it was!
#> cryptsetup luksOpen /dev/sda2 foo     #Open the LUKS encrypted device as new device "foo"
#> pvs                                   #Scan for LVM PVs, which foo should be -- and it was found!
#> vgchange -ay                          #Activate all LVM VGs on discovered PVs -- and my VG was found!
#> lvs                                   #Scan for LVM LVs -- and mine were found

At this point, I mounted my home LV, and was able to take a backup. Feeling brave, I gave the laptop a reboot, and everything is running as before.

So, thank you to Dedoimedo for pointing me towards TestDisk, and thank you to CGSecurity for the great tool!

Using Google Chromecast from Fedora 19

Using Chrome’s Google Cast with the Google Chromecast from an IPTables-enabled Linux distribution can be a bit tricky.

The extension starts by issuing an SSDP request from a local ephemeral UDP port to 239.255.255.250 port 1900.  The Chromecast will respond from its IP and another ephemeral UDP port, back to your source UDP port.

IPTables cannot track this simply as “RELATED”, given that the target of the first packet is the multicast address, while the source of the response packet is the Chromecast’s IP.  And unfortunately, there is no SSDP conntrack module (at least, not that I am aware of, at the time of writing this post).

Therefore, the best we can do for now is to open the ephemeral port range on the client machine.  The list of ephemeral ports, as defined by your Linux machine, can be found by:

cat /proc/sys/net/ipv4/ip_local_port_range

Fedora19 uses firewalld, so you will want to use the following:

firewall-cmd --permanent --add-port=32768-61000/udp
firewall-cmd --reload

Given the wide range of ports being opened, you may want to restrict access to just your local network. Consider using Network Manager to associate your NIC (eth0,wlan0, whatever) with your “home” zone, and use the following command instead of the above:

firewall-cmd --permanent --zone=home --add-port=32768-61000/udp

On non-firewalld systems, use this IPTables one-liner (modifying 192.168.0.0/24 as appropriate for your home network):

iptables -A INPUT -s 192.168.0.0/24 -p udp -m udp --dport 32768:61000 -j ACCEPT

Launch Chrome, click the Cast extensions, and it should now “Just Work”.  And if it doesn’t …. please let me know in the comments on this post.

UPDATE 20150803 – A few additional notes inspired by the great comment from mauriciograciag:

Note the use of the “–zone=home” parameter in the second firewall-cmd example above.  This can be a more secure option, but does require ensuring that you have a zone named “home”, and that Network Manager associates your active network profile with this zone.  If the Network Manager configuration is in place, I do recommend using that option for those working from systems (laptops) that might also find themselves on alternate networks.  However, for desktops that will not be connected to other networks, use of a zone will likely not add any tangible benefits.

If you set these rules via firewall-cmd and wish to revert them, the following should do the trick:

firewall-cmd –permanent –remove-port=32768-61000/udp
firewall-cmd –permanent –zone=home –remove-port=32768-61000/udp
firewall-cmd –reload

And lastly, note that the iptables rule must be run as root. Typically, this will be done by updating the iptables startup configuration for your favorite Linux distribution (e.g., you may need to add that line to /etc/iptables); but you might also want to run this a single time, non-persistently, from the command line.  If you have configured sudo appropriately on your Linux systems, preceding the iptables command with “sudo” would work as follows:

sudo iptables -A INPUT -s 192.168.0.0/24 -p udp -m udp --dport 32768:61000 -j ACCEPT

An ode to 130-064-785

9 digits, what do they mean to me? They are a milestone, for now I am an RHCE!

OK, so I’m no poet – but thankfully that is not a requirement at Red Hat! This week I took RH300, and today I passed both EX200 (RHCSA) and EX300 (RHCE). And so now, waiting for my flight out of DC, I celebrate:
image

More time in Raleigh, more snow in Connecticut!

So yet again, this blog post comes as I sit in the RDU airport, leaving behind sunny blue skies and ~50 degree temperatures to arrive just before midnight in cold, wet snow. — it is good to get home!  I’ve been in Raleigh again for a couple days, this time for Red Hat IdM (Identity Management( training, and Value Selling training.  Both were great sessions — of course I enjoy good technical sessions, but I learned quite a bit from the Sales class too.  It really opened my eyes to a few bad habits, which I can now work to address.
image

Red Hat’s IdM is pretty cool — I wish I had know more about it sooner.  It comes with Red Hat Enterprise Linux, and provides a unified LDAP, Kerberos, DNS, and CA solution.  Plus, when used in combination with SSSD, you get a nicely managed user/group/policy solution consistent across your RHEL servers and desktops (and to a lesser extent, other *nix systems that support Kerberos and LDAP).  I have been a longtime proponent of OpenLDAP and MIT Kerberos, and still believe they are each very powerful solutions — but Red Hat’s IdM is a very cohesive suite that ties multiple functions and technologies together very well.

Now to really get down to studying for the upcoming RHCE exam — wish me luck!

New York City

image

I don’t get into New York City too often, but I had the opportunity this week to check out Red Hat’s office.  I took the Amtrak in and out of Penn Station, and a quick subway hop to the office.  Just a stone’s throw from Wall St, Red Hat is waaaay up on the 24th floor.  I got to meet most of the SA team for the NE region, and we headed over to Suspenders for dinner, follow by drinks at the Pegu Club, and just had a real good time talking for several hours.

What a smart, active bunch — it is awesome ( but still a bit intimidating ) to be part of this!

Amtrak Rocks!

I’m taking the train from New London into Penn Station.  I haven’t been on a train in years, but this is great!  Free WiFi, free power, smooth ride — I’m getting a ton of work done.  I’ll definitely be doing this more!

Done with New Hire Orientation

Time to update the WordPress headshot — I now have my Red Fedora!

rhfaceI’m sitting in the RDU airport, wrapping up three days in Raleigh – two for New Hire Orientation, and one for training on the sales tool.  Ran into David Huff today in the new Red Hat Tower, who echoed a common theme that I’m hearing from Red Hat’rs, triggering this blog post.  Here’s a few of the things I’ve heard:

  • “I love it here!”
  • “This is an awesome place!”
  • “I’m where I want to be!”

There is an excitement here, people working towards common goals, within a common set of philosophies, understanding how they each contribute to the successes of the company.  The work is interesting, challenging, even enjoyable, and the goals are admirable.

Every session at orientation ended with the presenter saying “Welcome to Red Hat!” — and I believe they mean it!

I am incredibly excited to be on board – what a great place to be!

UPDATED WITH SLIGHTLY IMPROVED PHOTO OF MY NEW FEDORA — THANKS JOSH ;-p  

It’s So Hard to Say Goodbye to Yesterday

Cake

 
 
 
 

Check out this incredible cake!!  This was made by Roseanne, wife of my friend Mark.  @RedHat — do you need someone to bake for your events?

Motley Crue

As great as it is to be heading off to Red Hat to start a new chapter of my life, it truly is difficult to leave my many friends at UConn. Again, thank you all — for the party, and for 17 years of sharing, mentoring, and friendship as we worked for the greater good of the University.  You will all be missed – please keep in touch!

Cake

[UPDATE 2013-01-18 13:54] The following was just posted to the weekly IT Employee Newsletter:

Matt Smith, a dedicated professional and highly respected employee of UITS announced his resignation from the University effective January 24th. Matt joined UITS as a student employee supporting desktops and distributed servers in 1996. In those 17 years he developed vast knowledge and technical ability. Under his leadership and “can-do” attitude many technical solutions were researched and implemented. Matt’s expertise made him highly sought after over the years by top leaders in the public and private sectors. Matt has always had a strong commitment to UConn; however, opportunity knocked and he decided to leave and accept a job offer with Red Hat, Inc. Matt will be missed by the University community, his friends and colleagues at UITS, and especially by the Linux team he led since 2009. Please join us in wishing Matt and his family all the best.