Jump to content
XPEnology Community

tahitibub

Member
 View Profile  See their activity

  • Posts

    19

  • Joined

  • Last visited

 Content Type 

Posts posted by tahitibub

    Migration DSM 5.2 à 6.1 sur HP MicroServer GEN8 (Bare-Metal)

    in Compatibilité Hardware & Installation

    Posted · Edited by tahitibub

    Bonjour,

     

    Est-il possible de mettre à jour DSM 5.2 vers DSM 6.1 sur HP MicroServer GEN8 (Bare-Metal) en utilisant le dernier loader de Jun, disponible en version 1.02b ici ?

     

    Dans l'affirmative, quelle est la procédure à suivre (de manière très synthétique) pour effectuer cette mise à jour sans risque ?

     

    Enfin, est-il préférable d'attendre la disponibilité du loader de QuickNick pour se lancer dans cette démarche ?

     

    Merci

    HP ProLiant MicroServer Gen8 G1610T

    in Compatibilité Hardware & Installation

    Posted

    Bonjour avez vous un lien vers la dernière version du bios ? L'iso dans le thread en lien n'est pas la bonne version. Si un ame charitable arrive a se connecter chez Hp pour telecharger la dernière version.....

     

    Merci

     

    Bonne journée à tous

     

    Bonjour,

     

    Voici un lien magnétique vers le torrent de la dernière version du service pack connue à ce jour, le "Service Pack for ProLiant (SPP) Version 2016.10.0" :

     

    magnet:?xt=urn:btih:a5e1c453f10d9fb95677a6c2e796fffe0ad6189c&dn=871790_001_spp-2016.10.0-SPP2016100.2016_1015.191.iso&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Fopentor.org%3A2710&tr=udp%3A%2F%2Ftracker.ccc.de%3A80&tr=udp%3A%2F%2Ftracker.blackunicorn.xyz%3A6969&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969

     

    Je n'ai pas testé cette image ISO, mais sa somme de contrôle MD5 correspond à celle donnée sur le site HP (à savoir : 3e93873632c5758666c5b1c305d557ea).

     

    Merci de votre retour si vous la testez.

     

    Autres liens (non testés) :

    http://ddl7.digiboy.ir/871790_001-spp-2 ... 15.191.iso

    http://ddl4.digiboy.ir/871790_001-spp-2 ... 15.191.iso

    http://ddl6.digiboy.ir/871790_001-spp-2 ... 15.191.iso

    XPEnology Developers contact me for 7393 kernel src code

    in Developer Discussion Room

    Posted

    I got the impression the source code was just released to quicknick, and not yet to the public in general, so I don't know the exact conditions under which that happened (NDA? Or why just to him, while everyone and their dog have been asking for the same?). But if quicknick feels it's safe, by all means, share! :smile:

     

    How to be sure it's safe if it isn't publically shared by Synology itself ?

    However this is a good news, but I advise the developpers to check the conditions under which the code has been shared.

    Working DSM 6

    in Loaders

    Posted

    FYI: I have written an email to Synology due to the release of source code of DSM6. I cannot post the original answer here, but the core message is as follows:

     

    - DSM 6.0.2 will be available in the coming weeks

    - DSM 6.0.2 will be the candidate for the DSM GPL source

    - It is expected to be released around early Q4 this year

     

    I think this is pretty good news for you, guys! Let's hope the DEV team will start their work as soon as the source is available. I will be happy to contribute, someone of the DEV team please contact me via PM.

     

    That's a very good news, thanks !

    Working DSM 6

    in Loaders

    Posted

    Many thanks to oktisme for providing this. I was able (new to vmware) to get this working as described, with 2x2TB virtual drives on a 6TB USB my book drive using jbod.

    Also have a second nic on my windows PC that is used by the VM in Bridged mode allowing other hosts on my network to access the VM. Very useful for testing anything under

    DSM 6. Very well done and I am impressed as it's very stable.

     

    mrbasic1

     

    Hi,

     

    The forum thread is very long now (20 pages).

     

    Could you make a deteiled tuto on how to do it, using latest tips ?

     

    Is it possible to make it work on a Gen8 Microserver (with Vtd capable CPU) ?

     

    Regards

    XPEnology + DSM 6

    in Archives

    Posted · Edited by Guest

    Salut Korben,

     

    En attendant la nouvelle (et hypothétique) version d'XPEnoboot, il semble que certaines personnes ont réussi à faire tourner DSM 6 en virtualisation.

     

    Au cas où tu ne l'aurais pas vu, le fil de discussion est disponible ici.

     

    Après, je n'ai jamais installé ESXi mais je suppose que cela implique une mise à niveau processeur.

     

    Ça tombe bien, je viens de recevoir un i5 compatible avec le Gen8 ...

     

    NB : et bravo pour ton blog, véritable mine d'infos "geek" que je consulte régulièrement.

     

    @+

    Annoying BIOS reset issue is really bugging me!!!

    in DSM 5.2 and earlier (Legacy)

    Posted

    This is a disk image of my pen drive (512MB SD card). Plz try if it works or not: https://drive.google.com/file/d/0Bwkmhb ... sp=sharing

     

    This file is created by:

    1. Download Synoboot: https://github.com/Jman420/nanoBoot-DSM ... 3612xs.img

    2. Write the file to pen drive.

    3. Expand the partition and filesystem to ~100MB. Expansion of ext filesystem is way easier than FAT, and that is one of the reasons why I choose Synoboot.

    4. Replace zImage with *ORIGINAL* XPEnology 5.6-5644.5 one.

    5. Compress modified ramdisk (with synobios.ko hax) with gzip as rd.gz

    6. Add initrd parameter in /boot/grub/grub.conf.

    7. dd if=/dev/sdX of=img

     

    Hi,

     

    I finally used your disk image.

     

    I had to change my settings with this command (ubuntu) :

     

    sudo nano '/media/***/boot/grub/grub.conf'

     

    Everything seems to works for the moment.

     

    Regards

    Annoying BIOS reset issue is really bugging me!!!

    in DSM 5.2 and earlier (Legacy)

    Posted

    Hi,

     

    it works for HP MicroserverGen8. All credits go to updateing!

     

    #Link

    http://www54.zippyshare.com/v/6ktoFqSp/file.html

     

    #to load the modified vmlinux place the rd.gz next to syslinux.cfg on your bootstick and change syslinux.cfg

    # from

    APPEND root=/dev/md0 ihd_num=0

    # to

    APPEND root=/dev/md0 initrd=rd.gz ihd_num=0

     

    ######## Helpful commands ########

     

    #mount bootdrive in ssh session

    #!/bin/sh

