IG-88

nein das ist wie dsm und laoder arbeiten, wenn man eine dsm version installiert wird der kernel (zImage und rd.gz) auf den loader geschrieben, 2. partitons ursprünglich liegt dort 6.2.0 und höher geht, da kein downgrade geht wird er sich weigern nach 6.2.4 etwas älteres zu installieren - bis man die zwei kernel dateien wieder zurücksetzt (vorausgesetzt es ist nichts neueres bereits auf disk installiert) da geht nur ganz oder garnicht, man kann es nur entweder als cache oder daten laufwerk (volume) nutzen

what do you prefer? crystal ball, tea leaves or throwing bones?

have'nt seen bios option of dell, so only generic suggestions beside disabling any boot options other then usb you could also disable sata in bios maybe it helps if you connect one drive (even if not using it in dsm) to a sata port or you connect one of the drives from the lsi (the chipset sata's are usually not that bad)

the usb drives are part of the kernel source, afaik there is not additional driver you could add or exchange and going through you dmesg, the driver do load and detect usb ... [ 3.634630] ACPI: bus type USB registered [ 3.634657] usbcore: registered new interface driver usbfs [ 3.634670] usbcore: registered new interface driver hub [ 3.634695] usbcore: registered new interface driver ethub [ 3.634722] usbcore: registered new device driver usb [ 3.654706] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 3.671093] xhci_hcd 0000:00:14.0: xHCI Host Controller [ 3.671103] xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 1 [ 3.872212] xhci_hcd 0000:00:14.0: hcc params 0x200077c1 hci version 0x100 quirks 0x0004b010 [ 3.872219] xhci_hcd 0000:00:14.0: cache line size of 64 is not supported [ 3.872443] hub 1-0:1.0: USB hub found [ 3.872456] hub 1-0:1.0: 9 ports detected [ 3.876158] xhci_hcd 0000:00:14.0: xHCI Host Controller [ 3.876164] xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 2 [ 3.876188] usb usb2: We don't know the algorithms for LPM for this host, disabling LPM. [ 3.876353] hub 2-0:1.0: USB hub found [ 3.876365] hub 2-0:1.0: 4 ports detected [ 3.901609] usbcore: registered new interface driver usb-storage ... even the usb flash drive is detected and gets a sdq assignment ... [ 4.315698] usb 1-7: new high-speed USB device number 3 using xhci_hcd [ 4.603902] EXT4-fs (md0): barriers disabled [ 4.604236] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: [ 5.983838] usb 2-3: new SuperSpeed USB device number 2 using xhci_hcd [ 6.733919] Got empty serial number. Generate serial number from product. [ 7.484003] hub 1-7:1.0: USB hub found [ 7.983999] hub 1-7:1.0: 4 ports detected [ 10.234235] usb-storage 2-3:1.0: USB Mass Storage device detected [ 10.235758] scsi host3: usb-storage 2-3:1.0 [ 11.357287] usb 1-8: new high-speed USB device number 4 using xhci_hcd [ 11.857344] scsi 3:0:0:0: Direct-Access Kingston DataTraveler 3.0 PMAP PQ: 0 ANSI: 6 [ 12.234376] sd 3:0:0:0: [sdq] 121135104 512-byte logical blocks: (62.0 GB/57.8 GiB) [ 12.734420] sd 3:0:0:0: [sdq] Write Protect is off [ 12.734423] sd 3:0:0:0: [sdq] Mode Sense: 45 00 00 00 [ 12.984426] sd 3:0:0:0: [sdq] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [ 18.234861] Got empty serial number. Generate serial number from product. [ 18.986022] usb-storage 1-8:1.0: Quirks match for vid 05e3 pid 0723: 8000 [ 18.984964] usb-storage 1-8:1.0: USB Mass Storage device detected [ 18.986076] scsi host4: usb-storage 1-8:1.0 [ 19.036932] usb 1-7.3: new full-speed USB device number 5 using xhci_hcd [ 19.063953] sdq: sdq1 sdq2 ... the following part is where things go wrong, and where you could try to change something, xhci_hcd is usb 3 driver, so try a usb 3.0 port, a older usb 2.0 usb flash drive or connect a usb 2.0 hub and connect the usb flash drive this way, also try another flash drive and move it between usb ports you should also try to look into usb settings in bios, there are usually some settings about usb compatibility what is the chipset/mainboard? from dmesg its a broadwell chipset from 2014, so there should not be "new" problems with 918+ kernel 4.4.59+ ... [ 29.055753] xhci_hcd 0000:00:14.0: xHCI host not responding to stop endpoint command. [ 29.055757] xhci_hcd 0000:00:14.0: Assuming host is dying, halting host. [ 29.055778] xhci_hcd 0000:00:14.0: HC died; cleaning up [ 29.055892] usb 1-7-port3: couldn't allocate usb_device [ 29.055981] usb 2-3: USB disconnect, device number 2 [ 29.055985] usb 1-7: USB disconnect, device number 3 [ 29.056183] usb 1-8: USB disconnect, device number 4 [ 29.061877] sd 3:0:0:0: [sdq] Read Capacity(10) failed: Result: hostbyte=0x01 driverbyte=0x00 [ 29.061883] sd 3:0:0:0: [sdq] Sense not available. [ 29.061988] sd 3:0:0:0: [sdq] Attached SCSI removable disk [ 29.152095] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: barrier=1 [ 29.729670] EXT4-fs (md0): re-mounted. Opts: (null) ...

