Kernel Panic adding new User Share


Recommended Posts

I upgraded my 4.7 server to 5.0 last week. I didn't do any of the beta since I felt I couldn't afford to lose anything on my main server. The upgrade went smooth. Everything came up in the right place and I have been running fine since the upgrade until I tried to add a new user share last night. When I went to add a new share, the server crashed with a kernel panic. I forced a reboot, everything came back online just fine and thinking it may have been a fluke, I tried adding a new share again. Same thing, kernel panic. I never had any issues with 4.7. I was able to add and modify my shares to my hearts content.

 

I know I have nothing to provide to get help just yet, so my first question is, how can I get a log to see what may be happening? Since the syslog doesn't' persist after a reboot, and I can't access the server after the kernel panic, what should I do?

 

My build:

 

Intel BOXDG43NB Intel G43 ATX

Intel Pentium Dual-Core E6500 Wolfdale 2.93GHz

CORSAIR CMPSU-400CX 400W

4GB RAM

Link to comment

See SYSTEM LOG in my sig. Save a copy of the entire syslog using the unRAID GUI under Utils and then click the Log button on the top right of the unRAID GUI the open a window that will display and capture the ongoing syslog in real time. Leave this window open and  copy and paste it's contents into a text file after a crash. You will have 2 files that show the log from boot to crash. 

Link to comment
  • 3 weeks later...

Finally got around to testing things out. It seems to kernel panic with a couple of things. Creating a new share is one and panics when it tries to create the directory at /mnt/user. It also panics when I try and change the settings on a share. Attached is a log from boot to crash. The cause of the crash was enabling AFP for a share.

panic.txt

Link to comment

Still can't figure out what is going on, but I'm starting to think a filesystem issue or something. This is only happening on a few shares and any new shares I try and create that involve all disks. I can modify and do whatever I want to certain shares that are limited to a single disk or 2. I figured this out when I tried to copy some files to a certain share. The copy itself caused a kernel panic. I then tried to mv via telnet some files from one disk to another and got a kernel panic. I ran smart tests on the disks and everything checks out. I'm currently running reiserfsck --check on them as well. See the link below for a couple of pics I took of 2 of the panics. One was caused by enabling AFP on a share that includes all disks. The other is when I tried to move files from one disk to another. I suspect filesystem issues with one of these 2 disks. Thoughts??

 

http://www.flickr.com/photos/icedtrip/sets/72157636526537334/

Link to comment

I don't have any addons installed at the moment. Also, safe mode? I didn't know unraid had a safe mode.

 

Oct 12 17:49:37 Tower logger:  file /boot/packages/dmidecode-2.10-i486-1.txz: already exists
Oct 12 17:49:37 Tower logger:   upgradepkg --install-new /boot/packages/dmidecode-2.10-i486-1.txz ... 
Oct 12 17:49:37 Tower logger: +==============================================================================
Oct 12 17:49:37 Tower logger: | Installing new package /boot/packages/dmidecode-2.10-i486-1.txz
Oct 12 17:49:37 Tower logger: +==============================================================================
Oct 12 17:49:37 Tower logger: 
Oct 12 17:49:37 Tower logger: Verifying package dmidecode-2.10-i486-1.txz.
Oct 12 17:49:37 Tower logger: Installing package dmidecode-2.10-i486-1.txz:
Oct 12 17:49:37 Tower logger: PACKAGE DESCRIPTION:
Oct 12 17:49:37 Tower logger: # dmidecode (DMI table decoder)
Oct 12 17:49:37 Tower logger: #
Oct 12 17:49:37 Tower logger: # dmidecode is a tool for dumping a computer's DMI table (some say
Oct 12 17:49:37 Tower logger: # SMBIOS) contents in a human-readable format.  This table contains a
Oct 12 17:49:37 Tower logger: # description of the system's hardware components, as well as other
Oct 12 17:49:37 Tower logger: # useful pieces of information such as serial numbers and BIOS
Oct 12 17:49:37 Tower logger: # revision.
Oct 12 17:49:37 Tower logger: #
Oct 12 17:49:37 Tower logger: # dmidecode was written by Alan Cox and Jean Delvare.
Oct 12 17:49:37 Tower logger: #
Oct 12 17:49:37 Tower logger: Package dmidecode-2.10-i486-1.txz installed.
Oct 12 17:49:37 Tower logger: 
Oct 12 17:49:37 Tower logger: 
Oct 12 17:49:37 Tower logger: success
Oct 12 17:49:37 Tower logger:  file /boot/plugins/webGui-latest.txz: already exists
Oct 12 17:49:37 Tower logger:  file /tmp/plugin-tmp: successfully wrote INLINE file contents
Oct 12 17:49:37 Tower logger:   /bin/bash /tmp/plugin-tmp ... Verifying package webGui-latest.txz.
Oct 12 17:49:37 Tower logger: Installing package webGui-latest.txz:
Oct 12 17:49:37 Tower logger: PACKAGE DESCRIPTION:
Oct 12 17:49:37 Tower logger: Package webGui-latest.txz installed.
Oct 12 17:49:37 Tower logger: 
Oct 12 17:49:37 Tower logger: success
Oct 12 17:49:37 Tower logger:  plugin successfully installed
Oct 12 17:49:37 Tower logger: Installing user plugins

 

 

This package is not part of the unRAID distribution. Prepare a clean install on a formatted flash.

Link to comment

This package is not part of the unRAID distribution. Prepare a clean install on a formatted flash.

 

I guess I wasn't thinking of the new webgui as being an add-on. Also, I don't recall installing dmidecode. Was this installed along with the new webgui?

 

Either way, I started from scratch. I backed up my flash drive. Oddly, when I did, it wouldn't let me copy over one of the share config files due to corruption. Well, I formatted the flash drive, did a fresh install, but this time left off the share configs and reconfigured everything. Everything came up fine, but I am still having a panic when I interact with certain shares...the 2 shares that use all of the installed drives. Earlier, I mentioned that it paniced when I tried to move files directly from 1 disk to another. Again, the smart reports are fine with these 2 drives and the "reiserfsck --check" for both drives were fine too.

 

Attached is the most recent syslog up until crash.

panic3.txt

Link to comment

 

Thanks. I ran through all of my top level directories on all of my drives and found that several had the extended attributes set on the directories. I ran Tom's script and cleared them all up (just triple checked to make sure) and I'm still getting the kernel panic trying to enable AFP or creating a directory on the top level of this particular drive.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.