Cannot create new quotafile ?

ArtistPlug.ME — Sat, 08 Aug 2009 20:50:11 +0000

I’ve been busy with a very strange bug lately. A few weeks ago I’ve tried to fix it by using the normal quota procedures but still I was getting that dreadful DirectAdmin message with:

Error with system Quotas setquota: Mountpoint (or device) /home not found. setquota: Not all specified mountpoints are using quota.
Normally, the line /sbin/quotaoff -a ; /sbin/quotacheck -avugm ; /sbin/quotaon -a should fix it, but still, I got a rather nasty error with that:

root@mother:/# /sbin/quotacheck -avugm quotacheck: Cannot create new quotafile //aquota.user.new: File exists quotacheck: Cannot initialise IO on new quotafile: File exists quotacheck: Cannot create new quotafile //aquota.group.new: File exists quotacheck: Cannot initialise IO on new quotafile: File exists quotacheck: Scanning /dev/cciss/c0d1p1 [/home] ....

I’ve solved this finally by renaming four files and running the same command again. Seems to be a (new) bug in Debian Etch? ..

cd / ; mv aquota.user.new aquota.user.trash ; cd /home ; mv aquota.user.new aquota.user.trash
I’ve had no group quotas defined, the same probably has to be done with aquota.group.new.

No related posts.

Yikes, two Leaseweb server crashes in a row!

Freaking Wildchild — Mon, 09 Mar 2009 19:04:44 +0000

I’ve been having a terrible headache of crashing disk drives lately. For sure when this happens for twice in a row! Once at 2 march 2009, the second at 8 march 2009. This with the brand new HP DL 180 server hosted at Leaseweb.

Mental note: whatever you administrate:

KEEP BACKUPS READY! All time!

The first crash at 22:45 was swiftly taken care of, the disks were changed inside 24 hours with Western Digital, the dataloss was quite minimal. After working for 5 consecutive days all data was recovered, including my work for a second server which was ordered through Leaseweb. The restoration process was visible by miles, since the changes from ArtistBlog.ME/beta were implemented at once at the production side of ArtistBlog.ME.

The second crash happened just a day before writing this, this time at night. At 05:00 I’ve noticed the server was going very slow and I was able to send myself the latest snapshot of the backup which was ready to be transported. The server was brought back online at 18:00 thanks to Leaseweb support and after a bit of MySQL & permissions troubles the ArtistBlog.ME component was back on-line in no time later.

Leaseweb has responded me “the HP controller firmware seems to be buggy, which will be upgraded tomorrow morning.” Hopefully this firmware will fix the server with an automagical potion of fairy dust so it’ll be enchanted to the use of the ArtistPlug.ME network for many years. I’ve already demanded for a parallel solution if this server would corrupt it’s data one more time, to get a kosher prompt replacement of the server; because this could hurt customers with the second server i’ve been preparing at Leaseweb.

So, Leaseweb, let’s really hope so this HP DL 180 server will be healed up with the firmware for reliabilities sake…

update (19 june 2009): Until now the update has been working great! (holding wood). Leaseweb support has been swift and easy and the server has lived long and happy since that famous HP controller firmware update!

You’ll find a bit of reference material underhere!

The first crash … where it started …

Mar 2 23:12:46 mother kernel: cciss: cmd f7002500 has CHECK CONDITION sense key = 0×3
Mar 2 23:12:46 mother kernel: Buffer I/O error on device cciss/c0d1p1, logical block 136478722
Mar 2 23:12:46 mother kernel: cciss: cmd f7002750 has CHECK CONDITION sense key = 0×3
Mar 2 23:12:46 mother kernel: Buffer I/O error on device cciss/c0d1p1, logical block 139591683
Mar 2 23:12:46 mother kernel: lost page write due to I/O error on cciss/c0d1p1

[...] And it doesn’t get better than that afterwards ! [...]