no the reference about the extra with the old driver was about 918+ for 3617 you might not even need a extra, you use 0.11.2 but as you hardware is not that new the onboard nic should work with the drivers jun provides with the loader beside lsi sas drivers even the mellanox drivers have native drives from synology you could user open media vault with the synology disks, it would ignore the system/swap partitions and you should be able to use the data volume(2) install omv and it its ready connnect the dsm disks

no https://xpenology.com/forum/topic/28556-ds3617-not-see-all-disk/?do=findComment&comment=142685 look for jmb585 or maybe asm1166 based controllers https://xpenology.com/forum/topic/35882-new-sataahci-cards-with-more-then-4-ports-and-no-sata-multiplexer/

for one thats only true for 918+ and the other thing is even when present since loader 1.04b existed it only came to attention years later, there seem to be lot of users not having trouble with it, there might be other factors involved like what bios version the controller hast a what chip version you could test it with 3 disk in a raid5 and hibernation on, i di provide a extra version with the old driver (that can do sn and smart) you are safe when using 3617, just do a migration with 1.03b 3617 loader and thats it, you cant use hardware transcoding with that but most/all devices can replay higher grade streams so in most cases (in LAN) there is no real need for on the fly transcoding yes, you cant downgrade in a migration step

you can't just swap drivers files with linux like you do with windows last time we tried hpsa drivers form external they always crashed and i also di d not have controller working with the hpsa to test, shortly a p410 dropped into my lap and now i would be able to test a newer driver, still it is a awfull task as it does not boot on my system when hpe controller bios is active and when inactive the disks cant be configured (it needs to have a raid for disks as the p410 does not has a switchable hba mode) its on the todo list but not very high as the driver from the kernel does work (i did test it with the p410 a few weeks ago)

thats the method used by esxi install (3rd option in the boot menu), i never tried it that way baremetal no, different kernel 3.10.105 vs. 4.4.59+ no the superblock messages are normal and on every system the sdX device for usb boot is usually above the max disk count so sdq would be normal on a 918+ does your system has a serial port? with a null modem cable you might be able to get better and more information about the error when booting usb and failing to install you would use a null-modem cable and putty for the other end so see what happens can you add the grub.cfg from the loader you actually use for installing 918+?

it would be possible but kind of lame as the loader would just need to be adapted to the new id's also its unlikely to be done to "normal" hardware devices (like a marvel ahci controller) as it would mean you have to patch the kernel and drivers so only synologys own hardware like usb loader hardware (f400:f400 - the 2nd value is there choice as a vendor), also easy to mimic/adapt i must correct this, every version like 6.2.2, 6.2.3, 6.2.4 comes with a bios file (also 7.0) the 6.2.4 and 6.2.3 pat file content on 918+ look pretty much the same (918+ is already uefi bios) only 3615/17 have differences and it looks like some different change in bios update compared with 6.2.2->6.2.3 the presence of different flash utility's and a new SynoBootLoader.efi instead of SynoBootLoader.conf suggests a change from csm/legacy to uefi and when asking why, a reasonable answer might be secure boot and signed kernel/driver (they do use signing drives for a long time but if seemed to be used/enforced, maybe thats changing now) if we want to continue speculating we might do this in a new different thread

