[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: QNap Hard drive upgrade (Boot Sequence)

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 .

Please report back.


On Thu, May 31, 2012 at 9:11 AM, Björn Wetterbom <bjohv052@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!


If that does not work you could try a serial console and 

On Wed, May 30, 2012 at 11:31 PM, David Pottage <david@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?


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:

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

Reply to: