Recent Journal Comments

As far as sfdisk goes, it is a great tool but it is not available on the CentOS install/rescue discs, which is part of why I used printf/fdisk instead. fdisk is just more universally available than sfdisk, but if sfdisk is available it's definitely worth using.

Thanks for the pointer on d-i preload, Matt. I haven't used it, but I definitely should look at it. One of my biggest annoyances about the Debian install process is just that it requires so much attention. You can't just answer some questions and then come back to a completed install, you have to keep coming back and do a little more and then wait, a little more and then wait.

I know there are some ways around that, but I'm just right at that point where I don't do enough installs that it's worth figuring it out, but I do enough installs that it's annoying. :-)

I really like that Red Hat based releases will write a kickstart file which encapsulates the install you have just done, but I've had mixed luck with modifying the kickstart file for other purposes, probably half the times it just causes the next install to break in subtle but hard to figure out ways. Though I guess I do often do a very similar install.

Thanks,
Sean
(go to entry which this is a comment to)

Hey cool trick!

BTW are you using debian-installer preseeding? It has lots of options for partitioning.

http://d-i.alioth.debian.org/manual/en.i386/apbs04.html#preseed-partman

I'm using d-i preseeding for most of my installs now, here are my notes (although I'm not doing anything fancy with partitioning yet)

http://lackof.org/taggart/hacking/d-i_preseed/
(go to entry which this is a comment to)

sfdisk can write a partition table layout to a human-readable file. You can figure out the format and write scripts to do your partitioning programatically if you'd like. I did this when I made my own distro a while back to partition based on hard drive size/type and it worked great. "man sfdisk" for more info.
(go to entry which this is a comment to)

you were right, it did work on my 64 bit system without problems. Too bad you had removed it. I doubt anyone would have sued you for disobeying the GPL. It's a useful tool and that's what counts in this case.
(go to entry which this is a comment to)

Scott pointed out that the GPL requires source for distribution of modified binaries. Since I don't have the source for the resize2fs modifications, I have removed this binary. You'll need to reproduce the changes yourself. Sorry. Sean
(go to entry which this is a comment to)

Sorry, I've looked and I don't seem to have the modified source, just the binary. If your 64-bit system doesn't have the ability to run 64-bit static-compiled code (which would surprise me, that code definitely runs without a problem on my Ubuntu Intrepid 64-bit install), then you're going to have to reproduce the changes yourself.

Sorry,
Sean
(go to entry which this is a comment to)

For the record, at least Seagate drives seem to be more "tolerant" with the mishandling of 28-to-48 bit LBA by Linux:

Recent Seagate 750GB drives:

       sdparm /dev/sdd
           /dev/sdd: ATA       ST3750330AS       SD15
           [...]
       dd if=/dev/sdd bs=512 count=1 skip=268435455 >/dev/null
           1+0 records in
           1+0 records out
           512 bytes (512 B) copied, 7.05896 s, 0.1 kB/s
       -> This was run in an up-to-date Ubuntu 8.04 system:
           Linux felwithe 2.6.24-21-generic #1 SMP Mon Aug 25 17:32:09 UTC 2008 i686 GNU/Linux

Older Seagate 500GB drives:

       sdparm /dev/sdbsdparm  /dev/sdb
           /dev/sdb: ATA       ST3500641AS       3.AA
           [...]
       dd  if=/dev/sdb bs=512 count=1 skip=268435455 >/dev/null
           1+0 records in
           1+0 records out
      -> This was run on my own distribution, based on CentOS4 but with
         (among other things) a newer, custom-compiled kernel:
       uname -a
       Linux carbon 2.6.20.14p4 #2 Tue Jul 1 17:29:02 BRT 2008 i686 i686 i386 GNU/Linux

(go to entry which this is a comment to)

>I really wish the Linux software RAID had a "verify array" function.

Well, in recent kernels (at least since 2.6.20, possibly older ones too), you can do a

    echo "check" >/sys/block/md/md/sync_action
    (just replace <N> with your array number);

