Jump to content
limetech

unRAID Server Release 5.0-rc14 Available

204 posts in this topic Last Reply

Recommended Posts

I'm running 2GB RAM on my box so I'm thinking of skipping this RC and going from 13-15.  I know it's an easy change to get 14 working, but judging from the other post in Announcements, a new RC might be out fairly soon.

 

If I was you I would update it... maybe we will get rc15 soon but apparently Tom is still trying to get netatalk issue sorted before that, rc13 haves some more problems as you may have read (incl the crashs when stoping array).

 

All you need to do on your 2GB system to have no problems with rc14 is just don't update syslinux.cfg then you will not get the mem=4095M param on it... i.e. just update bzimage and bzroot and you will be ok.

Share this post


Link to post
Two V8 engines fused together? I'm sure there are a lot of vw engineers who would be upset by that, no it is a W16 engine, the only similar thing they have in common is 16 cylinders. (I work for vw engine assembly)

 

5h1t just got real yo!!!!  Sorry I couldn't resist.

Share this post


Link to post

okay okay - enough w. the car talk... back to reality.. we should keep this thread clean so that it makes Tom's job of reading posts to identify issues easier.

 

I too noticed a little slow down on the parity check in RC14... but i never went to rc13. My ram allocated is at 3GB and i picked the top option.

I haven't touched any of the NFS settings. Does the possibility exist of screwing it up if you go from one setting to another?

Share this post


Link to post

I too noticed a little slow down on the parity check in RC14... but i never went to rc13. My ram allocated is at 3GB and i picked the top option.

I haven't touched any of the NFS settings. Does the possibility exist of screwing it up if you go from one setting to another?

 

How much 'real' ram is actually in your machine?

For example, If you have 2GB and have told the kernel you have 4GB, you may eventually crash.

Share this post


Link to post

I guess the only way to test is to run a full parity, as eyeballing it just didn't cut it. 

 

Thanks for sharing your feedback. As for the above statement that is almost always the case  ;) glad you let it run through.

Share this post


Link to post

I've just updated to rc14 and I'm running without plugins for a while to make sure things are stable.

 

It seems like a couple of rc's ago it was suggested to add these two lines to the GO file. The idea was it would prevent emhttp and smb from ever getting shutdown as the result of a out of memory condition. Since I just switched to rc14 I have them "commented" out and they shouldn't have been read during initialization.

 

pgrep -f "/usr/local/sbin/emhttp" | while read PID; do echo -1000 > /proc/$PID/oom_score_adj; done
pgrep -f "/usr/local/sbin/smbd" | while read PID; do echo -1000 > /proc/$PID/oom_score_adj; done

 

I've had them in there and never encountered problems, to the best of my knowledge. It seems rc14 is running pretty well and we're getting close to finalizing V5. So, is there any reason to keep these lines in my GO file, or just let them go?

 

Thanks!

 

 

Share this post


Link to post

I too noticed a little slow down on the parity check in RC14... but i never went to rc13. My ram allocated is at 3GB and i picked the top option.

I haven't touched any of the NFS settings. Does the possibility exist of screwing it up if you go from one setting to another?

 

How much 'real' ram is actually in your machine?

For example, If you have 2GB and have told the kernel you have 4GB, you may eventually crash.

 

UnRaid is running in a VM ... physical i have 24GB... that shouldn't matter though, right? when I set the VM's allocation to 3GB? I have lots of spare ram to go up or can even decrease, since I only have a few add-ins

Share this post


Link to post

Can someone help me understand when in the process the USB drive gets mounted as /boot or as UNRAID and is there a timing of how long it waits for the drive to be loaded before moving on?

 

I'm trying to troubleshoot an error. rc10 worked, 11-12 no workie, 13 worked, 14 no workie. It appears to be related to the USB drive not getting mounted or being mounted in properly. The only thing I can someone trace it to is the kernel.

 

From my limited unix knowledge it appears the drive is mounted on the computer, but something is going on. The system comes up and emhttp doesn't appear or want to load. I can start it manually, but it has problems.

 

root@Tower:/# ls /dev/disk/by-id/*