just to make clear, the bios updates have nothing to do with out problems in 6.2.4, 918+ does not get any and is broken too

did you try installing 6.2.0 (23739)?

i dont get what you say here, what do you boot from disk? what disk? dsm boots from usb and installs to disks might be the differnce between dsm 6.1 / loader 1.02b and dsm 6.2 you can try loader 1.02b 916+, that also has a i915 driver, its Intel Pentium N3710 came with intel qsv at this time the transcoding had a diffrent base (gstreamer?) not sure if plex can use the transcoding of the 916+ the transcoding was jun's initial reason to introduce the 916+ https://xpenology.com/forum/topic/6253-dsm-6xx-loader/?page=102#comment-67297

usb driver are part of dsm not of the extra drivers, if your usb drives is not showing up check you /var/log/dmesg and use lsusb to check the status of the usb devices i'd suggest 1st using default config to see if the usb hdd shows up as external drive, if it does, change synoinfo.conf and reboot appart from this its nothing that the dev's at synology ever had in mind and even if it does work, it more of a misconfiguration error thats not catched properly, kind of a undefined state

from a quick look it seems to be a nec chip my card needed a firmware update before working with linux, windows did work fine for years before that https://www.station-drivers.com/index.php?option=com_remository&Itemid=353&func=fileinfo&id=120&lang=en

the output of the serial console look s the same as with dsm 7 preview/beta the kernel version is still the same (can be checked in kernel modules) so it might be a new protection layer also different in 6.2.4 is that for 3615/17 there seem to extra bios flash stuff in the file and a there is a "SynoBootLoader.efi", might be a sign these units are migrated to uefi boot

its the same error as with dsm 7 beta, maybe the pre-load kernel does not match the synology kernel anymore the modules in 6.2.4 file still have 4.4.59+ for the kernel version

a "f" stands for 4 bit aka 4 drives, you configured internal to 4 drives thats 24: internalportcfg="0xffffff" if two usb are not enough you can also change usbportcfg="0x30000" to usbportcfg="0xff0000" what makes you think its a driver problem, looks more like it broke the whole loader

thats not really a problem you could move usb and disks together to a different hardware and run it as long as nic and storage driver are working its not much of a problem 918+/1.04b need at least a 4th gen intel cpu (hasswell or newer) but you can "migrate" to a different type like 3617 and run it even on older hardware, config and data will be migrated so no loss (just change the loader to 1.03b 3617 in that case and boot, synology assistant will suggest a migration, the change of serial and mac is no problem as most of dsm works without valid serial/mac) if its ahci as storage and for nic a realtek 1G or intel 1G nic it sure will run 1.03b can be a little tricky to get running as it needs CSM mode when its uefi bios (and the non uefi usb boot device needs to be used) but in most cases thats a question of personal skill and experience, there are only very few newer systems not having csm/legacy mode and these usually run with 1.04b/918+ (and that can do uefi and csm)

no, the vid7pid is not needed for just finding the system in network, if you start installing to disk you will see error 13 that way because of the vid/pid mismatch most people i have seen using usb drives as internal drives had problems as it might not be stable (drives often dropping out of raid - hope you have a backup and know hot to manually recover a mdadm and lvm2) and you will loose the tweaked config when updating dsm (usually bigger version with 200-300MB *.pat file where the whole system disk is replaced, including the synoinfo.conf), i've seen both cases using usb as internal is not for 1st time users as its not easy to handle and will easily break you usually configure a overlap of internal drives and usb drives, like leaving usb on its default values and at the same time configuring max disks and internalportcfg to 24 drives, that way usb and internal overlap and you would see the usb drives within the 24 drive range

