Run unRAID from a hard drive - the easy way.


Recommended Posts

3 hours ago, gerard6110 said:

@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)

I was afraid of that. Seems like bzoverlay never gets opened, hence never used. Subsequently, BOOTDISK is mounted at /mnt/disks/BOOTDISK - this is actually done by UD and not by the original plan (it was supposed to be mounted at /boot, and the one with the license at /license). The original flash drive is mounted as /boot, read/write (so the desired result is not obtained at all).

3 hours ago, gerard6110 said:

After reboot, with new doron bzoverlay: Sorry to tell you, but no full boot ...

That's sad 🙂 This is probably the first time "bzoverlay" was actually opened and used.

What happened? What do you see during boot?

Link to comment

OK, noted, although I'm somewhat confused.

During boot bzimage, bzroot and bzoverlay are loaded OK. To differentiate between the original UNRAID (UR) flash and the BOOTDISK (BD) I changed the display settings before preparing the BD. UR I changed to black, whereas afterwards I changed BD to white (my usual theme). With thohell's bzoverlay it does boot with the BD because unraid dashboard opens in white. Also when changing the BD syslinux.cfg, which I had to do to see the log running during boot it uses the BD (in view of passing through my videocards, the default is video off). But indeed the mount points are not as we would like.

 

So now, running with your new bzoverlay,

From the running log during boot (only listing the still visible lines with errors):

- depmod warning could not open modules builtin

- mount /dev/shm can't find in /etc/fstab

- modprobe fatal: module bonding not found in directory /lib/modules/4.19.107-Unraid

- cannot find device "bond0"

- /etc/rc.d/rc.inet1 line 241: /proc/sys/net/ipv6/conf/eth0/disable-ipv6: no such file or directory

- modprobe warning module it87 not found in dir /lib/modules/4.19.107-Unraid

- modprobe warning module k10temp not found in dir /lib/modules/4.19.107-Unraid

 

IPv4 address: 169.254.28.39  => which is completely wrong.

Edited by gerard6110
Link to comment

I think what happened is that your settings were saved to the UR drive, even when you booted from the BD drive.

 

What happened during boot is quite clear... The fstab file from the original scheme could never have worked with recent Unraid versions; it misses some key mounts.

 

I haven't set up a test machine yet, so if you're willing to keep playing, you can try the attached for size (again, just place it on the BOOTDISK instead of the previous one(s)).

 

If the boot process completes successfully, please post results of "mount".

 

Note this is a stopgap, not an elegant solution; if it actually moves us forward, I'll try to whip up something more elegant.

bzoverlay

Edited by doron
Link to comment

You're right.

Unintentionally I booted without the BD and the interface was white.

With your new bzoverlay the boot process completed succesfully, that is:

- the first time the BD was mounted, but showing O space red, completely full also the disklight kept on flashing;

- I then turned on automount and rebooted

- At least the BD showed normal colors, however

- I had to turn off parity check as it was running, apparently due to an unclean shutdown

- I tried another reboot and agin parity check was running

 

Here is the new mount output:

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 /license type vfat (ro,shortname=mixed)
/dev/sda1 on /boot type vfat (rw,noatime,nodiratime,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/nvme1n1p1 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)

 

Also no initramfs unpacking failed message.

Also plugin update worked.

So, almost there? apart from the unclean shutdown.

Oh and 16GB flash (UR) now showing as 8 GB. Suffiicient for unraid of course, but still ...

 

Edited by gerard6110
Link to comment
15 hours ago, gerard6110 said:

So, almost there? apart from the unclean shutdown.

Sorry to be the bearer of bad news, but -- probably not; and in fact, the entire scheme, elegant as it may seem at first glance (which is what drew me in when I saw this thread, before stopping to think about it properly) cannot actually work. The only reason it kind-of-works for you right now is that your BOOTDISK is a USB flash drive, and not a hard drive. Had it been an HDD it would not have completed a full boot process (same as you saw earlier, one "bzoverlay" ago).

 

