wedgehog Posted December 15, 2022 Share #1 Posted December 15, 2022 Hi Guys, my apologies if I am in the wrong forum. I had the house power go off during an update, I have had a look at the serial log during startup and it looks like Uboot and RD are ok, I get pages of sensible instructions until it comes to it loading Zimage and it says it's corrupt, I removed the flash memory and read the contents and saved it with a view to re constructing the file, but I find Synology have decided to encrypt the .PAT files to prevent us from repairing our equipment! Please could someone give me a copy of their flash chip for the DS418, dosn't matter which version of DSM as the board should boot with no drives in it and say please insert a drive, I know the drives are ok as I put them in my DS920 and it reds them fine and all the data is ok, This is still a £350.00 or more machine so I would really like to save it Once again please can anyone give me a zip containing a DS418 flash image with the s/n and mac removed if you don't trust me not to use it. Or If no one want's to help me with a copy of the flash I would be happy with a list of the file Offsets for Zimage and RD.bin in any of the images below 711 (ones we can extract) I would need to know which 418 DSM it is from as I think they are all different as the file sizes vary. Please Bob Quote Link to comment Share on other sites More sharing options...
wedgehog Posted December 17, 2022 Author Share #2 Posted December 17, 2022 No one interested in helping me? Quote Link to comment Share on other sites More sharing options...
IG-88 Posted December 17, 2022 Share #3 Posted December 17, 2022 On 12/15/2022 at 2:18 PM, wedgehog said: but I find Synology have decided to encrypt the .PAT files to prevent us from repairing our equipment! you can unpack it with modded version of /usr/syno/sbin/synoarchive position 39F0 00 System 01 Nano 02 SecurityJson 03 Spk (default) 08 /var/packages/syno_dev_token 0A Small Patch with the 00 patched version for system pat files its use would look like this /usr/syno/sbin/synoarchive00 -vxf DSM_DVA1622_42661.pat -C . On 12/15/2022 at 2:18 PM, wedgehog said: Once again please can anyone give me a zip containing a DS418 flash image with the s/n and mac removed if you don't trust me not to use it. people here are often don't own original units, this forum is mostly about using DSM on generic hardware, so when looking for owners of original units your chances are higher in a synology forum also most people will not know how to remove the serial so if you want to have better chances explain how to read the content of the module and how to change/remove the serial number and mac from the image file, finding someone with that background knowledge in place is rare enough and having a ds418 too ...? if ts just about rd.gz and zImage then you can help yourself and even if you write a older versions to the module it should boot again and correct the problem by itself or with the syno assistant - the situation would be the same as if you would get a replacement unit with a older version on its module, should be something to find in syno's KB in theory the original loader should detect the mismatch when mounting the system volume and copy the needed newer files to from the system partition (at least afaik) so replace the rd.gz and zImage, boot without disks and see if the synology asisatant finds the unit in network (with the old build number), if thats working then put back you disks and do the same again, the assistant should suggest to correct the problem and you should be back in business 1 Quote Link to comment Share on other sites More sharing options...
wedgehog Posted December 18, 2022 Author Share #4 Posted December 18, 2022 (edited) Hi Ig, thanks for your help. I came here because I was told on another forum that you guys here were clever and would be able to help. It has been some time since I posted and during the wait I thought of what you said so I downloaded an older PAT file and constructed a new flash image, I am fairly sure I got it correct as It obviously runs Uboot as that's the first in the file but later in the log I can see it says it has fond the image but cannot write it to memory, this fail line end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(9,0) I am not good enough to know exactly what that means, I am guessing it's trying to write to a certain part of memory to creat the linux directory tree and can't, I was thinking of using the commands in Uboot to copy Zimage to memory at another location and then using Bootm to run it but I don't know exactly how to write the command or what memory start and finish addresses to use. While I have over 40 years experience as an electronics engineer I am no coder, Please could you help me with this? PS: I did post in the Synology forum at the same time I posted here and no one has answered me there either. I also added the log just in case you have time to read it. Bob putty.log Edited December 18, 2022 by wedgehog Quote Link to comment Share on other sites More sharing options...
IG-88 Posted December 18, 2022 Share #5 Posted December 18, 2022 1 hour ago, wedgehog said: so I downloaded an older PAT file and constructed a new flash image i thought you where using the original one from the usb dom and just replaced the rd.gz and zImage on the 2nd partition (thats where the kernel for a new dsm version is copied i've never seen a original dom image of a arm unit, might be different from one for x86? on a image i have from a 1511+ is a 17.48 MB ext2 parttion and a 104.8 MB ext2 partition, there is a file "vender" an the 2nd partiton that seems to contain the serial of the unit 1st 2nd and just to make clear, as yours is a arm cpu based unit you will not be able to boot any loader from here, everything here is around x86 cpu's (replacing the loader with one from here is not going to work) Jumping to 2nd bootloader... U-Boot 2015.07-g428cfe7-dirty (May 16 2018 - 10:29:38 +0800) CPU : Cortex-A53 Quad Core Board: Realtek QA Board DRAM: 2 GiB ... Starting Kernel ... [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Initializing cgroup subsys cpuacct [ 0.000000] Linux version 4.4.180+ (root@build16) (gcc version 7.5.0 (GCC) ) #41890 SMP Thu Jul 15 03:42:46 CST 2021 this looks like the boot from the 1st partition came out ok und then its starting to load zImage from the 2nd partiton (kernel 4.4.180 war introduced with dsm 6.x?) from the error it might by a problem with rd.gz? so check that one on the 2nd partition [ 8.437645] RAMDISK: lzma image found at block 0 [ 9.918577] List of all partitions: [ 9.922188] 0100 655360 ram0 (driver?) [ 9.926930] 0101 655360 ram1 (driver?) [ 9.931674] 0102 655360 ram2 (driver?) [ 9.936412] 0103 655360 ram3 (driver?) [ 9.941152] 0104 655360 ram4 (driver?) [ 9.945907] 0105 655360 ram5 (driver?) [ 9.950646] 0106 655360 ram6 (driver?) [ 9.955390] 0107 655360 ram7 (driver?) [ 9.960130] 0108 655360 ram8 (driver?) [ 9.964873] 0109 655360 ram9 (driver?) [ 9.969611] 010a 655360 ram10 (driver?) [ 9.974442] 010b 655360 ram11 (driver?) [ 9.979270] 010c 655360 ram12 (driver?) [ 9.984100] 010d 655360 ram13 (driver?) [ 9.988928] 010e 655360 ram14 (driver?) [ 9.993759] 010f 655360 ram15 (driver?) [ 9.998586] 1f00 1024 mtdblock0 (driver?) [ 10.003774] 1f01 3008 mtdblock1 (driver?) [ 10.008958] 1f02 4092 mtdblock2 (driver?) [ 10.014144] 1f03 64 mtdblock3 (driver?) [ 10.019327] 1f04 4 mtdblock4 (driver?) [ 10.024513] No filesystem could mount root, tried: ext3 ext4 ext2 [ 10.030890] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(9,0) Quote Link to comment Share on other sites More sharing options...
wedgehog Posted December 18, 2022 Author Share #6 Posted December 18, 2022 35 minutes ago, IG-88 said: i thought you where using the original one from the usb dom and just replaced the rd.gz and zImage on the 2nd partition (thats where the kernel for a new dsm version is copied i've never seen a original dom image of a arm unit, might be different from one for x86? on a image i have from a 1511+ is a 17.48 MB ext2 parttion and a 104.8 MB ext2 partition, there is a file "vender" an the 2nd partiton that seems to contain the serial of the unit 1st 2nd and just to make clear, as yours is a arm cpu based unit you will not be able to boot any loader from here, everything here is around x86 cpu's (replacing the loader with one from here is not going to work) Jumping to 2nd bootloader... U-Boot 2015.07-g428cfe7-dirty (May 16 2018 - 10:29:38 +0800) CPU : Cortex-A53 Quad Core Board: Realtek QA Board DRAM: 2 GiB ... Starting Kernel ... [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Initializing cgroup subsys cpuacct [ 0.000000] Linux version 4.4.180+ (root@build16) (gcc version 7.5.0 (GCC) ) #41890 SMP Thu Jul 15 03:42:46 CST 2021 this looks like the boot from the 1st partition came out ok und then its starting to load zImage from the 2nd partiton (kernel 4.4.180 war introduced with dsm 6.x?) from the error it might by a problem with rd.gz? so check that one on the 2nd partition [ 8.437645] RAMDISK: lzma image found at block 0 [ 9.918577] List of all partitions: [ 9.922188] 0100 655360 ram0 (driver?) [ 9.926930] 0101 655360 ram1 (driver?) [ 9.931674] 0102 655360 ram2 (driver?) [ 9.936412] 0103 655360 ram3 (driver?) [ 9.941152] 0104 655360 ram4 (driver?) [ 9.945907] 0105 655360 ram5 (driver?) [ 9.950646] 0106 655360 ram6 (driver?) [ 9.955390] 0107 655360 ram7 (driver?) [ 9.960130] 0108 655360 ram8 (driver?) [ 9.964873] 0109 655360 ram9 (driver?) [ 9.969611] 010a 655360 ram10 (driver?) [ 9.974442] 010b 655360 ram11 (driver?) [ 9.979270] 010c 655360 ram12 (driver?) [ 9.984100] 010d 655360 ram13 (driver?) [ 9.988928] 010e 655360 ram14 (driver?) [ 9.993759] 010f 655360 ram15 (driver?) [ 9.998586] 1f00 1024 mtdblock0 (driver?) [ 10.003774] 1f01 3008 mtdblock1 (driver?) [ 10.008958] 1f02 4092 mtdblock2 (driver?) [ 10.014144] 1f03 64 mtdblock3 (driver?) [ 10.019327] 1f04 4 mtdblock4 (driver?) [ 10.024513] No filesystem could mount root, tried: ext3 ext4 ext2 [ 10.030890] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(9,0) Hi IG, I'm sorry you have lost me, First of all yes I can see in my flash image there is a vendor section and it has the S/n and check sum in it, also when you extract the files from a .PAT they are not included as they are specific for the machine and have to be added. You say because mine is an Arm CPU I will not be able to boot with a bootloader from "Here" Do you mean from this forum? If that's the case I did not intend to. You can see from the top of my log that I am using Bus Pirate, and I just press the esc key after boot and access the Uboot Menu, that's where I was getting the command "Bootm" which should boot linux from the memory if I was able to load Zimage directly to another memory location to avoid the "Unable to write to Block 9,0" problem. Well that was my plan but I may be talking rubish, I am no where as good at this as you and I need things explained clearly, you speak of the first and second partition? Are you speaking of the disk structure created in memory which is refered to as the ramdisk in the log? or are you refering to different locations in the flash file? So just to be clear, I downloaded an older DSM file from Synology I extracted it and created a flash file placing Uboot (Redboot) at 00 and Zimage and RD.gz at exactly the same locations as they were in the original flash which I got when I first read the chip, I presumed that it was Zimage which got corrupted when the power went off. I then added the Vendor and serial number stuff at exactly the same position as they were in, in the original flash image. All I could do to get the offsets was to look at the original flash read from the chip with a hex editor and build mine to match. Now having said that, the files with the exeption of Uboot were different sizes in the older image, I presumed that as long as their start was at the same offsets as the original that wouldn't matter? Pleas could you confirm for me, in the flash memory image, the 64k chip, is the file order Uboot, Zimage, RD.gz than the Vendor and s/n stuff, I am worried that maybe zimae should have been the second file, but as you confirmed the log does say it was initially loading ok from my flash file. To be honest I doubt I am good enough to resurect this NAS, but I am very determined. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.