kmx236

Т.е. я правильно понимаю, что предположение о наличии связи между серийным номером и мак-адресами, влияющее на регистрацию в Synology accaunt и использование Quickconnect, не подтверждается?

Просит ключ дешифрования какой-то Извиняюсь. Действительно забыл

Нашлось время на нормальную переделку генератора. Что нового: Качаем тут, т.к. какого-то черта "Достигнут максимальный общий размер ваших вложений" при отсутствии коих как таковых. Ключ дешифрования для скачивания: !t-bczbJJwbHEBlsuTC_eb16Ijzaumd5Nls62fkIBqdw P.S. Я особо не следил за тем как вообще развивается тема генерации валидных серийных номеров и MACов на данном сайте и потому не в курсе, может кто-то уже сделал программу или скрипт по аналогии с моим генератором. Ну так как я его делал для себя, то вопрос о его использовании - это ваше личное дело. И еще, говорят что есть какая-то связь между серийным номером и маком, я это не проверял, т.ч. как всегда "на свой страх и риск". В файле всё также используется скрипт для кнопки генерации, просто мне так удобнее.

Хоть и прошло ровно девять месяцев, всё же отпишусь о решении своей проблемы. Короче. Ничего не помогло. Ни проверки поверхности диска и различные диагностики, не замены загрузчиков и переустановка разных версий DSM, ни поиск параметра в системных потрохах DSM (хотя я уверен что плохо искал, ведь он наверняка есть). В итоге пришлось делать то, чего не особо-то и хотелось, т.е. переносить все данные на вновь созданный раздел.

День добрый. Есть HP Microserver N54L c VMware vSphere ESXi 5.1 и несколько виртуалок на ней, включая и XPEnology на базе XPEnoboot_DS3615xs_5.2-5592 и DSM 5.2-5592. Подскажите кто в курсе, по какой причине возможна загрузка ЦП на VMware стабильно на 500МГц без явной нагрузке на неё? У меня у самого есть пара мыслей: 1. Возможно на установленной версии DSM (DSM 5.2-5592) есть фоновые процессы которые не отображаются в таскменеджере, или того хуже - левый процесс никак не связанный с XPEnology, ну предположим, что-то типа майнера для биткоинов. 2. Дело может быть в загрузчике (XPEnoboot_DS3615xs_5.2-5592). Возможно в нем протекают какие-то процессы. Как всё же узнать, что именно поедает часть ЦП, ведь если посмотреть на нижнюю часть скрина из VMware, то можно увидеть, что другие виртуалки (на винде и убунте) потребляют не более 100Мгц? Первая строчка с 840Мгц - это сама VMware. Что скажете, Господа?

Что-то я не очень понял. Можно чуть подробнее?

И тут я понял свой косяк Мне же проверять надо не md0, а /dev/vg1000/lv! > e2fsck -v -n -f /dev/vg1000/lv e2fsck 1.42.6 (21-Sep-2012) Warning! /dev/vg1000/lv is mounted. Warning: skipping journal recovery because doing a read-only filesystem check. Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Unattached inode 273472 Connect to /lost+found? no Unattached inode 273475 Connect to /lost+found? no Unattached inode 278585 Connect to /lost+found? no Unattached inode 278593 Connect to /lost+found? no Pass 5: Checking group summary information Block bitmap differences: +1084119 +1084174 -1147301 -1251329 Fix? no Free blocks count wrong for group #3 (1611, counted=1604). Fix? no Free blocks count wrong for group #33 (89, counted=91). Fix? no Free blocks count wrong for group #35 (9769, counted=9768). Fix? no Free blocks count wrong for group #36 (6633, counted=6625). Fix? no Free blocks count wrong for group #38 (6160, counted=6159). Fix? no Free blocks count wrong for group #817 (32766, counted=32767). Fix? no Free blocks count wrong for group #1034 (95, counted=94). Fix? no Free blocks count wrong for group #1476 (108, counted=107). Fix? no Free blocks count wrong for group #2171 (3816, counted=3862). Fix? no Free blocks count wrong for group #2807 (11655, counted=11330). Fix? no Free blocks count wrong for group #5954 (20572, counted=20571). Fix? no Free blocks count wrong (29391101, counted=29390796). Fix? no Inode bitmap differences: +273472 +273475 +278585 +278593 Fix? no Free inodes count wrong for group #33 (0, counted=2). Fix? no Free inodes count wrong for group #34 (3761, counted=3767). Fix? no Free inodes count wrong for group #816 (8190, counted=8191). Fix? no 1.42.6-3810: ********** WARNING: Filesystem still has errors ********** 506417 inodes used (0.76%, out of 66813952) 1488 non-contiguous files (0.3%) 98 non-contiguous directories (0.0%) # of inodes with ind/dind/tind blocks: 0/0/0 Extent depth histogram: 501671/778/27 237861635 blocks used (89.00%, out of 267252736) 0 bad blocks 106 large files 421074 regular files 80347 directories 1 character device file 0 block device files 0 fifos 479 links 4990 symbolic links (3936 fast symbolic links) 0 sockets ------------ 506887 files

