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
Was it a mistake to change the partition format to ext4 and re-size
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
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"
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
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
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