MOUNT_FOLDER="/root/boot"

mkdir -p ${MOUNT_FOLDER}
LOOP_DEVICE="$(losetup -f)"
losetup -o 32256 ${LOOP_DEVICE} /dev/synoboot
mount -t vfat ${LOOP_DEVICE} ${MOUNT_FOLDER}

     

    #unmount bootdrive

    #!/bin/sh

umount /root/boot
losetup -d /dev/loop0
rmdir /root/boot

     

    # And for the HP Microserver Gen8 users, with this you can change DSM to only see the 4 really existing hdd drives and not the other dummy ones

    #in /etc.defaults/synoinfo.conf
#no esata ports
esataportcfg="0x0"
#4 sata ports
internalportcfg="0xf"
#6 usb ports (2 front and 4 back)
usbportcfgo="0x2f0"

     

    Hi,

     

    I tried to copy the rd.gz next to syslinux.cfg on my bootstick, which has a Fat16 File System, but it has not enough free space.

     

    So, I tried to allow more space with Gparted, but I got this error : "File system doesn't have expected sizes for Windows to like it. Cluster size is 2k ..."

     

    Could you help me ?

     

    Regards

    Annoying BIOS reset issue is really bugging me!!!

    in DSM 5.2 and earlier (Legacy)

    Posted

    So here is what I thought and did...

     

    From the discussion pages before, we can infer that the BIOS resetting has something to do with the time setting. And from my NanoBoot build tests we know that synobios.ko is the suspect. So I digged into this file.

     

    0. Extract vmlinux from zImage from XPEnoboot, then extract ramdisk cpio in the vmlinux (why does XPEnology packs the ramdisk with vmlinux?)

     

    1. Extract synobios.ko from ramdisk. Load the file in IDA, and search for time related functions in the function window.

     

    2. There is an imported function named rtc_cmos_write, which fits our demand perfectly: time-related(RTC), operates with hardware(cmos_write) (Actually this is an exported function in common Linux kernel) So I decided to remove all calls to this function in order to block writing to the RTC.

    bgbmn8.png

     

    3. List all the cross references to rtc_cmos_write. This is the common procedure for a call:

    t9cbxk.png

    l8z81.png

    We need to replace all these calls including argument passing procedure with NOP(0x90), which instructs the processor to do nothing when we reach here.

     

    4. However, the file looks like this in WinHex: (IDA's Hex View is not showing original file)

    5yyg.png

    [updated 2016/03/10: Wrong mark on the WinHex side]

    This is due to the kernel modules are relocatable. The actual jumping address will be filled during runtime, and there is only a stub after the "call" instrcution. So we need to stop the "address filling".

     

    WARNING! Byte offset is different from the instruction offset shown in IDA. You can find the actual byte offset at the bottom left corner of IDA's Hex View. Byte offset should be used for "Navigation -> Goto Offset" in WinHex.

     

    5. ELFs use relocation tables for this. Each item in the table tells the linker where we should fill and what to fill with. However I don't know where the table is placed, and all I can do is to search the address of the stubs. The following picture is search results of the first stub (at 0x0000000000003820, presented as 0x2038000000000000 in little-endian)

    m76ezm.png

    This means the stub at 0x0000000000003820(2nd byte of "call rtc_cmos_write" in rtc_correct_wday) will be replaced with rtc_cmos_write's actual address at runtime.

    There are a bunch of these stubs which refers to rtc_cmos_write. Since the function rtc_correct_wday looks harmless, let's replace all references to other stubs to the one in this function, 0x0000000000003820. As those stubs won't get filled, we can continue using NOP to skip them.

     

    For example, there is "call rtc_cmos_write" in rtc_bandon_rotate_auto_poweron at 0x38c7 and the jumping target address stub begins at 0x38c8 (zeros omitted), then we search for 0xc838

    2qaspaa.png

    and change it to 0x2038.

    120hyc9.png

    Do the same for all other stubs in rtc_cmos_write calls. Be careful! Don't leave out any reference to the stubs.

     

    Note: all addresses mentioned in step 5 is IDA's instruction address. But since we are searching for hex values, we won't use Goto Offset menu so don't worry about the byte offset.

     

    6. Now, relocation won't interfere with our changes about NOP'ping the "call" instrcutions. It's time to change all bytes shown in step 4 to 0x90. Remember, we are not NOP'ping the one in rtc_correct_wday.

     

    For example, we are removing the "call rtc_cmos_write" at 0x38c7 (0x3937 for byte offset, use Goto Offset menu).

    The disassembly looks like this:

    hx94pu.png

    Change like this: (the argument calculating and passing procedure took a bit more (4) instructions...)

    35dawlc.png

    Then the disassemnly should be like this:

    33z347a.png

    Do the same for all other calls to rtc_cmos_write.

     

    Note: if you don't know how to determine where the argument passing procedure starts, just ignore it and NOP the call instruction (0xE8 and 4 following bytes). It may work...

     

    7. You are all set now. Put the modified file back into the cpio archive, copy to your boot disk, and let Grub load this archive as initrd to override the one inside zImage. If you encounter "No space left" error, you can try resizing the partition and filesystem.

     

    @updateing

    Could you publish your modified version of XPEnoboot ?

×
×
  • Create New...