mcdull
-
Posts
252 -
Joined
-
Last visited
-
Days Won
4
Posts posted by mcdull
-
-
2 hours ago, ThorGroup said:On 9/6/2021 at 4:53 PM, mcdull said:
I tried 3615 image in my old qnap. But it does not boot properly.
In GRUB> whenever I press enter, it will reboot by itself.
What CPU do you have? If it just hard-reboots it means the CPU just crashed, which usually means that it doesn't support some instructions.
mine is D425, probably require DS713+ image for maximum compatibility of instruction set.
-
most useful stuff is to use ds app on the go, while keeping the NAS under firewall.
I think it should be a norm to NOT explosing the NAS to the internet, see QNAP ransome case.
So with quickconnect, it is much easier to keep using the DS service.
Which can only be replaced by using VPN, which is not easy in most circumstances. Anyone has a good idea of a better implementation without quick connect?
- 1
-
2 hours ago, icaroscherma said:
Do you guys plan to work on a DS920+ release instead of 918+? Or it's just too much work?
I'm asking because I figured that DS Video won't work with HWA transcoding for hevc because it's based off the 918+ (Intel UHD500 - j3355/j3455, not UHD600 - j4105/j4125), so the DS Video authentication doesn't even check for hardware acceleration on hevc.
It would be a nice update from my baremetal jun's DSM6.2.3 918+ to a DSM7 920+. ❤️
I bet an AMD variant first will bring more benefit. I vote for 1621+
- 1
-
-
1 hour ago, ressof said:
No. How do I do that?
sorry, a typo, it should be active. use any partition tools or windows diskpart. Or refer to some pages before.
-
2 hours ago, ressof said:
But the installer won't continue after
FAT-fs (synoboot1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
2 hours ago, ressof said:But the installer won't continue after
FAT-fs (synoboot1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
did you set the partition to active (sorry typo before) for synoboot1?
-
32 minutes ago, ressof said:
Hi
Im trying to install DSM 7.01 apollolake 918+ on ESXI.
When running fdisk before installing PAT file I get this:
Disk /dev/sda: 120 GB, 128849018880 bytes, 251658240 sectors 15665 cylinders, 255 heads, 63 sectors/track Units: sectors of 1 * 512 = 512 bytes Disk /dev/sda doesn't contain a valid partition table Disk /dev/synoboot: 128 MB, 134217728 bytes, 262144 sectors 1008 cylinders, 5 heads, 52 sectors/track Units: sectors of 1 * 512 = 512 bytes Device Boot StartCHS EndCHS StartLBA EndLBA Sectors Size Id Type /dev/synoboot1 0,32,33 6,62,56 2048 100351 98304 48.0M 83 Linux Partition 1 has different physical/logical start (non-Linux?): phys=(0,32,33) logical=(7,4,21) Partition 1 has different physical/logical end: phys=(6,62,56) logical=(385,4,44) /dev/synoboot2 6,62,57 15,205,62 100352 253951 153600 75.0M 83 Linux Partition 2 has different physical/logical start (non-Linux?): phys=(6,62,57) logical=(385,4,45) Partition 2 has different physical/logical end: phys=(15,205,62) logical=(976,3,36) /dev/synoboot3 15,205,63 16,81,1 253952 262143 8192 4096K 83 Linux Partition 3 has different physical/logical start (non-Linux?): phys=(15,205,63) logical=(976,3,37) Partition 3 has different physical/logical end: phys=(16,81,1) logical=(1008,1,12)
and the logs when trying to install the PAT file from serial console
[ 183.720933] <redpill/rtc_proxy.c:37> MfgCompatTime raw data: sec=20 min=3 hr=6 wkd=5 day=10 mth=8 yr=121 [ 183.723631] <redpill/rtc_proxy.c:95> Writing BCD-based RTC [ 183.724954] RTC time set to 2021-09-10 6:03:20 (UTC) [ 186.800143] md: bind<sda1> [ 186.801637] md/raid1:md0: active with 1 out of 16 mirrors [ 186.802992] md0: detected capacity change from 0 to 2549940224 [ 189.811875] md: bind<sda2> [ 189.813208] md/raid1:md1: active with 1 out of 16 mirrors [ 189.814563] md1: detected capacity change from 0 to 2147418112 [ 190.198325] EXT4-fs (md0): couldn't mount as ext3 due to feature incompatibilities [ 190.209674] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: (null) [ 190.240130] <redpill/rtc_proxy.c:222> Got an invalid call to rtc_proxy_set_auto_power_on [ 190.246693] EXT4-fs (md0): couldn't mount as ext3 due to feature incompatibilities [ 190.257611] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: (null) [ 190.272865] EXT4-fs (md0): couldn't mount as ext3 due to feature incompatibilities [ 190.283741] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: (null) [ 196.595667] ext2: synoboot2 mounted, process=updater [ 196.599505] synoboot2 unmounted, process=updater [ 196.607208] ext2: synoboot2 mounted, process=updater [ 196.609221] synoboot2 unmounted, process=updater [ 196.616749] ext2: synoboot2 mounted, process=updater [ 196.619137] synoboot2 unmounted, process=updater [ 196.625799] ext2: synoboot2 mounted, process=updater [ 198.179513] synoboot2 unmounted, process=updater [ 203.191011] ext2: synoboot2 mounted, process=updater [ 203.250955] synoboot2 unmounted, process=updater [ 203.261041] ext2: synoboot1 mounted, process=updater [ 203.265540] vfat: synoboot1 mounted, process=updater [ 203.268169] FAT-fs (synoboot1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
Can this be fixed?
seems not fatal problem here in log.
-
2 minutes ago, jforts said:
According to some post, you will need a valid SN and MAC.
Mine is using a valid SN and MAC.
AFAIK, the valid mac is just needed to be input to the grub, but the actual hardware mac dose not matter, can you confirm?
I used it under proxmox so I acutally put the valid mac into virtual machine as well.
-
10 minutes ago, Franks4fingers said:
@pocopicoIt looks like I do not have synoboot in the directory structure. Any ideas how I rectify that?
it means the boot device is not properly mounted. in that case you should share again the boot device, config, check pid/vid and grub config, etc.
-
2 minutes ago, MastaG said:
That didn't work for me.
I believe it's something like this:
mkdir rd cd rd xz -dc < ../rd.gz | cpio -idmv (add drivers) find . 2>/dev/null | cpio -o -c -R root:root | xz -9 --format=lzma > ../rd.new.gz cd ../ rm -Rf rd mv rd.gz rd.old.gz mv rd.new.gz rd.gz
Still I can't seem to get any network interfaces.
Also the tg3.ko and libphy.ko where not inside the rd.gz archive.. while I did add it to the config.json file...
The iLO VSP console only print up to the point where it says:
[ 2.167768] <redpill/uart_swapper.c:428> ### LAST MESSAGE BEFORE SWAP ON "OLD" PORT ttyS1<=>ttyS0
From that point on I'm blind...
I
I am no ilo user. But I guess it is possible to redirect serial out to ilo interface?
-
1 minute ago, Franks4fingers said:
@pocopico - I can telnet to the box and get prompted for a login. Do you know of the default password for root? I couldn't find anything online so far.
root
then enter for nil password
-
20 minutes ago, Franks4fingers said:
I have checked and re-checked, used a different USB key and changed the PID / VID based on what that reported and it still hits 56% and then bombs out.
can you hook a serial out for debug?
and see if /dev/synoboot* is there?
-
seems 918 is in many way better than 3615
-
I dont see cpufreq folder in my DSM
-
-
48 minutes ago, titoum said:
for those that have mode their 6.x version to 7.0.1 RC.
have you done a clean or kept everything? i have mainly plex installed and saved it with hyperbackup so wondering if wouldnt be better to clean all and just keep files.
update and preserve setting is fine
-
5 minutes ago, jumkey said:
from https://gist.github.com/Izumiko/26b8f221af16b99ddad0bdffa90d4329
"synoinfo": { "supportsystemperature": "no", "supportsystempwarning": "no" },
yup. thats the one.. but I did not test it as I dont have this issue under proxmox.
-
I remembered there is a post in this thread shared a link to fix this.. the link is a script to replace some files?...
-
1 hour ago, titoum said:
is there a way to get the info when it fails at 56% ?
all is going smooth until the installation start and stop at that steps :s
thx
check if you have /dev/synoboot*
- 1
-
I tried 3615 image in my old qnap. But it does not boot properly.
In GRUB> whenever I press enter, it will reboot by itself.
-
After using the 7.0.1RC (918) on proxmox, I got quite a lot of call trace in log, and the system is very slow. Anyone experiencing the same?
[ 2160.666146] INFO: task kworker/u8:4:14489 blocked for more than 120 seconds. [ 2160.668620] Tainted: P OE 4.4.180+ #42214 [ 2160.670135] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 2160.671611] kworker/u8:4 D ffff8802613a3850 0 14489 2 0x00000000 [ 2160.672895] Workqueue: writeback wb_workfn (flush-btrfs-2) [ 2160.674311] ffff8802613a3850 00000000812c380a ffffffff818114c0 ffff8800367b6600 [ 2160.675579] 0000000000000000 ffff88027dc16300 7fffffffffffffff ffffffff81576880 [ 2160.676493] ffff8802613a3970 ffff8802613a3860 ffffffff81576126 ffff8802613a38d8 [ 2160.677916] Call Trace: [ 2160.678311] [<ffffffff81576880>] ? bit_wait+0x60/0x60 [ 2160.679061] [<ffffffff81576126>] schedule+0x26/0x70 [ 2160.679679] [<ffffffff81578cfe>] schedule_timeout+0x16e/0x280 [ 2160.680306] [<ffffffff810b836a>] ? ktime_get+0x3a/0xa0 [ 2160.682031] [<ffffffff81576880>] ? bit_wait+0x60/0x60 [ 2160.682702] [<ffffffff81575871>] io_schedule_timeout+0xa1/0x110 [ 2160.683374] [<ffffffff81576896>] bit_wait_io+0x16/0x60 [ 2160.683942] [<ffffffff8157663e>] __wait_on_bit_lock+0x4e/0xd0 [ 2160.684637] [<ffffffff8113124b>] __lock_page+0xab/0xb0 [ 2160.685314] [<ffffffff8108e850>] ? prepare_to_wait_event+0x100/0x100 [ 2160.685922] [<ffffffffa08c150d>] extent_write_cache_pages.isra.46.constprop.68+0x34d/0x480 [btrfs] [ 2160.686800] [<ffffffff8108e351>] ? __wake_up+0x41/0x50 [ 2160.687517] [<ffffffff81082c15>] ? update_curr+0xa5/0x130 [ 2160.688139] [<ffffffffa08c28bb>] extent_writepages+0x4b/0x60 [btrfs] [ 2160.688829] [<ffffffffa08a00b0>] ? btrfs_submit_direct+0x940/0x940 [btrfs] [ 2160.689620] [<ffffffffa089c8b6>] btrfs_writepages+0x26/0x30 [btrfs] [ 2160.690432] [<ffffffff8113ea7b>] do_writepages+0x2b/0x80 [ 2160.690986] [<ffffffffa08bd876>] ? clear_state_bit+0x156/0x1e0 [btrfs] [ 2160.691691] [<ffffffff811c34aa>] __writeback_single_inode+0x4a/0x380 [ 2160.692445] [<ffffffff811c3c69>] writeback_sb_inodes+0x1b9/0x530 [ 2160.693183] [<ffffffff811c4044>] __writeback_inodes_wb+0x64/0xb0 [ 2160.693901] [<ffffffff811c434a>] wb_writeback+0x22a/0x310 [ 2160.694571] [<ffffffff811c49f2>] wb_workfn+0x162/0x360 [ 2160.695197] [<ffffffff81073ceb>] worker_run_work+0x9b/0xe0 [ 2160.695860] [<ffffffff811c4890>] ? inode_wait_for_writeback+0x30/0x30 [ 2160.696723] [<ffffffff8106b2e3>] process_one_work+0x1e3/0x4f0 [ 2160.697559] [<ffffffff8106b61e>] worker_thread+0x2e/0x4b0 [ 2160.698251] [<ffffffff8106b5f0>] ? process_one_work+0x4f0/0x4f0 [ 2160.698850] [<ffffffff810700f5>] kthread+0xd5/0xf0 [ 2160.699369] [<ffffffff81070020>] ? kthread_worker_fn+0x160/0x160 [ 2160.699981] [<ffffffff81579fef>] ret_from_fork+0x3f/0x80 [ 2160.700547] [<ffffffff81070020>] ? kthread_worker_fn+0x160/0x160 [ 2160.701382] INFO: task SYNO.API.Auth.T:16585 blocked for more than 120 seconds. [ 2160.702204] Tainted: P OE 4.4.180+ #42214 [ 2160.702807] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 2160.703679] SYNO.API.Auth.T D ffff880235643c50 0 16585 10537 0x00000000 [ 2160.704476] ffff880235643c50 000000008182ed60 ffff880274970000 ffff8802643b8cc0 [ 2160.705284] ffff88025e54d760 ffff8802643b8cc0 ffff88025e54d764 00000000ffffffff [ 2160.706104] ffff88025e54d768 ffff880235643c60 ffffffff81576126 ffff880235643c70 [ 2160.706929] Call Trace: [ 2160.707196] [<ffffffff81576126>] schedule+0x26/0x70 [ 2160.707682] [<ffffffff815763b9>] schedule_preempt_disabled+0x9/0x10 [ 2160.708367] [<ffffffff81577b6c>] __mutex_lock_slowpath+0x8c/0x100 [ 2160.709101] [<ffffffff8119add9>] ? lookup_fast+0xc9/0x320 [ 2160.709633] [<ffffffff81577bf2>] mutex_lock+0x12/0x30 [ 2160.710157] [<ffffffff8119c8fb>] walk_component+0x21b/0x330 [ 2160.710773] [<ffffffff8119db24>] path_lookupat+0xb4/0x230 [ 2160.711384] [<ffffffff811a2d0a>] filename_lookup+0x9a/0x100 [ 2160.711974] [<ffffffff8117ca4d>] ? kmem_cache_alloc_trace+0x13d/0x150 [ 2160.712665] [<ffffffff811a2a23>] ? getname_flags+0x53/0x190 [ 2160.713253] [<ffffffff811a2e23>] user_path_at_empty+0x33/0x40 [ 2160.713815] [<ffffffff8118b0ff>] SyS_access+0x8f/0x2a0 [ 2160.714307] [<ffffffff81579c4a>] entry_SYSCALL_64_fastpath+0x1e/0x8e [ 2160.714866] INFO: task synoappnotify:16640 blocked for more than 120 seconds. [ 2160.715496] Tainted: P OE 4.4.180+ #42214 [ 2160.715977] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 2160.716882] synoappnotify D ffff880035693c60 0 16640 1 0x00000004 [ 2160.717741] ffff880035693c60 000000008119a7e5 ffffffff818114c0 ffff8802732ccc80 [ 2160.718576] ffff88025e54d760 ffff8802732ccc80 ffff88025e54d764 00000000ffffffff [ 2160.719414] ffff88025e54d768 ffff880035693c70 ffffffff81576126 ffff880035693c80 [ 2160.720268] Call Trace: [ 2160.720550] [<ffffffff81576126>] schedule+0x26/0x70 [ 2160.721168] [<ffffffff815763b9>] schedule_preempt_disabled+0x9/0x10 [ 2160.721904] [<ffffffff81577b6c>] __mutex_lock_slowpath+0x8c/0x100 [ 2160.722627] [<ffffffff81577bf2>] mutex_lock+0x12/0x30 [ 2160.723246] [<ffffffff811a0614>] path_openat+0x444/0x1a40 [ 2160.723882] [<ffffffff811e458a>] ? flock_lock_inode+0xda/0x280 [ 2160.724579] [<ffffffff811e47ee>] ? locks_remove_flock+0xbe/0xc0 [ 2160.725298] [<ffffffff811a390e>] do_filp_open+0x7e/0xc0 [ 2160.725897] [<ffffffff811ab2b1>] ? dput.part.25+0x91/0x200 [ 2160.726549] [<ffffffff811b1c6b>] ? __alloc_fd+0x3b/0x170 [ 2160.727187] [<ffffffff81189b4f>] do_sys_open+0x1af/0x240 [ 2160.727715] [<ffffffff8118bf3f>] SyS_openat+0xf/0x20 [ 2160.728242] [<ffffffff81579c4a>] entry_SYSCALL_64_fastpath+0x1e/0x8e [ 2160.728924] INFO: task SYNO.API.Auth.T:19202 blocked for more than 120 seconds. [ 2160.729745] Tainted: P OE 4.4.180+ #42214 [ 2160.730348] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 2160.731201] SYNO.API.Auth.T D ffff880231103c50 0 19202 10537 0x00000000 [ 2160.731980] ffff880231103c50 000000008182ed60 ffffffff818114c0 ffff88026c4f3300 [ 2160.732827] ffff88025e54d760 ffff88026c4f3300 ffff88025e54d764 00000000ffffffff [ 2160.733753] ffff88025e54d768 ffff880231103c60 ffffffff81576126 ffff880231103c70 [ 2160.734605] Call Trace: [ 2160.734819] [<ffffffff81576126>] schedule+0x26/0x70 [ 2160.735273] [<ffffffff815763b9>] schedule_preempt_disabled+0x9/0x10 [ 2160.735812] [<ffffffff81577b6c>] __mutex_lock_slowpath+0x8c/0x100 [ 2160.736580] [<ffffffff8119add9>] ? lookup_fast+0xc9/0x320 [ 2160.737218] [<ffffffff81577bf2>] mutex_lock+0x12/0x30 [ 2160.737791] [<ffffffff8119c8fb>] walk_component+0x21b/0x330 [ 2160.738406] [<ffffffff8119db24>] path_lookupat+0xb4/0x230 [ 2160.738980] [<ffffffff811a2d0a>] filename_lookup+0x9a/0x100 [ 2160.739615] [<ffffffff8117ca4d>] ? kmem_cache_alloc_trace+0x13d/0x150 [ 2160.740399] [<ffffffff811a2a23>] ? getname_flags+0x53/0x190 [ 2160.741083] [<ffffffff811a2e23>] user_path_at_empty+0x33/0x40 [ 2160.741734] [<ffffffff8118b0ff>] SyS_access+0x8f/0x2a0 [ 2160.742330] [<ffffffff81579c4a>] entry_SYSCALL_64_fastpath+0x1e/0x8e [ 2180.147079] <redpill/pmu_shim.c:324> Got 1 bytes from PMU: reason=1 hex={2d} ascii="-" [ 2180.297936] <redpill/pmu_shim.c:324> Got 1 bytes from PMU: reason=1 hex={75} ascii="u" [ 2180.298917] <redpill/pmu_shim.c:253> Executing cmd OUT_FAN_HEALTH_ON handler cmd_shim_noop+0x0/0x2d [redpill] [ 2180.298917] <redpill/pmu_shim.c:42> vPMU received OUT_FAN_HEALTH_ON using 1 bytes - NOOP
-
Is it normal that from 7.0 -> 7.0.1 also needs migration?
-
4 minutes ago, Aigor said:
I'v lost some updates, there is some recap to know "state of the art" of bootloader?
Thanksseems possibility of UEFI boot and 7.0.1. But need some customisation.
- 1
-
7 hours ago, jhoughten said:
How are you booting in UEFI? The image file has the MBR structure. I haven't seen anything about what changes need to be made to build a UEFI image.
I think he has enabled CSM.
RedPill - the new loader for 6.2.4 - Discussion
in Developer Discussion Room
Posted
A noob question. For every new loader image to test with, is it mandatory to migrate the entire system again?