Что-то никак не получается. Остановил все ненужные службы командной syno_poweroff_task Было > df Filesystem 1K-blocks Used Available Use% Mounted on /dev/md0 2451064 726308 1622356 31% / /tmp 512244 960 511284 0% /tmp /dev/vg1000/lv 1052232404 934668000 117462004 89% /volume1 /volume1/@optware 1052232404 934668000 117462004 89% /opt /volume1/OpenKM/repository 1052232404 934668000 117462004 89% /var/packages/OpenKM/target/OpenKM/repository /volume1/OpenKM/repository 1052232404 934668000 117462004 89% /var/packages/OpenKM/target/OpenKM/repository /dev/vg1001/lv 26302660 246084 25954176 1% /volume2 > syno_poweroff_task synologrotated stop/waiting initctl: Unknown instance: initctl: Unknown instance: webstation-httpd-conf-writer stop/waiting afpd stop/waiting synomkflvd stop/waiting ftpd stop/waiting php-fpm stop/waiting initctl: Unknown instance: nmbd stop/waiting sshd stop/waiting smbd stop/waiting synomkthumbd stop/waiting crond stop/waiting ntpd stop/waiting nginx stop/waiting cnid_metad stop/waiting synobackupd stop/waiting syslog-acc stop/waiting img_backupd stop/waiting httpd-user stop/waiting nfsd-adapter stop/waiting Стало > df Filesystem 1K-blocks Used Available Use% Mounted on /dev/md0 2451064 725980 1622684 31% / /tmp 512244 292 511952 0% /tmp Выполняем команду на проверку без изменений: > e2fsck -v -n -f /dev/md0 e2fsck 1.42.6 (21-Sep-2012) Warning! /dev/md0 is mounted. Warning: skipping journal recovery because doing a read-only filesystem check. Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information Free blocks count wrong (433068, counted=431271). Fix? no Free inodes count wrong (120930, counted=120970). Fix? no 34718 inodes used (22.31%, out of 155648) 157 non-contiguous files (0.5%) 16 non-contiguous directories (0.0%) # of inodes with ind/dind/tind blocks: 0/0/0 Extent depth histogram: 30269/32 189476 blocks used (30.44%, out of 622544) 0 bad blocks 1 large file 26916 regular files 2877 directories 151 character device files 2047 block device files 0 fifos 1162 links 2670 symbolic links (2163 fast symbolic links) 8 sockets ------------ 35831 files Теперь выполняем с изменениями на диске: > e2fsck -v -f -y /dev/md0 e2fsck 1.42.6 (21-Sep-2012) /dev/md0 is mounted. e2fsck: Cannot continue, aborting. Говорит что не желает продолжать видимо из-за Есть еще какие-нибудь мысли на эту тему? Кстати, обновил загрузчик и версию DSM (в пределах 5.0) - не помогло. что ожидаемо.

