gerard6110

@doron: Please note the output of "mount" with thohell's bzoverlay: proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) tmpfs on /dev/shm type tmpfs (rw) tmpfs on /var/log type tmpfs (rw,size=128m,mode=0755) /dev/sdb1 on /boot type vfat (rw,noatime,nodiratime,flush,dmask=77,fmask=177,shortname=mixed) /boot/bzmodules on /lib/modules type squashfs (ro) /boot/bzfirmware on /lib/firmware type squashfs (ro) hugetlbfs on /hugetlbfs type hugetlbfs (rw) /mnt on /mnt type none (rw,bind) tmpfs on /mnt/disks type tmpfs (rw,size=1M) /dev/md1 on /mnt/disk1 type xfs (rw,noatime,nodiratime) /dev/nvme0n1p1 on /mnt/cache type btrfs (rw,noatime,nodiratime) shfs on /mnt/user0 type fuse.shfs (rw,nosuid,nodev,noatime,allow_other) shfs on /mnt/user type fuse.shfs (rw,nosuid,nodev,noatime,allow_other) /dev/sda1 on /mnt/disks/BOOTDISK type vfat (rw,noatime,nodiratime,nodev,nosuid,umask=000) /mnt/cache/system/docker/docker.img on /var/lib/docker type btrfs (rw) /mnt/cache/system/libvirt/libvirt.img on /etc/libvirt type btrfs (rw) After reboot, with new doron bzoverlay: Sorry to tell you, but no full boot ...

OK, removed the PreClear Disks plugin and rebooted. No more repeating messages. Also checked the system log; no errors; Yesss! Thanks alot doron. Only some warnings (although there were also warnings even when booting from the original UNRAID flash), as follows: May 14 18:29:31 Tower kernel: ACPI: Early table checksum verification disabled May 14 18:29:31 Tower kernel: Initramfs unpacking failed: Input was encoded with settings that are not supported by this XZ decoder May 14 18:29:31 Tower kernel: floppy0: no floppy controllers found May 14 18:29:31 Tower kernel: random: 7 urandom warning(s) missed due to ratelimiting May 14 18:29:31 Tower kernel: igb 0000:06:00.0 eth0: mixed HW and IP checksum settings. May 14 18:29:31 Tower kernel: ccp 0000:0e:00.1: psp initialization failed May 14 18:29:31 Tower kernel: ACPI Warning: SystemIO range 0x0000000000000B00-0x0000000000000B08 conflicts with OpRegion 0x0000000000000B00-0x0000000000000B0F (\GSA1.SMBI) (20180810/utaddress-204) May 14 18:29:31 Tower kernel: igb 0000:06:00.0 eth0: mixed HW and IP checksum settings. May 14 18:29:31 Tower kernel: igb 0000:06:00.0 eth0: mixed HW and IP checksum settings. May 14 18:29:31 Tower kernel: igb 0000:06:00.0 eth0: mixed HW and IP checksum settings. May 14 18:29:31 Tower kernel: igb 0000:06:00.0 eth0: mixed HW and IP checksum settings. May 14 18:29:34 Tower kernel: igb 0000:06:00.0 eth0: mixed HW and IP checksum settings. May 14 18:29:40 Tower rpc.statd[2191]: Failed to read /var/lib/nfs/state: Success May 14 18:29:56 Tower kernel: igb 0000:06:00.0 eth0: mixed HW and IP checksum settings A;though everything seems to working fine, anything to worry about? From memory I believe ACPI Early ... and random: 7 are no issue. floppy0 also not of course - who still uses floppies nowadays 😃. It seems to me that initramfs, igb and ACPI Warning are new. Then mounted the BOOTDISK flash, and it was succesfully mounted. Thus set it to automount and still OK, no warning messages. Except for the few above warnings things seems fine to me.

