- Try changing the UUIDs on the new disk to match those of the old disk and leave fstab unchanged.
- As you mentioned, try not changing to ext4.
- Try to get help at http://forum.qnap.com/viewforum.php?f=147
- Get a serial console and run 'update-initramfs -u && flash-kernel' from within initramfs-tools accordning to http://www.cyrius.com/journal/debian/orion/d-link/dns-323/fix-initramfs-tools.tbmI'm not sure why it does not work for you. I have done this several time with HDDs and USB thumb drives, albeit not with SSDs.Good luck!/BjörnIf that does not work you could try a serial console andOn Wed, May 30, 2012 at 11:31 PM, David Pottage <firstname.lastname@example.org> wrote:
It is not working for me.
To summarize what I have done, I setup my SSD with the same partition as the original hard drive, but with different sizes, to reflect usage. I kept the /boot partition as ext2, and the root partition as ext3, but changed the format of all other partitions to ext4 so as to have support for trim.
When I put the SSD into my Qnap device, and turned it on. I got the status light slow flashing red and green, and LAN light flickering. The box did not respond to pings, or SSH access. I left it in that state for 5 minutes in case it was slow booting.
Thing I have tried:
I ran fsck on all partitions to check for errors.
I changed the mount options in /etc/fstab to remove anything problematic (eg discard on an ext2 partition)
I have double checked that the UUIDs are correct.
I have connected the SSD to the Qnap device's eSATA port, and confirmed that the Qnap box can access the SSD and mount the partitions.
Was it a mistake to change the partition format to ext4 and re-size them?
Could there be an issue with the partition layout that is preventing uboot or the kernel from finding what it needs?
I have enabled boot logging, but a boot log was not created. Presumably this means that the boot process failed before it could mount /var
Can you suggest anything else I might try?
On 27/05/2012 20:58, Björn Wetterbom wrote:
Don't worry, just run rsync -aHX (iirc) from the old disk to the new and update fstab with new UUIDs and it will work. I've done it on several occasions.
The kernel is stored in flash memory (if you watch kernel updates, they are always finalized with flash-kernel), so the mbr of the disk is not used.
A brief explanation, I know, but the keyboard of my phone isn't that comfy. Use Google for more info.
(Sent from my phone.)On May 27, 2012 5:06 PM, "David Pottage" <email@example.com> wrote:
I have a Qnap TS-110, which I am using as a home server for the past year. It runs Debian Squeeze.
I have decided to replace the internal hard drive with a much smaller SSD, but I am concerned about how the Kirkwood boot sequence works, and how I make sure that u-boot can find the kernel image and other necessary files to boot on the new SSD drive.
Many years ago, when I used desktop based linux distros that used lilo to boot, I recall that the boot block contained raw hard drive offsets to the kernel an intrid image files, and if you moved the files on disc without re-writing the lilo boot block then the boot sequence would fail as the kernel would not be found, despite the fact that the pathname remained the same.
Is there a similar issue with u-boot on Kirkwood devices? Do I need to make an exact copy of the boot partition in order for it to work, or is u-boot able to mount and understand the ext2 filesystem and find the boot image by pathname?
Are there any similar issues with the root or any other partition on the system?
To UNSUBSCRIBE, email to debian-arm-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org
Archive: 4FC23E99.email@example.com" target="_blank">http://lists.debian.org/4FC23E99.firstname.lastname@example.org