Я так понимаю, что эта команда не стандартная для DSM, т.к.: > chkfs -ash: chkfs: not found Извините, опечатка. Попробуйте fsck.ext4 А не подскажете с каким ключом и параметрами? Usage: fsck.ext4 [-panyrcdfvtDFV] [-b superblock] [-B blocksize] [-I inode_buffer_blocks] [-P process_inode_size] [-l|-L bad_blocks_file] [-C fd] [-j external_journal] [-E extended-options] device Emergency help: -p Automatic repair (no questions) -n Make no changes to the filesystem -y Assume "yes" to all questions -c Check for bad blocks and add them to the badblock list -f Force checking even if filesystem is marked clean -v Be verbose -b superblock Use alternative superblock -B blocksize Force blocksize when looking for superblock -j external_journal Set location of the external journal -l bad_blocks_file Add to badblocks list -L bad_blocks_file Set badblocks list

Я так понимаю, что эта команда не стандартная для DSM, т.к.: > chkfs -ash: chkfs: not found Да, данные читаются как и прежде, как через SMB, так и через File Station, т.е. DSM перешел в состояние "Только чтение" (с отключением всех пакетов способных генерировать данные для записи на диск), т.к. предполагает, что с жестким диском произошла беда и что его пора бы заменить. А так как при записи новых данных, по его мнению, жесткий диск может дать сбой, то он и перешел в режим "Только чтение", типа "Бекапь всё и вставляй новый диск". НО, я то знаю, что DSM заблуждается из-за того, что произошла ошибка записи по причине заполнения виртуального диска на 100%, а сам физический диск еще имел 300Гб свободного пространства (напомню, что XPEnology работает на виртуалке VMware с виртуальным дисковым пространством, а не диском на прямую) И почему это самое простое? У меня есть DS413j и больше Терабайта свободного места на нем, но на XPEnology установленном на виртуалке, а меня крутится не особо важная инфа, типа фильмов и сериалов, плюс различные сторонние вебсервисы, что в итоге дает 1Тб данных которые будут копироваться "вечность", а особенно папка web (учитывая тормознутость DS413j и RAID 1). Хоть этот вариант на 100% рабочий и очевидный, применить его хотело бы только в самом последнем случаи, т.е. не найдя "элегантного решения". Так как известно, что физическая проблема с диском отсутствует и DSM ошибочно полагает, что диску пора идти на покой, то резонно предположить, что в системных папка DSM есть параметр который хранит состояние системы, ну или что-то на подобии этого, который и сообщает, что DSM должна перейти в режим "Только чтение". Так если этот параметр можно поправить, то не проще ли так и сделать, а не таскать сотни гигабайт данных? Если есть хотя бы предположение в какую сторону капать, то не стесняйтесь высказать его.

Поймал такую же проблему, но с некоторыми оговорками. XPEnology с DSM 5.0-4458 Update 2 крутится на VMWare vSphere 5.1. Под нужды XPEnology выделен виртуальный раздел на 1Тб. На кануне не уследил за объемом свободного пространства и получил проблему в виде сбоя. Физической проблемы с диском нет. Отсюда вопрос: как убрать состояние "Только на запись" (Degraded) в котором находится DSM. Т.е. возможно ли как-то поправить через терминал это состояние или же возможно получится решить проблему сменой загрузчика и повышением версии DSM? Есть какие-то мысли на этот счет, уж больно не хочется гонять сотни гигабайт с винта на винт?

По-моему больше месяца не работает. До этого была такая же ситуация, но за несколько дней починили, а тут... Жалко что и хостинг на RU-Center'е, надеялся по IP бекап сделать (информации уж больно много там накопилось), но не судьба. Только на кэши Гугла надежда.

Сегодня был приобретён HP n54l .... Если кто-то действительно хочет повторить смену МАК-адреса таким способом - готов описать технологию в личку (чтобы не было множества трупов сетевых карт). Думаю, лишним не будет

