Jump to content
XPEnology Community

Search the Community

Showing results for tags '7.x'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Information
    • Readers News & Rumours
    • Information and Feedback
    • The Noob Lounge
  • XPEnology Project
    • F.A.Q - START HERE
    • Loader Releases & Extras
    • DSM Updates Reporting
    • Developer Discussion Room
    • Tutorials and Guides
    • DSM Installation
    • DSM Post-Installation
    • Packages & DSM Features
    • General Questions
    • Hardware Modding
    • Software Modding
    • Miscellaneous
  • International
    • РУССКИЙ
    • FRANÇAIS
    • GERMAN
    • SPANISH
    • ITALIAN
    • KOREAN

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


About Me

Found 6 results

  1. Introduction This tutorial is a supplement to the main TCRP installation tutorial located here: https://xpenology.com/forum/topic/62221-tutorial-installmigrate-to-dsm-7x-with-tinycore-redpill-tcrp-loader/ You should be familiar with all the concepts and procedures in that tutorial, and general knowledge of VMware ESXi installation and virtual machine management. The focus here is on differences between installing on baremetal (with DSM as the only OS on the NAS), and as a virtual machine using VMware ESXi as the hypervisor. However, much of the conceptual information applies to other hypervisors. Some reasons to install DSM using a hypervisor: virtualize unsupported network card virtualize NVMe or other storage and present to DSM as SATA run other VMs in parallel on the same hardware (as an alternative to Synology VMM) share storage or network cards with other non-XPEnology VMs testing and rollback of updates About VMware ESXi ESXi (currently branded as the "VMware vSphere Hypervisor") is a stand-alone hypervisor that is part of the VMware enterprise computing platform. ESXi's strength includes robust testing and support, good compatibility with modern hardware platforms, and very flexible control over the hypervisor configuration. The core hypervisor is free to use, all that is needed is to sign up to receive a lifetime free license key. Key limitations of the free license are 8 vCPU's (8 threads, same as DS918+) and no serial port virtualization. To use the serial console, a physical connection is needed from the motherboard to your personal computer, or if the motherboard has IPMI features, intercepting the physical serial data with the IPMI remote access tools works as well. There is also a trial ESXi license that offers 256 vCPUs and serial port virtualization. ESXi and DSM Platform/Architecture All currently supported DSM platforms can run as virtual machines. As of this writing, the Device Tree platforms (DS920+ and DS1621+) are not supported by the TCRP device tree patcher when ESXi virtual SATA controllers are used. The problem is understood but currently the only way to make these platforms work is to manually patch the DTS. Transcoding platforms are supported with a compatible CPU, but actual transcoding requires a passthrough configuration of the VGA display adapter, which is somewhat complicated to set up, and beyond the scope of a basic tutorial. As DSM is run as a workload inside ESXi, there is an overhead tax, so the minimum requirements are somewhat higher: x86-64 CPU with two cores or more Hardware virtualization features enabled in the BIOS (Intel VT-x or AMD RVI) 4GB of RAM or more Dedicated 138GB or larger boot and storage device for ESXi system files, run-time files and datastore containing VM configuration files and virtual disks Block storage/controllers on ESXi's compatibility list OR compatible with DSM for passthrough Storage for use with DSM (either as backing storage for virtual disks, or passthrough devices) Creating a DSM Virtual Machine, Part 1 When we create a virtual machine we are defining its hardware characteristics. This machine must be compatible with DSM. For the purposes of the tutorial, we'll create a simple DSM VM with a 21GB virtual SATA drive. First the hardware profile must be selected. The recommended options are illustrated below. Other 3.x Linux (64-bit) is best even when installing a DSM platform with 4.x kernel. The selection here doesn't actually have anything to do with the OS being installed - it's just defining the behavior of the emulated hardware. Here's the initial complement of hardware created with Other 3.x Linux (64-bit): The pre-configured Network Adapter is VMware 10Gbe virtual vmxnet3 and is directly supported by TCRP. However, some changes need to be made to the virtual machine: Change the CPU vCore count to 2 or more Change the memory amount to 2048 or more Change the virtual hard disk size to 21GB or larger (see minimum spec here) If desired, open the drop-down menu and change the virtual disk type to Thin if the VM is only for testing Delete the USB controller Delete the CD/DVD Drive Add a second SATA controller - this will initially be called "New SATA Controller" Save the virtual machine. This creates a virtual machine folder on the datastore, and provisions the VM configuration file and virtual disk in that folder. It is not ready for use yet; some additional preparatory steps need to be completed. Preparing the TCRP Image ESXi VMs cannot boot virtualized USB flash drive images. A passthrough physical USB can be used, but is not recommended. Instead, a special version of the loader is used as a bootable virtual SATA drive. When the TCRP loader boots in this manner, it is called SATABOOT. Download the tinycore-redpill 7.x loader and save it to your personal computer. Then, open it with a zip manager to show the boot images: tinycore-redpill.vX.X.X.img.gz (for BIOS/CSM/Legacy boot from USB flash drive) tinycore-redpill-uefi.vX.X.X.img.gz (for UEFI/EFI boot from USB flash drive) tinycore-redpill.vX.X.X.vmdk.gz (for virtual machine SATABOOT from disk image) Save the vmdk gzip file to your personal computer. Then, upload it to the new virtual machine folder contained in the datastore: For the next step, ESXi console access is required. From the web GUI, enable both SSH and the console shell. SSH into the ESXi host and navigate to the new VM's folder: [root@esxi:] cd /vmfs/volumes [root@esxi:] cd <datastore> [root@esxi:] cd MyNewNAS [root@esxi:] ls -la total 65664 drwxr-xr-x 1 root root 73728 May 28 09:02 . drwxr-xr-t 1 root root 81920 May 28 08:58 .. -rw------- 1 root root 22548578304 May 28 08:58 MyNewNAS-flat.vmdk -rw------- 1 root root 474 May 28 08:58 MyNewNAS.vmdk -rw-r--r-- 1 root root 0 May 28 08:58 MyNewNAS.vmsd -rwxr-xr-x 1 root root 1941 May 28 08:58 MyNewNAS.vmx -rw-r--r-- 1 root root 65260813 May 28 09:02 tinycore-redpill.v0.4.6.vmdk.gz The TCRP SATABOOT image is provided compressed and in VMware Workstation format. These commands prepare it for use with ESXi: [root@esxi:] gunzip tinycore-redpill.v0.4.6.vmdk.gz [root@esxi:] vmkfstools -i tinycore-redpill.v0.4.6.vmdk MyNewNAS-TCRP.vmdk Destination disk format: VMFS zeroedthick Cloning disk 'tinycore-redpill.v0.4.6.vmdk'... Clone: 100% done. Creating a DSM Virtual Machine, Part 2 From the GUI console, select the DSM virtual machine and Edit. This is what things look like now: Now the SATABOOT loader must be added to the virtual machine. Select Add hard disk (existing hard disk) and choose the TCRP vmdk created in the previous step It will be displayed as "New hard disk" - expand the dropdown Change the controller to SATA Controller 0 The disk address should be SATA0:0 Save the changes to the VM The default for the Other 3.x Linux (64-bit) hardware profile is to create a SCSI virtual controller and attach all new virtual disks to it. DSM works better with the virtual SATA controller, so we need to move the DSM virtual data disk to it. Edit the virtual machine Expand the dropdown for Hard disk 1 (note that it is 21GB or whatever size we selected) Change the controller to SATA Controller 1 The disk address should be SATA1:0 Save the changes to the VM VMWare has an odd behavior in that it renumbers all the hard disks based on the last edit. This is cosmetic, and only affects the VM configuration screen. It does not change the disk addressing order in any way. The VM edit window now looks like this: Now that no disks are attached to the SCSI controller, we can (and should) delete it. The final configuration of controllers and disks is: SATA Controller 0: SATABOOT (SATA0:0) SATA Controller 1: DSM Data DIsk (SATA1:0) Any additional virtual DSM data disks should be added to SATA1 (i.e. SATA1:1, SATA1:2, etc). SATA0 should be reserved only for SATABOOT. The VM is now ready for the TinyCore boot (main tutorial, Step 3). System-Specific Parameters and SATABOOT ESXi requires minor adjustments to the basic tutorial configuration steps: The USB flash drive VID/PID configuration step (./rploader.sh identifyusb) is invalid and can be skipped when using SATABOOT. When using a virtual network adapter (such as VMXNET 3), its MAC address and the loader's MAC address setting must match. When a virtual machine is booted for the first time, a random address is assigned to each virtual adapter. Unless your primary network interface is a passthrough device, the serialgen configuration step requires the realmac argument to match the virtual NIC's random address to TCRP. Example: ./rploader.sh serialgen DS3622xs+ realmac The Drive Slot Mapping configuration step is the same, but the outcome is different when SATABOOT is in use. ./rploader.sh satamap will enforce the prohibition on data disks attached to SATA0 and warn if this configuration exists. SataPortMap and DiskIdxMap are configured to remove a blank slot between the SATA0 and SATA1 controllers. SCSI/SAS controllers or HBAs (either passthrough or virtual) ignore satamap functionality. When SATABOOT is also in use, there is an unavoidable blank slot between the last SATA controller and the first SCSI/SAS controller or HBA. Boot DSM with GRUB When the GRUB Menu is displayed: if necessary, use the arrow keys to ensure that SATA is selected and press ENTER. Advanced Configuration Examples: Passthrough and Raw Device Mapping (RDM)
  2. Hello! I am xpenology user. And I am an IT engineer who creates shell scripts as hobbies. Please understand that it is written by a google translate site. because i’m korean who is not fluent in English. I created a tool to change cpu information for Xpenology’s users. Modify the actual cpu name and cores of your pc or server. Howto Run ============================================================= 1. Download attached file on your PC (ch_cpuinfo.tar) (ch_cpuinfo_en.tar) / (ch_cpuinfo_kr.tar is file for korean) 2. Upload file to your DSM location (by filestation, sftp, webdav etc....) 3. Connect to ssh by admin account. (dsm > control panel > terminal & snmp > terminal > enable ssh check) 4. Switch user to root: sudo su - (input admin password) 5. Change directory to where ch_cpuinfo.tar file is located: cd /volume1/temp 5-1. in another way, Download ch_cpuinfo.tar with wget wget https://github.com/FOXBI/ch_cpuinfo/releases/download/ch_cpuinfo/ch_cpuinfo.tar 6. Decompress file & check file: tar xvf ch_cpuinfo.tar ls -lrt (check root’s run auth) 7. Run to Binary file ./ch_cpuinfo or ./ch_cpuinfo.sh (If you use busybox in DSM 5.x, you can use it as a source file) 8. When you execute it, proceed according to the description that is output. 9. Check your DSM’s CPU name, CPU cores at “information center” made a video of the how to run ch_cpuinfo. Extra Action If you want to use ch_cpuinfo in your language Modify and use the LANG.txt file in the same path as ch_cpuinfo. It is possible to use after changing the English content of each variable after translation and changing the value of CUSTLANG in line 8 to Y. Sample image(by Google trans) ==================================================== Addtional, Adjust binary to excute file made by shc(http://www.datsi.fi.upm.es/~frosal) The tool does not inclue worms, bad code. If you want to edit the CPU information yourself manually, please refer to the contents below. ——————————————————————————————————————————————————————————————— Location : /usr/syno/synoman/webman/modules/AdminCenter Source : admin_center.js / admin_center.js.gz(above 6.2) Add Before -> if(Ext.isDefined(h.cpu_vendor)&&Ext.isDefined(h.cpu_family)&&Ext.isDefined(h.cpu_series)){ o.push([_T("status","cpu_model_name"),String.format("{0} {1} {2}",h.cpu_vendor,h.cpu_family,h.cpu_series)])} if(Ext.isDefined(h.cpu_cores)){o.push([_T("status","cpu_cores"),h.cpu_cores])} Add contents: h.cpu_vendor="Intel";h.cpu_family="Xeon";h.cpu_series="E3-1220 V3";h.cpu_cores="4 Cores (1 CPU/4 Cores | 4 Threads)"; h.cpu_detail="<a href='https://ark.intel.com/content/www/us/en/ark/search.html?_charset_=UTF-8&q=E3-1220 V3' target=_blank>detail</a>" Change contens: String.format("{0} {1} {2}",h.cpu_vendor,h.cpu_family,h.cpu_series) to String.format("{0} {1} {2} {3}",h.cpu_vendor,h.cpu_family,h.cpu_series,h.cpu_detail) ——————————————————————————————————————————————————————————————— Finally, All descriptions are based on version 6.2, and the actual executable file supports 5.x, 6.x and 7.x Publish the source through github(https://github.com/FOXBI/ch_cpuinfo). For versions DSM 6.x and later, you can use the binary as before. If you use busybox in DSM 5.x, you can use it as a source file(ch_cpuinfo.sh). Please contact me by comment or bug report, i’ll respond to you as much as possible within my ability. Test & Made Environment ———————————————————————————————————— Base Server : HP ML310e v2 gen8 + VMware ESXi 6.0 + RDM DSM : DSM 6.2.3-25426 Update 3 (DS3615xs) Base Server : HP ML310e v2 gen8 + VMware ESXi 6.0 DSM : DSM 7.0.1-42214 (DS3615xs) Base Server : HP ML310e v2 gen8 + VMware ESXi 6.0 DSM : DSM 7.0.1-42214 (DS918+) Base Server : HP ML310e v2 gen8 + VMware ESXi 6.0 DSM : DSM 6.2.4-25556 (DS3615xs) Base Server : Intel E5-2630 v2 + VMware ESXi 6.7u2 DSM : 6.2.2-24922 Update 2 (DS3617xs) ———————————————————————————————————— Change Log Update new version (ch_cpuinfo ver 4.2.0-r01) 2023.02.18 - Application of AMD's CPU information collection function improvement - xpenlib(cpu_info.sh) refered https://github.com/FOXBI/xpenlib/blob/main/cpu_info.sh Update new version (ch_cpuinfo ver 4.2.1-r01) 2023.03.05 - Fixed error when users of previous version perform redo with version 4.2.0-r01 (Thanks for the @Mentat report.) I am sorry for not being able to actively respond to your inquiries due to busy life. Thank you!! Have a nice day!! Cheer up!! We can do it!! Reduce activity & Stay home & Wear a Mask!! Let's overcome COVID-19 !! Let's pray and support together for the two countries where the earthquake caused great damage and many deaths and missing people. ============================================= Download links: ch_cpuinfo ver 4.2.0-r01 - new version update -> ch_cpuinfo ver 4.2.1-r01 - new version update -> ch_cpuinfo.tar Reference images # 1.04b + DS918+ # 1.03b + DS3615xs # 1.03b + DS3617xs # Normal output is possible even when using more than 8core. # Support DSM 7.x
  3. Mon problème est que mon xpenology fonctionnait très bien avec DSM 6.2. Après une panne de courant, et le rôle de l'UPS qui a fait son job, 1) le serveur ne s'est pas arrêter comme prévu du tout et 2) lors du redémarrage impossible de retrouver l'accès samba ou url du NAS. Quand j'essaye d'installer la version 7.x : impossible de booter dessus ni même d'installer tout court malgré le suivi du guide... D'avance merci pour votre aide
  4. hello, i cannot install on my esxi an DS920+ or DS3622xs+ with DSM 7.1 (it's okay with 7.01) after rploader build the VM boot but NAS not detect HDD an idea ? Thanks
  5. I must be missing something, but I can't figure out what it is. I'm trying the following on my ESXi 6.7 system which has been running a JUN DSM6 for several years: I created the VM, with the latest VMDK (0.8.0.0). It boots fine, update/fullupgrade work fine, I believe the version is now 0.8.0.3 or something like that. For the build I've run the following commands: ./rploader.sh serialgen DS3622xs+ realmac ./rploader.sh satamap (where I specify 9 disks, to allow 1 vmdk for volume1 and bringing over my 8 RDM devices for volume2, which I will not do until after testing) ./rploader.sh build broadwellnk-7.1.0-42661 The build seems to go fine and does not display any errors, however when I reboot the VM I still only have TinyCore at the GRUB screen. I don't have any entries for RedPill. Anyone have any ideas?
  6. Voici ma méthode sur Proxmox [DS3622xs+] Pré-requis : 1 - Être sur Promox 2 - Mettre Sa carte Réseau en Intel e1000 (Ce qui voudrait dire que le pilote que vous aller installer est celui de intel et non virtio.) Sur Tiny Core en Ssh : sudo su (important pour ajouter le pilote Intel) ./rploader.sh update now ./rploader.sh fullupgrade now ./rploader.sh serialgen DS3622xs+ ./rploader.sh satamap now ./rploader.sh ext broadwellnk-7.0.1-42218 add https://raw.githubusercontent.com/pocopico/rp-ext/master/e1000/rpext-index.json ./rploader.sh build broadwellnk-7.0.1-42218 ./rploader.sh backup now ( Pour Sauvegarder tous ce que vous venez de faire) Pour Passer de DSM 7.0.1 à 7.1.0-42661 enchaîner avec cette commande (ça peut ne pas marcher): ./rploader.sh clean now ./rploader.sh build broadwellnk-7.1.0-42661 ./rploader.sh clean now rm -rf /mnt/sdb3/auxfiles rm -rf /home/tc/custom-module ./rploader.sh backup now N'oubliez pas de vérifier le Vid et le Pid dans User config json avant chaque build voir la video de @Sabrina
×
×
  • Create New...