/dev/disk/by-id/ata-WDC_WD20EARS-00MVWB0_WD-WMAZA0310325@        /dev/disk/by-id/scsi-SATA_WDC_WD20EARS-00_WD-WMAZA2802606@

/dev/disk/by-id/ata-WDC_WD20EARS-00MVWB0_WD-WMAZA0310325-part1@  /dev/disk/by-id/scsi-SATA_WDC_WD20EARS-00_WD-WMAZA2802606-part1@

/dev/disk/by-id/ata-WDC_WD20EARS-00MVWB0_WD-WMAZA2802606@        /dev/disk/by-id/usb-Lexar_JD_FireFly_TXVSZS46RZ0JRC7V5WG1-0:0@

/dev/disk/by-id/ata-WDC_WD20EARS-00MVWB0_WD-WMAZA2802606-part1@  /dev/disk/by-id/usb-Lexar_JD_FireFly_TXVSZS46RZ0JRC7V5WG1-0:0-part1@

/dev/disk/by-id/ata-WDC_WD20EARS-00S8B1_WD-WCAVY2836928@          /dev/disk/by-id/wwn-0x50014ee00261e6e5@

/dev/disk/by-id/ata-WDC_WD20EARS-00S8B1_WD-WCAVY2836928-part1@    /dev/disk/by-id/wwn-0x50014ee00261e6e5-part1@

/dev/disk/by-id/scsi-SATA_WDC_WD20EARS-00_WD-WCAVY2836928@        /dev/disk/by-id/wwn-0x50014ee2041dd087@

/dev/disk/by-id/scsi-SATA_WDC_WD20EARS-00_WD-WCAVY2836928-part1@  /dev/disk/by-id/wwn-0x50014ee2041dd087-part1@

/dev/disk/by-id/scsi-SATA_WDC_WD20EARS-00_WD-WMAZA0310325@        /dev/disk/by-id/wwn-0x50014ee65608294e@

/dev/disk/by-id/scsi-SATA_WDC_WD20EARS-00_WD-WMAZA0310325-part1@  /dev/disk/by-id/wwn-0x50014ee65608294e-part1@

root@Tower:/# ls /dev/disk/by-label/*

/dev/disk/by-label/UNRAID@

 

Should I try unmounting /boot and remounting in manually and starting emhttp?

 

Thanks,

Josh

syslog14a.txt

Share this post


Link to post

Tom,

 

I've wrapped up my testing of RC14, using my 'Current' build in my signature line.  I tested with both mem=4095M and without, and ran full parity checks, starts/stops/starts/stops and powerdowns through GUI using unRAID's stock script, copying 100's of gigabytes of data to the array, and watching Blu-Ray ISO's on the array. 

 

I did not add/upgrade/remove/format any drives, so I can't report on those capabilities.

 

No issues to report, great job!  The md_sync_window fixes are still working perfectly for me on RC14, just as they did on RC12a (I skipped RC13, sorry).

Thank you for your hard work!

 

Interestingly, even though the mem=4095M parity check appeared slower to my eyes (reported speeds seemed 5-10% lower while processing), by the stopwatch both parity checks completed within a minute of each other, regardless of the mem=4095M setting.  I guess the only way to test is to run a full parity, as eyeballing it just didn't cut it. 

That makes sense because the parity-sync/check operation uses a dedicated memory pool created by the unraid driver when it starts up.  The "mem=" parameter is affecting the amount of memory linux allocates to write-back cache in it's general buffer pool used for file I/O, ie, called the "buffer cache".  Lowering the RAM seen by linux is really just masking a different bug somewhere in the linux memory allocation code (which apparently is fixed in later kernels, btw).

 

Thank you,

-Paul

Share this post


Link to post

Can someone help me understand when in the process the USB drive gets mounted as /boot or as UNRAID and is there a timing of how long it waits for the drive to be loaded before moving on?

Look on the console, do you see any messages getting output there?

Share this post


Link to post
Lowering the RAM seen by linux is really just masking a different bug somewhere in the linux memory allocation code (which apparently is fixed in later kernels, btw).

 