А разве не от лицензии зависит кол-во камер?

Сделал генератор серийного номера и МАС-адреса viewtopic.php?f=5&t=2222&start=20#p15986 viewtopic.php?f=5&t=2222&start=30#p16012

Сделал генератор серийного номера и МАС-адреса viewtopic.php?f=5&t=2222&start=20#p15986 viewtopic.php?f=5&t=2222&start=30#p16012

Обновил документ. Добавил валидный генератор МАСов (делал на основании большого массива найденных серийных номеров). Добавлять уже сгенерированный МАС в файл Vender можно с помощью программы XPEnology vendor file patcher, она обеспечивает правильность его записи. Если хотите внести четыре МАСа, то просто генерируете первый, а второй, третий и четвертый формируйте меняя последний символ. Т.е. если вы сгенерировали МАС 00-11-32-17-E9-75, то оставшиеся три МАСа будут в таком виде: Так же переделал документ под Английский язык (его знание у меня хромает, т.ч. возможны ошибки) Важное уточнение! Проверить правильность работы генератора МАСов пока нет возможности, т.ч. используйте на свой страх и риск.

Вот набросал генератор серийных номеров. Выбираете из списка нужное устройство (под надписью "Выбрать модель") и кликаете на кнопку Генерировать или (если боитесь запускать скрипт) нажимаете на кнопку F9. Делалось в MS Office 2013. [spoiler=Содержимое макроса]Sub Обновить() ' ' Обновить Макрос ' ' Calculate End Sub

Приветствую! Извините те, кому не смог ответить. Запросов на серийники было очень много и я не мог всем ответить, хотя и видел сообщения. Раздачу серийников пока прекращаю. Возможно, чуть позже, выложу маски серийников для разных моделей.

Возможно, человек решил барыжить самосбором под видом продукции от Synology

Как патчили (с какой версии переходили)? У меня выдает ошибку доступа к катологу при попытке обновится

У меня такая же беда. Я хочу подключить в XPEnology шару с настоящего Synology и у меня выдает такую ошибку, а вот если наоборот, то всё прекрасно подключается. Кто-либо знает как победить? Сама папка доступна по CIFS и легко монтируется в винде А если по сути вопроса то можно сделать так как делал я: Ставите Midnight Commander, делаете доступ к нужной шаре по ФТП и конектитесь через FTP Link (см. скрин http://yadi.sk/d/pMTR11oFK6FmF ). Ну а дальше я думаю ясно.

Так я не понял, нужно просто правильный диапазон МАС-адресов или же еще этот диапазон должен соответствовать определенному серийному номеру?

Я думаю есть простое сопоставление МАСа определенному номеру, т.е. если в серийном номере еще есть принцип формирования, то МАС просто присваивается тому или иному серийному номеру. А откуда взялась информация, что при пользовании сервисами Synology МАС также учитывается?

Я разобрался в принципе формирования серийного номера и знаю маску серийника. Если кто-то хочет себе легальный (соответствующий модели) серийник для прошивки основанной на DS3612xs (ну или той что есть в спойлере), то обращайтесь в личку. Рассказывать о принципе формирования серийного номера не хочется, т.к. опасаюсь что могут появится проблемы при массовой регистрации серийников. [spoiler=Список устройств с известной маской]CS-406 CS-406e CS407 CS407e DS-101 DS-101g+ DS-101j DS107 DS107+ DS108j DS112 DS112j DS1511+ DS1511+ DS1512+ DS1812+ DS207+ DS211+ DS211+ DS212 DS212+ DS212j DS2411+ DS3611xs DS3612xs DS408 DS411 DS411+II DS412+ DS413j DS508 DS712+ DX1211 RS212 RS2211+ RS2211RP+ RS3411RPxs RS3411xs RS408 RS408-RP RS411 RS812 RS812+ RS812RP+ RX1211 RX1211RP Synology Remote VS80