Jump to content
XPEnology Community

WiteWulf

Contributor
  • Posts

    423
  • Joined

  • Last visited

  • Days Won

    25

Posts posted by WiteWulf

  1. 3 minutes ago, altas said:

    You think is better as ESX host instead of Barmetal??

    Pros: flexibility, ability to host multiple guests on the same hardware, standardised drivers that are well supported by Synology, faster to reboot guests

    Cons: more complex, not easy to migrate if you're already on baremetal, run best with additional hardware (ie. SATA HBA)

     

    So, not better, different....

  2. 6 minutes ago, Mixpower said:

    @WiteWulfI did a migration which went fine and on boot all 4 drives seem detected but in DSM only one drive is detected for some reason.

    Is it possible to save this or start from scratch?

    I don't know, that's very strange. I've only heard this happening with additional SATA/SAS HBA cards installed. Go back to basics: check all the cables are connected internally, that the BIOS is seeing all drives, then have a look through the console output as it's booting up to see if there's anything obvious.

  3. 12 hours ago, Mixpower said:

    EDIT2: It just does this over and over and over, tried different usb ports but it does not matter it keeps doing this, I checked the VID and PID again and there are correct anyone has a clue?

     

    If I unplug the usbdrive and plug it back in it does this but then goes back to the same again.

     

    Glad you sorted out the serial port thing.

     

    Re. the USB, I can't see anything wrong there. All the mentions of devices with a VID of 0x03f0 are it testing HP devices inside your machine and it failing (as they don't match the VID/PID you specified), which is to be expected.

     

    It finally finds... 

    Device <vid=26bd, pid=9917>

    ...(an Integral Memory USB stick) and mounts the synoboot partitions.

     

    I've a feeling this may be fixed by the boot-wait extension when the extensions are up and running

     

    Catching up! I see you sorted the USB boot thing with another stick.

     

    FWIW, I had problems with the tg3 drivers pocopico has in his rp-ext repo on my baremetal Gen8.

     

    Try these instead (they work on my 7.0.1-42218 system with a 3.10.108 kernel):

     

    • Like 1
  4. 1 hour ago, WiteWulf said:

    bnx2x is 10GbE, isn't it?

     

    I think the Gen8's onboard NIC uses tg3.ko, but I've not successfully tested this myself.

    Confirmed:

    $ sudo insmod libphy.ko
    Password:
    [ 1441.477154] WARNING: module 'libphy' built without retpoline-enabled compiler, may affect Spectre v2 mitigation
    $ sudo insmod tg3.ko
    [ 1457.964161] tg3.c:v3.132 (May 21, 2013)
    [ 1457.996728] tg3 0000:03:00.0 eth2: Tigon3 [partno(N/A) rev 5720000] (PCI Express) MAC address 00:11:32:11:22:33
    [ 1458.047412] tg3 0000:03:00.0 eth2: attached PHY is 5720C (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1])
    [ 1458.096052] tg3 0000:03:00.0 eth2: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[1] TSOcap[1]
    [ 1458.134917] tg3 0000:03:00.0 eth2: dma_rwctrl[00000001] dma_mask[64-bit]
    [ 1458.177824] tg3 0000:03:00.1 eth3: Tigon3 [partno(N/A) rev 5720000] (PCI Express) MAC address 00:11:32:11:22:33
    [ 1458.227580] tg3 0000:03:00.1 eth3: attached PHY is 5720C (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1])
    [ 1458.276282] tg3 0000:03:00.1 eth3: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[1] TSOcap[1]
    [ 1458.314943] tg3 0000:03:00.1 eth3: dma_rwctrl[00000001] dma_mask[64-bit]

     

    Using the drivers you posted here (which I think may have originally come from labrouss?):

     

    • Thanks 1
  5. Yes, I agree that it's not a viable long-term solution. I also tried increasing the watchdog threshold to a higher value and, while the kernel panics took longer to occur (matching the increased timer value), they still happened eventually. I hadn't tried disabling it altogether before, though.

     

    As you say, let's wait and see. Hopefully these developments will lead to a more sustainable solution.

  6. With the recent commits to redpill-lkm it looks like the soft lockups on virtualised systems are now solved, but hard lockups on baremetal are still a problem.

     

    TTG theorise that this could be down to "an over-reactive kernel protection mechanism", namely the NMI watchdog. The NMI watchdog exists (among other things) to automatically reboot a linux machine if it gets hung up for some reason. Unfortunately it appears to be falsely identifying kernel hangs on baremetal with DS3615xs image.

     

    A workaround is to disable the NMI watchdog, but this is not recommended and you should understand the implications of taking this step before applying it to your system. Having said that, I've been running my system for a few days now with it disabled and it has been very stable. YMMV!!!

  7. 30 minutes ago, Rebutia said:

    Hi WiteWulf, just a quick question, is it because of the change in DSM6/7 that we can no longer see console booting message like what we did in the DSM5 xpenology loader? No I am not urging anybody to include this nostalgic function, just curious, and it also seems to be easier for debugging.

    I honestly can't remember that far back :) , did we used to have console output to the screen? Was that in the xpenoboot days? I don't think there's been console output to the screen at all since we moved to Jun's bootloader.

     

    To be honest, I find it *much* easier to debug with a virtual serial port via the iLO on my HP MicroServer, but I appreciate that not everyone has such hardware.

  8. 22 hours ago, Schyzo said:

    Hmm, you're right, sorry for that.

    Server boot on the USB, and display exactly that.

    No problem, it's just when reporting problems or asking for help it's in everyone's interest to be as precise as possible in the initial report.

     

    "Booting" or "bootstrapping" (to use the old fashioned term) usually refers to the very first stage of loading code from a storage device once the BIOS has loaded. If you get as far as the "Booting the kernel." message your system has booted. It may not have successfully finished loading an operating system, but it's *booted* ;) 

     

    What a lot of people are incorrectly assuming (and this bears repeating) is that when they see the "Booting the kernel." message, and nothing else follows, that the system has failed to boot. The Synology kernel has no video drivers or framebuffer in it (as "real" Synology devices don't have a video card or display connected), so the console output is all sent to serial console (virtual or physical) one the kernel is loaded. You will not see anything else on screen after this point.

     

    If you have connectivity issues after this point (you don't see the system requesting a DHCP lease from your network or the Synology finder tool fails to locate your new system) the chances are that the NIC you're using isn't supported by the default image build. You either need to load the relevant drivers or get a NIC that's supported by the default build.

     

    (I appreciate you've already figured out this last bit, @Schyzo, but was posting this for the benefit of others who may be in this situation as it pops up regularly on here)

    • Like 5
  9. 57 minutes ago, mpuff said:

    my micro gen8 does not boot from the stick that i have created with the tool, vid pid set correctly, mac address added and a serial number that i used at juns loader, i see than it tries to boot from PXE.

    is there legacy boot allowed? i can see on the stick it is UEFI i think?

    Set the first partition as active using fdisk after you’ve written the image to the stick. Gen8 is picky about usb boot sticks.

×
×
  • Create New...