Ah ha! So the problem isn't PAE causing the issue, it's another bug somewhere.

 

Frankly I tried beating the hell out of my lil HP N54L last night PAE and mem=4095.

I could not find a slow down or trigger this issue.

Share this post


Link to post

At the console, I'm seeing a number of "waiting for /dev/disk/by-label/UNRAID" there are about 10 or messages then /dev/disk/by-label/UNRAID not found. Mounting non-root local file systems.

 

if -rc15 is coming out with the 3.9.6 kernel, I'll just see how that goes as -rc13 worked.

 

-Josh

Share this post


Link to post

At the console, I'm seeing a number of "waiting for /dev/disk/by-label/UNRAID" there are about 10 or messages then /dev/disk/by-label/UNRAID not found. Mounting non-root local file systems.

 

if -rc15 is coming out with the 3.9.6 kernel, I'll just see how that goes as -rc13 worked.

 

-Josh

 

this means your USB isnt labelled "UNRAID" or it was not detected, or a 3rd rare issue, see below.

 

I found a device that would start the boot process (meaning the stick was detected and booted from) but later would get forgotten and not detected by Linux. the stick was definately named UNRAID, but it just "dropped" somewhere during boot.

Share this post


Link to post

At the console, I'm seeing a number of "waiting for /dev/disk/by-label/UNRAID" there are about 10 or messages then /dev/disk/by-label/UNRAID not found. Mounting non-root local file systems.

 

if -rc15 is coming out with the 3.9.6 kernel, I'll just see how that goes as -rc13 worked.

 

-Josh

 

this means your USB isnt labelled "UNRAID" or it was not detected, or a 3rd rare issue, see below.

 

I found a device that would start the boot process (meaning the stick was detected and booted from) but later would get forgotten and not detected by Linux. the stick was definately named UNRAID, but it just "dropped" somewhere during boot.

Yup, looks like you need a different (better) USB flash device.

Share this post


Link to post

I'm currently using a Lexar Firefly, that is only a couple of years old. I've checkdisked it and it comes back fine.

 

I also tried another newer USB drive I have laying around. Same thing, system behaved the same way.  Also if the flash drive was going bad, I would not have expected rc13 to work. 

 

It seems to be related some how to this http://lime-technology.com/forum/index.php?topic=25250.msg220900#msg220900 For what ever reason the USB drive isn't mounting and it's only waiting soo long.

 

I do see a lot of ata5: link is slow to respond errors on the concole, but I thought those were due to ata ports on the mobo that are not in use.

 

Jun 14 20:50:43 Tower kernel: sd 1:0:0:0: [sdb] Attached SCSI disk

Jun 14 20:50:43 Tower kernel: scsi 8:0:0:0: Direct-Access    Lexar    JD FireFly      1100 PQ: 0 ANSI: 0 CCS

Jun 14 20:50:43 Tower kernel: sd 8:0:0:0: [sdd] 3915776 512-byte logical blocks: (2.00 GB/1.86 GiB)

Jun 14 20:50:43 Tower kernel: sd 8:0:0:0: [sdd] Write Protect is off

Jun 14 20:50:43 Tower kernel: sd 8:0:0:0: [sdd] Mode Sense: 43 00 00 00

Jun 14 20:50:43 Tower kernel: sd 8:0:0:0: [sdd] No Caching mode page present

Jun 14 20:50:43 Tower kernel: sd 8:0:0:0: [sdd] Assuming drive cache: write through

Jun 14 20:50:43 Tower kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0

Jun 14 20:50:43 Tower kernel: sd 1:0:0:0: Attached scsi generic sg1 type 0

Jun 14 20:50:43 Tower kernel: sd 2:0:0:0: Attached scsi generic sg2 type 0

Jun 14 20:50:43 Tower kernel: sd 8:0:0:0: Attached scsi generic sg3 type 0

Jun 14 20:50:43 Tower kernel: sd 8:0:0:0: [sdd] No Caching mode page present

Jun 14 20:50:43 Tower kernel: sd 8:0:0:0: [sdd] Assuming drive cache: write through

