sloniu82
-
Posts
16 -
Joined
-
Last visited
Everything posted by sloniu82
-
Hi I've successful built test system with proxmox and DS3617 1.3b image. As others here I was forced do use BIOS instead of UEFI and USB3 emulation of synoboot pendrive. DSM (fresh install) after week of test seems stable and the performance is comparable to DSM 6.1. One thing stopping me from migration of my production system - lack of virtio drivers in synoboot. Could someone compile these drivers, please?
-
Hi. I'm using @hellbondz way to boot vm from img (using uefi). Everything is working well so far. Few days ago I installed second Xpenology VM to test updates (with quemu disks only to use snapshots). What I found in console after loader boot, that MAC address is the same as my main xpeno box. (So there is MAC conflict in my LAN) Then I checkd that my production box is not using my generated MAC/Serial, but this default shipped with loader. What could cause this? I think there's a problem with VID/PID when using virtual device as usb loader - maybe thats why loader gets their default values) I tried to pass vendorid=0xxxxx,productid=0xxxxx to device section in vm.conf, but vm not starting after that. So once again I looking for proper way to automatically boot jun's loader in proxmox enviroment
-
Update successful on barematal HP ML10 gen9 I'm using DS3617xs 1.01a2 loader
-
I don't think than is the best option - if you do that way you will need to play with raid array using mdadm (DSM always creates raid partition, even with one disk) What i tryied to say last time, DSM mounts used filesystems only if it is a USB or ESTA (ie external) disk. If you connect USB drive, you can format this drive as ext3/4 event from DSM, and it will be readable in ubuntu. I've done quick test - added this to args line in qm.conf file: args: -device 'piix3-usb-uhci,addr=0x18' -drive 'id=synoboot,file=/synoboot-virtio.img,if=none,format=raw' -device 'usb-storage,id=synoboot,drive=synoboot' -device 'nec-usb-xhci,id=xhci,addr=0x1b' -drive 'id=testusb,file=/dev/disk/by-id/ata-ST3320613AS_xxxxxxxx,size=320071851520,if=none,format=raw' -device 'usb-storage,id=testusb,drive=testusb' This emulates two usb devices in our qm: #1 jun's bootloader as USB1 #2 phisical disk as USB2 After restart you can find in DSM that phisical HDD is passthru as USB disk (this is my test hdd so you see mdadm dsm's partitions there) You can format drive (or partition) to ext4 or FAT32 and at the end DSM will automaticly mount this new volume as usbshare. This partition is a normal ext4 filesystem, that you can mount wherever you want. I can't tell you that this is the best way to do what you want. Maybe someone smarter/better in proxmox/kvm's configuration know better way to do this. I hope it helps.
-
Can you boot jun's bootloader as baremetal on your hardware? I'm asking, because my first proxmox test system was sitting on old atom D410 ITX motherboard. And on this hardware jun's loader couldn't boot (as kvm virtual machine or baremetal). So even KVM virtualization couldn't cheat hardware incompability. (probably some unsupported CPU instructions used in loader kernel)
-
I'm not sure, but I think that DSM only mount external disks (USB oraz ESATA ) as volume not managed by DSM. This how it works in real Synology. You can try to passthru drive as USB device
-
Well, this is not working on my test PC, will see if this problem exist on my main server (ML10 gen9). But I think you can't passthru internal sata controller while using it as boot device for proxmox (in my configuration one disk is for pve and it's local storage) Anyway, disk smart data passthru is not a deal breaker here, I can still manage SMART tests on proxmox side (using cron and smartctl with email notifications)
-
Hi there, I'm considering to migrate my baremetal Xpenology system to proxmox. So I installed test pve system on my old PC and configured latest DS3617xs DSM with Jun's 1.02b loader. Thanks everyone for tips from this thread! Found one problem - I've passthru one drive as sata, but DSM can't read SMART data. Can someone tell me how to passthru HDD with all smart data?
-
Successfully applied 6.1.3-15152-4 update (direct download from Control Panel) Hardware: baremetal HP ML10 gen9 I'm using DS3617xs 1.01a2 loader
-
I've successfully applied 6.1.3-15152 Update 1 update on my HP ML10 gen9 baremetal with 1.01a2 loader. No restart needed
-
I've successfully applied DS3617xs 6.1.3-15152 update on my HP ML10 gen9 baremetal without any issues. I'm still using 1.02a2 loader (I wonder how many updates it will survive )
-
I've applied update this morning on HP ML10 gen9 baremetal without any issues.
-
Hi. I'm currently on DS3617 latest DSM with 1.02a2. Is it worth to upgrade loader to 1.02b? Do I need to reinstall DSM with neewer loader? I'm not sure what is the procedure of loader upgrade.
-
Upgrade from 6.1.1-15101 to 6.1.2-15132 successfull on baremetal ML10 gen9
-
I can confirm too, installed 6.1.1 u4 on baremetal ds3617xs loader - everything works fine so far.
-
Thats not true - of course you can migrate from ds3615xs to ds3617xs with all settings. I did this on my machine (HP ML10 gen9). Of course it wasn't that easy - my first attempt fail. Here's my story: #1 attempt --> with all disks installed, boot server with new loader with install option and go to xpenology_ip:5000. Synology assistant detects migration from 3615 to 3617 and propose migration with or without settings. Of course I've selected migration with settings. But someting was wrong because whole DSM installation process was very short, less than 2 minutes, but without errors. After reboot no joy - bricked DSM. #2 attempts - same scenario, but: - disconnected all drives exept my first hdd (seperate 1 drive volume1 for less sensitive data) - reflashed loader and recreated pid/vid/serial/mac - after boot loader with install option selected, synology assistant still/again ofered migration from 3615 to 3617. And this time upgrade worked fine, took about 10 minutes. After succesfull 6.1.1 upgrade I've applied DSM 6.1.1-15101 Update 2 patch without aby problems. Now: power off, reconnect rest of my drives and boot. Used mdadm command to add connected drives to md0 array. Everyone must remember that this migration is (I think) very hardware specific - with no proper drivers in loader it will fail. My rig is very familiar with oryginal DS3617xs hardware (same CPU architecture). EDIT By the way, I wanted to report a strange problem: After migration my DSM dispalying strange IP address: Of course, DSM real IP is normal. Anyone have any clue whats couse this?