The system will then start a full verify on the array, where all blocks will be read and (if the array is of a redundant type like RAID1, RAID5, etc) the redundancy will be checked too; in case you get physical read errors, the kernel will automatically recompute the block in error and then try to write to it and read it right afterwards (in fact this will solve most read errors, as the disk's firmware will simply reallocate the block to a good one from its internal block rellocation list). All this ends up logged in syslog.

It's also possible (because of firmware issues, FUBARed controllers, etc) to have the redundant blocks being read ok but not agreeing: in this case, you will get a counter incremented in /sys/block/md<N>/md/mismatch_cnt, but no syslog messages; in that case, be sure to check mismatch_cnt after the check operation finishes (the above "echo" returns immediately, the check operation is actually done in background; you can monitor it via syslog (the end of the check operation gets logged), via "cat /proc/mdstat", or by checking the /sys/block/md<N>/md/sync_action to see when it turns to idle.

In fact, Ubuntu 8.04 installs a script in /usr/share/mdadm/checkarray that starts an array check, and it by default is run by cron via /etc/cron.d/mdadm every first sunday of each month.
(go to entry which this is a comment to)

Can you post the modifications you made to reseize2fs as a patch or the modified source code ? I need them to compile resieze2fs to work on a 64 bit Centos 5.

thanks in advance
(go to entry which this is a comment to)

Yeah, I was surprised since Fedora 9 had it that Ubuntu 8.04 did not. But, NetworkManager has been working fairly well for the WiFi connections.

Sean
(go to entry which this is a comment to)

I'm running Ubuntu 8.10 (beta) on my main laptop, and the new builds of Network Manager support EDGE and CDMA cards out-of-the-box. You plug it in, pick "Auto cdma network connection" from the left-click drop-down list from Network Manager, and you're in business!

I've really been enjoying 8.10 on my laptop--apart from the e1000e bug, which never bit me but did get the device blacklisted for a while, and an Intel wireless kernel panic which bit me a zillion times.
(go to entry which this is a comment to)

Nice work tracking this down! Now I can buy drives again. Too bad Hitachi didn't catch it in their own Linux QA :( I also wonder if Hitachi could issue a firmware workaround, that would save a lot of hassle when doing installs.
(go to entry which this is a comment to)

Hey Sean,

I just received an 0A35415 myself from mwave. I haven't had time to test it out, but I'll certainly let you know if I see the same issues you're running into.
(go to entry which this is a comment to)

Wikipedia has a good discussion of Bad Sectors. It includes basically what you said above, but does go over the distinction of bad sectors at read time and at write time.

What must be happening in the cases I saw was that data was written to the disc, and then the sector went bad and couldn't be read later. But once you write new data there, say when doing later badblocks testing, it does the remapping and the drive shows as fine.

One thing to consider about this is it's impact on RAID controllers. Most controllers will fail a rebuild if they run into an error on a read.

So imagine you have a 2 drive RAID-1 array with 20GB of data on 500GB drives. And one drive falls out of the array... You replace the drive and tell the array to rebuild. The controller is going to read all 500GB from one drive and write it to the other. Now, what if one of the sectors on the source drive has a read error. This read error is likely to be outside the used space, but the controller is now likely to set the array as failed (instead of simply degraded), and treat both drives as failed.

Some controllers now have an option for "continue rebuild on read error", which may result in the unreadable sectors being corrupted, but at least the bulk of the data will be available.

This is why it's important to make use of your controllers "verify array" functionality regularly. That should detect bad sectors early and allow remapping before bad sectors occur on both drives.

This is one of the few things that I don't like about the Linux software RAID. It doesn't have this verify functionality. To do it you would have to fail a drive from the array and add it back in and allow it to rebuild. However, if you fail one drive and there are bad sectors on the other, you're hosed. I really wish the Linux software RAID had a "verify array" function.

What I've done for this situation in the past is to set up regular jobs which read from the underlying devices, hoping that if a bad sector is detected it will cause the RAID array to fail the drive. A better test may be to do a full read from the RAID device to ensure that bad sectors are definitely detected on at least one set of the drives if they exist, even if the bad sector is outside of the used data space.

One nice thing about reading from the underlying device is that you can run the read on different schedules. I like to run the test on one drive once a week, but the other drive twice a week. I feel like I'm less likely to wear out the drives at the same rate so that hopefully they don't fail within close proximity of each other.

Sean
(go to entry which this is a comment to)

Hitachi, in the 45 days or so that we have been talking to them, has never made any suggestions about the firmware versions on the drives. Which is odd, because in other circumstances I've found this is one of the first things they'll suggest. However, at this point all the 500GB Hitachi drives we have had in inventory are now all in production. We usually have a case of pre-tested drives around for new deployments or failures, but right now we don't have any tested drives that we can easily pull the firmware information out of.

I was really expecting Hitachi support to come back with "yeah, there's a new firmware that uses different thermal recalibration code, here try this version". To be honest, I don't think calling Hitachi's response "stonewalling" we be entirely unfair.

Sean
(go to entry which this is a comment to)

This is how I understand it, I don't remember where I heard this or even know if it's correct....

Drives have their own internal list of bad blocks and also additional storage beyond the published size of the drive. When the drive determines a block is bad, it marks it bad and allocates a block from this additional storage so that the size of the drive stays constant.

So I think your heavy testing is causing marginal blocks that otherwise might remain in use to fail and be listed as bad and replacement blocks to be allocated. This sounds like a good thing and is probably a good reason for everyone to do such testing. When you deploy the drive you'll have less of the "spare" space left and when that space is used up you will start getting real errors. But that is what that space is there for, better to use it sooner rather than later.

Anyone who knows this stuff, please correct the above if I have it wrong.

Matt
(go to entry which this is a comment to)

Thanks for the detailed write up. I was about to purchase a bunch of Hitachi drives based on your previous recommendation, but now I think I will wait until this is resolved.

Does Hitachi provide a firmware update tool and firmware images? If so have you tried testing different versions?

Matt
(go to entry which this is a comment to)

I went through this for CentOS 4, and I got it working but it required a private (non GPL) driver. I've got an Addonics PCI-Express eSATA controller, which is based on the Silicon Image 3132 chip. I've got an external enclosure with an Addonics hardware SATA port multiplier. There's a single eSATA cable from the controller to the enclosure, which at the moment only has two drives in it.

SiliconImage don't really maintain their Linux drivers. However, I was pretty impressed as when I asked them about a later driver for CentOS 4, they agreed to release a newer one to me under a Non Disclosure Agreement (which I can't release for obvious reasons.

At the moment I'm maintaining a holding pattern, keeping my server on CentOS 4 and patching everything except the kernel. I'm running VMware Server on it, and it has been running without a hitch for over a year.

I'll wait until Red Hat catch up with their kernel versions, and will check that they include the revised hardware port multiplier support (which is meant to support the 3132 based controllers) before I upgrade!
(go to entry which this is a comment to)

This is helpful. It *is* in the vim documentation, but you have to be familiar with <> as marks, which I was not. Thanks.
(go to entry which this is a comment to)

USB devices tend to have unique serial numbers, or at least unique vendor:product IDs. The standard way for doing what you're accomplishing is with a udev rule that matches on these and creates a symlink to an expected device path. For example, creating /dev/input/tablet-graphire/:

KERNEL=="event[0-9]*", SYSFS{idVendor}=="056a", SYSFS{idProduct}=="0010", SYMLINK+="input/tablet-graphire"

We can also create matches based on strings found in the product field, as shown here for /dev/pilot:

KERNEL=="ttyUSB*", ATTRS{product}=="Palm Handheld*|Handspring *|palmOne Handheld", SYMLINK+="pilot"

Or based on MAC address for the wlan0 interface:

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:13:e8:cc:XX:XX", ATTR{type}=="1", NAME="wlan0"

And you can run a script after setting up the device name:

KERNEL=="lp*", SUBSYSTEMS=="usb", SYSFS{idVendor}=="03f0", SYSFS{product}=="HP LaserJet 1020", SYMLINK+="hplj1020", RUN+="/usr/sbin/hplj1020"

Maybe you considered udev but couldn't use it for some reason? It's the right answer here, assuming you're using Linux.

- Chris.
(go to entry which this is a comment to)

> I guess this is a enhacemnt of your script and it might even be pretty cool to do. 
> Probably using python or something similar. 
> But what if the pictures not just get downloaded to my HD 
> but also uploaded to my website.
>
>I currently have a Gallery web-app. Is this possible?

Possibly. I use the 'digikam' application to do that. It has a gallery export.

>Subject: ipod touch
>I presume that udev was already set up to recognise the camera in 
>this case and you'd set up something in mtab to map a path to the camera device?
>
>If I want to do something similar with an ipod touch, 
> i think what I need to do is first set up udev to recognise 
> the ipod and create a /dev/ipod link. Then, set up a mapping 
> that will mount /media/ipod to /dev/ipod and have an ipod 
> hotplug script perform the mounting/unmounting.
>
>Does that sound about right?

It would be on a system using hotplug... see below tho.

>Following your description i wanted to trigger a particular reaction 
> when i insert a memory stick.
>
>However, i have no directory /etc/hotplug on my fedora 8 machine, 
> even though 'locate hotplug' shows lots of kernel modules like for 
> instance /lib/modules/2.6.25.11-60.fc8/kernel/drivers/pci/hotplug/acpiphp.ko
>
>Do i have to do some sort of installation or configuration to get it running?

This article is from 2004, when Fedora still used hotplug. ;) So, it's out of date and no longer usefull for modern installs.

