Jump to content
XPEnology Community

Rowdy

Member
  • Posts

    29
  • Joined

  • Last visited

Everything posted by Rowdy

  1. It works! It just works! And a green 'healthy' sign, I'm really happy. Thank you very, very much and might you ever find yourself in the vicinity of Venlo, the Netherlands, swing by, I'll buy you a beer. (or ten)
  2. Yes, my drives are hot-swappable. :) The parity consistency check is done, and the volume has entered a new status; the warning status. That's a new one! Mdstat also seems okay? rowdy@prime-ds:/$ sudo cat /proc/mdstat Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] md3 : active raid5 sdb6[6] sda6[0] sdd6[4] sdc6[5] 2930228736 blocks super 1.2 level 5, 64k chunk, algorithm 2 [4/4] [UUUU] md2 : active raid5 sda5[6] sdb5[1] sdc5[4] sdd5[5] 5846050368 blocks super 1.2 level 5, 64k chunk, algorithm 2 [4/4] [UUUU] md1 : active raid1 sdd2[3] sdc2[2] sdb2[1] sda2[0] 2097088 blocks [16/4] [UUUU____________] md0 : active raid1 sda1[0] sdb1[1] sdc1[3] sdd1[2] 2490176 blocks [12/4] [UUUU________] unused devices: <none>
  3. I will. Parity consistency check is running. Just the below command I presume? rowdy@prime-ds:/$ sudo cat /proc/mdstat And now I'm looking back,I've totally missed it there was something wrong... So this old output md3 : active raid5 sda6[0] sdd6[4] sdc6[5] 2930228736 blocks super 1.2 level 5, 64k chunk, algorithm 2 [4/3] [U_UU] Should become something like this if the parity consistency is ready? md3 : active raid5 sda6[0] sdd6[4] sdc6[5] 2930228736 blocks super 1.2 level 5, 64k chunk, algorithm 2 [4/4] [UUUU] Trying to grasp what I'm doing, so next time I hopefully don't have to waste your time.. 😬
  4. I was aware of that, but I tried it three times because I thought I screwed up; ie with repairing it while the volume wasn't accessable.. rowdy@prime-ds:/$ sudo smartctl -d sat --all /dev/sda | fgrep -i sector Sector Sizes: 512 bytes logical, 4096 bytes physical 5 Reallocated_Sector_Ct 0x0033 195 195 140 Pre-fail Always - 154 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0
  5. Ow well. That was a bust. So, after parity check it shows as degraded, but fine. Can access all files etc. I get occasionally a message thet the system partition is damaged, if i want to repair that. Yes, and it's fine. I don't have the option to deactivate drive 1 (I could deactivate 3..4, not a good plan ) and If I yank it out the volume is crashed. If I enter the new drive, it won't show me the option to repair, probably because the volume is crashed? After that, if I put the old drive back, run the command you gave me (mdadm /dev/md2 --manage --add /dev/sda5) it wil start the check again and after A while I'm fine, with a busted drive.. All the commands I've put in seems a lot better, no errors and such.. One thing that's curious though, is that each time the parity check runs it runs faster (first time took 14 hours, second 8, last time 6 hours) but the bad sectors on drive one go waaaay up... Any suggestions left, or should I give up and recreate the whole thing?
  6. Small update; after the check I could 'kick' the drive, however; I've did the add/parity check while the volume was not accessable.. 😒 So I could kick the drive, but could not add the new drive. So now I've booted with the old drive and an accessable volume, and restarted the add/parity check.. More news probably late this evening...
  7. It's at 88%.. Fingers crossed! I'll keep you posted. Thansk for the help so far!
  8. No problem, I was not able deduce that there where two arrays myself Using the OLD drive, I could perform that command, and the storage manager seems to be checking parity now. Does that mean it's finding the loss in redundancy and it's going to correct that?
  9. Unfortunatly, I can't do anything there I'm afraid. I can do health checks with both (OLD, NEW) drives in and hit 'Configure' with the OLD drive in. I've also checked what I could do on drive two, that shoudl have some errors as per your first reply, but no joy I'm afraid?
  10. Thanks! I've tried that, with the old drive, new drive, no drive and reboots, but they all say the same; rowdy@prime-ds:/$ sudo mdadm /dev/md2 --manage --add /dev/sdb5 Password: mdadm: Cannot open /dev/sdb5: Device or resource busy How do find what's keeping the drive busy?
  11. So, I'm a bit stuck. Over the last years when a disk crashed, I'd pop the crashed disk out, put in a fresh one and repair the volume. No sweat. Over time I've migrated from a mixed 1 and 2TB disks to all 3TB one and earlier this year I'd received a 6TB one as a RMA for a 3TB one from WD. So I was running: Disk 1: 3TB WD - Crashed Disk 2: 3TB WD Disk 3: 6TB WD Disk 4: 3TB WD So I've bought a shiny new 6TB WD to replace disk 1. But that did not work out well. When running the above setup; I've a degraded volume, but it's accessable. When putting in the new one, the volume is crashed and the data is not accessable. I'm not able to slect the repair option; only 'Create'. When putting back the crashed disk, after a reboot the volume is accessable again (degraded). I've did a (quick) SMART test on the new drive and it seems OK. The only thing that's changed since the previous disk replacement is that I've did an upgrade to 6.2.3-25426. Could that be a problem? However, before we proceed (and I waste your time), I've got backups. Of everything. So, deleting and recreating a new volume (or the entire system) would not be that big of a deal; It'll only cost me a lot of time. But that seems the easy way to go. I've got a Hyper-Backup of the system on an external disk and all the apps and a few of the shares. The bigger shares are backed up to several other external disks. If I delete the volume, create a new one, restore the last Hyper-Backup and copy back the other disks, I'm golden? The Hyper-Backup will contain the original shares? Might that not be the best/simplest solution, I've attached some screenshots and some outputs so we know what we are talking about.. Thanks!
  12. - Outcome of the update: SUCCESSFUL - DSM version prior update: 6.2.2-24922 Update 5 - Loader version and model: Jun's v1.04b DS918 - Using custom extra.lzma: ig-88's extra.lzma and extra2.lzma - Installation type: BAREMETAL - ASRock J4105-ITX - Additional comments: I've rebuild my boot usb stick with the new extra.lzma and the extra2.lzma from ig-88's topic. I've combined that with the rd.gz and the zImage files from the DSM_DS918+_25426.pat from Synology. After rebooting I've used https://find.synology.com to locate my server and started the migration process. Choose manual install and selected the aforementioned pat. After 10 minutes I was golden. No data lost. Let's Encrypt certificates renewal works like a charm. Have to test out hardware transcoding though.
  13. - Outcome of the update: SUCCESSFUL - DSM version prior update: DSM 6.2-23739 Update 2 - Loader version and model: Jun's v1.04b DS918 - Using custom extra.lzma: real3x mod - Installation type: BAREMETAL - ASRock J4105-ITX - Additional comments: No reboot
  14. No, I'm sorry, that's for a rainy day, did not come to it to activate it. Also the mentioned folder does not exist on my system..
  15. Ah, I didn't get why my logs where not collapsed. Thanks, I'll do!
  16. - Outcome of the update: SUCCESSFUL - DSM version prior update: DSM 6.2.1-23824 update 6 - Loader version and model: Jun's v1.04b DS918 - Using custom extra.lzma: YES (see attached topic) - Installation type: BAREMETAL - ASRock J4105-ITX - Additional comments: My kernel was panicing after the upgrade, but it works now, see the attached topic for the solution.
  17. @real3x, If you'll ever be near Venlo, I will buy you a beer. A lot of beer. THANK YOU. 🤩 My usb bootdisk broke down, so I had to make a new one; but after that the system would want to do a fresh install. No thank you! So, I figured, back up some more data using @Polanskiman's tutorial, so I created an livedisk, mounted the first partition. System. O, well. Clean the update folder and give it another try, because, it's already broken, eh. And it just works. SOLUTION So, might someone stumble upon this topic; what I did; (with a lot of help) - Created a new bootdisk with the extra.lzma from @real3x's signature - Removed the extra2.lzma from that bootdisk - Used a livedisk to mount my disks (tutorial) and cleaned the updates folder (/usr/lib/modules/update/) And if you did do above; also do the serial console.. It is very helpful.
  18. Hm. I Can't edit my last post anymore? I read on Synology that the default user is admin and password blank, on a Dutch forum I read that for jun's loaders the user is root and password blank. Can't seem to find anymore now. user admin, pass <blank> user root, pass <blank> user rowdy, pass <blank> user rowdy, pass <MYPASS> user admin, pass <MYPASS> user root, pass <MYPASS> user Demo, pass <blank> Strange thing is, sometimes it just randomly prints this. DiskStation login: Login timed o Wed Aug 21 17:40:36 2019 DiskStation login: Well, My Ubuntu image is almost downloaded, so I'll go try that way..
  19. That works, kind of. But it won't accept my credentials. (I tried typing my pass in the login so it shows and I can verify it's correct) My guess is; this is the default environment that is waiting to recover my system. So clean DiskStation. Any idea what the default login might be? That does not work :( (at least, admin and blank) :: Loading module syno_hddmon ... [FAILED] [ 31.879293] EXT4-fs (md0): barriers disabled [ 31.962650] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: ============ Date ============ Wed Aug 21 15:29:22 2019 DiskStation login: rowdy Password: [ 41.547009] EXT4-fs (md0): barriers disabled [ 41.580100] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: [ 41.929834] EXT4-fs (md0): barriers disabled [ 41.961033] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: Login incorrect DiskStation login: rowdy Password: [ 61.793348] md: md0: resync done. [ 61.797831] md: md0: current auto_remap = 0 [ 61.840119] RAID1 conf printout: [ 61.843481] --- wd:4 rd:12 [ 61.846458] disk 0, wo:0, o:1, dev:sda1 [ 61.850564] disk 1, wo:0, o:1, dev:sdb1 [ 61.854703] disk 2, wo:0, o:1, dev:sdd1 [ 61.858850] disk 3, wo:0, o:1, dev:sdc1 Login incorrect DiskStation login: rowdy Password: process '/sbin/ Wed Aug 21 15:30:26 2019 DiskStation login: rowdy Password: Login incorrect DiskStation login: rowdy Password: Login incorrect DiskStation login: root Password: Login incorrect Wed Aug 21 15:31:07 2019 DiskStation login:
  20. Yeah, but no network by the looks of it (just loopback). Can I send command by the serial connection I'm using?
  21. The update folder is maybe still giving some trouble.. I'll give that mounting and removing a try hopefully by tomorrow, or wednesday. My method; adjusting it in the image (replace extra and remove extra2) and rewrite that on the card and reboot did not work right, or at least, it gives me a lot of new errors. at least, it keeps my busy. Thanks so far! Serial log (without quiet option, replaced extra.lmza and removed extra2.lzma)
  22. First of all, thanks! But I'm not sure if I got it right..? As far as I can tell, you say that I should put my Synology in update mode (syno_install_flag) and mount some files. Replace the extra.lzma and delete the extra2. After that, clean the update folder and reboot. But all suggests I have access to the machine? Or do I have to follow this procedure with a live disk and access the drives that way..? (could be tricky as I've used 4 disks in SHR?) I guess, mounting the bootloader with OSFmount and replacing the lzma there in the second partition will not do the trick? By the way, Rf? Be carefull? Don't need to say. I learned the hard way. In my early Gentoo Linux days I've accomplished to chmod 0777 -R / and instead of tab I hit ENTER. Same with rf, in about the same manner. In the Netherlands we have a saying about that a donkey will not hit his head twice on the same stone. Well. I did. But in my defense, student back then, got great ideas in the bar, tried to execute them before going to bed. Not a bright idea. Kids, learn from this!
  23. Okay, I'm stuck.Last week, after I saw some good comments in this topic for my setup I've hit that update button, as I did may times before. However, my NAS did come online. After searching, Googling, buying an USB-RS232 adapter, fiddling with some breadboard wires I did manage to get my serial up and running. The conslusion so far, somewhere in the boot sequence it got stuck, but I can't figure out why. It does not come to the point where it presents a login or brings up net, so I can't access it now. I hope you folks can help me, or at least, point me in the right direction. - Outcome of the update: FAILED - DSM version prior update: DSM 6.2.1-23824 update 6 - Loader version and model: Jun's v1.04b DS918 - Using custom extra.lzma: NO - Installation type: BAREMETAL - ASRock J4105-ITX - Additional comments: None What I've done so far; - Redownloaded the loader - Attached serial (output posted below) - Updated the grub.config so my serial spit out some more detail (removed quiet) - Checked my BIOS settings Other hail mary's I going to try: - Implement the extra lzma (one of the succesfull reports has it, the other not) - Implement the slow boot fix (didn't have issues before) I saw in another post that there is a suggestion to first install Update 1 manually, but I have no clue how to do that; my system is trashed.
  24. - Outcome of the update: SUCCESSFUL - DSM version prior update: DSM 6.2.1-23824 update 4 - Loader version and model: Jun's v1.04b DS918 - Using custom extra.lzma: NO - Installation type: BAREMETAL - ASRock J4105-ITX - Additional comments: None
  25. - Outcome of the installation/update: SUCCESSFUL - DSM version prior update: 6.2.1-23824 Update 1 - Loader version and model: JUN'S LOADER v1.04b - DS918+ - Using custom extra.lzma: NO - Installation type: BAREMETAL - ASRock J4105-ITX - Additional comments: None
×
×
  • Create New...