June 27, 20179 yr I'm currently on stable but keeping track of all the changes towards the next release. I have a macvlan setup with Docker and I'm making use of the network, ip and hostname flags (in the extra parameters field). With manual IP assignment integrated into the WebGUI, I know I'll have to make some edits to my containers -- my questions are: - Should I be making my modifications before or after I update UnRAID? - Can I set the network name and container hostname along with a static ip (via WebGUI) or are we looking at static ip only?
June 27, 20179 yr On 26/06/2017 at 9:56 AM, methanoid said: Its an awful thread for that. The short version for you: Mod your BIOS to strip out microcode (it will be too recent). UEFI boot, set your Xeon settings to allcores at max, set your UEFI shell to load a file before the OS, and boot OS, loading newer microcode with Windows (most using that) but Linux can load microcode a different way and the Allcore Turbo is locked in at the single core rate. Not done it myself yet but the benefits are there. My E5-2683-v3 is 2.0 GHz, allcore 2.5 and single core 3.0. With this process I should be able to run all cores at 3.0 GHz, effective 20% boost. Handy for VMs of course. I am looking forward to trying this, I have an E5-2695 v3 QFQG. It nominally runs at 2.3 with a single boost to 3.5. Having all at 3.5 would be *awesome* Not sure how I go about or work out how to do the bios microcode bit though...
June 27, 20179 yr 1 hour ago, Henry Thomas said: how can I default to gui mode on bootup so it will do that unattended Main - Boot Device - click on Flash to get to its page. In Syslinux Configuration move the menu default line under the label you want to be the default and Apply.
June 27, 20179 yr 23 minutes ago, trurl said: Main - Boot Device - click on Flash to get to its page. In Syslinux Configuration move the menu default line under the label you want to be the default and Apply. Based on your PM it seems like you didn't read or understand what I said here. These instructions I gave are referring to the unRAID webUI. You can do this edit in the webUI. You don't need to edit it from Windows.
June 27, 20179 yr 2 hours ago, Henry Thomas said: how can I default to gui mode on bootup so it will do that unattended Since you are new, here are more detailed instructions. In the GUI: 'Main' >>> 'Boot Device'. Then double click on "Flash" (in the "Device" column). Then click on the ' Syslinux Configuration ' tab. In the big box find the "menu default" line. Select the entire line and do a Ctrl-X and move the cursor to the next line after "label unRAID OS GUI Mode". Do a Crtl-V to paste the command there. You may have to use the enter key and space bar to make everything look proper. If you have an blank line where you cut the command from, delete the invisible new line character. Click on the "Apply" button and ant "Done" button.
June 28, 20179 yr I just upgraded from 6.3.5 to this version to try out qemu 2.9.0. One of the feature available from qemu 2.9.0 is the ability to boot macOS using an unmodified Clover plus being able to specify a more modern guest CPU model (e.g. IvyBridge). I have successfully done this with El Capitan 10.11.6 However, to run Sierra 10.12.5, it is necessary to patch qemu 2.9.0 with the applesmc patch as Gabriel L. Somlo has pointed out: https://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/ Is it possible to have this patch applied before the final release of 6.4? It would be a great help.
June 28, 20179 yr My VM menu is blank, can't access anything there. I really wanted to test Ryzen, any idea how to fix it?
June 28, 20179 yr 42 minutes ago, Josecitox said: My VM menu is blank, can't access anything there. I really wanted to test Ryzen, any idea how to fix it? Most likely a corrupt or invalid libvirt.img. Check Settings -> VM Manager
June 28, 20179 yr lost connectivity to my server, it just fell off the network. tried to do a soft power-off by hitting the power button, didn't work after 10mins so i did a cold boot. unfortunately i didn't have a monitor handy to diag live, but I've included a post-restart diag if anyone wants to have a peak. Haven't had anything like this happen since the 4.x days. vault13-diagnostics-20170628-1853.zip Edited June 28, 20179 yr by Dephcon
June 29, 20179 yr 15 hours ago, Dephcon said: lost connectivity to my server, it just fell off the network. tried to do a soft power-off by hitting the power button, didn't work after 10mins so i did a cold boot. unfortunately i didn't have a monitor handy to diag live, but I've included a post-restart diag if anyone wants to have a peak. Haven't had anything like this happen since the 4.x days. vault13-diagnostics-20170628-1853.zip This has happened on 2 out of 3 of my servers, I still had ssh access, but running diag, reboot -f , shutdown -r, etc. manually would never complete. I did a hard restart & havent had the issue since, I was waiting for someone else to post, or it to happen again.
July 3, 20179 yr With the release of kernel 4.12, it might be a god idea to get a rc7 based on 4.12? Perhaps the IOMMU changes will benefit those of us doing hardware passthrough?
July 3, 20179 yr On 6/24/2017 at 0:50 AM, Lev said: After a +1 week of using builds since rc3, this has been very stable now up to rc6. I'd like to say a special thanks to bonienl, the changes made in rc3 allowing IP addresses assignable to docker containers was a feature I'd been wanting for a long time! It made me upgrade early to this 6.4 pre-release version. It works great. I can setup a static route in the new network settings UI as well to point the IP around my OpenVPN plugin to allow that container to now be in the VPN, so ports still forward to it (Great for those wanting to run Plex and have remote access yet still run OpenVPN for everything else on UnRAID). It works fantastic! I finally shutdown my last VM, it's all docker now. Thank you bonienl !!!!! I made an official request to also have the ability to assign static DNS entries to containers (and my reason why): Edited July 3, 20179 yr by johnodon
July 3, 20179 yr Author 4 hours ago, pederm said: With the release of kernel 4.12, it might be a god idea to get a rc7 based on 4.12? Perhaps the IOMMU changes will benefit those of us doing hardware passthrough? Maybe.
July 3, 20179 yr 3 hours ago, limetech said: Maybe. I'm half and half on whether such a change should be made... Although it's 'stable' it's brand new and hasn't been deployed for long in the field, not the best idea (IMHO) to deploy it to something which needs to be rock-solid stable, i.e. a NAS. Yet on the other hand; 4.12 brings with it a flurry of interesting changes! IOMMU changes, Intel P-State driver updates, BFS scheduler, md updates for faster parity calc, etc etc... So if it does make it into 6.4 I'd still be stoked to try it out! ?
July 3, 20179 yr I would prefer to see the 4.12 kernel as a 6.4.1 release - brand new interesting changes to throw on top of a release that's went through 6 "rc" releases doesn't sound stable..
July 3, 20179 yr Is that not the purpose of RC's? Surely RC7 or even RC8 should be the new Kernel so that we can try it. X.X.1 releases are for bug fixes not kernel upgrades. Imho do an RC with the new kernel so we can atleast try it and see if there are any glaring issuesSent from my iPhone using Tapatalk
July 3, 20179 yr Author Well the purpose of our -rc series is to stabilize in order to release a stable version. Typically a kernel "minor" update (eg, 4.11.x to 4.12.x) is really a fairly significant set of changes, though in this case it looks more like bug fixes than major new features introduced. We also monitor the "longterm" support series, the last being 4.9.x: https://www.kernel.org/category/releases.html Usually fairly soon after releasing a new 'stable' branch they will either mark the previous series [EOL] or decide to make it "longterm". For an unRAID OS stable release we like to be on a "longterm" kernel.
July 4, 20179 yr 1 hour ago, miniwalks said: Is that not the purpose of RC's? No. That's the purpose of Betas.
July 4, 20179 yr 6 hours ago, limetech said: Well the purpose of our -rc series is to stabilize in order to release a stable version. Typically a kernel "minor" update (eg, 4.11.x to 4.12.x) is really a fairly significant set of changes, though in this case it looks more like bug fixes than major new features introduced. We also monitor the "longterm" support series, the last being 4.9.x: https://www.kernel.org/category/releases.html Usually fairly soon after releasing a new 'stable' branch they will either mark the previous series [EOL] or decide to make it "longterm". For an unRAID OS stable release we like to be on a "longterm" kernel. 6 hours ago, limetech said: Does that mean we should expect no update of the kernel until November? (http://news.softpedia.com/news/linux-4-14-to-be-the-next-lts-kernel-series-supported-for-at-least-2-years-516520.shtml)
July 4, 20179 yr If the new kernel is the one which enables better Ryzen operation I think it should be a priority - and I don't own a Ryzen! I'd like to get a Threadripper for unRAID on release though!
July 4, 20179 yr Seems inappropriate to release a release candidate (witch most users have come to expect a relatively safe and stable) with a new kernel. If release of the new kernel is a high priority (and I'm not commenting on that), would seem a 6.5 beta could come out while the 6.4 RC cycles continue.
July 4, 20179 yr 14 hours ago, BRiT said: No. That's the purpose of Betas. Which frankly these RC's have been. As long as new features are being added, it's a beta IMO.
July 4, 20179 yr 7 hours ago, methanoid said: If the new kernel is the one which enables better Ryzen operation I think it should be a priority - and I don't own a Ryzen! I'd like to get a Threadripper for unRAID on release though! Ryzen support was added in 4.10 so we're good on that front. It's only the IOMMU optimizations for Ryzen in 4.12 that's an improvement over 4.11... which is only really useful for those doing wiz-bang VM pass-though stuff. Edited July 4, 20179 yr by Dephcon
July 4, 20179 yr 5 minutes ago, GoChris said: Which frankly these RC's have been. As long as new features are being added, it's a beta IMO. You might have argued this on the first RC of the 6.4 series, but if you go back to Tom's -rc1 post, you'll find some rationale for no beta in the 6.4 release.
Archived
This topic is now archived and is closed to further replies.