Leaderboard

Да завсегда на здоровье .... )))

Should we be concerned? Long term, with the intermediate updates not working? (assuming we already have backups and have all the functionality we need) Define concern? Is there anything that can be done with 6.2.4 that cannot be done with 6.2.3? The assumption has always been is that any update has the possibility of breaking the loader. Could DSM 6.2.3-25426 Update 3 possibly be the last safe Xpen Version for us using Jun's Loaders? Maybe. Is Jun still kicking around to come up with a possible solution? Or anyone else? Jun is the only one that can answer that question. My guess is that if they are at all interested in keeping XPe alive, they will be focusing on DSM 7 and not a minor "last-of-the-line" patch on a DSM version that already works quite well. How often in the past have 2 consecutive updates failed right out of the gate like the latest intermediate updates have? 25554 and 25556 are in fact the same update. Updates either work, or they don't. Is there any particular reason, such as a major OS change, or Synology wanting to rid us "Open Sourcers" of this beautiful software, that is causing these updates not to work? I am sure Synology would prefer that we do not use DSM in this way. They probably consider DSM as entirely their IP even though it is derived from GPL-licensed open source. They could probably set up a Secure Boot solution that would probably shut DSM to us forever. But that would also limit backward compatibility with the hundreds of thousands or millions of units they have shipped up until now, and probably interfere with any cloud service/virtualization plans they have in the wings. So I don't think that this or the other issues that have been worked through in the past to be a result of an "anti-XPe" effort on the part of Synology. Just to be clear, DSM 6.2.3 "broke" the loader. FixSynoboot corrects the failure without modifying or updating the loader. We have also had problems with PCI hardware compatibility, and were able to work through solutions. Other than the irrational FOMO, I'm not clear why getting 6.2.4 working is anyone's priority at this point. Personally, I'm far more interested in DSM 7.

I thought I'd post here, not seeing a thread explaining what the deal is with the latest intermediate updates failing and so few people testing them, my curiosity got the best of me, unless i'm just missing something completely, which has been known to happen. 😉 Though not the newest member, I've been on Xpen 2 years maybe? I do have some noob-type questions since noticing the two latest updates failing, and not seeing a lot of discussion of it. In my short time here I cannot recall new updates like 25554/25556 failing so quickly, and it does concern me. But again, I'm relatively new. And I'm sure this isnt the first time this has happened, where Jun or others have had to fix loaders MY HW 2x Identical Baremetal DS918+ Xpen's 1.04b With Gigabyte B360-hd3's I3-8100's both working fantastically on DSM 6.2.3-25426 Update 3 My questions regarding this are: Should we be concerned? Long term, with the intermediate updates not working? (assuming we already have backups and have all the functionality we need) Could DSM 6.2.3-25426 Update 3 possibly be the last safe Xpen Version for us using Jun's Loaders? Is Jun still kicking around to come up with a possible solution? Or anyone else? How often in the past have 2 consecutive updates failed right out of the gate like the latest intermediate updates have? Is there any particular reason, such as a major OS change, or Synology wanting to rid us "Open Sourcers" of this beautiful software, that is causing these updates not to work? Have Xpen users been migrating to alternatives to Jun's loader or other solutions noobs may not be aware of? if so what's out there for Baremetal?

Это работает на разных уровнях. Сильно упрощая примерно так: Шлюз работает на уровне сетевого (несущего) протокола IP, а ftp, torrent и пр. на уровне сессий и приложений (TCP/UDP). Можно перенаправить на разные шлюзы с помощью маршрутизации или статических маршрутов только направление на разные сети-хосты, но все TCP/IP протоколы вместе, а не отдельные подварианты. То есть можно указать маршрут на конкретный ftp сервер через другой шлюз, но все остальные подключения к этому хосту SMB, IPP, RDP, HTTP, NFS и пр. тоже будут направлены по этому маршруту. У торрента конечный адрес подключения зарание не известен и все пакеты идут через шлюз по умолчанию - default gateway.

https://xpenology.com/forum/announcement/26-dsm-624-25554-intermediate-update/ https://xpenology.com/forum/announcement/27-dsm-624-25556-intermediate-update/

Он выбран по умолчанию. В новой версии переименовали.

хм.. а где такой режим ?

Well the folder "/var/lib/vz" should be there. If not, create it

Some people *claims* that this can be done with Unraid.

