Bagpuss

Members
  • Content Count

    17
  • Joined

  • Last visited

Community Reputation

2 Neutral

About Bagpuss

  • Rank
    Newbie

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Somehow, C1E support in the BIOS had got re-enabled. I didn't make any changes in the BIOS, so I'm wondering if booting Ubuntu somehow affected it. All very weird. Going to try putting the Mellanox card back in now.
  2. Have tried clean bootloader. Only changes were to enter MAC and USB hardware ID. If I boot machine from an Ubuntu live USB drive, then the onboard ethernet works fine. It's really weird. :-(
  3. Hi All, I don't have a serial port on the N54L, so troubleshooting this is proving difficult. I've been running DSM 6.1.7-15284 update 2 with JUN'S LOADER v1.02b - DS3615xs for some time. No problems. I've just installed a ConnectX-2 MPNA-19 card, along with v4.9 of the extra.lzma, and this too was working. Both the internal ethernet, and the Mellanox worked fine, and could connect to my main PC. I was seeing both network interfaces and addresses in Synology Assistant. The 1Gig ethernet was on 192.168.0.x, and the Mellanox on 192.168.1.x. The Mellanox card was first running firmware 2.9.1000, so I updated it to 2.9.1200 by booting Ubuntu from a live USB stick and running the tools. This worked fine, and everything still worked. I then wanted to try out RDMA, which needs a newer firmware. I updated to the 2.10.720 firmware and rebooted into DSM. Now, none of the network interfaces works at all. Booting back into Ubuntu, and both interfaces work fine. I've also tried the Mellanox card in another PC, and it works fine. I've reverted the firmware on the Mellanox card back to 2.9.1200. Still no luck. I then removed the Mellanox card from the machine, modified grub.cfg back to one interface, and reverted to the stock extra.lzma. Still, no sign of the array in Synology Assistant. I then booted with 'Install' mode in the bootloader, and it still isn't being recognised by Synology Assistant, or attempting to get a DHCP lease. I've also tried booting into 'Install' mode with no disks inserted, and still nothing. I've run out of things to try, and was wondering if anyone had any suggestions? The next obvious thing to try is getting serial console working. Is there a recommended PCI-E card for this that will definitely work with Jun's loader? Would appreciate some links. I'm guessing I'll also need a USB to serial cable for my main PC. Any help would be much appreciated. Thanks, Andy.
  4. Bagpuss

    Hp n40l

    I've been using the 'Kamzata' BIOS on my MicroServers (N40L, N54L). It's based on a newer version of the BIOS, and enables a lot more options. It's been working fine on my machines for the last couple of years. Why not give them both a try, and see which one suits you best. You can download it here: https://www.bios-mods.com/forum/Thread-HP-Proliant-Microserver-AMI-BIOS-MOD?pid=75965#pid75965
  5. Hi All, Just wondering if anyone can point me in the right direction. I've been using XPEnology for a long time (since 4.2), and have always used SHR. This was mainly driven by cost concerns, as I had a mixture of disk sizes, and couldn't afford to upgrade them all at the same time. This hasn't caused me a problem up until now, as I've never re-created my volumes. Once SHR, always SHR it appears. I've gone from 4.2 -> 5.2 -> 6.1.7 on my MicroServer (N36L initially, then N54L following a hardware transplant). I've just been given another N54L, and thought I'd turn it into a XPEnology box. I've got 5 x 2TB drives on the shelf, so it seemed a good idea. I've done a fresh install of 6.1.4 using Jun's loader v1.02b, and stuck with an array type of DS3615xs (it's always worked perfectly in the past, so why change). This has lead me to realise that SHR is no longer supported on the 'Enterprise' grade models. I guess the assumption is that anyone who can afford the more expensive models will likely be able to afford to replace all the drives simultaneously. As I really want to have SHR support, then I'm assuming that the DS916 or DS918 are the array types I need to choose. Is that correct? From what I can see, that means using the DS916 emulation for the 1.02b loader, or DS918 for the 1.03a2 loader. Is that also correct? That brings up another question. The DS916 and 918 only seem to be 4-drive arrays. On my N54L, I've got 5 drives installed. Will the 5th drive be recognised, or is there a config change I can make to ensure that it is? Also, if I wanted to migrate my existing array from using DS3615xs emulation to DS918, is there a way to do this without losing data? Thanks, Andy.
  6. - Outcome of the installation/update: SUCCESSFUL - DSM version prior update: DSM 5.2-5967 Update 6 - Loader version and model: XPENoboot 5.2-5967.1 - DS3615xs - Installation type: BAREMETAL - Microserver N54L - Additional comments: System appears to boot fine on first reboot, but you get a message saying, "Abnormality detected on MicroServer. All volumes have been unmounted.". Upon a second reboot, the volume(s) mount and everything works okay.
  7. - Outcome of the update: SUCCESSFUL - DSM version prior update: DSM 6.1.4 15217 - Loader version and model: Jun's Loader v1.02b - DS3615xs - Installation type: Baremetal (HPE Proliant MicroServer Gen7 N54L) - Additional comments: Requires reboot
  8. For my N54L running 4.2, I made the following changes: internalportcfg="0x3f" 0000 0000 0011 1111 - 6 SATA esataportcfg="0x00000" 0000 0000 0000 0000 - 0 eSATA so for my USB ports, I have to get 0001 1111 1100 0000 usbportcfg="0x1fc0" This seems to work okay, and I believe is correct for the MicroServer, as compared to the defaults. I've not bothered to try these settings with 4.3, as it all just seems to work, but they'd probably still be appropriate.
  9. I've got 4.2 running on my N54L MicroServer, and 4.3 update 3 on my N36L. I haven't noticed any slowdown in transfer speed between them, or from any of my Windows or OSX clients.
  10. Yes. I've installed it on my N36L MicroServer, and it appears to work just fine. Andy. Hi Andy, I tried on my HP36L with Trantor 4.3 3810++ 1.0 and it's not working... update programs stop at 10% with and empty error windows (title: DSM Update, no text, only ok button). Any idea? Thanks! eman One difference I can see is that I'm running the v1.1 beta 2 of synoboot, which might make a difference. You might also ssh in as root, and look at the log files in /var/log. Check the messages file and synoupdate.log for any signs of a problem. If you've previously updated to update2, then you need to ssh in and delete the autoupd@te.info file before attempting the new update. Not sure what else to suggest.
  11. Yes. I've installed it on my N36L MicroServer, and it appears to work just fine. I did the following: 1) Download update using the DSM Update tool. 2) Create task that contains the following code: sed 's/flashupdateDeb/flashupdateDeb1/' /autoupd@te.info > /autoupd@te.info1 mv /autoupd@te.info1 /autoupd@te.info 3) Run this task manually. 4) Logged in as root, and verified that autoupd@te.info was modified correctly (which it was). 5) Clicked update button in DSM update. The MicroServer rebooted, but hung during bootup. The last message before the hang is: [ 0.288134] pci_root PNP0A08:00: ignoring host bridge window [mem 0x000d0000-0x000dffff] (conflicts with Adapter ROM [mem 0x000cf000-0x000d19ff]) I then power cycled the machine, and it all booted up just fine. I am running the v1.1 beta2 of synoboot, but I'm not sure if this is important. Hope that helps, Andy.
  12. I'm running 4.3-3810 with synoboot 1.1 beta 2 on my N36L MicroServer. The initial install went fine, and everything appeared to work. I then wanted to install update 2, and followed the procedure above. Unfortunately, I failed to notice that overnight, update 3 had been released, and so I ended up installing that instead. The procedure I followed was this: 1) Download update using the DSM Update tool. 2) Create task that contains the following code: sed 's/flashupdateDeb/flashupdateDeb1/' /autoupd@te.info > /autoupd@te.info1 mv /autoupd@te.info1 /autoupd@te.info 3) Run this task manually. 4) Logged in as root, and verified that autoupd@te.info was modified correctly (which it was). 5) Clicked update button in DSM update. The MicroServer rebooted, but hung during bootup. The last message before the hang is: [ 0.288134] pci_root PNP0A08:00: ignoring host bridge window [mem 0x000d0000-0x000dffff] (conflicts with Adapter ROM [mem 0x000cf000-0x000d19ff]) The contents of the autoupd@te.info before modification were: {"blNeedReboot":true,"buildnumber":3810,"configUpdate":true,"debDir":"/volume1//@smallupd@te_deb","flashupdateDeb":"flashupdate_4.3-3810-s2_all.deb","installDeb":["libsynocgi-bromolow-bin_4.3-3810-s1_all.deb","libdsm-bromolow-bin_4.3-3810-s1_all.deb","webapi-bromolow-bin_4.3-3810-s1_all.deb","webfm2-bromolow-bin_4.3-3810-s1_all.deb","dsm-bromolow-bin_4.3-3810-s1_all.deb","libsynosdk-bromolow-bin_4.3-3810-s1_all.deb","openssh-5.8p1-bromolow-bin_5.8p1-3810-s1_all.deb","synologrotated-bromolow-bin_4.3-3810-s2_all.deb","openssl-1.0.x-bromolow-bin_1.0.1e-3810-s2_all.deb","libsynosdk-bromolow-bin_4.3-3810-s2_all.deb","flashcache-bromolow-bin_1.0-3810-s2_all.deb","libsynoflashcache-bromolow-bin_4.3-3810-s2_all.deb","dsm-bromolow-bin_4.3-3810-s2_all.deb","synobackup-bromolow-bin_4.3-3810-s2_all.deb","lnxscemd-2.0-bromolow-bin_4.3-3810-s2_all.deb","samba-3.6.x-bromolow-bin_3.6.9-3810-s2_all.deb","openssh-5.8p1-bromolow-bin_5.8p1-3810-s2_all.deb","samba-3.6.x-bromolow-bin_3.6.9-3810-s3_all.deb","webfm2-bromolow-bin_4.3-3810-s3_all.deb","libsynosdk-bromolow-bin_4.3-3810-s3_all.deb","lnxsdk-bromolow-bin_4.3-3810-s3_all.deb","openssh-5.8p1-bromolow-bin_5.8p1-3810-s3_all.deb","dsm-bromolow-bin_4.3-3810-s3_all.deb","lunbackup-bromolow-bin_4.3-3810-s3_all.deb","synobackup-bromolow-bin_4.3-3810-s3_all.deb","apache-2.2.x-bromolow-bin_2.2.25-3810-s3_all.deb","apache-2.2.x-virtual-worker-bromolow-bin_2.2.25-3810-s3_all.deb","linux-3.x-bromolow-bin_4.3-3810-s3_all.deb"],"newSmallFixNumber":3,"smallupdateDeb":"smallupdate_4.3-3810-s3_all.deb","updateType":"smallupdate"} and after were: {"blNeedReboot":true,"buildnumber":3810,"configUpdate":true,"debDir":"/volume1//@smallupd@te_deb","flashupdateDeb1":"flashupdate_4.3-3810-s2_all.deb","installDeb":["libsynocgi-bromolow-bin_4.3-3810-s1_all.deb","libdsm-bromolow-bin_4.3-3810-s1_all.deb","webapi-bromolow-bin_4.3-3810-s1_all.deb","webfm2-bromolow-bin_4.3-3810-s1_all.deb","dsm-bromolow-bin_4.3-3810-s1_all.deb","libsynosdk-bromolow-bin_4.3-3810-s1_all.deb","openssh-5.8p1-bromolow-bin_5.8p1-3810-s1_all.deb","synologrotated-bromolow-bin_4.3-3810-s2_all.deb","openssl-1.0.x-bromolow-bin_1.0.1e-3810-s2_all.deb","libsynosdk-bromolow-bin_4.3-3810-s2_all.deb","flashcache-bromolow-bin_1.0-3810-s2_all.deb","libsynoflashcache-bromolow-bin_4.3-3810-s2_all.deb","dsm-bromolow-bin_4.3-3810-s2_all.deb","synobackup-bromolow-bin_4.3-3810-s2_all.deb","lnxscemd-2.0-bromolow-bin_4.3-3810-s2_all.deb","samba-3.6.x-bromolow-bin_3.6.9-3810-s2_all.deb","openssh-5.8p1-bromolow-bin_5.8p1-3810-s2_all.deb","samba-3.6.x-bromolow-bin_3.6.9-3810-s3_all.deb","webfm2-bromolow-bin_4.3-3810-s3_all.deb","libsynosdk-bromolow-bin_4.3-3810-s3_all.deb","lnxsdk-bromolow-bin_4.3-3810-s3_all.deb","openssh-5.8p1-bromolow-bin_5.8p1-3810-s3_all.deb","dsm-bromolow-bin_4.3-3810-s3_all.deb","lunbackup-bromolow-bin_4.3-3810-s3_all.deb","synobackup-bromolow-bin_4.3-3810-s3_all.deb","apache-2.2.x-bromolow-bin_2.2.25-3810-s3_all.deb","apache-2.2.x-virtual-worker-bromolow-bin_2.2.25-3810-s3_all.deb","linux-3.x-bromolow-bin_4.3-3810-s3_all.deb"],"newSmallFixNumber":3,"smallupdateDeb":"smallupdate_4.3-3810-s3_all.deb","updateType":"smallupdate"} Would really appreciate some insight into what I did wrong. I'm guessing that one of the changes in the update has broken XPenology (i.e. 1. Enhanced system security) Any help would be greatly received. Andy. [EDIT] I have now power cycled the server, and everything booted up and it running fine. Not sure what went wrong, but a cold restart has fixed the issue. Update 3 now up and running, and all appears to be fine.
  13. Installed 4.3-3810 with v1.1-beta2 of synoboot on a N36L MicroServer with 8GB ram and 5x3TB drives. Everything works fine out of the box (as far as I can tell). Only thing I've not yet tested is WOL. Massive thanks to everyone who has worked hard on this new release!
  14. Hi All, I'm sure that this question has been answered in the forum, but I'm currently unable to find it. When I try to search, I'm told that the phrase 'mac address' is too common. I guess it must be important, then. My current assumption is that the DSM builds here use a default MAC address and serial number (which seems to be derived from the MAC). This is presumably not the same as the MAC address on the underlying hardware. If this is so, then it's clear that you need to change this if you are going to run more than one system with XPEnology in the same LAN. I'm also thinking that there might be some kind of tie in with Synology network services, which rely on unique IDs to access the box from the big wide world. Can someone confirm this? So, that leads me to the real question. Given that the first three octets of a MAC identify the vendor, do I need to use a MAC from a Synology block? If so, I can't see any way to be sure that this is unique, which is a problem. Is it simply enough to modify the file to use the MAC address of my underlying hardware, and then derive the serial number from that? Any guidance would be much appreciated. Andy.