With an MBR Partition Table it was easy enough to just nuke the beginning of the drive (adapt sdz for your drive), ala:

dd if=/dev/zero of=/dev/sdz bs=1M count=1

and be on your way.  Wouldn’t it be lovely if dd understood negative indexing and you could just say:

dd if=/dev/zero of=/dev/sdz bs=1M count=-1

and be done?   Alas, it’s not meant to be.

One way to do this is to simply use ‘dd’ to write zeroes to the entire device:

dd if=/dev/zero of=/dev/sdz bs=8M

This is entirely effective, but with today’s 2-3TB drives, this can take quite a while.  You can start it and go home for the night, but if you’re not paying attention, a dd that doesn’t finish can cause you frustration and embarrassment.  Since we only need to write 34 512-byte blocks, really what we need to do is to calculate the size of the drive and find the correct blocks to overwrite.

In the recent past, people will have told you to run fdisk, look for the cylinder/heads/sectors/clusters information, apply a mathematical transform, and plug that into ‘dd’.  Besides being a pain, fdisk doesn’t even claim to support disks over 3TB.  Before the floods, those were becoming quite common.

Fortunately, Linux’s sysfs will report a block device’s size, conveniently in 512-byte block units (though that’s not necessarily obvious in context).  For instance:

# cat /sys/block/sdz/size
3907029168

shows me a 2TB disk’s actual size. I’ve looked at a 3TB disk, and fortunately (for now at least), even though the drive really uses 4k blocks, linux is still reporting in terms of 512-byte blocks.  This helps since GPT size is defined in terms of 512-byte blocks, but I wouldn’t count on sysfs to maintain this convention forever.  At some point nobody will have any 512-byte block drives and somebody will decide it’s silly to keep reporting fake block counts in sysfs.  Sanity check before blowing away drives, eh?

So, now that we know that we have the right value with the right units, it’s simply a matter of taking out the first GPT label:

/bin/dd if=/dev/zero of=/dev/sdz bs=512 count=34

and then the second (3907029168-34=3907029134):

/bin/dd if=/dev/zero of=/dev/sdz bs=512 count=34 skip=3907029134

To make sure linux understands what you’ve done here, run:

partprobe /dev/sdz

and make sure partprobe doesn’t insist upon a reboot to get the kernel straight about this (so far I haven’t found a way around this).

Verify with other partition information tools that might be relevant, e.g.:

zdb -l /dev/sdz

for ZFS.

TL;DR : for convenience, here’s a perl script that automates the above process.  Call it as:

perl zero-gpt.pl /dev/sdz

or, simply:

perl zero-gpt.pl sdz

As of this writing, the script simply prints commands for you to run – it’s not brave enough to run them itself.  So, check them before you run them.

There might be a port available, but not stock on machines, and if your machine is inside a restrictive firewall, it might be hard to get.  In a pinch, the following seems to work fine:

while /bin/true ; do clear; date; echo; ps ax | grep send; sleep 5; done

Where ‘ps ax | grep send’ is an example of the command to be used. All the rest is boilerplate. Adjust the ’5′ as you would the ‘-n’ parameter.  No doubt a simple shell script could be made to act like real ‘watch’.

1. md-raid mirror
2. LUKS encryption
3. ZFS zvol

This works nicely as it’s easy to split off an encrypted backup disk to take offsite, but since ZFS encryption hasn’t come to Linux yet, it’s still a stack of technologies to manage.  My backup set gets ever larger, so to expand the backups capacity, I bought a pair of Hitachi 3TB SATA drives.  Assuming:

• the old drives were sdc and sdd
• the new drives are sde and sdf
• the md mirror is md3
• the LUKS volume is called backup and presents as dm-0
• the zfs pool is called ‘backup’

to expand the stack:

1. mdadm –add /dev/md3 /dev/sde
2. mdadm –fail /dev/md3 /dev/sdc
3. mdadm –remove /dev/md3 /dev/sdc
4. wait for rebuild to finish (cat /proc/mdstat)
5. mdadm –add /dev/md3 /dev/sdf
6. mdadm –fail /dev/md3 /dev/sdd
7. mdadm –remove /dev/md3 /dev/sdd
8. wait for rebuilt to finish
9. mdadm –grow –size=max /dev/md3
10. cryptsetup resize backup
11. zpool online -e backup dm-0

and then run ‘zfs list’ to ensure the size is updated.  Conveniently, this can all be done without taking any of the filesystems offline.

The biggest challenge is the integrated ATI HD 6550D graphics.

Download the latest .fc16 build of Linux 3.0 from koji for proper KMS (kernel mode setting) support. Then download the latest ATI Catalyst driver from AMD. The version in RPM Fusion isn’t new enough as of this writing, nor is the xorg-x11-drv-ati build in koji new enough (the PCI ID’s are in their git tree).

That’s enough to get the system up (oh, systemd, why don’t you give me any virtual consoles when X startup fails?).

I’m stuck at 1600×1200 resolution at the moment. This display does 1900×1200, so it’s blurry. I haven’t yet found a way around this.