@doron: make_bootable_linux: This I tried after extracting the backup.zip to the usb and then inserting the usb in an ubuntu 20.04 system and running make_bootable_linux. Then rebooting and it did not boot. SIGHUP messages: yes, it was clear this had to do with the UD plugin. So I already tried setting it to automount, but then I go a lot of RED I/O errors, like: May 13 20:15:44 Tower kernel: sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 May 13 20:15:44 Tower kernel: sd 0:0:0:0: [sda] tag#0 Sense Key : 0x6 [current] May 13 20:15:44 Tower kernel: sd 0:0:0:0: [sda] tag#0 ASC=0x28 ASCQ=0x0 May 13 20:15:44 Tower kernel: sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 00 02 08 00 00 f0 00 May 13 20:15:44 Tower kernel: print_req_error: I/O error, dev sda, sector 520 May 13 20:15:44 Tower kernel: print_req_error: I/O error, dev sda, sector 760 May 13 20:15:44 Tower rc.diskinfo[10768]: SIGHUP received, forcing refresh of disks info. Note: sectors change everytime and also opcode changes. I also tried to change BOOTDISK to /boot, but then again the same "not set to automount" messages and tried /boot and automount, and again the opcode and sector messages. So now back to BOOTDISK and not automount (with SIGHUP messages).

@fmp4m: Indeed I did set it to automount, but then I got all kinds of continuous RED errors, so I thought that can't be good and thus deslected the automount again, only leaving the above SIGHUP errors.

