pocopico

Members
  • Content Count

    21
  • Joined

  • Last visited

  • Days Won

    1

pocopico last won the day on July 1

pocopico had the most liked content!

Community Reputation

4 Neutral

1 Follower

About pocopico

  • Rank
    Junior Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. The same process as above works for 4.5.0 version of QuTS if anyone is interested in checking the ZFS version. MODEL_TYPE="QZ601_Q0040_12_11 " PATCHED_FIRMWARE="TS-X83XU_20200520-h4.5.0.1308" DOWNLOAD_URL="https://download.qnap.com/Storage/QuTShero/TS-X83XU/" Models found in the firmware : Q00V1_Q00W0_11_11 = TS-2483XU QZ601_Q0040_12_11 = TS-1683XU QZ601_Q00M0_11_10 = TS-1283XU QZ601_Q00M1_11_10 = TS-883XU QZ602_Q00M0_12_10 = TS-1283XU TBJBOD_QW580_QW750_20_20 = TX-800P TBJBOD_QW580_QX180_20_20 = TX-500P Have fun
  2. Hi all, in an effort to simplify the process, I've done some work towards that, but i think there is a lot of room for improovement. So far what i've done : - Translated about 100% all disk, kept original and translated original on a separate folder - Cleaned up the firmware process and kept as much many as i could from initial scripts - Added an automated process to figure out as many devices as i could during model.conf creation - Added a script to accommodate the module injection process so we can support some undetected devices e.g. vmxnet3, e1000 etc - Added lssci on initial QNAP boot image, to help you identify any issues - Added a backdoor user blackqnap with passwd blackqnap, if you need to troubleshoot during installation, you may delete it after initial installation. - Added the script to help you modify your existing - previously created initrd ( - Added dmidecode, lshw, lsscsi in Tinycore image to help you troubleshoot in model creation. 1. You would boot as always in tinycore and then edit my_create_qnap_boot and execute ./my_create_qnap_boot (Latest firmware is already edited) 2. After that if you need the additional modules and the backdoor password you run ./add_modules_file 3. Review initrd/etc/model.conf , perform any necessary changes 4. Execute ./pack_your_initrd to include the latest changes 5. Reboot Any case you need to modify any information in model.conf at anytime : 1. Boot into tinycore 2. Execute ./modify_your_initrd 3. Edit initrd/etc/model.conf or any other file 4. Execute ./pack_your_initrd to include the latest changes 5. Reboot You may give it a try and let me know how this works for you. https://mega.nz/folder/LJ4wyaDY#MxOC2UgNqC-Y6gQXu-IUFA
  3. Actually I think it’s important for the combination of DEV_BUS and DEV_PORT to not report conflicting info about the SLOT. I might have some conflict in the model.conf as I was really dizzy trying for two days to figure this out. If you dont mind, could you please share the python script ?
  4. I’ve also noticed that if you don’t have the correct [System Network X] defined then it will fail to get an IP. You should match the PCI bus id for all your network devices. See my answer above for modifying your initrd (ramdisk). The PCI bridge will be used only for additional devices you connect I guess, which actually makes no sense for a VM.
  5. if your are also using VMware workstation it might address the devices differently you can modify the model.conf manually without regeneration from the firmware. You simply mount /dec/sdb2 while in tinycore and execute # mkdir /home/tc/initrd; cd initrd; gunzip -c /mnt/sdb2/boot/initrd.boot | cpio -id Then once you are done with the modifications you run the re_repacking command to repack and copy the files over to boot disk. If you start over the process again you will loose the additional modules but if you don’t need them then it’s not a bug problem Well I guess PCI bridge only matters in physical world where someone might connect a compatible PCI card e.g a 10G or an FC HBA etc. Now as for the network I’m running with the impression that you should also modify to match your configuration otherwise the default admin password which is taken from the first System Nework card will not work. Did you manage to install using the provided VM configuration ?
  6. Also seems critical to have the actual PCI bus set for at least one [System Disk X]. This is maybe due to bad device bus interpretation by QNAP's hal_app. Anyway until i find a more solid solution, if you set this to something like below its should work : [System Disk 1] DEV_BUS=B02:D04:F0 # ACTUAL PCI BUS reported by /sbin/lspci DEV_PORT = 0 .. .. .. [System Disk 11] DEV_BUS=B00:D17:F0 # The misinterpreted PCI BUS reported by lsscsi -v e.g. /sys/devices/pci0000:00/0000:00:11.0/000:02:05.0/ata1/host0/target0:0:0/0:0:0:0 DEV_PORT = 0 I have this installed also on VMware ESXi 6.7 and have verified that this workaround works fine.
  7. Well, finally i've figured this out.. The main issue is that on VMware the PCI device is interpreted into wrong PCI number to be recognized from QNAP hal_app. Additional to what you would normally do with tinycore follows : Please remember to use IDE as the boot disk and set this up according to the PCI device ID e.g B00:D07:F1 so it doesn't get overwritten by the initial installation process. I have inlcuded /sbin/lsscsi in the boot image. Once you've booted into QNAP, you should check # lsssci -vvv This returns something like /sys/devices/pci0000:00/0000:00:11.0/000:02:05.0/ata1/host0/target0:0:0/0:0:0:0 The critical part is after pcixxxx:xx e.g 0000:00:11.0 this is the PCI bus that you should use once you convert to DECIMAL so in this case B00:D17:F0. The DEV_PORT = X should be set to the SATA port you have set in VMware. [System Disk 11] DEV_BUS=B00:D17:F0 DEV_PORT = 0 To verify, while logged in to QNAP as admin, running # hal_app --pd_get_devid pd_sys_name=/dev/sda should return the specified slot ID. If empty retry changing the PCI bus. I've included several modules into /lib/modules and modified modules.dep for VMXNET3 and other ethernet devices to work. I'll post the process to create your own modules also sometime in the future. You may download the VMware workstation from the link below : https://wetransfer.com/downloads/e46dd6f5f8bf8b36ea41eb556e82a95a20200626200122/3a6fa4c90e3ba0c578c943231395575b20200626200706/612941
  8. Hi (Sorry for the English but i really dont know any German although i was born there ), i've been strungling with the black disk creation over the last few days and i've managed to get to some point where i pretty much understand how this works. So far my progress on both VMware ESXi and VMware workstation reached up to the point where i still cannot see any disks so i'll keep working on that. On a physical machine though (a laptop that i had and was collecting dust) i've managed to complete the initial install and have this running for a day. I've rebooted several times and have installed few apps. The interface looks very professional compering to Synology where you get a more home user friendly experience. What seems very critical, is to have a compatible CPU (mine is an i5 4xxx) because on older cpus the OS libraries faill to operate correctly and not all services are coming up. Someone will have to use a compatible firmware that matches their CPU but to get an older CPU to work you should go back to 3.x kernel and that is before 4.4.x QNAP firmware. I'll try to elaborate some with a guide in the near future but so far other than the CPU that is critical the next are also importand. ################ LATEST FIRMWARE that i've used. ################ MODEL_TYPE="QY380_QY390_10_11" PATCHED_FIRMWARE="TS-X85_20200529-4.4.2.1320" DOWNLOAD_URL="https://download.qnap.com/Storage/TS-X85/" Model.conf sections that figured out what they mean (please note all BXX:DXX:FX should be DECIMAL and not HEX as they are represented by lspci command) Please make sure that you have no conflicting information (PCI bus or DISK ports) in the configuration as it will fail to match the configuration and will not create the system devices on the fly during boot time. - [System Network X] , the PCI network device that will be used as a system network interface. In my case where i have only one interface i used only [System Network 1] and used dummy addresses for the rest. - [ System Disk XX] each entry should match the PCI AND the SLOT number e.g. DEV_BUS=B00:D31:F2 DEV_PORT = 0 and should be other than the boot disk. The script does not take care of that you should figure this out by yourself. Also importand is to match the disk type accoringly e.g M.2 NVME/SSD/Drive. In mycase i have a single disk (green circle). Not all disks services will be used for all type of disks i guess. - [System PCIE SLOT X ] can be a valid PCI bridge - [Usb Port 1] should be a valid USB port if you are planning to use them. - [Boot Disk 1] should be the boot disk in my case it was a USB port DEV_BUS = B00:D20:F0 NEVER perform a firmware update as the hack relies on initrd.boot file that contains files that will be overwritten during the update. Now that i have a working black box, i'll digg into VMware issues and hopefully resolve as many as i can. -
  9. Same here, it’s seems that there is a last step that should do something to identify the disks. UDEV maybe ? I have compiled vmxnet3.ko and e1000.ko modules and I get an ip from DHCP. GUI is accessible but no disks are found
  10. Hi, can someone please share a working vmware image ? I have created missing kernel modules and figured what to do in order to have them loaded succesfully (i can provide additional kernal modules if anyone is interested), but i still fail to get the disks identified. I anyone has a VM to test i would be thankfull.
  11. - Outcome of the update: SUCCESSFUL - DSM version prior update: DSM 6.1.4 15217 Update 1 - Loader version and model: Jun's Loader v1.02b - DS3615xs - Installation type: Baremetal (HPE Proliant MicroServer Gen7 N54L) - Additional comments: Requires reboot
  12. Thanks for the tutorial !!! It was exactly what i was looking for.
  13. Well, it was mainly because of the BTRFS phantom crashes that i had to got to 6.1 ... now my system is unfortunately not bootable anymore so i will have to either wait for new loader of just create the modules and update loader to make it work.
  14. Hi, after some BTRFS volume crashes in 6.02, i have decided to go with the update to DSM 6.1. Unfortunately i did that before searching in depth for the issue, and i recently found that issues exist in 6.1 as well. Anyway, i have already tried to perform the update to 6.1 before updating the 6.02 loader and failed. I have then tried to boot with Jun 6.1 Alpha loader and i found out that the driver is probably missing for the onboard NIC NC107 (broadcom) 1GB card as the server never comes online. I have tried to recreate both ramdisk and extra.lzma with the additional modules taken from the 6.02 image but they fail to load due to kernel incompatibility (3.10.77 in 6.02 vs 3.10.102 in 6.1) and looks like i have to recompile them with the new sources. I will try to follow the viewtopic.php?f=2&t=31211 topic to recreate the missing modules and update the loader with them. Anyway before going through all this painful process, i thought it might worth asking here if someone else did that before and has already compiled the modules i need. Mainly missing the NIC drivers and firmware from the image. I will keep you posted for the progress.