the following from your dmesg shows the kernel parameters comming from grub.cfg of the loader and the usb vid/pid is still the default of the loader [ 0.000000] Linux version 4.4.59+ (root@build3) (gcc version 4.9.3 20150311 (prerelease) (crosstool-NG 1.20.0) ) #25426 SMP PREEMPT Tue May 12 04:54:55 CST 2020 [ 0.000000] Command line: syno_hdd_powerup_seq=1 HddHotplug=0 syno_hw_version=DS918+ vender_format_version=2 console=ttyS0,115200n8 withefi elevator=elevator quiet syno_hdd_detect=0 syno_port_thaw=1 root=/dev/md0 sn=1780PDN388713 mac1=0011327B2C73 mac2=0011327B2C74 netif_num=2 vid=0x1908 pid=0x0226 [ 0.000000] KERNEL supported cpus: thats from the loaders grub.cfg set extra_initrd="extra.lzma" set info="info.txt" set vid=0x1908 set pid=0x0226 set sn=1780PDN123456 set mac1=001132123456 set rootdev=/dev/md0 set netif_num=1 its most often seen error and its explicitly mentioned in the tutorial with the error number 13 yes thats normal, installing dsm to usb drives is not supported, by default usb drives are only supported as external single drive (no raid) cenge vid/pid of 1.04b loader, seems you did it right with loader 1.02b if you installed 6.1.7, so redo the 1.04b loader and check twice

i'm not sure you will easily achieve this, afaik the original code checks for the presence of hardware specific for the model and if your 1010+ does have different hardware from 1511+ (very likely) it will fail to start the 1511+ install, i'm not sure when they introduced this protection but recent 6.2 loader has "emulated" devices in the list of lspci for that purpose so your best shot might be to use the already properly hacked versions 3615/3617 and try to make led's and fan control working (or leave it on 5.2 and sell the unit, its of limited use afair as a 32bit software on it can have max 16TB volumes - same will be true for 1511+ as its still x86 and not x64 as dsm version 6.2) the Intel Atom D510 in 1010+ seems to be a x64 cpu but to really free it from its (capacity) shackles it would need a x64 dsm version like 3615/3617 not sure if its really worth the effort, it will barely be able to hit the max. of 1GBit read/write rate https://www.smallnetbuilder.com/nas/nas-reviews/31075-new-to-the-charts-synology-ds1010

no what i tied to say was use the default extra.lzma and install 6.2.3 - but i did forget to mention the details how to do it (i was kind of assuming you would start from scratch with redoing the loader and using *.pat file of 6.2.0 or 6..2.3) if still using the 6.2.1 in theory the special extra.lzma for 6.2.2 could also be a cure if replacing the default one the system should boot with 6.2.1 and be found in network https://xpenology.com/forum/topic/21663-driver-extension-jun-103b104b-for-dsm622-for-3615xs-3617xs-918/ but thats not good solution as when updating from 6.2.1/6.2.2 to 6.2.3 later you will have exactly the same problem (and would again need to replace the extra.lzma to a version compatible with 6.2.3) so download 6.2.3 pat file, extract zImage and rd.gz from it using 7zip and use it together with the 6.2.3 extra.lzma (link below) on the 2nd partition on the loader, replacing all three files there https://xpenology.com/forum/topic/28321-driver-extension-jun-103b104b-for-dsm623-for-918-3615xs-3617xs/ boot with it and migrate/udpate to 6.2.3 when its found in network using *.pat file of 6.2.3 as alternative you could also extract zImage and rd.gz from the loaders *.img file using 7zip and copy it to the 2nd partition of the loader, same for extra.lzme form the img file that way loader and extra.lzma are back the way you started your journey and booting the usb you should find the system again in network, now use dsm 6.2.3 pat file to migrate/update the existing (6.2.1) installation, that should result in a working solution after the automatic reboot

das ist die lösung der meisten, man kann noch HT abschalten (und einen gewissen verlust in kauf nehmen) um den cpu count zu halbieren qemu und kvm, ich schätze mal das liegt daran das es AGPL ist und man nicht von der gnade vmware's abhängt (ich erinnere mich noch gut als die den ram beschränken wollten)

http://images.zeno.org/Literatur/I/big/bwe1441c.jpg whats the goal? having a 3615/3617 6.2.3 working on a original 1010 hardware and adding support for led's and fan control adapting from a older version? that was interesting, i always wanted a original boot image for comparing anything more recent (x64) that you found on the way?