zyxel 325v2 migration fail
All Replies
-
Hello, i have the same problem after installing a second HDD to my NSA 325 V2. I am trying to resize the inner filesystem but i have the following problem:
I do not know which commands to use. I have little experience with this stuff and i managed to login via telnet but am lost from here.
I do not know what device-name to put in the commands:resize2fs /dev/<dev> 10577568
I do not know what to put in as device name. How can i find that out?
Here is my output:~ # cat /proc/partitions
major minor #blocks name
7 0 143360 loop0
8 0 2930266584 sda
8 1 498688 sda1
8 2 2929766400 sda2
31 0 1024 mtdblock0
31 1 512 mtdblock1
31 2 512 mtdblock2
31 3 512 mtdblock3
31 4 10240 mtdblock4
31 5 10240 mtdblock5
31 6 48896 mtdblock6
31 7 10240 mtdblock7
31 8 48896 mtdblock8
9 0 2929765240 md0~ # cat /proc/mdstat
Personalities : [linear] [raid0] [raid1]
md0 : active raid1 sda2[0]
2929765240 blocks super 1.2 [2/1] [U_]
unused devices: <none>~ # mdadm --examine /dev/sd?2
/dev/sda2:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 8d293632:619b8223:c9668de8:73ee5a63
Name : Toaster:0 (local to host Toaster)
Creation Time : Wed Oct 23 12:08:58 2019
Raid Level : raid1
Raid Devices : 2
Avail Dev Size : 2929765376 (2794.04 GiB 3000.08 GB)
Array Size : 2929765240 (2794.04 GiB 3000.08 GB)
Used Dev Size : 2929765240 (2794.04 GiB 3000.08 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
State : clean
Device UUID : faae24c1:0ec395c1:f3bd9cf5:ea4734cc
Update Time : Thu Oct 24 10:18:12 2019
Checksum : b30f2c95 - correct
Device Role : Active device 0
Array State : A. ('A' == active, '.' == missing)
mdadm: cannot open /dev/sdb2: No such device or address
mdadm: cannot open /dev/sdc2: No such device or address
mdadm: cannot open /dev/sdd2: No such device or address
mdadm: cannot open /dev/sde2: No such device or address
mdadm: cannot open /dev/sdf2: No such device or address
mdadm: cannot open /dev/sdg2: No such device or address
mdadm: cannot open /dev/sdh2: No such device or address
mdadm: cannot open /dev/sdi2: No such device or address
mdadm: cannot open /dev/sdj2: No such device or address
mdadm: cannot open /dev/sdk2: No such device or address
mdadm: cannot open /dev/sdl2: No such device or address
mdadm: cannot open /dev/sdm2: No such device or address
mdadm: cannot open /dev/sdn2: No such device or address
mdadm: cannot open /dev/sdo2: No such device or address
mdadm: cannot open /dev/sdp2: No such device or address
mdadm: cannot open /dev/sdq2: No such device or address
mdadm: cannot open /dev/sdr2: No such device or address
mdadm: cannot open /dev/sds2: No such device or address
mdadm: cannot open /dev/sdt2: No such device or address
mdadm: cannot open /dev/sdu2: No such device or address
mdadm: cannot open /dev/sdw2: No such device or address
mdadm: cannot open /dev/sdx2: No such device or address
mdadm: cannot open /dev/sdy2: No such device or addressmdadm: cannot open /dev/sdz2: No such device or address
0 -
Thank you so much for your help! i tried it but i get the following results:
BusyBox v1.17.2 (2017-06-23 10:40:08 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.
~ # mdadm --stop /dev/md0
mdadm: stopped /dev/md0~ # e2fsck.new -f /dev/sda2
e2fsck 1.41.14 (22-Dec-2010)
e2fsck.new: Superblock invalid, trying backup blocks..
e2fsck.new: Bad magic number in super-block while trying to open /dev/sda2
The superblock could not be read or does not describe a correct ext2 filesystem.
If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
~ # resize2fs /dev/sda2 732441310
resize2fs 1.41.14 (22-Dec-2010)
resize2fs: Bad magic number in super-block while trying to open /dev/sda2
Couldn't find valid filesystem superblock.
~ # mdadm --assemble /dev/md0 /dev/sda2 --run
mdadm: /dev/md0 has been started with 1 drive (out of 2).
~ # resize2fs /dev/md0
resize2fs 1.41.14 (22-Dec-2010)
Please run 'e2fsck -f /dev/md0' first.
What am i doing wrong or how do i have to change the commands?
0 -
Maybe I should have paid more attention to your info, and less to your question.Why do you think your problem is the same? What is the output of
e2fsck.new /dev/md0
0 -
Ok, so here is my hole story:
In my Zyxel NSA 325v2 i have a 3TB HDD in Slot 2. It has been in there for 4 Years. I only make Backups of the important data that i have on the HDD, not of all the big files. I wanted to change that and make a RAID 1, so i would have somewhat of a Backup if one HDD failed. So i bought a 4TB HDD and put it in Slot 1. When i logged into the Web-Interface, my 3TB HDD was down. The log said "migration fail"
When i tried to scan and repair it, after a moment a window popped up:
I started searching and found this thread with what i thought was the same problem. So i thought, that i could use the same fix...
Here is the output:~ # e2fsck.new /dev/md0 e2fsck 1.41.14 (22-Dec-2010) The filesystem size (according to the superblock) is 732441344 blocks The physical size of the device is 732441310 blocks Either the superblock or the partition table is likely to be corrupt! Abort<y>?
Should i create a new thread or should i keep posting here?
Again, thank you so much for your help! If the data will be restored, i will buy a external Drive and will make propper backups!0 -
OK. md0 has a recognizable ext filesystem, and sda2 doesn't. That is not surprising, as according to the raid header there is a Data Offset of 2048 sectors, which means the start of md0 is 2048 sectors further than the start of sda2.According to your /proc/partitions sda2 is 2929766400 'blocks' and md0 is 2929765240 'blocks'. The difference is 1160. In this case a block is 1k, so that equals 2320 sectors. For some reason 272 sectors at the end of sda2 are not used by md0.To make it simple, the filesystem blocks have a different size. For the filesystem md0 is 732441310 blocks, so apparently one block is 2929765240/732441310 = 4kB. The filesystem needs 732441344 blocks, which is 2929765376kB, which happens to be exactly the size of sda2 -2048 sectors. So the array didn't cut the last 272 sectors before the conversion. I have no idea why.Anyway, fortunately it's possible to create a virtual block device starting at 2048 sectors from the start of sda2, which should contain the filesystem, using a loop device, on which the filesystem can be resized.The commands are
<div>mdadm --stop /dev/md0</div><div><br></div><div>losetup -o 1048576 /dev/loop1 /dev/sda2</div><div><br></div><div>e2fsck.new -f /dev/loop1</div><div><br></div><div>resize2fs /dev/loop1 2929765240K</div><div><br></div><div>losetup -d /dev/loop1</div><div><br></div><div>mdadm --assemble /dev/md0 /dev/sda2 --run</div><div><br></div><div>resize2f /dev/md0<br></div><div></div>
0 -
I used the commands and get the following output:
~ # mdadm --stop /dev/md0 mdadm: stopped /dev/md0 ~ # losetup -o 1048576 /dev/loop1 /dev/sda2 ~ # e2fsck.new -f /dev/loop1 e2fsck 1.41.14 (22-Dec-2010) 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 /dev/loop1: 172519/183115776 files (2.2% non-contiguous), 593703403/732441344 blocks<br><p>~ # resize2fs /dev/loop1 2929765240K resize2fs 1.41.14 (22-Dec-2010) Resizing the filesystem on /dev/loop1 to 732441310 (4k) block. resize2fs: Memory allocation failed while trying to resize /dev/loop1Please run 'e2fsck -fy /dev/loop1' to fix the filesystem after the aborted resize operation. </p>
The first time i ran the commands, i said yes to the fixes from e2fsck.new -f /dev/loop and got this output:<p> BusyBox v1.17.2 (2017-06-23 10:40:08 CST) built-in shell (ash) Enter 'help' for a list of built-in commands. ~ # ~ # mdadm --stop /dev/md0 1^H mdadm: stopped /dev/md0 ~ # ~ # ~ # ~ # ~ # losetup -o 1048576 /dev/loop1 /dev/sda2 <span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Lato, Helvetica, Arial, sans-serif;">~ # e2fsck.new -f /dev/loop1 </span></p><p><span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Lato, Helvetica, Arial, sans-serif;">e2fsck 1.41.14 (22-Dec-2010)</span><span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Lato, Helvetica, Arial, sans-serif;"> </span><span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Lato, Helvetica, Arial, sans-serif;"> </span><br></p><p>Pass 1: Checking inodes, blocks, and sizes <br>Deleted inode 56885273 has zero dtime. Fix<y>? yes <<<<<<<<<<<<<<<<<<<<<<<<removed this section, it was to long >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Free blocks count wrong (138737916, counted=138737941). Fix<y>? yes Inode bitmap differences: -56885273 -(56885285--56885290) -56885292 -56885621 -56885711 -56886280 -(56886288--56886289) -56886291 -56886305 -56886361 -56886495 -(56886497--56886498) -(56886500--56886501) -56886774 -56886780 -56886783 -79175681 Fix<y>? yes Free inodes count wrong for group #6944 (6493, counted=6517). Fix<y>? yes Free inodes count wrong for group #9665 (8180, counted=8181). Fix<y>? yes Directories count wrong for group #9665 (12, counted=11). Fix<y>? yes Free inodes count wrong (182943232, counted=182943257). Fix<y>?yes /dev/loop1:***** FILE SYSTEM WAS MODIFIED ***** /dev/loop1: 172519/183115776 files (2.2% non-contiguous), 593703403/732441344 blocks ~ # resize2fs /dev/loop1 2929765240K resize2fs 1.41.14 (22-Dec-2010) Resizing the filesystem on /dev/loop1 to 732441310 (4k) blocks. resize2fs: Memory allocation failed while trying to resize /dev/loop1 Please run 'e2fsck -fy /dev/loop1' to fix the filesystem after the aborted resize operation. ~ # losetup -d /dev/loop1 ~ # mdadm --assemble /dev/md0 /dev/sda2 --run mdadm: /dev/md0 has been started with 1 drive (out of 2). ~ # resize2f /dev/md0 sh: resize2f: not found ~ # resize2fs /dev/md0 resize2fs 1.41.14 (22-Dec-2010) Please run 'e2fsck -f /dev/md0' first</p>
Did i screw up somehow? What could i do next?0 -
That resize was supposed to work, but apparently there's something unusable which triggered a bug in resize2fs. Google is not helpful, I can only find one hit on a similar problem, which doesn't have a solution.There are a few options. You can try to get more available memory, by killing some daemons which are not needed right now, like the webserver. Unfortunately the error message doesn't give a clue how much extra is needed. And as resize2fs recommends to run e2fsck after the aborted resize, I think resize2fs doesn't end gracefully. So retrying with another amount of memory can be harmful.Another option is to first copy over the data to another disk, and then simply recreate this filesystem.You can pull this disk, put in the 4TB disk, and create a volume on it. When that is done, you can add this disk, create the loopdevice, mount that, and copy everything over. After that you can create a new volume on this disk, or put it in an USB enclosure for an external backup.How about that?0
-
Whatever will make the Data expressible again! Would it work just like that or do i have to change things about the Filesystem, once its copied?
Could you point me in the direction where i would find a tutorial for that? Do i have to do it over the WEB-UI or Telnet?
If you could help me, that would be a blast!0 -
The loop device should be mountable.So basically, the creation of a volume on your 2nd disk shouldn't be a problem. When you have put both disks in nas, you can use
<div>cat /proc/partitions <br></div><div>cat /proc/mdstat</div>
to find out the device name of the old disk, and see if it has an md device which has to be stopped first.Then you can stop the md device, if needed, and create the loopdevice, like you did before. Only /dev/md0 might be changed in /dev/md1, and /dev/sda2 in /dev/sdb2.Then mount the loopdevice:<div>mkdir /mnt/mountpoint</div><div><br></div><div>mount -o ro /dev/loop1 /mnt/mountpoint</div>
When that has succeeded find the mountpoint of the other md device:cat /proc/mounts | grep /dev/md
It's /i-data/<some-hex-code>Now enter some share, for instance admin, and copy everything over:<div>cd /i-data/<some-hex-code>/admin/</div><div><br></div><div>cp -av /mnt/mountpoint/* .</div><div></div>
This will take several hours, I think, and you'll have to keep the telnet session open.0
Categories
- All Categories
- 415 Beta Program
- 2.4K Nebula
- 151 Nebula Ideas
- 98 Nebula Status and Incidents
- 5.7K Security
- 277 USG FLEX H Series
- 277 Security Ideas
- 1.4K Switch
- 74 Switch Ideas
- 1.1K Wireless
- 42 Wireless Ideas
- 6.4K Consumer Product
- 250 Service & License
- 395 News and Release
- 85 Security Advisories
- 29 Education Center
- 10 [Campaign] Zyxel Network Detective
- 3.6K FAQ
- 34 Documents
- 34 Nebula Monthly Express
- 85 About Community
- 75 Security Highlight