Update: point 1 below should be the correct answer. A background is at http://forum.qnap.com/viewtopic.php?f=147&t=58300 .
Please report back. /B On Thu, May 31, 2012 at 9:11 AM, Björn Wetterbom <bjohv...@gmail.com> wrote: > > 1. Try changing the UUIDs on the new disk to match those of the old > disk and leave fstab unchanged. > 2. As you mentioned, try not changing to ext4. > 3. Try to get help at http://forum.qnap.com/viewforum.php?f=147 > 4. 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.tbm > > I'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örn > > If that does not work you could try a serial console and > > > On Wed, May 30, 2012 at 11:31 PM, David Pottage > <da...@electric-spoon.com>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? >> >> Thanks. >> >> >> 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. >> >> Good luck. >> >> (Sent from my phone.) >> On May 27, 2012 5:06 PM, "David Pottage" <da...@chrestomanci.org> wrote: >> >>> Hello >>> >>> 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? >>> >>> Thank you. >>> >>> -- >>> David Pottage >>> >>> >>> -- >>> To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org >>> with a subject of "unsubscribe". Trouble? Contact >>> listmas...@lists.debian.org >>> Archive: http://lists.debian.org/4fc23e99.1040...@chrestomanci.org >>> >>> >> >
