Hi folks

First off, like to say great product! I'm so impressed I'm thinking of paying to benefit from the user level security feature

I've been testing using 4.2.4 but get a network problem when i upgrade to 4.3.1

Followed instructions to copy the bzimage and bzroot files over, reboot but then network config gets 'lost'. ie issue an ifconfig and no ip info. Manually change the IP address and can ping from workstation but no web management access. Copy back bz* files and everything ok again on 4.2.4

Motherboard is a Gigabyte GA-945GZM-S2. Strangely I had a similar sort of problem testing using an ECS mb with 945 chipset but different network chip!?

Any comments gratefully received!

A bit of research turns up the fact there are different revisions of this board, with different LAN chipsets.  One uses a common Marvell chipset, which should not be a problem.  The other uses a common Realtec chipset, which could have been a problem with unRAID v4.1 and v4.2, but not v4.3.

 

It would be useful to see both a syslog using v4.2.4, and another using v4.3.1.  You also might try an ifconfig at the console with both versions, and an lsmod, and an ethtool -i eth0, and report the results.  If you try the 3 commands in a Telnet box, you can cut and paste the results.

 

At this point, I have no ideas why v4.3.1 would not work *better* than v4.2.

Thanks for your input Rob

the problem is due to "mount: special device /dev/disk/by-label/UNRAID does not exist" error and therefore the config files can't be read

Must be something to do with the way I have prepped the USB sticks, but strange how 4.2.4 works...

Anyway, I'll have a read of this thread http://lime-technology.com/forum/index.php?topic=1116.0 and hopefully fix it over the weekend!

Have a good one

Make sure the stick is labeled UNRAID, all caps ... also that there is no strange partition on it. But, like you said, Strange the older version works which has the same requirements. 

Unless he re-formatted the flash drive, the volume label is unlikely to have been changed.

 

What is far more likely is that the newer version of unRAID is using a newer version of the Linux kernel, and it now uses different routines to deal with the motherboard hardware.  Most likely to be the cause are the functions dealing with interrupts from the hardware.

 

I would try some of the options in the syslinux.cfg as shown in this post: http://lime-technology.com/forum/index.php?topic=1676.msg11412#msg11412

 

I've seen various posts describing how acpi handling is broken in some bios.   One post suggests enabling the parallel port in the motherboard bios, even if you do not intend to use it, just so it will reserve the interrupt.  A subsequent post in the same thread recommends disabling the parallel port, if you do not need it. Hey, try it both ways. 

 

See:

http://vip.asus.com/forum/view.aspx?SLanguage=en-us&id=20060823111425215&board_id=1&model=M2N32-SLI%20Deluxe&page=1&count=15

 

Amother post described the issue as this:

The problem is that without APIC I end up with most of the onboard devices (sound, usb, pcmcia) on IRQ 11. When this happens it ACPI resets IRQ 11 half way through the bootup sequence. Not a problem in a normal Kernel boot but as I am using the USB system to host my boot drive (USB2 hd caddy) it's a bit of a problem. The Kernel looses track of the boot drive and ends in a kernel panic (unable to mount root)

In their case, when the kernel reset IRQ 11, it lost their boot device (USB hard disk).  In our case, it might be doing the same and losing the USB flash drive.  We do a bit better since we have a RAM filesystem that has been booted, so we don't get a kernel panic, but it sounds like the same issue, since we lose the USB interrupt.

 

It would be interesting, using both the older and new release of unRAID to see the output of this command and how they differ:

cat /proc/interrupts

 

It would be equally interesting if two syslogs could be attached to this thread, one from a boot up with the older release of unRAID, the other with the newer release that does not find the USB drive properly.

 

Joe L.

This one from 4.2.4 works

root@NAS:~# cat /proc/interrupts

          CPU0

  0:      16707    XT-PIC-XT        timer

  1:        166    XT-PIC-XT        i8042

  2:          0    XT-PIC-XT        cascade

  5:        229    XT-PIC-XT        ehci_hcd:usb1, uhci_hcd:usb2

  7:          0    XT-PIC-XT        uhci_hcd:usb4

  8:          3    XT-PIC-XT        rtc

  9:          0    XT-PIC-XT        acpi

10:        458    XT-PIC-XT        eth0

11:          0    XT-PIC-XT        uhci_hcd:usb3

12:          0    XT-PIC-XT        uhci_hcd:usb5

14:      58746    XT-PIC-XT        libata

