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" <
david@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-REQUEST@lists.debian.org
with a subject of "unsubscribe".
Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/4FC23E99.1040103@chrestomanci.org