WiteWulf

Yeah, but the free license doesn't support 24-way SMP

Yeah, I think I need a full enterprise license for virtual serial ports The license it has on it was a bundled one that came with some Cisco UC stuff I was working on years ago.

Damnit....I have a "spare" ESXi host at work with 64GB and 12 XeonE5-2680 v3 cores in it that would make a lovely xpenology machine, but it's got a crappy "Foundation for Embedded OEMs" ESXi license on it that doesn't allow virtual serial ports on it 😡

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....

Oh my word, that was ridiculously quick and easy! That's gonna make testing new images a whole lot simpler. I've now got a virtual 918+ running in VMware Fusion on my iMac *edit* Wow, I've got to get my Gen8 migrated to ESXi, it's *so* much quicker to reboot, if nothing else!

Installing a 918+ image now 👍

Trying to figure out how to get networking running on VMware Fusion now. It seems @Amoureux has already done some good work on this, but my Russian(?) is non-existent

Yeah, that worked!

@Orphée I wonder if that works on VMware Fusion? 🤔

Ah, okay, you didn't mention the LSI controller previously. Please include as much information as you can either in your signature or on every request for help you post. I don't have an HBA, though, so I'm afraid I'm unable to help further...

I thought you were running baremetal on Gen8 Microserver? You don't need to load the SAS drivers for the onboard AHCI controller, it's SATA and supported natively.

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.

I'm going to mark this thread/question as answered, but as it's a combination of all the different responses I can't mark any one of you as having answered the question, sorry!

@Mixpower sorry, catching up posts in order I've editted my original post above.

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):

Try swapping the com ports in bios settings.

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?):

bnx2x is 10GbE, isn't it? I think the Gen8's onboard NIC uses tg3.ko, but I've not successfully tested this myself.

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.

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!!!

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.

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)

You need a new boot image created with the matching DSM version for each released DSM version. You cannot reuse a boot image across different DSM versions.

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

Looks like we're getting somewhere: https://github.com/RedPill-TTG/redpill-lkm/issues/21#issuecomment-932808905