Longer explanation: Unraid's OS, by design, places the various HDD controller (and many other) drivers as loadable kernel modules (not compiled in). Those modules are packaged separately (bzmodules) and are not part of the initramfs. Result is that during the early stages of the boot process, HDD's are not accessible - until bzmodules is mounted (and udev gets kicked to rediscover devices).

Effectively, this means that if Unraid is booted from an HDD, there'll be a bootstrap deadlock, since bzmodules won't be accessible, hence not mountable, hence HDD can never be seen or mounted. Game over, insert coin.

 

I believe the scheme proposed in this thread has never actually worked. The bzoverlay file that allegedly performs the cool trick has been never successfully unpacked by the kernel (cuz it wasn't properly packed). Therefore, boot worked and things were looking nice - but the truth of the matter was that no change actually took place, the original licensed USB flash was mounted r/w as /boot, and the boot drive was just lying there doing very little. Only after I gave you a properly packed bzoverlay, have we started to see it "functioning" - essentially making things break...

 

Solving this properly would require repackaging of the Unraid OS, which, while perfectly doable, would change the scheme from elegant to terribly messy.

Edited by doron
Link to comment

OK, doron, no worries.

Thank you very much for spending the time and trying to get this to work.

Actually it would be nice if Limetech would incorporate this, so that the re-issuing of license keys is solved (particularly in case within 12 months from the 1st replacement; like in my case, I must hope my current UNRAID usb does not die for one year). I hope one day Limetech makes it such that the license key can be put on a second (loaded as read only, and thus much less likely to go bad) LICENSE usb, with the system itself on the main UNRAID usb and where unraid first tries to read it from the license usb and if not found, read from its own usb (as per users option).

For Limetech it would not matter because one still needs a license key linked to a usb ID (no problem with that).

And if the system usb then gets bad it can be easily replaced using a backup.zip and of we go.

Once again, thanks alot for trying.

Edited by gerard6110
Link to comment

You're welcome, @gerard6110

Incidentally, a different way to solve the issue as you're framing it is to use an USB Card Reader instead of a USB stick. Some of the card readers have IDs that can be used by Limetech's licensing scheme. If the flash component (an SD card of sorts - usually a microSD) wears out, you just pull it out, install a new one and restore content from backup. ID remains the same so license remains intact.

 

You can find out more about this here and here.

Link to comment
23 minutes ago, gerard6110 said:

About the card readers; yes I know, I tried that then with below Kingston MobileLite G4.

But blocked as no unique GUID. Then I didn't try anymore.

Yeah, I'm using the G2. Old, can sometimes be had from ebay, but does have a solid GUID.

Link to comment
  • 1 month later...
11 hours ago, piyper said:

I would like to run unraid in a VM but my server doesn't support iommu :(

 

I read through all this and from what I gather is we still can't do this, is that correct?

 

So the only way to run Unraid in a vm is to use iommu?

You do not need IOMMU to run Unraid in a VM

 

The technique described here works fine without IOMMU being needed.   It is what I use to run a VM for plugin development/testing.

 

Link to comment

To piyper: I did not try that and was not the purpose of the thread. My purpose was only to have the license key on a separate USB (or at least at User's option) that in case that USB would become read-only, as happened to me two times now (albeit on two different systems), I would not have to go to Limetech to ask for a replacement license key, particularly as the 2nd time my USB become read-only it was already within 4 months (still don't know why this has happened and no tool available to fix it, because USB hardware issue). For Limetech it would not matter as the key is and shall remain linked to one and the same USB-ID. So basically I would like to see:

USB1, with:

- UNRAID OS

- As per User's option: License Key or optionally on USB2

Boot sequence:

- Boot from USB1

- (First try to) read License key on USB2 and authenticate (therefore, even if USB2 had become Read-Only)

- If not on USB2 proceed with USB 1 to check License key and authenticate

- Continue boot

Edited by gerard6110
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.