
Mitt27
Member-
Posts
31 -
Joined
-
Last visited
Recent Profile Visitors
The recent visitors block is disabled and is not being shown to other users.
Mitt27's Achievements

Junior Member (2/7)
1
Reputation
-
would this allow me to enable push notifications on things like surveliance station?
-
Hi, I have followed the steps but I am trying to move from baremetal to esxi 6.7 install, I get as far as manually installing the pat file but now I am stuck in a loop where it just says the system is recoverable, each time I go through the recovery process I end up back at the same point. Has anybody had a similar experience or any ideas on what I could try to resolve the problem? Thanks
-
Yes I am using 1.02b at the minute but that is booting in uefi mode, same thing happens with my other usb drive with 1.02b if I disable this and use legacy boot. I have gave this another try but same result unfortunatley Can I use uefi boot with 918+ or is it across the board for this release that needs to be booted in legacy? I am using an AMD FX770k which is socket FM2+ (piledriver) so might give this a try if its uefi compatible.
-
So I have hit a bit of a brick wall, I tried to create a new bootable usb using both win32diskimager and rufus using your latest 6.2.3 extra.lmza and the zImage and rd.gz from the latest DSM 6.2.3. The issue I have is that if i leave uefi boot enable in the bios I get as far as the boot loader but it is not found in find.synology, if I disable uefi boot I just end up a blank screen without even seeing the boot loader screen. Do you have any ideas on anything else I can try or maybe point out where I could be going wrong? The usb device name in the bios is KingstonDataTraveler G3 1.00 in case that helps
-
ok thanks will give it another try, assume I can just use the standard 1.03b bootloader and not worry about your additional steps for copying the kernal from dsm or do I still need to so that? I was getting as far as the bootloader menu and was able to select the first option but it just wouldnt go on to show in find.synology, is there maybe a way to see whats going on once the boot loader is running or does the screen just stop refreshing like it says on the screen? thanks
-
Hi, Yes thats correct its an old oem build that I was able to repurpose for a bare metal install and it has been going strong for some 5 years or so. I have copied the output below, thats very much for taking a look. Matt@DiskStation:/$ lspci -k 0000:00:00.0 Class 0600: Device 1022:1422 Subsystem: Device 103c:2b17 0000:00:02.0 Class 0600: Device 1022:1424 0000:00:02.1 Class 0604: Device 1022:1425 Kernel driver in use: pcieport 0000:00:03.0 Class 0600: Device 1022:1424 0000:00:03.4 Class 0604: Device 1022:1426 Kernel driver in use: pcieport 0000:00:04.0 Class 0600: Device 1022:1424 0000:00:10.0 Class 0c03: Device 1022:7814 (rev 09) Subsystem: Device 103c:2b17 Kernel driver in use: xhci_hcd 0000:00:10.1 Class 0c03: Device 1022:7814 (rev 09) Subsystem: Device 103c:2b17 Kernel driver in use: xhci_hcd 0000:00:11.0 Class 0106: Device 1022:7801 (rev 40) Subsystem: Device 103c:2b17 Kernel driver in use: ahci 0000:00:12.0 Class 0c03: Device 1022:7807 (rev 11) Subsystem: Device 103c:2b17 Kernel driver in use: ohci_hcd 0000:00:12.2 Class 0c03: Device 1022:7808 (rev 11) Subsystem: Device 103c:2b17 Kernel driver in use: ehci-pci 0000:00:13.0 Class 0c03: Device 1022:7807 (rev 11) Subsystem: Device 103c:2b17 Kernel driver in use: ohci_hcd 0000:00:13.2 Class 0c03: Device 1022:7808 (rev 11) Subsystem: Device 103c:2b17 Kernel driver in use: ehci-pci 0000:00:14.0 Class 0c05: Device 1022:780b (rev 16) Subsystem: Device 103c:2b17 0000:00:14.2 Class 0403: Device 1022:780d (rev 01) Subsystem: Device 103c:2b17 0000:00:14.3 Class 0601: Device 1022:780e (rev 11) Subsystem: Device 103c:2b17 0000:00:14.4 Class 0604: Device 1022:780f (rev 40) 0000:00:14.5 Class 0c03: Device 1022:7809 (rev 11) Subsystem: Device 103c:2b17 Kernel driver in use: ohci_hcd 0000:00:18.0 Class 0600: Device 1022:141a 0000:00:18.1 Class 0600: Device 1022:141b 0000:00:18.2 Class 0600: Device 1022:141c 0000:00:18.3 Class 0600: Device 1022:141d 0000:00:18.4 Class 0600: Device 1022:141e 0000:00:18.5 Class 0600: Device 1022:141f 0000:01:00.0 Class 0300: Device 10de:1380 (rev a2) Subsystem: Device 3842:3753 0000:01:00.1 Class 0403: Device 10de:0fbc (rev a1) Subsystem: Device 3842:3753 0000:02:00.0 Class 0200: Device 10ec:8168 (rev 0c) Subsystem: Device 103c:2b17 Kernel driver in use: r8168 0001:00:02.0 Class 0000: Device 8086:6f04 (rev ff) 0001:00:02.2 Class 0000: Device 8086:6f06 (rev ff) 0001:00:03.0 Class 0000: Device 8086:6f08 (rev ff) 0001:00:03.2 Class 0000: Device 8086:6f0a (rev ff) 0001:00:1f.0 Class 0000: Device 8086:8c54 (rev ff) 0001:00:1f.3 Class 0000: Device 8086:8c22 (rev ff) 0001:06:00.0 Class 0000: Device 1b4b:1475 (rev ff) 0001:08:00.0 Class 0000: Device 1b4b:9235 (rev ff) 0001:09:00.0 Class 0000: Device 8086:1533 (rev ff) 0001:0c:00.0 Class 0000: Device 8086:1533 (rev ff) 0001:0d:00.0 Class 0000: Device 8086:1533 (rev ff) Matt@DiskStation:/$
-
Just a quick update any for anybody else that has a similar issue the following appears to have brought the volume back: sudo btrfs check --init-extent-tree /dev/md2 Thanks again for all your help.
-
Great thank you for your help will give that a go!
-
The output from dmesg seems to allude to some corruption and invalid superblock, is the next step to just attempt a repair?
-
-
So my system booted up this morning as per its schedule but immediately I was welcomed by a volume crash notification, the system has been stable for around 5-6 years with only 1 drive failure ever occurring last year. I have had a look around the forum but cant find any examples that help me troubleshoot my exact issue and I don't want to just blindly head off trying things as if possible I need to recover the data. I have included some screenshots below of storage manager along with a few commands I ran on the command line. Any help would be greatly appreciated as I am drawing a bit of a blank having never encountered anything like this in the past.