15:      30127    XT-PIC-XT        libata

NMI:          0

ERR:          0

 

I tried editting the syslinux.cfg to use

acpi=off nolapic noapic

acpi=noirq irqpoll

acpi=off

but no luck

I even tried disabling the serial and parallel ports in bios..

With the tested configs I end up with /proc/interrupts entries for IO-APIC-edge and IO-APIC-fasteoi but nothing on IRQ 10

I believe it can't find the ethernet port on IRQ10 with 4.3.1!

Anyway, given up for now.... 

Joe (and other gurus!)

There is definitely something strange going on with interrupts...

under 4.3.1 the eth0 gets assigned irq21 (by doing ifconfig eth0) but not showing in the /proc/interrupts listing...

sorry can't easily paste any configs as I have no connectivity to it!  :'(

 

Sorry I can't be of help but I just thought I would add that I have the same problem. 4.2.4 boots fine but 4.3.1 refuses to boot. I have tried updating syslinux but still no joy (motherboard is an asus P5Kc).

 

 

At this point, Tom needs to investigate...  It appears to be an issue with the newer Linux kernel.  I' bet  there is some option you can add to the syslinux.cfg file, just not one you've tried.

 

Perhaps this thread will give him a clue or two.

 

Joe L.

I'm just a guru-in-training. (got the "T" shirt, but only rarely do I patch the running kernel using "dd" by writing to /dev/kmem  )

I haven't seen this problem in any of our test systems...

 

You will have to mount the Flash device manually, then copy the system log to it, then plug into PC and post or send to me.

 

To mount the Flash, at console after logging in, type:

 

cat /proc/partitions

 

This will give a list of all the devices.  You want to look for the device that is about the size of your Flash (units are 1K).  If easy to do, you could also disconnect all your hard drives and then the only device in this list should be the flash.

 

Once you figure out which one is your flash, you want to type:

 

mount /dev/sda1 /boot

 

And substitute for "sda1" whatever device appears to be your flash.

 

If this succeeds, you should be able to type:

 

ls /boot

 

and see the flash contents.  Assuming success, now copy your system log to the flash:

 

cp /var/log/syslog /boot/syslog.txt

 

While you're at it, might as well type this too:

 

v /dev/disk/by-id >/boot/devices.txt

 

Now unmount the Flash:

 

umount /boot

 

Plug Flash into PC and post or send the two files, syslog.txt and devices.txt.

Well there is definitely something very strange going on, I put the 4.3.1 bzimage and bzboot files on the USB to get the syslog as requested and it booted no problem first time around! This is after having spent 2 days trying to get it to work with no success! I rebooted it a couple more times and each time it worked fine, so I let it run overnight and in the morning I powered it down to move it back to the basement and now it refuses to boot again!! I have no idea why. Nothing had changed to make it work in the first place and as far as I am aware absolutely nothing changed to make it stop working again. All the time 4.2.4 works perfectly.

The syslog and devices files are attached as requested.

 

 

Any help is greatly appreciated.

 

 

I would like to request again, before and after syslogs, a 4.2.4 syslog and 4.3.1 syslog.  In your case, santan17, if you could also obtain and attach a 4.3.1 syslog from a successful boot, that would be helpful.  What we are looking for is a comparison of the way the hardware was identified and setup under each version, when it worked and when it didn't.

 

santan17:  this syslog is rather bazaar!  It does not appear to have finished probing the drive setup, and quit before identifying any network hardware, or loading the fuse and unRAID modules.  Yet it apparently offered you a login prompt!  Can you detail what was on the screen when you logged in?  It did not (or had not yet) identified any IDE controllers, is that possible, have you turned them all off?  And it had only found 4 SATA ports (so far?).  This appears to be an Intel ICH6-based board, but does not appear to be configured for ahci.  It did not identify anything on the JMB363 controller.

 

Hi RobJ

 

Thanks for your help! Here is the info as requested:

 

The motherboard is an ASUS P5KC with the latest BIOS. It has 4 SATA connections off the ICH9 and uses a J-Micron eSATA/PATA controller for a 5th SATA connection but the controller has been disabled in the BIOS hence the lack of IDE controllers.

Other possibly relevant BIOS settings:

Diskette drive disabled

Sata configuration: Enhanced

Configure SATA as IDE

Hard Disk Write Protect Disabled

SATA Time OUT (Sec) 35

 

 

During 4.3.1 boot everything seems to go ok (I think) until it tries to mount unraid then I get:

 

mount: special device /dev/disk/by-label/UNRAID does not exist

INIT: Entering runlevel: 3

Going multiuser...

Updating shared library links: /sbin/ldconfig &

Starting sysklogd daemons: /usr/sbin/syslogd -m0/usr/sbin/klogd -c 3 -x

Triggering udev events: /sbin/udevtrigger --retry-failed

/etc/rc.d/rc.inet1.conf: line 18: /boot/config/network.cfg: No such file or directory

/etc/rc.d/rc.inet1.conf: line 19: /var/tmp/network.cfg: No such file or directory

 

Welcome to Linux 2.6.24.4-unRAID (tty1)

Tower login:

 

 

I have also attached a successfull 4.2.4 Syslog and the unsuccessfull 4.3.1 Syslog. Unfortunatly I have not been able to succesfully boot into 4.3.1 to get a syslog...

 

Once again thanks for your help

 

Santan.

The motherboard is an ASUS P5KC with the latest BIOS. It has 4 SATA connections off the ICH9 and uses a J-Micron eSATA/PATA controller for a 5th SATA connection but the controller has been disabled in the BIOS hence the lack of IDE controllers.

Other possibly relevant BIOS settings:

Diskette drive disabled

Sata configuration: Enhanced

Configure SATA as IDE

 

That explains why no IDE controllers and only 4 SATA ports.  You will want to change the BIOS settings for the SATA ports to AHCI, or if that is not available, then some sort of native SATA mode, anything but IDE mode.

 

I also learned from this that although you have an ICH9, the Linux kernel is identifying it as ICH6, meaning there is probably so little difference between Intel's ICH6 through ICH10 that it is using the same setup routines.

 

During 4.3.1 boot everything seems to go ok (I think) until it tries to mount unraid then I get:

 

mount: special device /dev/disk/by-label/UNRAID does not exist

INIT: Entering runlevel: 3

Going multiuser...

Updating shared library links: /sbin/ldconfig &

Starting sysklogd daemons: /usr/sbin/syslogd -m0/usr/sbin/klogd -c 3 -x

Triggering udev events: /sbin/udevtrigger --retry-failed

/etc/rc.d/rc.inet1.conf: line 18: /boot/config/network.cfg: No such file or directory

/etc/rc.d/rc.inet1.conf: line 19: /var/tmp/network.cfg: No such file or directory

 

Welcome to Linux 2.6.24.4-unRAID (tty1)

Tower login:

 

Comparison of the 2 syslogs plus the messages above indicate that your problem is not a network problem, but a failure to find the USB flash drive after boot.  It proceeded to the point of setting up the networking but needed the configuration files on the flash drive, and could not find it.  The first obvious thing to check is that it still has its label of UNRAID - exactly 6 capital letters.

 

Since you probably did not change or remove the label, I recommend checking the USB Flash Drive Preparation page.  In particular, check the very last paragraph about the new syslinux.  Although your symptoms may be different than the others, a number of users have found that running the latest syslinux was necessary to make their working flash drive boot v4.3.1.  Please report back if that helps.  Edit: sorry, I just noticed that you mentioned above trying the updated syslinux.

 

It's also possible that you and adder need another boot parameter, but I'll save that for another post.

I found Joe's research into the changes in interrupt handling interesting.  Examining santan17's 2 syslogs shows that the interrupt handling *has* changed somewhat.  In unRAID v4.2.4, ACPI uses PIC to setup the IRQ's, resulting in the traditional x86 IRQ use, of interrupts 0 through 15.  In v4.3.1, ACPI uses IOAPIC which sets them up in higher interrupts, beginning with 16 and above.  I've checked other syslogs and this works fine for most, but it is not working fine for adder, and possibly not for santan17.  I suggest checking the Boot Codes page, and experiment with boot options that may restore the previous way of setting up the IRQ's.

 

A couple of interesting ACPI links:

  http://www.columbia.edu/~ariel/acpi/acpi_howto.html

  http://www.rigacci.org/wiki/doku.php/doc/appunti/linux/sa/irq_acpi_apic

 

Edit:  None of the options I found seem to affect how IOAPIC is used, or not used.  I have no ideas as to what parameter might help.

Well I have just spent the evening playing with syslinux and boot codes with no success. I did manage to boot successfully twice in a row to 4.3.1 (without any additions to syslinux.cfg) then I changed in the Bios the "serial port1 address" from 3F8/IRQ4 to disabled and it refused to boot. So changed it back again but still didn't boot. None of the additions for syslinux.cfg suggested on the Boot Codes page were successfull.

 

There doesn't appear to be any differences in the successfull and unsuccessfull syslogs other than the last line where the unsuccessfull one just gives me a command prompt and the succesfull one mounts the stick.

It seems strange that sometimes it mounts and other times it just doesn't. I would be tempted to think that maybe there is a hardware fault but 4.2.1 loads everytime with no problems.

 

Maybe I should just stick with 4.2.4 and hope for more success with 4.3.2...

 

 

Santan

Maybe I should just stick with 4.2.4 and hope for more success with 4.3.2...

As long as you are aware of any "bugs/limitations" in 4.2.4, and can live without features introduced in subsequent versions, that works perfectly well.

 

One thing to keep in mind, Tom usually upgrades the Linux kernel to the most current "stable" release each time he puts out a new version of unRAID.  The odds of 4.3.2 working are as good as any.

 

Joe L.

The only bug I am aware of is replacing a data drive with a bigger one but I have no plans to do that in the next 6 months. Are there any other serious bugs I need to know about?

 

 

Santan

That's about it.

It seems strange that sometimes it mounts and other times it just doesn't. I would be tempted to think that maybe there is a hardware fault but 4.2.1 loads everytime with no problems.

 

I have the same problem with an ECS 945GCT-M/1333 motherboard and Sony Micro Vault Tiny flash drive. So far none of my tinkering has resulted in a consistent mount. But 4.2.4 mounts every time.

 

Maybe I should just stick with 4.2.4

 

I'm starting to have the same thoughts.

 

Jim

Have you tried using the new version of syslinux?  (Tom has it available in the downloads area now)  For some, it made all the difference in the new releases.

 

Joe L.

Have you tried using the new version of syslinux?  (Tom has it available in the downloads area now)  For some, it made all the difference in the new releases.

 

Joe L.

 

Sure have. I've tried just about every suggestion I could find in the forums for booting. Some times it will boot fully, and some times it won't.

 

Jim

Have you tried using the new version of syslinux?  (Tom has it available in the downloads area now)  For some, it made all the difference in the new releases.

 

Joe L.

 

Sure have. I've tried just about every suggestion I could find in the forums for booting. Some times it will boot fully, and some times it won't.

 

Jim

If it is a timing thing, you might try changing the "rootdelay=10" line in syslinux.cfg to something either larger or smaller.

Try rootdelay=30 to start.... or even rootdelay=5

 

If making it 30 seconds works consistantly, then you can try 20 seconds so you don't have to wait so long when rebooting.

 

Are you using a USB hub? or plugging the flash drive directly into the motherboard?

Have you tried using the new version of syslinux?  (Tom has it available in the downloads area now)  For some, it made all the difference in the new releases.

 

Joe L.

 

Sure have. I've tried just about every suggestion I could find in the forums for booting. Some times it will boot fully, and some times it won't.

 

Jim

If it is a timing thing, you might try changing the "rootdelay=10" line in syslinux.cfg to something either larger or smaller.

Try rootdelay=30 to start.... or even rootdelay=5

 

If making it 30 seconds works consistantly, then you can try 20 seconds so you don't have to wait so long when rebooting.

 

Are you using a USB hub? or plugging the flash drive directly into the motherboard?

Joe,

I just got through trying rootdelay=20 when I read your reply. I will try rootdelay=30 and rootdealy=5 soon.

 

The flash drive is plugged directly into the motherboard. I tried a Lexar flash drive a little bit earlier this morning. It is buliker than the Sony Micro Vault Tiny so I had to put it in a different USB port of the motherboard because the video connector was in the way. The results were the same though.

 

I seem to be seeing a pattern with successes and failures.

 

When at the boot menu, if I press ENTER to bypass the 5 second delay or if I let the 5 second delay to play out, the boot will most likely fail.

 

When at the boot menu, if I press TAB and then ENTER (with no changes the the defaults) the boot will most likely be successful.

 

Jim

 

 

Maybe I should just stick with 4.2.4

 

I'm starting to have the same thoughts.

 

Jim

 

Just to add another data point, I went back to 4.2.4.  4.3.1  just wasn't stable for me.  unraid would crash every few days requireing a hard reboot.  Even the console was dead.  Hopefully in a later release it will get better again.