I guess I was a little bit too quick, because when looking at the logs, the following is repeated every 3 seconds. Quote kernel: sda: sda1 rc.diskinfo[10775]: SIGHUP received, forcing refresh of disks info. unassigned.devices: Disk with serial 'Flash_Disk_12345678', mountpoint 'BOOTDISK' is not set to auto mount and will not be mounted. Unquote Not sure if really a problem, but at least I see the flash lighting up every 3 seconds, so cannot be good for the flash itself (although it can now be replaced quite easily - as I did it twice this evening with the same flash usb - first time to try and 2nd time to check and complete my instructions. As to make_bootable_linux. I went back to the basics and just tried it without any changes and the USB did not boot, so then I stopped going with the linux method. I could try it again just for the sake of the messages, but most or all had to do with mounting and unmounting.

It worked, but differently - still a lot of thanks to thohell for the bzoverlay and the initial idea. Note: the make_bootable_linux installer itself does not work! So I did it using Windows, as follows: - Using the terminal of the server itself to download the bzoverlay file to /boot, with the wget instruction. - Backing up the flash drive (and thus already with the bzoverlay). - Extracting the backup.zip to the new flash labeled BOOTDISK - Modifying the make_bootable.bat; replacing UNRAID by BOOTDISK (only once for tag) - Running make_bootable.bat (as admin) - Modifying syslinux/syslinux.cfg; replacing all instances of /bzroot by /bzroot,/bzoverlay (except /bzroot-gui) - and then of course, changing the bootsequence in BIOS. Basically that's it. Detailed instructions I would have also.

OK, will do. I'm trying to boot from a second target USB, while reading the license key from the orginal flash source USB. As the original flash source USB will not be written to anymore, possibly becoming read-only will not be an issue anymore. The main and only reason is therefore to be able to easily exchange that target USB in case that would become corrupted; thus without having to claim a replacement license key, particularly within 12 months from an earlier replacement. I didn't think USB or HDD would matter. Correct?

So tried again with method 2 and g flag in the sed command. Still errors in the make_bootable_linux command, as follows: In my case: sdc is the source USB - called UNRAID sdd is the new target USB - at this moment called BOOTDISK Target USB still not bootable.

Hi Doron, Thanks for the tips. Indeed I had seen mkfs.fat instead, but as vfat allows longer filenames I wasn't sure if using mkfs.fat would give (hidden) errors (and thus unexplanable issues lateron). So didn't try that. I also checked the make_bootable_linux script after the sed patch command afterwards, and I still saw UNRAID mentioned (and thus not all instances of "UNRAID" replaced by "BOOTDISK"), but as mentioned being a linux noob, I could not check if that was OK or not. BTW, same with the syslinux patch command, where also not al "/bzroot" instances are replaced by "/bzroot,/bzoverlay". Should all the instances be replaced? If so I can do this manually, but I guess not. I checked the sed command, but could not figure it out fully; like the "-e" option. To me it seemed that this "-e" was there to consider only the first instance per code line. Will try your suggestions and post back.

Twice is indeed not funny, but it was on two different machines. The one of 1-2 years ago is still running fine - it's also on 24/7. The most recent one became read-only in a brand new machine with Ryzen 3900X and Gigabyte Aorus Master X570 mobo, with latest BIOS F11 - in itself running fine with two GameVMs, each with a Gigbyte NVidia 1660S vidoecard passthrough (occasional 1080p gaming is sufficient for me, also in view of in-house streaming - basically because it can; not because of real need). 64 GB of ram. 2x 1 TB nvme for redundant cache and 2x 4 TB of redundant storage. So yes quite a decent machine. And then a simple flash failing (like with an F1 car with failing spark plug 😉 ). This machine is not running 24/7; let's say 15 hours per week. - I'll see if I can update my signature. The flash was put in the white USB 3.0 slot (f); from the manual: USB 3.1 Gen 1 Port (White) The USB 3.1 Gen 1 port supports the USB 3.1 Gen 1 specification and is compatible to the USB 2.0 specification. Use this port for USB devices. Before using Q-Flash Plus (Note), make sure to insert the USB flash drive into this port first. The orignal flash was a small Patriot Tab 3.0 16 GB metal usb; but running quite hot?! Maybe too small in that it could not get rid of the heat? I'm sure nothing is unintentionally writing to the flash. At that time a wired mouse was in the back of the machine, for passthrough using the libvirt plug-in. PS. Maybe the white port has too much power on it (being used for Q-flash)?. But I could not find anything on that and thus not able to reduce the power on it (in BIOS).

1 - 2 years ago the USB 3.0 flash of my 2nd unRAID system became read-only. I had read about booting from a 2nd flash, while reading the license key from the original flash. But as it was a first, I just replaced the key. Now on my 3rd system, the USB 3.0 flash has also become read-only; after less than 5 months. No way to fix it, like with diskpart or EaseUS; it just seems a hardware failure (like the first one). So now I'm really interested in this bzoverlay solution. However, I've now spent a number of evenings trying to get it to work (to no avail obviously). For starters I'm a linux noob, but no problem figuring things out myself. I'm running the latest stable version 6.8.3. What I have done / tried: - Prepare a flash drive with a single primary FAT32 partition - not bootable yet; just the partition - each time I tried another method. Method 1. From the server itself, - command mkfs.vfat ... cannot be found; so a real showstopper. Method 2: From a PC, booting with either archiso or ubuntu server 20.04 from a USB stick - This seems to work, but the BOOTDISK does not become bootable; in fact during the make_bootable_linux it seems to make the original disk bootable; also some message about tmp/BOOTDISK not found or so (I believe; all of my head). - The syslinux.cfg on the BOOTDISK is also not patched with bzoverlay Method 3: - running mkfs.vfat ... on the alternative linux distro and add the unraid_disk directory for the mount point - then insert it in the server, but than the mount point cannot befound, even using mount -t vfat ..., and/or adding chmod 777 to the /mnt/unraid_disk directory while still on the alternative linux distro. Method 4: - Like 3, but than mounting the drive using unassigned devices - but does did not help either Also checked whether I could add mkfs.vfat to unRAID itself, but could not find the proper info to do so. ... not sure what else I tried. And yes, being a hobby programmer myself, very carefully typing the instructions or copying and inserting the correct device partition. All above methods first using the original read-only flash with original license key. Finally I replaced the flash and thus license key, again to now avail. But it means I now have to hope the new flash does not die within the year ... it is a USB 2.0, which should not be an issue towards speed as with the bzoverlay only the license key would be read from it. The real bootdisk will become a 3.0 USB once this works. One note: it seemed that the bzoverlay solution did work partly while using the orignal read-only flash. At least I have seen bzoverlay being loaded, but still unRAID was complaining that my flash drive was read-only - I also could not modify settings in any way (tried for example to change display settings). I'm afraid that the mkfs.vfat command has been removed and also that may be the make_bootable_linux file has been modified. As you can understand I'm quite interested in the solution, because if the new BOOTDISK dies it can easily be replaced without key-issues. Would you care to have a look. Thanks. Please let me know what you need from me to solve this. Like the proper messages ...

Well today already a 2nd USB drive failed, that is became read-only, both within 2 years in two different systems, and this one a proper Patriot TAB 16GB in a brand new system, only in use for 5 months! Already tried diskpart and EaseUS tool, to no avail. The first time I read about a script in the go file so that you can boot from a 2nd USB, with the original USB only there to read the OS-key from. At that time I didn't think much use, but now I really would like to set this up - if UNRAID cannot fix this?!

I have an X570 Aorus Master with a 3900X and similarly the commander pro plugged in to a USB 2 header on my MOBO and shows up as a device eligible to attach to a VM. But doing so (ticking the boxes, I have two corsair devices?! maybe also the power supply iLink, which is also connected to the commander pro) and rebooting the Windows VM, iCue does not detect any device and thus unable to control the leds and fan speeds. I have also tried attaching just either one of them, to no avail, obviously. Have you done anything special, like passing through the relevant USB controller? At least I cannot do that, because then I loose network.

Copying over the 1GB network from the array (normal 2.5" drives) of server 1 to a windows PC with SSD with 1 1GB switch inbetween reaches the 100+ MB/s - OK. Copying from the SSD cache from server 1 to the attached (unassigned device) USB3 disk only reaches 25 MB/s - NOK! Copying from server 2 to the same USB3 disk does reach 100+ MB/s, so the USB3 disk is not the bottleneck. So why is copying from the SSD cache only 25% of the array speed, where reading from the cache is much faster than from the array?

While almost on the verge of giving up I'd like to share succes with the above hardware. Biggest change was using i1440fx-4.1 instead of Q35-4.1! With the help of you fellow unraiders I am using the following syslinux configuration while booting unraid: append vfio-pci.ids=10de:21c4,10de:1aeb,10de:1aec,10de:1aed isolcpus=1-11,13-23 initrd=/bzroot video=efifb:off vfio-pci.ids=10de:21c4,10de:1aeb,10de:1aec,10de:1aed to not have unraid use them (videocard, sound plus a few other things, in fact the entire IOMMU group) isolcpus=1-11,13-23 to allow unraid only using cpus 0 and 12 (which it prefers and thus the rest really for VMs and Dockers) video=efifb:off another parameter to avoid video (card) conflicts. Obviously isolcpus=1-11,13-23 is optional. Spend a lot of time using the Q35-4.1 machine. And actually, once I was able to also install the NVidia drivers, replacing the Microsoft Basic Display drivers, but thereafter could never get the VM to boot properly. And then going back to VNC even messed up the MOBO BIOS. Then tried the i1440fx-4.1 machine, basically as a quick test. ET VOILA, Windows on Screen (instead of black screen or nothing at all). Passing through the videocard (also) using Graphics ROM BIOS for my specific card downloaded from TechpowerUp. Hope this helps. Good luck.

To keep things organized, I had put ISOs in subfolders, like Windows10, VirtIO, Ubuntu1804, etc. But then I can't choose them; only from the root folder; in my case AllISOs. Hope this is/will be possible (in the future)

Perfect. Thanks.

After trying a Windows 10 VM with a Gigabyte GTX 1660 Super passthrough on X570 Aorus Master with 3900X (and several changes/attemps - still not working), all of a sudden my BIOS got corrupted, disabling HVM and IOMMU. Which in turn disabled the VMs tab in unraid (in itself logical), but even worse disabled the "Apply" button in VM Manager - just no response; not even a page refresh! And yes, after restoring BIOS and thus re-enabling HVM and IOMMU, checking the folders in advance view and enabling VMs. So cannot even continue with VMs, because cannot get VM Manager running. A separate bug report has been submitted. Maybe replace one of the flash files with a backup file or start fresh? Any suggestions ...

I have the same issue; also with a GTX 1660 Super; hanging on black screen. Worse yet, after some attemps with some changes all of a sudden my BIOS got corrupted, disabling HVM and IOMMU. Which in turn disabled the VMs tab in unraid (in itself logical) and even more worse disabled the "Apply" button in VM Manager - just no response; not even a page refresh! So cannot even continue with VMs, because cannot get VM Manager running. A separate bug report has been submitted. Basically did all the same steps, except extracting my own ROM (just using the one from Techpowerup). Most interested in a safe solution.

OK searched, and although not recommended it worked by changing host to bridge?!

Hi, I have tried this docker on both my Unraid servers (as per SpaceInvader's video; so I think I set up everything correctly). But I cannot get the server to start; I get the following error(s); same on both. What I did notice that the server should already be running after installing the docker (and before making some of the changes, like replacing the admin, etc.), but that was obviously not the case with mine. What am I doing wrong?

Follow up on my Elite with AMD cpu and unraid basic: After changing to "Settings:VM Manager:Advanced View" I noticed the "View libvirt log" option. This showed the following errors: 2017-05-04 20:51:57.324+0000: 29397: error : x86FeatureInData:780 : internal error: unknown CPU feature __kvm_hv_spinlocks 2017-05-04 20:51:57.324+0000: 29397: error : x86FeatureInData:780 : internal error: unknown CPU feature __kvm_hv_vendor_id Googling it seemed to be affected by the VM's CPU mode (in advanced view when creating the VM). Although "host passthrough ..." with the same AMD cpu worked before, I changed it to "Emulated QEMU64" (just trying ...), and bam! the VM booted instantly. What is strange however, is that on my Stacker with Intel and unraid pro "host passthrough ..." is working fine. As the unraid basic and pro versions are exactly the same (except for the maximum number of drives), apparently it matters which CPU one uses since version 6.2.4, because since then my VM had not booted anymore with "host passthrough ...". Hope this info helps to pinpoint the exact root cause. At least glad my VM is running again, albeit (a little) slower then with "host passthrough ...".

PS. it got broken after moving from 6.2.3 to 6.2.4. Hope this helps (also). From the diagnostics files you may have noticed that the 6.3.3 pro is on: Model: CM 690 M/B: ASUSTeK COMPUTER INC. - P8B75-M LX PLUS CPU: Intel® Core™ i3-3225 CPU @ 3.30GHz HVM: Enabled IOMMU: Disabled Cache: 128 kB, 512 kB, 3072 kB Memory: 8 GB (max. installable capacity 16 GB) Network: eth0: 1000 Mb/s, full duplex, mtu 1500 Kernel: Linux 4.9.19-unRAID x86_64 OpenSSL: 1.0.2k Whereas the 6.3.3 basic is on: Model: Elite 110 M/B: ASRock - AM1H-ITX CPU: AMD Athlon™ 5350 APU with Radeon™ R3 @ 2050 HVM: Enabled IOMMU: Disabled Cache: 256 kB, 2048 kB Memory: 8 GB (max. installable capacity 8 GB) Network: eth0: 1000 Mb/s, full duplex, mtu 1500 Kernel: Linux 4.9.19-unRAID x86_64 OpenSSL: 1.0.2k

There's no difference between autostart and manual start. As it has a special boot sequence, it boots the boot.iso first, but does not complete it, meaning after the initial options screen where one can select to 'proceed' (default option), debug or install/upgrade, nothing happens (black VNC screen), whereas on the unraid pro system, it boots properly. Not sure what is happening exactly, because after the initial boot, control is handed to the vdisk, but unsure at which moment. Still, the pro system handles this fine, whereas the basic system does not, even though they are both the same latest version and with the same plugins. Only difference is that the basic system has a few additional dockers (but from principle these should not interfere) and an additional VM (which I believe should also not interfere). Which is why I am lost. I have attached the full diagnostics of both systems (for comparison). elite-diagnostics-20170502-1905 - unraid basic.zip

Thanks for your reply (although the email notification is showing more than above? "Tools - Diagnostics. The XML's being different are possibly because you have differing hardware between your pro and basic system. Beyond drive limitations, there is no differences between Pro / Basic / Trial on any version of unRaid."). I know, and that's why its so strange that creating and running the VM on my pro system works like a breeze and on my basic not. For instance in pro version there are all kinds of alias's in the xml, whereas in the basic there are none; also in basic xml vnc port and websocket are -1, whreas in stacker they are 5900 and 5700). Changing in basic does not stick. Please find attached the relevant? diagnostics files of my stacker with unRAID pro and my elite with unRAID basic Only the SyNAS VM on my basic system is not booting; that is not completing