Point 1 was the correct answer. Thank you.
I changed the UUIDs on the root and boot volumes, put the SSD back in my
TS-110, and it worked.
(I did not need to change the UUIDs of the other volumes, or re-format
them back to ext3).
One for the FAQ over at http://www.cyrius.com/debian/kirkwood/ I think.
On 31/05/12 08:23, Björn Wetterbom wrote:
Update: point 1 below should be the correct answer. A background is at
http://forum.qnap.com/viewtopic.php?f=147&t=58300
<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 <[email protected]
<mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>> 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"
<[email protected] <mailto:[email protected]>> 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
[email protected]
<mailto:[email protected]>
with a subject of "unsubscribe". Trouble? Contact
[email protected]
<mailto:[email protected]>
Archive:
http://lists.debian.org/[email protected]
