April 25, 2017, 05:38:09 am
News:
Pages: [1]
Print
Author Topic: HOWTO: Putting LINK on internal HDD  (Read 3065 times)
manthony121
Newbie
*
Posts: 37


View Profile
« on: January 10, 2010, 10:09:11 pm »

This file documents installation of Link on an internal HDD.

Moving the Link OS to an internal HDD need not be complex or difficult.
One option is to just "clone" the USB jump drive onto the HDD, and perhaps
add a few new partitions for swap space and a data directory.  As a long
time Linux user, I have some preferences for my HDD partitioing scheme.
In particular, I don't like my root filesystem, "/", to be almost full
right from the start, as it is with the 4G partition.

Run the command:
Code:
du --max-depth=1 / |sort -gr

This will show that most of the space used on the root partition is being
used by the "/usr" directory.  This means that you can "clone" the USB
drive onto the HDD, create a new partition for the "/usr" directory tree,
and move the original "/usr" to its own partition, thus freeing up most
of the space on the root partition.  This can be done on a  running
system without breaking anything.  You may also want to add a swap
partition, and have a separate partition for "/home". Here are the
details:

With the LINK turned off (duh!), install the HDD.  I used a 320G
SATA drive that cost all of $45 at Newegg.com, and plugged it into
SATA socket 1.  Now, turn on the LINK to start the boot.  If you get
an error saying "Non-system disk", you have to massage the BIOS a little
to get started.


Changing BIOS boot parameters

Reboot, and when the ASUS splash screen appears, press and hold the
'Del' key.  This puts you in the BIOS configuration utility.  Press the
right arrow key until "Boot" is highlighted, and select "Hard Disk Drives"
(I have the nVidia version of the ASUS motherboard.  If you have the
ATI version, M3A78-VM, the BIOS options may be slightly different, but
you should be able to figure it out.)

With the USB jump drive plugged in, and the new SATA drive installed,
it may have the SATA drive as the first choice for boot device.  Change
it so that you boot from the USB drive, save changes and exit.  The
system should reboot as normal.

Open a terminal screen for what follows:

If you haven't already created a password for "root", do it now.
It's a lot more convenient (and potentially dangerous!) than having to
type "sudo" in front of every command.

Run:
Code:
sudo passwd root
Enter your password, ("ntv" is the default)
Pick a password, like "ntv", and enter it when prompted

Change your starting directory, so it is not "/home/neurosuser/".
(You'll see why later), and become root:

Code:
cd /
su -

Give the password, and you are now root until you press ^D (hold down
the Ctrl key and press D) when you are done to get back to being
"neurosuser."


Run:
Code:
fdisk -l

This should verify that the Link is running from /dev/sdb2, and that
the HDD is /dev/sda with no partition table.

Run: 
Code:
dd if=/dev/sdb of=/dev/sda bs=1M

This will take a bit of time to complete.

Run:
Code:
fdisk -l

This should verify that the HDD now has a single partition, /dev/sda2, that
is about 4G in size, and the rest unallocated.

Use your favorite disk partitioning program to create whatever additional
partitions you like.  I used plain 'ol "fdisk", and did as follows: (Sizes are
approximate; mount points are just a reminder)

/dev/sda2     4G        /          primary
/dev/sda3     2G        swap       primary
/dev/sda4   300G        extended   extended
/dev/sda5     4G        /usr       logical
/dev/sda6    10G        /home      logical
/dev/sda7   286G        /pub       logical

for each of the new partitions, you must create a filesystem.  I used "ext3"
with default parameters.  If you are using a different partitioning program,
it may have done this for you already. Otherwise:

Code:
for i in 5 6 7; do  mkfs -t /dev/sda$i; done
swapoff -a; mkswap /dev/sda3; swapon -a

Mount the new partitions so you can write to them:

Code:
mkdir /mnt/sda{5,6}
mount /dev/sda5 /mnt/sda5
mount /dev/sda6 /mnt/sda6

Now, we are going to copy the "/usr" directory tree to its new future home:.

Code:
rsync -a /usr/ /mnt/sda5

( NOTE!  The trailig "/" after "/usr" is VERY important!)

Code:
rsync -a /home/ /mnt/sda6

Next, we will delete the old "/usr" tree, and mount the new one in its place:

Code:
rm -fr /usr
umount /mnt/sda5
mount /dev/sda5 /usr

I have not been able to figure a way to delete the old "/home" directory tree,
as there are open files on it.  If you are able to log in as "root" from a
command line interface when booting, you should be able to do so. On my system,
with the Grub2 boot manager, you hold down the "Shift" key as the system starts
to bring up the boot menu.  However, when I select "rescue mode", the on-screen
menu gets screwed up, and I can't continue.  (Fixing that will be my next
project.)  In the meantime, mounting the new "/home" over the old one won't
hurt anything, it just takes up a little extra disk space.  Fortunately, it is
not much.

Delete what you can: (Don't mind the error messages)
Code:
rm -fr /home
umount /mnt/sda6
mount /dev/sda6 /home

Now, we need to tweak the file "/etc/fstab" to make our new partitions mount
automatically when they system boots.  The following short script will create
some new entries at the end of "/etc/fstab".
Code:
cd /etc
for i in 3 5 6 7; do echo -e "# /dev/sda$i\nUUID=$(blkid -o value /dev/sda$i)" >> fstab

Now we need to finish those new entries.  Open "fstab" with you favorite
text editor.  There should be several new lines at the end of the file, somewhat
like this:


# /dev/sda3
UUID=long-string-of-gobbeldy-goop
swap
# /dev/sda5
UUID=more-gobbeldy-goop
ext2
ext3
# /dev/sda6
UUID=...
ext2
ext3
# /dev/sda7
UUID=...
ext2
ext3


These lines need to be edited to look like this:

# /dev/sda3
UUID=....          none         swap      sw             0  0
# /dev/sda5
UUID=....          /usr         ext3      relatime       0  2
# /dev/sda6
UUID=....          /home        ext3      relatime       0  2
# /dev/sda7
UUID=....          /pub         ext3      relatime       0  2

save the file and exit.

That's it!  Shut down the system, remove the jump drive, and power
back on.  It should boot normally.  From a terminal screen:

Run:
Code:
mount|grep sd[a-z]

You should get something close to:

/dev/sda2 on / type ext2 (rw,errors=remount-ro)
/dev/sda5 on /usr type ext3 (rw,relatime)
/dev/sda6 on /home type ext3 (rw,relatime)
/dev/sda7 on /pub type ext3 (rw,relatime)

Run:
Code:
df -h

You should see something close to:

Filesystem            Size  Used Avail Use% Mounted on
/dev/sda2             3.7G  712M  2.8G  20% /
udev                  944M  252K  944M   1% /dev
none                  944M   24K  944M   1% /dev/shm
tmpfs                 944M   60K  944M   1% /tmp
tmpfs                 944M  100K  944M   1% /var/run
none                  944M     0  944M   0% /var/lock
none                  944M     0  944M   0% /lib/init/rw
/dev/sda5             4.0G  2.1G  1.7G  56% /usr
/dev/sda6             9.9G  241M  9.2G   3% /home
tmpfs                 944M  528K  943M   1% /home/neurosuser/.mozilla/firefox/gismclso.default/Cache
/dev/sda7             274G  4.7G  256G   2% /pub

This shows that both / and /usr have lots of free space, giving you much
more flexibility to add new software packages and upgrades.

The only other thing you may want to do is to make the "/pub" directory
available to everyone:  As root:
Code:
chmod 777 /pub
Enjoy.

Logged
manthony121
Newbie
*
Posts: 37


View Profile
« Reply #1 on: January 10, 2010, 10:29:28 pm »

I should have pointed out in the beginning of the "HOWTO" post, that the reason I couldn't just clone the LINK to the HDD, then use a partition editor to resize/enlarge the partition, was that I was getting "Bad superblock" errors whenever I tried doing that.  I don't know if that is unique to the latest LINK image, but after a few days of experimenting, the procedure posted was the best compromise I could come up with.
Logged
greyback
Administrator
Hero Member
*****
Posts: 1639


View Profile
« Reply #2 on: January 22, 2010, 03:32:43 pm »

Wow, this is an excellent guide! Thanks for all your effort!
-G
Logged
adl73x
Newbie
*
Posts: 9


View Profile
« Reply #3 on: May 03, 2011, 04:12:15 pm »

Thank you, manthony121 for your instructions.  They were very useful in my successful transfer of the 1.502n image to a new sata HDD on the Link.

I did encounter a few errors and other observations which hopefully I can help anyone else following to avoid.  

Just installing the HDD, it was not immediately obvious that I'd need not only to take off the top cover, but also remove the drive housing, and to get that off, you need to remove the front panel.  The three latches at the top of the front panel can be easily released, but the plastic catches toward the bottom of the front panel are not easy to remove without breaking.

Anyway, once you have all that out, the SATA ports are accessible, and there is a single SATA power cable already in the unit available for use.

Put it all back together and you're ready to begin.




Run:  
Code:
dd if=/dev/sdb of=/dev/sda bs=1M

This will take a bit of time to complete.


This worked for me although as has been noted in other threads on this forum, there are risks in dd copying from the USB device while it is booted and in use.



Mount the new partitions so you can write to them:

Code:
mkdir /mnt/sda{5,6}
mount /dev/sda5 /mnt/sda5
mount /dev/sda6 /mnt/sda6


Really, at this point you should also mount the original partition that was created by the dd command as a copy of the contents of the USB drive, and now should be /dev/sda2.

The reason is that for all the instructions that follow, the operations should be on the copy of the image that is now on your hard drive.  If you follow the instructions as written, you'll be deleting data from the currently booted environment which is the USB drive, which is not the intention.

Getting /dev/sda2 to mount was problematic.  Firstly, as a dd copy of the USB, it also copies the UUID of the USB partition.  XFS rightly baulks at mounting the same UUID twice. (dmesg let me know that was the problem with the attempted mount).

This can be fixed by changing the UUID using xfs_admin.  However, if you change a UUID and want to boot from that device, both fstab and grub.cfg will also need to be changed to refer to the new UUID.
Code:
xfs_admin -U generate /dev/sda2
Clearing log and setting UUID
writing all SBs
new UUID = 01fbb5f2-1ee0-4cce-94fc-024efb3cd3a4

You might then be able to mount /dev/sda2.  I couldn't as there were still journaling errors from the dd copy.  xfs_repair fixed these.

Code:
xfs_repair -v -L /dev/sda2

Now I could mount the image copy as well as my new partitions, so to modify the instructions above

Code:
mkdir /mnt/sda{2,5,6}
mount /dev/sda2 /mnt/sda2
mount /dev/sda5 /mnt/sda5
mount /dev/sda6 /mnt/sda6


Next, we will delete the old "/usr" tree, and mount the new one in its place:


This where we need to delete the correct "old" data.  It should be

Code:
rm -fr /mnt/sda2/usr
umount /mnt/sda5
mount /dev/sda5 /usr

and similarly:

Code:
rm -fr /mnt/sda2/home
umount /mnt/sda6
mount /dev/sda6 /home

I didn't have any problem deleting this HDD copy of home because it wasn't the one in use at the time (remember, it's still the USB that is booted and defining your working environment at this point)


Now, we need to tweak the file "/etc/fstab" to make our new partitions mount
automatically when they system boots.  The following short script will create
some new entries at the end of "/etc/fstab".


So we edit the correct fstab, change the following to:

Code:
cd /mnt/sda2/etc
for i in 3 5 6 7; do echo -e "# /dev/sda$i\nUUID=$(blkid -o value /dev/sda$i)" >> fstab

When you edit the /mnt/sda2/etc/fstab file, remember also to change the UUID of the / on /dev/sda2 mount point to the new UUID you created earlier.  Then proceed as manthony121 suggested to reformat the lines for swap, /usr, /home and /pub

I mentioned you also need to update the UUID of /dev/sda2 in the grub.cfg file.  (Lucid Lynx uses grub2 which does not have a simple menu.lst file, like plain old grub.  Instead the grub.cfg is normally generated by the update_grub command).  This will be the one time I will suggest editing a file that begins 'do not edit this file'....

edit /mnt/sda2/boot/grub/grub.cfg to replace all references to the old UUID of the USB with the new UUID created above.  There are quite a few of them to replace.  After you've successfully booted your new HDD environment, you can run update_grub and ease your conscience.

After that it all worked fine.
« Last Edit: May 07, 2011, 05:11:30 am by adl73x » Logged
Jake019
Newbie
*
Posts: 1



View Profile WWW
« Reply #4 on: November 15, 2013, 02:58:24 am »

The steps on how to link are cleared to me. Yet, I'm afraid that I may fail to configure BIOS properly.
Logged
Pages: [1]
Print
Jump to: