Nexus 10

It's pretty awesome.

Erase (Discard) all data on an SSD in Linux

A little background:
I had a 60 GB OCZ SSD that had Windows on it and some apps. I wanted to erase it to start fresh to test out Fedora 18 Alpha on it in a laptop. I didn't need to securely erase anything, I just wanted the SSD to know it can erase everything.


Here's what I did.

First I had a Fedora LiveUSB drive. That's not important but what is important is hdparm installed. I had to yum install hdparm from a terminal. Single user runlevel is a good idea for the rest of this...

First I needed to see how large the SSD is in sectors.
gdisk told me what what I wanted to know.

(The following is retyped, not copy and pasted and parts are omitted)

gdisk /dev/sda
Command (? for help): p
Disk /dev/sda: 117231408 sectors

So now know the size, 117231408 sectors which is important because hdparm will need input in sectors.

I found out that the --trim-sector-ranges option of hdparm will not do more than 65535 sectors at a time so I needed to use --trim-sector-ranges-stdin so I could specify all at once.

First I needed to generate a sector list.

for ((i = 0; $i < 117231408; i = $i + 65535)) do echo $i:65535 >> sectors.txt; done

Warning about that, I typed that from memory. The important part is you're looping from Sector 0 up untill the end before 11723140 (for my drive). Then it's stepping by 65535. I feel like I should have stepped by 65536 but I didn't so each line might have overlapped by 1 sector. In practice it wasn't an issue. Also, the very last entry in sectors.txt will be wrong. I didn't care enough to special case it or manually calculate the correct length.

So now sectors.txt looks like
0:65535
65535:65535
131070:65535
...

Then I did the actual (well nearly the actual) trim command.

hdparm --trim-sector-ranges-stdin /dev/sda < sectors.txt

Actually there's another --option thing but it will tell you and warn you what you're about to do is dangerous to your data. I'll omit it for the people copy and pasting to make the stop and think.

I ended up getting an error about a few of the sectors at the end (the error on the last entry basically) but nothing bad. Rebooting is now a good idea. And you're done!

If you follow these instructions be warned I might be doing it wrong and I only looked at about the first 1K of data on the drive to see it was blanked.

Good luck.

Dell PERC 5/e on Fedora 16 and an MD1000 Enclosure

For various reasons I have a Dell PERC 5/e hooked up to an MD1000 enclosure on a workstation running Fedora 16 64 bit. All is fine with the already configured raid but I can't edit it at all when I add or remove drives. For a long time I lacked a way to edit arrays without rebooting to bios.

Now no more.

Thanks to the following links:

Download link for MegaCli: http://www.lsi.com/downloads/Public/Obsolete/Obsolete%20Common%20Files/4.00.16_Linux_MegaCli.zip

Ah-ha moment link (a.k.a how to make it work): http://www.kattare.com/docs/faq_view/1532/how-can-i-setup-megacli-on-my-64-bit-ubuntu-11-04-or-12-04.html

How to use it: http://tools.rapidsoft.de/perc/perc-cheat-sheet.html

So first download the zip, unzip the zip, unzip the zip that was in the zip, yum localinstall the rpm and you're done installing. You'll find the program in /opt/MegaRAID/MegaCli/

Now for the magic to make it work, lets make a shell script wrapper. It's not mandatory but it's a good idea. Just look at the ah-ha moment's link about 2/3rds down the page right after the part where they "Test it out..." Actually, just read the whole page. In case that's down the magic is that the program checks the kernel version and only runs on 2.6.
setarch x86_64 --uname-2.6 /opt/MegaRAID/MegaCli/MegaCli64
Will make it work. The script sticks all that in a wrapper for less typing.

Fedora 17, Lenovo B570, Windows 7 and GPT

I bought a new laptop a few weeks ago. This time the Lenovo B570 which is pretty similar to the G570 I talked about previously.

I had a new challenge with this one. Fedora 17 would not install with the plan I used with the G570 and Fedora 16.  It insisted on having a GPT labeled hard drive because it detected the laptop's EFI support or something but my first problem was the hard drive didn't have enough unused partitions. Since it was an MBR label there was a max of 7 partitions. Windows took up 2, the Lenovo One Key recovery thing took another primary partition and then there was another driver partition as a logical volume. So no primary partitions for Linux and only 3 extended partions left in the middle of the drive. this is of course after following my old steps to shrink Windows' C: drive and move the start of the extended partitions.

After deleting the driver partition I still couldn't satisfy the Fedora installer so I decided to fix this by converting my MBR labeled hard drive to a GPT label and I didn't want to reinstall Windows either so fixing it's ability to boot was going to need to be figured out.

Converting the drive from MBR to GPT

First, I needed to resize the hidden recovery partition at the end of the drive.  Well I could have just deleted it but I decided not to. Turns out GPT need a little bit of room to store a backup copy of the partition so I used a LiveUSB with Fedora 16, installed gparted, selected that last partition and shrunk it. No big deal. Then for safety I dd'd the first 10 MB of my drive to a file on a usb drive so I might be able to roll back to MBR. I didn't care about any data on the drive so I didn't mind being this reckless. So with the last partition shrunk by 250 MB (excessive I know) and a backup of the MBR (and more since 10MB was excessive too) I proceeded to do the conversion. I had to yum install gdisk because the LiveUSB was missing it but then it was as easy as gdisk /dev/sda and then pressing w to write it. The first time I did it I got a warning (before pressing w) about that last partition being too close to the end.

Quit out of that and done. Well sort of. I still needed to install Fedora 17 which went smoothly this time. 

Fixing Window's Ability to Actually Boot

As expected, Windows would not boot anymore. From the GRUB menu I tried the old rootnoverify and chainload to boot to windows but the commands wouldn't work and it seemed to be because the filename format you need to pass to chainload changed by being a GPT drive. I didn't have any idea if that would work anyways and gave up and decided I needed to try to use Windows repair tools to write a new boot record. Turns out I don't have a Windows 7 install disc. The Lenovo recovery media just re-images the drive rather than running Windows 7 and the One Key recovery button was similarly broken. What I did have was a Windows 2011 SBS install disk which was good enough to let me use a command prompt to try to fix it. Between using bootrec /fixboot, bootrec /scanos, and bcdboot d:\windows I was able to get the laptop to offer Windows on the boot menu (F12 at power-on). (And yes it was D:\windows because that's where /scanos found it.)

Results

Windows 7 runs like normal.

Fedora 17 runs like normal*.

The Lenovo recovery button doesn't work.

The hard drive is GPT labeled with 8 partitions.

UPDATE 1: I would recommend you not try this at home. It has issues. One is when Windows Hibernates the system you cannot resume Windows without first booting to Linux and then rebooting if Linux is the default boot target. It skips giving you the option to press F12 for the boot menu. You can't even get into setup. If I can get a clean Lenovo Win 7 Install disc I would probably try reinstalling everything from scratch to see if it fixes things like that. Also, I had no idea what I was doing when I was fixing Window's boot loader with bcdboot so maybe I did it wrongly. The commands had boot in the name and /? showed those options and I just tried them haphazardly. Again I had a full backup of the hard drive so I didn't care about screwing up anything. Actually that's the only issue I've found so maybe it's not such a big deal.

Other update goodness. Fedora 17 KDE is working fairly well. I installed a CAD program and it works well enough when I plug in an external projector however I'm disappointed by the choices of resolution when I try to mirror. It' was a 1080p projector via HDMI so extended desktop works best.

UPDATE 2:
Command (? for help): p
Disk /dev/sda: 976773168 sectors, 465.8 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 86753090-2233-AACC-8888-123456789012
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 976773134
Partitions will be aligned on 2048-sector boundaries
Total free space is 554989 sectors (271.0 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1           10240          411647   196.0 MiB   0700  Microsoft basic data
   2          411648       456042495   217.3 GiB   0700  Microsoft basic data
   3       456042496       456452095   200.0 MiB   EF00  EFI System Partition
   4       456452096       457476095   500.0 MiB   EF02 
   5       457476096       562333695   50.0 GiB    0700 
   6       562333696       574457855   5.8 GiB     8200 
   7       574457856       945829887   177.1 GiB   0700 
   8       945829888       976228351   14.5 GiB    2700  Microsoft basic data 

Fedora 16+ on Eee PC T91MT

Hello world... again.

(Update 2)
As of today May 1, 2012 the latest Fedora 17 beta is working just fine. Well mostly. The backlight blinks out momentarily every once in a while. Basically all this below is out of date.

(Update 1)
First off, you probably don't want to do this. Seems it's not as stable as I thought it was and since it's using a staging driver, it taints the Kernel with a C. Still, something to look forward to when F17 is ready. 

A while back I bought an Eee PC T91MT. It's the laptop with the screen that can rotate around and run in a tablet mode with a two point multitouch screen. I thought I would make a cool remote for something someday. Last time I installed Fedora on it (back on 14) I had a few issues I never really resolved.

The touch screen didn't work under linux.
The video driver was unsupported and there was a proprietary driver but the system still had issues including never shutting down and never rebooting without manual button intervention.

That's changed! I installed the 32 bit Fedora 16 from the net install and all the defaults other than custom partitioning.

Setup finished and then... just console. X wouldn't start up the login screen. Darn. I switched to another VT and logged in as root and started digging. Fortunately it didn't take long.
startx revealed X didn't want to touch the video device because a kernel driver had control.
lsmod told me there was a poulsbo driver active. rmmod poulsbo and a startx later and X started working. And for bonus points, the touch screen is working. Tryout installing the "mypaint" app. The pressure sensitive drawing works.

This was not the solution though. Next I went and blacklisted poulsbo but it still loaded on startup. I could have tried making a new initrd image but there was another problem. Video was limited to 800x600 when it did work. Not worth the effort for less than working completely.

The bad news:
Lots of stuff still doesn't work. No 3D acceleration.
Just look at what Ubuntu has to say: https://wiki.ubuntu.com/HardwareSupportComponentsVideoCardsPoulsbo#PSB-GFX_driver