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