tahuru
-
Posts
5 -
Joined
-
Last visited
Posts posted by tahuru
-
-
Hi,
Is there a simple way to upgrade to 0.9 from 0.8 without running all the steps again?
Thx!
-
Can we make this somehow less talkative?
611.160667] <redpill/smart_shim.c:646> Got SMART *command* - looking for feature=0xd0 [ 611.161950] <redpill/smart_shim.c:646> Got SMART *command* - looking for feature=0xd0 [ 611.161951] <redpill/smart_shim.c:390> Generating fake SMART values [ 611.165183] <redpill/smart_shim.c:390> Generating fake SMART values [ 671.176693] <redpill/smart_shim.c:646> Got SMART *command* - looking for feature=0xd0 [ 671.178139] <redpill/smart_shim.c:390> Generating fake SMART values [ 731.190918] <redpill/smart_shim.c:646> Got SMART *command* - looking for feature=0xd0 [ 731.192880] <redpill/smart_shim.c:390> Generating fake SMART values [ 791.205513] <redpill/smart_shim.c:646> Got SMART *command* - looking for feature=0xd0 [ 791.207420] <redpill/smart_shim.c:390> Generating fake SMART values [ 799.637267] <redpill/smart_shim.c:646> Got SMART *command* - looking for feature=0xd0 [ 799.639182] <redpill/smart_shim.c:390> Generating fake SMART values [ 799.641056] <redpill/smart_shim.c:646> Got SMART *command* - looking for feature=0xd0 [ 799.642968] <redpill/smart_shim.c:390> Generating fake SMART values [ 799.644788] <redpill/smart_shim.c:646> Got SMART *command* - looking for feature=0xd0 [ 799.646715] <redpill/smart_shim.c:390> Generating fake SMART values [ 799.648550] <redpill/smart_shim.c:646> Got SMART *command* - looking for feature=0xd0 [ 799.650512] <redpill/smart_shim.c:390> Generating fake SMART values [ 799.652390] <redpill/smart_shim.c:646> Got SMART *command* - looking for feature=0xd0 [ 799.654330] <redpill/smart_shim.c:390> Generating fake SMART values [ 799.656183] <redpill/smart_shim.c:646> Got SMART *command* - looking for feature=0xd0 [ 799.658071] <redpill/smart_shim.c:390> Generating fake SMART values
-
Hi all!
Anyone else seeing this issue?
Im using Proxmox and passthrough a few harddrives to the VM
Upon booting... its taking its time for each disk.
Any workaround for this?
Thanks!
96.261440] <redpill/boot_shim_base.c:34> Checking if SATA disk is a shim target - id=0 channel=0 vendor="QEMU QEMU HARDDISK 2.5+" model="QEMU HARDDISK "
[ 96.264417] <redpill/boot_shim_base.c:44> Device has capacity of ~228936 MiB - it WILL NOT be shimmed (>1024)
[ 96.266575] <redpill/scsi_notifier.c:87> Calling original sd_probe()
[ 96.267836] want_idx 1 index 8. delay and reget
[ 97.268128] want_idx 1 index 8
[ 97.268639] want_idx 1 index 8. delay and reget
[ 98.269206] want_idx 1 index 8
[ 98.269678] want_idx 1 index 8. delay and reget
[ 99.270114] want_idx 1 index 8
[ 99.270604] want_idx 1 index 8. delay and reget
[ 100.271169] want_idx 1 index 8
[ 100.271827] want_idx 1 index 8. delay and reget
[ 101.272107] want_idx 1 index 8
[ 101.272872] want_idx 1 index 8. delay and reget -
On 12/30/2019 at 10:41 PM, IG-88 said:
it should have worked wit the old extra.lzma and dsm 6.2.0, only the kernel options change by synology broke that for 6.2.2 and it needed newly compiled drivers to match the new kernel
but now as there are fresh drivers for 6.2.2 it should be working with 6.2.2
when already running 6.2.2 you could add the new extra.lzma to your usb and on next reboot it should be loaded and copied to your system
if you want a test without any risk there are 2 options
- extract the bnx2.ko from extra.lzma (extraction is possible with 7zip or the way described in the driver injection tutorial), copy it to your running 6.2.2 dsm and insmod the driver (as the old one did not work it should not be needed to rmmod the driver), that driver needs firmware but the firmware should be already there and is still the same as in the former 6.2.0 version
- create a new usb, disconnect all drives in use, use new usb (6.2.2 kernel and new 0.5 extra.lzma) and install to a empty disk to check the result
if there is no one around providing new drivers then using a hardware that is directly supported by dsm is a option (the other is to stay on a older release like 6.2.0 or 6.1)
on my new system i will use a 8 port ahci controller instead of the good old sas2008 (mpt2sas) based controller - as synology is not meddling in the kernel code of the network cards its still no problem to provide drivers for nic's (as long as they are in the 4.4.59 kernel or the external source is compatible with that kernel - at least for 918+, for 3615/17 its kernel 3.10.105 and that can be a problem in some cases as new external drivers might compile/work with that old kernel)
edit: wait, it did not work for you on dsm 6.1 with my extra.lzma (like v4.8)? should have, the driver is there and the firmware files also match the driver, i'm sure there where people with dell's that got it working, afaik this driver was already part of jun's extra.lzma but there where 2 (mips) firmware files missing in jun's extra.lzma so it work not for all (maybe depending on hardware version of the nic)
Hi IG
Thank you so much for your work. Much appreciated!!
Do you mean that LSI 2008 IT mode will not be viable for the future and will it not work for the current DSM?
Ive been lurking here to build myself an Xpenology box that will include the LSI card.
Thanks and a Happy New Year to all forum members!
DSM 7.2-64561
in DSM Updates Reporting
Posted · Edited by tahuru
- Outcome of the Install: SUCCESSFUL
- DSM version prior to update: NON
- Loader version and model arpl-i18n - DSM 7.2 64570 Update 1 using DVA1622 image.
- Using custome xtra.lzma: NO
- Installation type: BAREMETAL QNAP 453a 4GB RAM N3160 4x4GB Western Digital Red
- Additional comments: Plex Transcoding using the iGPU WORKS!
- All 4 LAN Ports are operational.