It sounds like it to me. Is the filesystem ext2 or ext3? An ext3 filesystem is slightly more survivable because of the journal - however, both formats have the same underlying structure, so the same tools work on either (ext2 tools just ignore journaling and work directly on the drive). ---- Jack Kramer Computer Systems Specialist University Relations, Michigan State University w: 517-884-1231 / c: 248-635-4955 ________________________________ From: Jesse Howard <[log in to unmask]> Reply-To: Jesse Howard <[log in to unmask]> Date: Wed, 18 Mar 2009 08:50:17 -0400 To: <[log in to unmask]> Subject: Re: [MSUNAG] UNIX webserver questions Thanks. I did an fsck -y and was able to reboot to the command line. So you think this is caused by a physical disk failure? Jesse Howard _______________________ IT Administrator Michigan State University Press [log in to unmask] www.msupress.msu.edu -----Original Message----- From: Kelly Climer [mailto:[log in to unmask]] Sent: Wednesday, March 18, 2009 8:37 AM To: Jesse Howard Cc: 'STeve Andre''; 'Peter Cole'; MSU Network Administrators Group Subject: Re: [MSUNAG] UNIX webserver questions Hi Jesse, Last time I had this it was a harbinger of doom. The drive survived for another 4 months. You can force a yes response to every question in fsck. fsck -y That will clear them all. There is a chance that you might lose some data but that is the way I could get my old web server back on line after a crash. Eventually the drive will be corrupt enough that it will not boot anymore. If these errors can be cleared and the drive is still viable it will boot. I don't know any other way to mount a drive unless it passes a fsck. Replace it soon please. I hope this helps a little. Thanks, Kelly Jesse Howard wrote: > This morning I was greeted with "kernel panic snapacct_ufs2: bad block. > Cannot dump. No dump device specified". Fsck in single user mode > returns the following over and over: > UNREF FILE > I=1912306 > OWNER=me > MODE=100600 > Size=0 > MTIME=today > Clear? > > Is there any way I can turn off snapshots from single user mode? > > > Jesse Howard > _______________________ > > IT Administrator > Michigan State University Press > [log in to unmask] > www.msupress.msu.edu > > > -----Original Message----- > From: STeve Andre' [mailto:[log in to unmask]] > Sent: Tuesday, March 17, 2009 10:43 PM > To: [log in to unmask] > Subject: Re: [MSUNAG] UNIX webserver questions > > If you can't access lost+found when you're root, things are definitely > messed up, or the partition was NFS mounted or something and it was broken. > > Probably you should rebuild this machine, such that /jail is bigger. > This is one of the reasons I don't like jails: its always the wrong > size, and you have to deal with it. ;-) > > Getting a small ups for the system wouldn't be bad idea either, if > this is an important machine. Glad to help! > > --STeve > > On Tuesday 17 March 2009 18:17:43 you wrote: > >> I could not access this lost+found directory at all, even though I >> have root, which is wierd. After checking the logs, I've discovered >> that this didn't happen all at once. /jail has been around 90% for a >> while, and somebody tipped it over today, probably just ftping files. >> I blew away the >> l+f directory and replaced it. Everything works. I think that you are >> correct that this was a dump, probably created by a power outage restart. >> Thanks for your help. >> >> Quoting "STeve Andre'" <[log in to unmask]>: >> >>> Yes, /jail is at 104% capacity. If lost+found is 12G, that means >>> that you had a dirty shutdown, and fsck found all sorts of stuff >>> (files) in an inconsistent state, didn't know where they were, so >>> put them in lost+found for a human to look at. >>> >>> Lost+found is going to stay there 'till you do something to it. At >>> this point I wonder how damaged the system is. Those things in >>> l+o were there in /jail and now they're not. My first suggestion >>> would be to inventory /jail and see what you're missing. If its a >>> mostly static partition, I'd save it, pull stuff off the last >>> backup, then manually graft the newer changed stuff atop the items >>> in /jail. >>> >>> How familiar are you with unix, or freebsd in general? This isn't >>> that hard a thing to do, unless you aren't familiar with it all and >>> then it can be daunting. >>> >>> >>> --STeve >>> >>> On Tuesday 17 March 2009 16:28:42 you wrote: >>> >>>> I think I found the problem. I did a sudo du -sh to the >>>> subdirectories inside /jail, and discovered a directory titled >>>> 'lost+found' that is 12G. I have to add myself to the operator >>>> group to even ls it. If I downed the server all the way, would this >>>> dump that directory, do you think? >>>> >>>> >>>> Jesse Howard >>>> _______________________ >>>> >>>> IT Administrator >>>> Michigan State University Press >>>> [log in to unmask] >>>> www.msupress.msu.edu >>>> >>>> >>>> -----Original Message----- >>>> From: MSU Network Administrators Group [mailto:[log in to unmask]] >>>> On Behalf Of STeve Andre' >>>> Sent: Tuesday, March 17, 2009 4:23 PM >>>> To: [log in to unmask] >>>> Subject: Re: [MSUNAG] UNIX webserver questions >>>> >>>> On Tuesday 17 March 2009 16:16:25 Jesse Howard wrote: >>>> >>>>> Who do I go to with UNIX questions on campus. Is there an >>>>> official/unofficial resource that I can bounce questions off of? >>>>> I have a freebsd jail telling me that it's file system is full >>>>> when it >>>>> >>>> shouldn't be. >>>> >>>> >>>>> Jesse Howard >>>>> >>>> You could post stuff here and see what happens. In this case a df >>>> showing the disk usage would be a good start. >>>> >>>> --STeve Andre' >>>> > > > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 3944 (20090317) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 3944 (20090317) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > __________ Information from ESET NOD32 Antivirus, version of virus signature database 3944 (20090317) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com