Pretty much every now is done with udev itself. See articles like: http://ubuntuforums.org/showthread.php?t=502864 for more info.

kevin
(go to entry which this is a comment to)

Hi

Following your description i wanted to trigger a particular reaction when i insert a memory stick.

However, i have no directory /etc/hotplug on my fedora 8 machine, even though 'locate hotplug' shows lots of kernel modules like for instance /lib/modules/2.6.25.11-60.fc8/kernel/drivers/pci/hotplug/acpiphp.ko

Do i have to do some sort of installation or configuration to get it running?

Thank You
Jody
(go to entry which this is a comment to)

I presume that udev was already set up to recognise the camera in this case and you'd set up something in mtab to map a path to the camera device?

If I want to do something similar with an ipod touch, i think what I need to do is first set up udev to recognise the ipod and create a /dev/ipod link. Then, set up a mapping that will mount /media/ipod to /dev/ipod and have an ipod hotplug script perform the mounting/unmounting.

Does that sound about right?
(go to entry which this is a comment to)

I am typing my passphrase 15 times. It's not like I'm rebooting very frequently, so it's not a big deal... However, the cryptsetup command can take the key via the --key-file option. Obviously, if you are saving the key on your disc, you'd better make sure that disc is encrypted. So, you could reasonably have the key-file saved to your encrypted root, and use that to automate the boot process. I just haven't felt the need yet.

Sean
(go to entry which this is a comment to)