Jun 14 20:50:43 Tower kernel:  sdd: sdd1

Jun 14 20:50:43 Tower kernel: sd 8:0:0:0: [sdd] No Caching mode page present

Jun 14 20:50:43 Tower kernel: sd 8:0:0:0: [sdd] Assuming drive cache: write through

Jun 14 20:50:43 Tower kernel: sd 8:0:0:0: [sdd] Attached SCSI removable disk

Jun 14 20:50:43 Tower kernel: ata5: link is slow to respond, please be patient (ready=-19)

Jun 14 20:50:43 Tower kernel: ata5: COMRESET failed (errno=-16)

Jun 14 20:50:43 Tower kernel: ata5: link is slow to respond, please be patient (ready=-19)

Jun 14 20:50:43 Tower kernel: ata5: COMRESET failed (errno=-16)

Jun 14 20:50:43 Tower kernel: ata5: link is slow to respond, please be patient (ready=-19)

Jun 14 20:50:43 Tower kernel: ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 310)

Share this post


Link to post

I'm currently using a Lexar Firefly, that is only a couple of years old. I've checkdisked it and it comes back fine.

 

I also tried another newer USB drive I have laying around. Same thing, system behaved the same way.  Also if the flash drive was going bad, I would not have expected rc13 to work. 

 

It seems to be related some how to this http://lime-technology.com/forum/index.php?topic=25250.msg220900#msg220900 For what ever reason the USB drive isn't mounting and it's only waiting soo long.

 

I do see a lot of ata5: link is slow to respond errors on the concole, but I thought those were due to ata ports on the mobo that are not in use.

 

Jun 14 20:50:43 Tower kernel: sd 1:0:0:0: [sdb] Attached SCSI disk

Jun 14 20:50:43 Tower kernel: scsi 8:0:0:0: Direct-Access    Lexar    JD FireFly      1100 PQ: 0 ANSI: 0 CCS

Jun 14 20:50:43 Tower kernel: sd 8:0:0:0: [sdd] 3915776 512-byte logical blocks: (2.00 GB/1.86 GiB)

Jun 14 20:50:43 Tower kernel: sd 8:0:0:0: [sdd] Write Protect is off

Jun 14 20:50:43 Tower kernel: sd 8:0:0:0: [sdd] Mode Sense: 43 00 00 00

Jun 14 20:50:43 Tower kernel: sd 8:0:0:0: [sdd] No Caching mode page present

Jun 14 20:50:43 Tower kernel: sd 8:0:0:0: [sdd] Assuming drive cache: write through

Jun 14 20:50:43 Tower kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0

Jun 14 20:50:43 Tower kernel: sd 1:0:0:0: Attached scsi generic sg1 type 0

Jun 14 20:50:43 Tower kernel: sd 2:0:0:0: Attached scsi generic sg2 type 0

Jun 14 20:50:43 Tower kernel: sd 8:0:0:0: Attached scsi generic sg3 type 0

Jun 14 20:50:43 Tower kernel: sd 8:0:0:0: [sdd] No Caching mode page present

Jun 14 20:50:43 Tower kernel: sd 8:0:0:0: [sdd] Assuming drive cache: write through

Jun 14 20:50:43 Tower kernel:  sdd: sdd1

Jun 14 20:50:43 Tower kernel: sd 8:0:0:0: [sdd] No Caching mode page present

Jun 14 20:50:43 Tower kernel: sd 8:0:0:0: [sdd] Assuming drive cache: write through

Jun 14 20:50:43 Tower kernel: sd 8:0:0:0: [sdd] Attached SCSI removable disk

Jun 14 20:50:43 Tower kernel: ata5: link is slow to respond, please be patient (ready=-19)

Jun 14 20:50:43 Tower kernel: ata5: COMRESET failed (errno=-16)

Jun 14 20:50:43 Tower kernel: ata5: link is slow to respond, please be patient (ready=-19)

Jun 14 20:50:43 Tower kernel: ata5: COMRESET failed (errno=-16)

