guruleenyc Posted June 4, 2018 Share Posted June 4, 2018 @doron, thanks for the fast response! I tried the unraid 6.3.2 plugin method in ui to upgrade, but after prompted reboot it is still at ver. 6.3.2. Also, I tried downloading the 6.4.x ver and swapping out the two bz files in my vmdk, but it does not boot. Any tips? Quote Link to comment
doron Posted June 4, 2018 Share Posted June 4, 2018 Just now, guruleenyc said: @doron, thanks for the fast response! I tried the unraid 6.3.2 plugin method in ui to upgrade, but after prompted reboot it is still at ver. 6.3.2. Also, I tried downloading the 6.4.x ver and swapping out the two bz files in my vmdk, but it does not boot. Any tips? Try to run the 6.5.2 update via "tools -> Update OS"; then, DO NOT REBOOT but copy all bz* files from /boot into your real boot drive (you'd probably need to mount it first). So if your real boot drive (not the USB flash) is e.g. /dev/sdc, do something like -- mkdir /mnt/t mount /dev/sdc1 /mnt/t cp -p /boot/bz* /mnt/t/ Then, reboot. Let me know if this works. 1 Quote Link to comment
guruleenyc Posted June 4, 2018 Share Posted June 4, 2018 1 minute ago, doron said: Try to run the 6.5.2 update via "tools -> Update OS"; then, DO NOT REBOOT but copy all bz* files from /boot into your real boot drive (you'd probably need to mount it first). So if your real boot drive (not the USB flash) is e.g. /dev/sdc, do something like -- mkdir /mnt/t mount /dev/sdc1 /mnt/t cp -p /boot/bz* /mnt/t/ Then, reboot. Let me know if this works. @doron, So just to confirm the steps: 1. Use unraid plugins upgrade OS function in my 6.2.3 version 2. Do reboot, but replace bz* files in my vmdk, OR on the usb stick which boots the vm? Thanks in advance for the assistance and clarification! Quote Link to comment
guruleenyc Posted June 4, 2018 Share Posted June 4, 2018 1 hour ago, doron said: Try to run the 6.5.2 update via "tools -> Update OS"; then, DO NOT REBOOT but copy all bz* files from /boot into your real boot drive (you'd probably need to mount it first). So if your real boot drive (not the USB flash) is e.g. /dev/sdc, do something like -- mkdir /mnt/t mount /dev/sdc1 /mnt/t cp -p /boot/bz* /mnt/t/ Then, reboot. Let me know if this works. I performed the upgrade via Plugins > OS Upgrade. Now I see the new bz* files in /boot with timestamp of 5/15/18 and changes.txt show its 6.5.2. However, I am not sure where to copy these files if not to the USB stick. I think I only have one /boot on vm in vmdk... Quote Link to comment
uldise Posted June 4, 2018 Share Posted June 4, 2018 /boot is a flash drive. which method are you using to boot unRAID ? you can use ploKExec to boot from their ISO image, and then you don't need any VM boot image.. 1 Quote Link to comment
guruleenyc Posted June 4, 2018 Share Posted June 4, 2018 @uldise, Thanks for responding. I do not recall which method I'm using to boot the usb stick connected to the unraid vmdk. However, I did only attempt replacing the bzimage and bzroot files from/boot and copied it to my usb stick. This was not successful and booted back to 6.3.2. Should I grab all updated files under /boot that start with bz* ? Quote Link to comment
uldise Posted June 4, 2018 Share Posted June 4, 2018 yes, and you should copy them to vmdk.. BUT, as i wrote, it's much easier to boot unRAID with plopKExec. you will not need to copy over files every time after unRAID version change.. just download this(https://download.plop.at/plopkexec/plopkexec.iso) iso, copy it to your ESXi server next to you unRAID VM files, assign it as CD-Rom, and boot from it - when it boots, it selects your unRAID flash drive and continue to boot unRAID.. 1 Quote Link to comment
guruleenyc Posted June 4, 2018 Share Posted June 4, 2018 1 minute ago, uldise said: yes, and you should copy them to vmdk.. BUT, as i wrote, it's much easier to boot unRAID with plopKExec. you will not need to copy over files every time after unRAID version change.. just download this(https://download.plop.at/plopkexec/plopkexec.iso) iso, copy it to your ESXi server next to you unRAID VM files, assign it as CD-Rom, and boot from it - when it boots, it selects your unRAID flash drive and continue to boot unRAID.. Thank you for the further clarification and recommendation. I will work on this later. Quote Link to comment
doron Posted June 4, 2018 Share Posted June 4, 2018 2 hours ago, guruleenyc said: I performed the upgrade via Plugins > OS Upgrade. Now I see the new bz* files in /boot with timestamp of 5/15/18 and changes.txt show its 6.5.2. However, I am not sure where to copy these files if not to the USB stick. I think I only have one /boot on vm in vmdk... Sorry, had to go into a meeting. Let's take half a step back. Under ESXi, unRAID VM does not actually boot off your flash drive (limitation of the hypervisor). Instead, unRAID boots from a virtual HDD (your vmdk) which somewhat clones the bootable content of the flash drive. Early in the boot process, unRAID detects your real flash drive, and mounts it as /boot. Now when the "Update OS" process happens, it updates the real flash drive. What we need to do is to copy the files containing the kernel, drivers etc. from the flash drive (which is under /boot) to the small HDD you are using to boot (which is typically not mounted). So back to my reply above. If we assume that your vmdk is /dev/sdb, you would do this, after Update OS but before rebooting: mkdir /mnt/t mount /dev/sdb1 /mnt/t cp -p /boot/bz* /mnt/t/ Good luck! 1 Quote Link to comment
guruleenyc Posted June 4, 2018 Share Posted June 4, 2018 5 minutes ago, doron said: Sorry, had to go into a meeting. Let's take half a step back. Under ESXi, unRAID VM does not actually boot off your flash drive (limitation of the hypervisor). Instead, unRAID boots from a virtual HDD (your vmdk) which somewhat clones the bootable content of the flash drive. Early in the boot process, unRAID detects your real flash drive, and mounts it as /boot. Now when the "Update OS" process happens, it updates the real flash drive. What we need to do is to copy the files containing the kernel, drivers etc. from the flash drive (which is under /boot) to the small HDD you are using to boot (which is typically not mounted). So back to my reply above. If we assume that your vmdk is /dev/sdb, you would do this, after Update OS but before rebooting: mkdir /mnt/t mount /dev/sdb1 /mnt/t cp -p /boot/bz* /mnt/t/ Good luck! Makes sense now and I recall this from when I originally set this up a few years ago. If I do not see /dev/sdb when I SCP in. How do I identify and mount my vmdk w/o shutting it down and downloading the vmdk files to mount offline with WinIMage? Quote Link to comment
doron Posted June 4, 2018 Share Posted June 4, 2018 2 minutes ago, guruleenyc said: Makes sense now and I recall this from when I originally set this up a few years ago. If I do not see /dev/sdb when I SCP in. How do I identify and mount my vmdk w/o shutting it down and downloading the vmdk files to mount offline with WinIMage? Yes, you will have to figure out where the drive is. It will be one of the /dev/sd* (you'd have quite a few). When you say you don't see /dev/sdb, what do you mean? If you still can't find it, can you paste the output of: ls -la /dev/sd* ls -la /dev/disk/by-uuid BTW, @uldise's suggestion is also excellent. It calls for a change in the way you boot your VM though. Quote Link to comment
guruleenyc Posted June 4, 2018 Share Posted June 4, 2018 @doron root@Tower:/dev# ls sd* sda sda1 sdb sdb1 sdc sdc1 sdd sdd1 sde sde1 sdf sdf1 sdg sdg1 root@Tower:/dev# ls -la /dev/disk/by-uuid total 0 drwxr-xr-x 2 root root 200 Jun 4 12:09 ./ drwxr-xr-x 7 root root 140 Jun 4 12:07 ../ lrwxrwxrwx 1 root root 10 Jun 4 12:07 25d5cb0f-784e-4871-85c3-e0d31579ab38 -> ../../sdg1 lrwxrwxrwx 1 root root 10 Jun 4 12:07 491e0f08-9110-4f89-9010-c9e9c93c725d -> ../../sdf1 lrwxrwxrwx 1 root root 10 Jun 4 12:07 4C75-46AF -> ../../sda1 lrwxrwxrwx 1 root root 10 Jun 4 12:07 a8f923f6-497d-40be-857e-b8fa7919304d -> ../../sdd1 lrwxrwxrwx 1 root root 10 Jun 4 12:07 c432e7f1-a023-4746-90ad-91c0a55ce928 -> ../../sde1 lrwxrwxrwx 1 root root 11 Jun 4 12:09 c8be74f1-106e-400c-9e5f-8ce2129cf83d -> ../../loop1 lrwxrwxrwx 1 root root 10 Jun 4 12:07 ed70cf8c-dbdb-4166-af58-1d69f6171228 -> ../../sdc1 lrwxrwxrwx 1 root root 11 Jun 4 12:08 f424ef4c-e986-4065-b939-7c510417b911 -> ../../loop0 root@Tower:/dev# Quote Link to comment
doron Posted June 4, 2018 Share Posted June 4, 2018 8 minutes ago, guruleenyc said: @doron root@Tower:/dev# ls sd* sda sda1 sdb sdb1 sdc sdc1 sdd sdd1 sde sde1 sdf sdf1 sdg sdg1 @guruleenyc So here's /dev/sdb right there. Can you now paste: mkdir /mnt/t mount /dev/sdb1 /mnt/t ls -la /mnt/t Quote Link to comment
guruleenyc Posted June 4, 2018 Share Posted June 4, 2018 1 minute ago, doron said: @guruleenyc So here's /dev/sdb right there. Can you now paste: mkdir /mnt/t mount /dev/sdb1 /mnt/t ls -la /mnt/t @doron I get this as a result: root@Tower:/dev# mount /dev/sdb1 /mnt/t mount: wrong fs type, bad option, bad superblock on /dev/sdb1, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so. Quote Link to comment
doron Posted June 4, 2018 Share Posted June 4, 2018 (edited) 24 minutes ago, guruleenyc said: @doron I get this as a result: root@Tower:/dev# mount /dev/sdb1 /mnt/t mount: wrong fs type, bad option, bad superblock on /dev/sdb1, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so. Oh. So the vmdk is not at /dev/sdb after all. Can you paste the output of "df" (when the array is online and mounted)? We can then find it by elimination... (might be /dev/sdg?) Anyway, we can either continue looking for the right /dev/sdX for the vmdk, or you can shortcut this by doing it with the server offline. It'd be good if you do find it, since you will need to copy these files each time you update the unRAID OS. Edited June 4, 2018 by doron Quote Link to comment
guruleenyc Posted June 4, 2018 Share Posted June 4, 2018 33 minutes ago, doron said: Oh. So the vmdk is not at /dev/sdb after all. Can you paste the output of "df" (when the array is online and mounted)? We can then find it by elimination... (might be /dev/sdg?) Anyway, we can either continue looking for the right /dev/sdX for the vmdk, or you can shortcut this by doing it with the server offline. It'd be good if you do find it, since you will need to copy these files each time you update the unRAID OS. @doron root@Tower:/dev# df Filesystem 1K-blocks Used Available Use% Mounted on rootfs 2500428 398608 2101820 16% / tmpfs 2541924 232 2541692 1% /run devtmpfs 2500444 0 2500444 0% /dev cgroup_root 2541924 0 2541924 0% /sys/fs/cgroup tmpfs 131072 2264 128808 2% /var/log /dev/sda1 7807424 575712 7231712 8% /boot /dev/md1 3905110812 1966093256 1939017556 51% /mnt/disk1 /dev/md2 3905110812 1416179428 2488931384 37% /mnt/disk2 /dev/md3 3905110812 33008 3905077804 1% /mnt/disk3 /dev/sdc1 126875648 77132764 49344436 61% /mnt/t shfs 11715332436 3382305692 8333026744 29% /mnt/user0 shfs 11842208084 3459438456 8382371180 30% /mnt/user /dev/loop0 41943040 6122460 34282068 16% /var/lib/docker shm 65536 0 65536 0% /var/lib/docker/containers/24ea32895c680b5415411e6073fe303c08b3248d7673c86caa363d0aa58fe830/shm shm 65536 0 65536 0% /var/lib/docker/containers/ff3a18f5a78caf6fb4429f654b19314d0ad38be80305ee1dd677788096c20f59/shm shm 65536 0 65536 0% /var/lib/docker/containers/3b6af8925fbf2b210065153bfde3927cab157b69f2909b5e5867059580ae6658/shm shm 65536 0 65536 0% /var/lib/docker/containers/767650da23239e6fc026bc1058319270ae6e578450b5d40de3934c0113ffde7f/shm shm 65536 8 65528 1% /var/lib/docker/containers/f6dde6c677c1185fb6a837046f80bf7aba1cf8fec651274907f91423d43c6b16/shm shm 65536 0 65536 0% /var/lib/docker/containers/a4285f9799d74a16677434208e1c6833d6c3c630fd906a705e2b5cf2101ed056/shm /dev/loop1 1048576 16752 926288 2% /etc/libvirt root@Tower:/dev# Quote Link to comment
doron Posted June 4, 2018 Share Posted June 4, 2018 Ah. You have /dev/sdc1 mounted on /mnt/t - probably from previous attempts ? We can't double mount. /dev/sdc seems to be a ~128GB HDD (or flash). Your USB flash drive seems to be 8GB. We need to unmount /mnt/t to start clean. Please do: umount /mnt/t mount /dev/sdb1 /mnt/t ls /mnt/t Quote Link to comment
guruleenyc Posted June 4, 2018 Share Posted June 4, 2018 4 minutes ago, doron said: Ah. You have /dev/sdc1 mounted on /mnt/t - probably from previous attempts ? We can't double mount. /dev/sdc seems to be a ~128GB HDD (or flash). Your USB flash drive seems to be 8GB. We need to unmount /mnt/t to start clean. Please do: umount /mnt/t mount /dev/sdb1 /mnt/t ls /mnt/t @doron root@Tower:/dev# umount /mnt/t root@Tower:/dev# mount /dev/sdb1 /mnt/t mount: wrong fs type, bad option, bad superblock on /dev/sdb1, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so. root@Tower:/dev# ls /mnt/t root@Tower:/dev# Quote Link to comment
doron Posted June 4, 2018 Share Posted June 4, 2018 So we haven't nailed the vmdk device yet. Okay, one more shot. Please paste output of: fdisk -l Also, how large is your vmdk? (will help in eliminating) Quote Link to comment
guruleenyc Posted June 4, 2018 Share Posted June 4, 2018 4 minutes ago, doron said: So we haven't nailed the vmdk device yet. Okay, one more shot. Please paste output of: fdisk -l Also, how large is your vmdk? (will help in eliminating) @doron, vmdk is 1.11GB Disk /dev/loop0: 40 GiB, 42949672960 bytes, 83886080 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk /dev/loop1: 1 GiB, 1073741824 bytes, 2097152 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk /dev/sda: 7.5 GiB, 8004304896 bytes, 15633408 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x00000000 Device Boot Start End Sectors Size Id Type /dev/sda1 * 8192 15631244 15623053 7.5G b W95 FAT32 Disk /dev/sdc: 121 GiB, 129922523136 bytes, 253754928 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0xf6abb9d1 Device Boot Start End Sectors Size Id Type /dev/sdc1 2048 253753343 253751296 121G 83 Linux Disk /dev/sdd: 3.7 TiB, 4000787030016 bytes, 7814037168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: 1FD63159-FC88-4F08-A8F9-46A700449731 Device Start End Sectors Size Type /dev/sdd1 64 7814037134 7814037071 3.7T Linux filesystem Disk /dev/sde: 3.7 TiB, 4000787030016 bytes, 7814037168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: A4DDF22F-729E-4D95-B90E-964BB4DA78D0 Device Start End Sectors Size Type /dev/sde1 64 7814037134 7814037071 3.7T Linux filesystem Disk /dev/sdf: 3.7 TiB, 4000787030016 bytes, 7814037168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: 26AB77C2-FA2F-40FD-A87F-D674D5D23077 Device Start End Sectors Size Type /dev/sdf1 64 7814037134 7814037071 3.7T Linux filesystem Disk /dev/sdb: 3.7 TiB, 4000787030016 bytes, 7814037168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: BDBDE1D4-F973-4C0A-B929-2CD7126ABB56 Device Start End Sectors Size Type /dev/sdb1 64 7814037134 7814037071 3.7T Linux filesystem Disk /dev/sdg: 3.7 TiB, 4000787030016 bytes, 7814037168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: AD0993AD-6CE9-4BB3-938B-5F5E69BABDD7 Device Start End Sectors Size Type /dev/sdg1 64 7814037134 7814037071 3.7T Linux filesystem Disk /dev/md1: 3.7 TiB, 4000786976768 bytes, 7814037064 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk /dev/md2: 3.7 TiB, 4000786976768 bytes, 7814037064 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk /dev/md3: 3.7 TiB, 4000786976768 bytes, 7814037064 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes root@Tower:/dev# Quote Link to comment
guruleenyc Posted June 4, 2018 Share Posted June 4, 2018 root@Tower:/mnt/t# mount /dev/sda1 /mnt/t root@Tower:/mnt/t# cd .. root@Tower:/mnt# ls cache/ disk1/ disk2/ disk3/ disks/ hgfs/ t/ u/ user/ user0/ root@Tower:/mnt# cd t root@Tower:/mnt/t# ls EFI-/ bzroot* custom/ make_bootable.bat* previous/ bzfirmware* bzroot-gui* ldlinux.c32* make_bootable_linux* syslinux/ bzimage* bzroot.bak* ldlinux.sys* make_bootable_mac* bzimage.bak* changes.txt* license.txt* memtest* bzmodules* config/ logs/ packages/ root@Tower:/mnt/t# Quote Link to comment
doron Posted June 4, 2018 Share Posted June 4, 2018 1 minute ago, guruleenyc said: root@Tower:/mnt/t# mount /dev/sda1 /mnt/t root@Tower:/mnt/t# cd .. root@Tower:/mnt# ls cache/ disk1/ disk2/ disk3/ disks/ hgfs/ t/ u/ user/ user0/ root@Tower:/mnt# cd t root@Tower:/mnt/t# ls EFI-/ bzroot* custom/ make_bootable.bat* previous/ bzfirmware* bzroot-gui* ldlinux.c32* make_bootable_linux* syslinux/ bzimage* bzroot.bak* ldlinux.sys* make_bootable_mac* bzimage.bak* changes.txt* license.txt* memtest* bzmodules* config/ logs/ packages/ root@Tower:/mnt/t# Yes but that is your actual flash drive (I'd umount it now - double mounting ain't healthy - "umount /mnt/t"). This is weird. I'm kind of at the end of my wits on this one - not sure how your boot drive would not have a Linux device. It might have to do with the version discrepancy between the flash and the VHD, causing your booted kernel to not have all the needed drivers to access the boot device. That's a guess though. My suggestion now would be to power down the unRAID VM, copy the bz* files from the flash drive to the vmdk (using another machine - probably Windows, or a Hiren Boot CD if you have that, etc.) and then restart unRAID and see that you successfully upgraded. Once this is done, I'd be curious to see another run of "fdisk -l", to see if my theory above holds water. And assuming it does, you will from that point on be able to do this much more easily - using the mechanism I described above (which is what I do regularly). 1 Quote Link to comment
guruleenyc Posted June 4, 2018 Share Posted June 4, 2018 After above mount, anything I create in /mnt/t auto syncs to /boot. I guess I have the wrong volume still... Quote Link to comment
uldise Posted June 5, 2018 Share Posted June 5, 2018 just curious, if you reboot your unRAID, can you boot it still to old version? cos i don't see your vmdk too. but i think, just try plexKExec route 1 Quote Link to comment
guruleenyc Posted June 5, 2018 Share Posted June 5, 2018 just curious, if you reboot your unRAID, can you boot it still to old version? cos i don't see your vmdk too. but i think, just try plexKExec route It boots back to 6.3.2. But I have not fully replaced all the bz* files within the vmdk yet. Aside from taking unraid vm offline, downloading the vmdk and mounting it with winimage for bz* file injection, is there an easier way to mount over net to esxi? Sent from my SM-N910V using Tapatalk Quote Link to comment
Recommended Posts
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.