Если какие то проблемы по Обновлении, к слову, у меня при обновлении тоже система заглючила, то возможно имеет смысл снести /etc.defaults 1. Удалить папку /etc.defaults . Необходим так называемый ROOT доступ https://www.synology.com/ru-ru/knowledgebase/DSM/tutorial/General_Setup/How_to_login_to_DSM_with_root_permission_via_SSH_Telnet 2. Перезагрузить Хрень и установить DSM заново 3. Восстановить конфигурацию из *.dss . До всех манипуляций, Обязательно сохранить резервную копию настроек 4. Установить необходимые приложения, настройки должны сохраниться. 5. Радоваться Жизни и Хрени ...))))

Получилось зашить MAC с помощью этой програмульки. Хотя у меня Realtek совсем древний - RTL8111B. Вощем для одной сетевушки просто пишем: pg8136.exe /efuse /barmac /# 1 После запуска прога сама попросит ввести новый MAC, который вводим без пробелов. Но при попытке авторизации на синоакаунте DSM хрени все так же вываливает неизвестную ошибку.

pretty sure you will not be the last download a rescue/live linux like system rescue cd (i used a "older" version 6.0.3, mdadm and lvm worked ootb, any newer should be fine too), transfer it to a usb (not your dsm boot usb) to boot from it assemble your raid1 system partition like here (1st partitions of all disks as /dev/md0) skip anything about swap or volume1 data partition, we only need access to the dsm system partiton https://xpenology.com/forum/topic/7004-tutorial-how-to-access-dsms-data-system-partitions/ mount the assembled raid1 to /mnt with this mount /dev/md0 /mnt then remove some files with this rm -rf /mnt/SynoUpgradePackages rm -f /mnt/SynoUpgrade.tar rm -f /mnt/SynoUpgradeindex.txz rm -f /mnt/SynoUpgradeSynohdpackImg.txz rm -f /mnt/checksum.syno rm -f /mnt/.syno/patch/* and shutdown the linux shutdown -h now now you will have to restore the kernel files on your boot usb to 6.2.3 (the udpate also replace files on the loaders 2nd partition) win10 can have some difficulties with mounting the 2nd partitons of the loader, so look here https://xpenology.com/forum/topic/29872-tutorial-mount-boot-stick-partitions-in-windows-edit-grubcfg-add-extralzma/ (it can also be done with linux but i have not tried what other tools will extract the kernel files but if you are familiar with linux you will find out https://xpenology.com/forum/topic/25833-tutorial-use-linux-to-create-bootable-xpenology-usb/) on 2nd partition delete all files except extra.lzma and extra2.lzma (if its 3615/3617 then its just extra.lzma) use 7zip to open "DSM_xxxxx_25426.pat" (dsm 6.2.3 install file, depends on you dsm type 3615/3617/918+) extract "rd.gz" and "zImage" and copy it to the 2nd partition of your xpenology usb <edit> the assumption here is you already had 6.2.3 before the 6.2.4 udpate try, if not you would use the kernel files from the *.pat of the 6.2.x you had installed as a example what could go wrong: if you had 6.2.2 and did 6.2.4 your extra/extra2.lzma on the loader where usually replaced with special ones made for 6.2.2, if you add 6.2.3 kernel files to the 6.2.2 extra/extra2 (drivers) then most of the drivers will not work as of the incompatibility with 6.2.1/6.2.2 with 6.2.0/6.2.3 if you are unsure about the extra/extra2 or you dsm version then use the original extra/extra2 from jun's loader (img file can be opened with 7zip, loaders kernel files and drivers in its extra/extra2 are 6.2.0 level) or use a extended version of the extra/extra2 made for 6.2.3 and use the kernel files of 6.2.3 if you had a older 6.2.x that would do a update to 6.2.3 </edit> put back your usb to the xpenology system, boot up, find it in network (i used synology assistant) and migrate to version 6.2.3 (aka reinstall 6.2.3) it will boot two times, one for 6.2.3, 2nd for 6.2.3_U3 (it will be downloaded automatically if internet connection is present) everything should be back to normal except patches like nvme ssd patch (or other stuff you patched after installing 6.2.3 that is not dsm update resistant) if that all works you i will make a new thread in the tutorial section because if synology starts offering 6.2.4 with the web update there will be more people asking for a fix to come back to 6.2.3 please comment on how to make it easier to follow, its just a short version i tried once if that sounds all to complicated then its still possible to use the other downgrade method (but you will loos all settings and end with a factory default DSM) https://xpenology.com/forum/topic/12778-tutorial-how-to-downgrade-from-62-to-61-recovering-a-bricked-system/

i'm about to fix this today by working on a new package with latest intel drivers, that should fix your problem looks like you will be the first beta tester, i will write you a message when i have something up and running my guess is this one wont help you as it contains my "old" 918+ extra/extra2 drivers