Performance isn’t yet screaming ‘magical’ – on some tasks it’s faster than the Core2Quad it’s replacing (maybe the faster memory?) but on others it seems a bit slower. Probably not much is tuned for it yet – this is really early in the adoption curve.

Update 2011/08/21: Sound is now working with the 2.6.40 kernel update.  Haven’t tried graphics yet, as I put an nVidia card in the machine after having a shifted video problem I couldn’t resolve with the video.

On the Nexenta/Solaris machine, for zpool ‘storage’:

zfs set aclinherit=passthrough storage/shared

zfs set sharenfs=on storage/shared

/usr/sun/bin/chmod A=everyone@:read_data/list_directory/write_data/add_file/append_data/add_subdirectory/read_xattr/write_xattr/execute/delete_child/read_attributes/write_attributes/delete/read_acl/write_acl/write_owner/synchronize:file_inherit/dir_inherit:allow /storage/shared

Now install idmapd on the linux side and start it (rpcidmapd service on Fedora/RHEL/CentOS, libidmap and the nfs service on SuSE) and mount it with these options:

mount -t nfs4 -o rw,intr,hard,proto=tcp,port=2049,acl storage-server:storage/shared /mnt/shared

or set up your automounter to use similar options.  Now, all users can do everything to the share.

note: Comments are off until I get a better blog. Please e-mail me any corrections and I’ll add them.

/usr/bin/curl http://www.nasa.gov/ram/35037main_portal.ram | /usr/bin/head -1 | /usr/bin/xargs mplayer

If the URL above changes, look for the ‘RealPlayer’ option at http://www.nasa.gov/ntv for a new .ram file.

At issue in Warshak’s e-mail flap was a 1986 law that allows the government to obtain a suspect’s e-mail from an internet service provider or webmail provider without a probable-cause warrant, once it’s been stored for 180 days or more. The appeals court said Tuesday that this part of the Stored Communications Act is unconstitutional.

“My current line of thinking is that ZFS has the required reliability, OpenSolaris is where it actually works now.

FreeBSD 9 should have a good version of it (they can’t get the zpool up to v23 in FreeBSD 8 based on FreeBSD’s major-version compatibility requirements), and Linux is also going to get it. Either of those two are good destinations. Both are currently flakey though, and OpenSolaris is solid.

The ZFS storage layer has been ported to linux by one of the National Labs – they’re still working on the POSIX layer. I suspect that’ll be ready in a year or so.

I suspect Nexenta will wind up switching kernels itself and still calling itself Nexenta in a year or two. ZFS is endian- and platform agnostic, so moving a pool from one OS to another is a ‘zpool export storage’ on the source OS, re-install the base OS, and ‘zpool import storage’ and you’re good to go.

Linux’s btrfs might even be a decent in 2-3 years, but it’s really really early still.

There’s also the Illumos project which is making an Oracle-free OpenSolaris which stands a chance. Nexenta is funding those guys – at least they’ll finally be able to do a complete Open Source build. That’s probably transitional, though – why compete with FreeBSD on drivers? “Because OpenSolaris is much faster on disk access” is a fair answer, so they could also wind up supporting a more narrow set of hardware on an ongoing basis, until FreeBSD is that fast (they can figure out how OpenSolaris beats them pretty easily, especially with lots of people wanting it to be where they wind up.)

FreeBSD is license-compatible with CDDL, otherwise Linux would be the presumptive destination. Oracle could still chose to dual-license and settle the matter that quickly, but that’s seeming less and less likely. Bill Moore, co-lead on ZFS has already left Oracle and joined the Nexenta board, so I suspect that’s where ZFS will evolve, not at Oracle. If Jeff Bonwick does the same, it’s pretty much settled.”

Reboot for xend to do its setup correctly (please commment if there’s a way to do this without reboot that works…) and instead of ‘no peth0′ you’ll find one now exists. Also, your xenbr0 will be set up properly.

Fedora client, Nexenta Server.

On the linux side, start rpcidmapd and set it to start on boot.

service rpcidmapd start
chkconfig --levels 345 rpcidmapd on

Wherever your DNS is, make sure your forward and reverse are set up correctly. No, really, make sure.

$ host my.linux.host.fqdn
my.linux.host.fqdn has address 1.2.3.4
$ host 1.2.3.4
4.3.2.1.in-addr.arpa domain name pointer my.linux.host.fqdn.

Make sure dnsdomainname returns correctly on the linux host. You need to have my.linux.host.fqdn first on the line with 127.0.0.1 in /etc/hosts. This sets the NFSv4 domain name. Restart rpcidmapd if you needed to fix this. If this is wrong your files will all show as nobody:nobody on the mount (at this point everybody in the mailing lsit archives gives up and goes back to the crummy NFSv3). Make sure linux’s dnsdomainname matches the output of Solaris’s:

cat /var/run/nfs4_domain

Now, share under zfs:

zfs set sharenfs=rw=my.linux.host.fqdn,root=my.linux.host.fqdn pool/vol/subvol

mount under linux:

mount -t nfs4 solarismachine:/vol/subvol /mnt/localmount/ -o rw,intr,hard,proto=tcp,port=2049

Then set up a root nfs mount by:

blah, blah, blah, todo, todo, todo