Mar 2 23:13:20 mother kernel: EXT3-fs error (device cciss/c0d1p1): ext3_journal_start_sb: Detected aborted journal
Mar 2 23:13:20 mother kernel: Remounting filesystem read-only
Mar 2 23:13:21 mother kernel: cciss: cmd f70006f0 has CHECK CONDITION sense key = 0×3
Mar 2 23:13:21 mother kernel: Buffer I/O error on device cciss/c0d1p1, logical block 166789121
Mar 2 23:13:21 mother kernel: cciss: cmd f7000940 has CHECK CONDITION sense key = 0×3
Mar 2 23:13:21 mother kernel: Buffer I/O error on device cciss/c0d1p1, logical block 166789172
Mar 2 23:13:21 mother kernel: lost page write due to I/O error on cciss/c0d1p1
Mar 2 23:13:21 mother kernel: cciss: cmd f7000b90 has CHECK CONDITION sense key = 0×3
Mar 2 23:13:21 mother kernel: Buffer I/O error on device cciss/c0d1p1, logical block 166793477
Mar 2 23:13:21 mother kernel: lost page write due to I/O error on cciss/c0d1p1
Mar 2 23:13:21 mother kernel: cciss: cmd f7000de0 has CHECK CONDITION sense key = 0×3
Mar 2 23:13:21 mother kernel: lost page write due to I/O error on cciss/c0d1p1
Mar 2 23:13:35 mother kernel: cciss: cmd f7000000 has CHECK CONDITION sense key = 0×3
Mar 2 23:13:55 mother last message repeated 2 times
Mar 2 23:13:55 mother kernel: EXT3-fs error (device cciss/c0d1p1): ext3_find_entry: reading directory #83396003 offset 0

The second crash …

similar problems, this was for me the hint this was NOT the hard disk but rather the controller!

Mar 9 04:32:20 mother kernel: cciss: cmd f7100000 has CHECK CONDITION sense key = 0×3
Mar 9 04:32:20 mother kernel: EXT3-fs error (device cciss/c0d2p1): read_inode_bitmap: Cannot read inode bitmap – block_group = 6656, inode_bitmap = 218103809
Mar 9 04:32:20 mother kernel: EXT3-fs error (device cciss/c0d2p1) in ext3_new_inode: IO failure
Mar 9 04:35:37 mother kernel: cciss: cmd f7100000 has CHECK CONDITION sense key = 0×3
Mar 9 04:35:37 mother kernel: EXT3-fs error (device cciss/c0d2p1): read_inode_bitmap: Cannot read inode bitmap – block_group = 6656, inode_bitmap = 218103809
Mar 9 04:35:37 mother kernel: EXT3-fs error (device cciss/c0d2p1) in ext3_new_inode: IO failure
Mar 9 04:37:40 mother kernel: cciss: cmd f7100250 has CHECK CONDITION sense key = 0×3
Mar 9 04:37:40 mother kernel: EXT3-fs error (device cciss/c0d2p1): read_inode_bitmap: Cannot read inode bitmap – block_group = 6656, inode_bitmap = 218103809
Mar 9 04:37:40 mother kernel: EXT3-fs error (device cciss/c0d2p1) in ext3_new_inode: IO failure
Mar 9 04:39:21 mother kernel: cciss: cmd f7100000 has CHECK CONDITION sense key = 0×3
Mar 9 04:40:36 mother kernel: cciss: cmd f7102500 has CHECK CONDITION sense key = 0×3

Cannot create new quotafile ? How to fix a nasty quotaproblem on Debian Etch. quotacheck:...

ArtistBlog.ME had a crash .. at start ;)

Freaking Wildchild — Sun, 01 Mar 2009 01:09:08 +0000

Some more news about this hard disk crash …

ArtistBlog.ME & ArtistPlug.NET were before in development locally & remotely
The changes with WordPress MU and Buddypress were just at their final milestone
The graphics were fully implemented, css files were tweaked
A lot of my work was semi-done on that system ready to be transported to another
I was backing up as we speak …….

Then, the enevitable happens, the moment I was doing a tar backup to move everything off-site the hard drive started spewing out I/O errors; the backup didn’t even made it!

The bad news: A lot of the front end has been demolished, including a few plugins I’ve created. The WordPress directory was zero’d out with a lot of other files.

The good news: The database was found intact for about 95% ! Woohoo!

All content, layout, images and doodles will be reinstalled in a matter of time, the network has experienced a week slowdown but hey! I’ve got a new mental note!

Don’t buy seagates 1000gb drives! Furtheron the site has found it’s basic design now!
be prepared before you are prepared! Because once you are backing up it could go wrong too!

Signing out!