Jun 14 20:50:43 Tower kernel: ata5: link is slow to respond, please be patient (ready=-19)

Jun 14 20:50:43 Tower kernel: ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 310)

 

Is it a usb3 or usb2 port? I've had a variety of problems with USB devices not detecting or working properly when they were plugged into a usb3 port which were fixed by just moving them to a usb2 port.

 

Sent from my Nexus 4 using Tapatalk 2

 

 

Share this post


Link to post

I did started reading calypsocowboy posts and also thought if maybe the problem may not be related to that "new" 10s timeout to wait usb flash to be mounted on init script, as on some tests I made recently to get unraid running from an hdd, on one boot attempt I did without an UNRAID partition available I did see the lines and wondered myself... damn it only waits this and ceases? what if for some reason, on some system (not sure if possible but... sometimes all it's possible :) ) things take some more time to get ready? maybe increasing it to 20 or 30 seconds could be an idea to be safer that it is really enough?

Share this post


Link to post

I did started reading calypsocowboy posts and also thought if maybe the problem may not be related to that "new" 10s timeout to wait usb flash to be mounted on init script, as on some tests I made recently to get unraid running from an hdd, on one boot attempt I did without an UNRAID partition available I did see the lines and wondered myself... damn it only waits this and ceases? what if for some reason, on some system (not sure if possible but... sometimes all it's possible :) ) things take some more time to get ready? maybe increasing it to 20 or 30 seconds could be an idea to be safer that it is really enough?

Since it should drop out of the loop as soon as the USB drive is discovered, a longer timeout should affect nobody except someone who really needs it.

Share this post


Link to post

I did started reading calypsocowboy posts and also thought if maybe the problem may not be related to that "new" 10s timeout to wait usb flash to be mounted on init script, as on some tests I made recently to get unraid running from an hdd, on one boot attempt I did without an UNRAID partition available I did see the lines and wondered myself... damn it only waits this and ceases? what if for some reason, on some system (not sure if possible but... sometimes all it's possible :) ) things take some more time to get ready? maybe increasing it to 20 or 30 seconds could be an idea to be safer that it is really enough?

Since it should drop out of the loop as soon as the USB drive is discovered, a longer timeout should affect nobody except someone who really needs it.

Ok, upped the timeout to 30 sec, no one tell Barzija.

Share this post


Link to post

I tried to boot my machine and a DIMM went bad, so now I am down to a single stick of 2gb ram.

 

So all the talk of the 4gb memory limit and parameters, well, with RC14 if I try to boot up with 2gb of ram it does not work. It uses the default option of course with 4gb limit and it does not boot. It loops back to POST. If I take the other option it boots ok. So how can I make it default to the other option? Why does it not work on default option? Do I need to change some option in my BIOS to do with memory mapping? The default is that it is set to ENABLED in my BIOS. I think this is an option for 32bit OS's to be able to use 4gb or more.

 

Confused.

 

Off to modify syslinux.cfg file and/or remove it.

Share this post


Link to post

I tried to boot my machine and a DIMM went bad, so now I am down to a single stick of 2gb ram.

 

So all the talk of the 4gb memory limit and parameters, well, with RC14 if I try to boot up with 2gb of ram it does not work. It uses the default option of course with 4gb limit and it does not boot. It loops back to POST. If I take the other option it boots ok. So how can I make it default to the other option? Why does it not work on default option? Do I need to change some option in my BIOS to do with memory mapping? The default is that it is set to ENABLED in my BIOS. I think this is an option for 32bit OS's to be able to use 4gb or more.

 

Confused.

 

Off to modify syslinux.cfg file and/or remove it.

 

 

edit the syslinux.cfg

move the line "menu default" to the option you want to boot by default

i.e. the option without the mem=

 

 

Share this post


Link to post

@jaybee: ... or if you are not comfortable with editing it just get syslinux.cfg file from rc13, rc12, ... as it defaulted to no memory limit on these versions (in fact mem option doesn't limit but force that memory amount, that's why you can't boot with 2GB, then the problem you get it's normal and others got it too, don't mess with bios options :) ).

Share this post


Link to post

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.