Sometimes my internet speed becomes slow when I use Fedora after a system reboot. Once this happens, I experienced the effect even though all the network related applications are closed. My internet connection is not a super fast, so it annoyed me a lot. I wanted to find out the reason behind this issue.
Step 1: use netstat to identify the PID/applications which have opened TCP connections,
[root@desktop9 ~]# netstat -anp -t
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 192.168.0.1:53 0.0.0.0:* LISTEN 1252/dnsmasq
tcp 13 0 192.168.1.9:48208 192.168.1.50:445 CLOSE_WAIT 6776/gvfsd-smb
tcp 0 0 192.168.1.9:44632 137.189.4.14:80 ESTABLISHED 10934/python
tcp 0 0 192.168.1.9:44635 137.189.4.14:80 CLOSE_WAIT 10934/python
tcp 0 0 192.168.1.9:44690 137.189.4.14:80 CLOSE_WAIT 10934/python
tcp 13 0 192.168.1.9:36304 192.168.1.50:139 CLOSE_WAIT 6769/gvfsd-smb-brow
The output shows that the process 10934/python has a established connection with destination 137.189.4.14:80.
Step 2: Use ps command to find out more information of this process
[root@desktop9 ~]# ps -efw | grep 10934
root 10934 1 0 18:56 ? 00:00:00 /usr/bin/python -OO /usr/bin/dnf -v makecache timer
root 11204 11153 0 19:02 pts/0 00:00:00 grep --color=auto 10934
The output shows the culprit. it was "/usr/bin/dnf -v makecache timer"
The man page of dnf describes makecache downloads and caches in binary format metadata for all known repos available in the system.
Man page output:
dnf [options] makecache
Downloads and caches in binary format metadata for all known repos. Tries to avoid downloading whenever possible (e.g. when the local metadata
hasn't expired yet or when the metadata timestamp hasn't changed).
dnf [options] makecache timer
Like plain makecache but instructs DNF to be more resource-aware, meaning will not do anything if running on battery power and will terminate
immediately if it's too soon after the last successful makecache run (see dnf.conf(8), metadata_timer_sync).
It seems that the dnf makecache is scheduled to run after every reboot. I decided to disable this and do manual metadata updates whenever it's required.
Command to disable dnf-makecache.service:
systemctl disable dnf-makecache.service
Update 1: Disable the dnf-makecache.timer as well. Otherwise the service will be restarted.
systemctl disable dnf-makecache.timer
Update 2: I started using Fedora 29 Server edition and noted packagekit is also involved in this.
Therefore I disabled them as well,
systemctl disable packagekit.service
systemctl disable packagekit-offline-update.service
Saturday, September 5, 2015
Sunday, August 2, 2015
TestDisk, The best data recovery tool I have ever used
One of my friends had a problem with his portable hard disk (WD10TMVW) which appeared to be an issue with a corrupted partition table. It was not detected by Windows. Fortunately it was detected by Fedora, but it was not auto mounted. It was appeared only in /dev directory.
I tried many data recovery tools to retrieve the data, but all the tools failed, many of them even failed to recognize the disk. However "TestDisk", in fact photo_rec was able to detect the disk and recover few files. after recovering few files, it went to an endless loop. I believe this was happened due to some bad sectors.
So I went though their forum and found out that editing a status file (i.e. photorec.ses ) you can start recovery from a given sector. this status file is used by the tool to resume previously stopped recovery session.
The second line of this file keeps the last processed sector.
If you encounter the endless loop, you can change the highlighted value and restart the recovery. You must choose Y when the tool asks to continue previous session.
2nd line of photorec.ses generated by photo_rec:
/dev/sdc partition_none,255,blocksize,512,fileopt,fat,disable,ext,disable,options,paranoid,keep_corrupted_file_no,wholespace,search,status=ext2_off,185497,inter
Whenever you encounter the endless loop, you have to do this modification and restart the recovery.
So, eventually I was able to recover most of the data from the disk, thank to this great tool.
Home page of TestDisk: http://www.cgsecurity.org/wiki/TestDisk
I tried many data recovery tools to retrieve the data, but all the tools failed, many of them even failed to recognize the disk. However "TestDisk", in fact photo_rec was able to detect the disk and recover few files. after recovering few files, it went to an endless loop. I believe this was happened due to some bad sectors.
So I went though their forum and found out that editing a status file (i.e. photorec.ses ) you can start recovery from a given sector. this status file is used by the tool to resume previously stopped recovery session.
The second line of this file keeps the last processed sector.
If you encounter the endless loop, you can change the highlighted value and restart the recovery. You must choose Y when the tool asks to continue previous session.
2nd line of photorec.ses generated by photo_rec:
/dev/sdc partition_none,255,blocksize,512,fileopt,fat,disable,ext,disable,options,paranoid,keep_corrupted_file_no,wholespace,search,status=ext2_off,185497,inter
Whenever you encounter the endless loop, you have to do this modification and restart the recovery.
So, eventually I was able to recover most of the data from the disk, thank to this great tool.
Home page of TestDisk: http://www.cgsecurity.org/wiki/TestDisk
Sunday, April 26, 2015
Download video lectures from Coursera
Today I came a cross Coursera website and found some great video tutorials on computer science. After going through some of the available courses, I decided to download all the files belongs to a course. However It was annoying to click on each link to download video, power point presentation, PDF document and etc. So I did a google search and found out that there are plugins for common browsers and download managers which can be used to download all the files in one go. Anyway instead of using the already available options, I decided to write my own script to download the files as I had time to kill. Writing your own software for already available solutions may not make much sense. But it will help you to learn some thing new.
I tested the script "High Performance Scientific Computing" and "The Hardware/Software Interface" pages and worked perfectly.
To download the files using the script, you want two local files.
1. Cookies information after you logged in to the Coursea site. This information can be extracted using a browser plugin. I used a plugin called "cookie.txt export". Save this information to a file called "cookies.txt".
2. Course page (html) where the links you want to get downloaded listed.
You can download the script from here,
Link: https://sites.google.com/site/blogswapoff/coursera_downloader.tar.gz?attredirects=0&d=1
Copy the script where the html page and the cookies.txt are copied. Then execute the script.
You need to provide the file name of the html page as the first argument.
E.g.: nohup ./coursera_downloader.pl Coursera_hpsc.html &
As usual, the script was executed on my Buffalo Linkstation NAS. Use nohup when you execute the script so that you can push the script to background and close the terminal if required.
root@LS-VL406:/mnt/disk1/share/downloads/courseea_files# ls -ltr
-rw-rw-r-- 1 root root 1731 Apr 26 09:37 cookies.txt
-rw-r----- 1 root root 322767 Apr 26 16:29 Coursera_hpsc.html
-rwxr-xr-x 1 root root 1785 Apr 26 17:43 coursera_downloader.pl
drwxr-xr-x 2 root root 97 Apr 26 19:26 High_Performance_Scientific_Computing_Course_Overview
drwxr-xr-x 2 root root 4096 Apr 26 19:29 Week_1_-_Introduction_to_the_Course_amp_Lecture_1
drwxr-xr-x 2 root root 4096 Apr 26 19:33 Week_1_-_Lecture_2_Binary_storage_and_version_control
drwxr-xr-x 2 root root 4096 Apr 26 19:36 Week_1_-_Lecture_3_Demo_of_Python_and_git
drwxr-xr-x 2 root root 4096 Apr 26 19:40 Week_2_-_Lecture_4_Continued_demo_of_Python_and_git
drwxr-xr-x 2 root root 4096 Apr 26 19:43 Week_2_-_Lecture_5_Python_language_features
drwxr-xr-x 2 root root 4096 Apr 26 19:47 Week_2_-_Lecture_6_NumPy_and_timing_Python_code
drwxr-xr-x 2 root root 4096 Apr 26 19:50 Week_2_-_Cloud_Computing_Amazon_Web_Service_Supplemental_Information
drwxr-xr-x 2 root root 4096 Apr 26 19:53 Week_3_-_Lecture_7_Python_debugging_and_Fortran_intro
drwxr-xr-x 2 root root 4096 Apr 26 19:56 Week_3_-_Lecture_8_Fortran_subroutines_functions_and_arrays
drwxr-xr-x 2 root root 4096 Apr 26 19:59 Week_3_-_Lecture_9_Multi-file_codes_and_Makefiles
drwxr-xr-x 2 root root 4096 Apr 26 20:02 Week_4_-_Lecture_10_Fortran_modules_and_Newtons_method
drwxr-xr-x 2 root root 4096 Apr 26 20:06 Week_4_-_Lecture_11_Computer_architecture_and_memory_optimization
drwxr-xr-x 2 root root 4096 Apr 26 20:09 Week_4_-_Lecture_12
drwxr-xr-x 2 root root 4096 Apr 26 20:12 Week_5_-_Lecture_13
drwxr-xr-x 2 root root 4096 Apr 26 20:16 Week_5_-_Lecture_14
drwxr-xr-x 2 root root 4096 Apr 26 20:17 Week_5_-_Lecture_15
drwxr-xr-x 2 root root 4096 Apr 26 20:20 Week_6_-_Lecture_16
drwxr-xr-x 2 root root 4096 Apr 26 20:22 Week_6_-_Lecture_17
drwxr-xr-x 2 root root 4096 Apr 26 20:26 Week_6_-_Lecture_18
drwxr-xr-x 2 root root 4096 Apr 26 20:30 Week_7_-_Lecture_19
drwxr-xr-x 2 root root 4096 Apr 26 20:33 Week_7_-_Lecture_20
drwxr-xr-x 2 root root 4096 Apr 26 20:35 Week_7_-_Lecture_21
drwxr-xr-x 2 root root 4096 Apr 26 20:38 Week_8_-_Lecture_22
drwxr-xr-x 2 root root 4096 Apr 26 20:39 Week_8_-_Lecture_23
-rw------- 1 root root 3386311 Apr 26 20:39 nohup.out
I tested the script "High Performance Scientific Computing" and "The Hardware/Software Interface" pages and worked perfectly.
To download the files using the script, you want two local files.
1. Cookies information after you logged in to the Coursea site. This information can be extracted using a browser plugin. I used a plugin called "cookie.txt export". Save this information to a file called "cookies.txt".
2. Course page (html) where the links you want to get downloaded listed.
You can download the script from here,
Link: https://sites.google.com/site/blogswapoff/coursera_downloader.tar.gz?attredirects=0&d=1
Copy the script where the html page and the cookies.txt are copied. Then execute the script.
You need to provide the file name of the html page as the first argument.
E.g.: nohup ./coursera_downloader.pl Coursera_hpsc.html &
root@LS-VL406:/mnt/disk1/share/downloads/courseea_files# ls -ltr
-rw-rw-r-- 1 root root 1731 Apr 26 09:37 cookies.txt
-rw-r----- 1 root root 322767 Apr 26 16:29 Coursera_hpsc.html
-rwxr-xr-x 1 root root 1785 Apr 26 17:43 coursera_downloader.pl
drwxr-xr-x 2 root root 97 Apr 26 19:26 High_Performance_Scientific_Computing_Course_Overview
drwxr-xr-x 2 root root 4096 Apr 26 19:29 Week_1_-_Introduction_to_the_Course_amp_Lecture_1
drwxr-xr-x 2 root root 4096 Apr 26 19:33 Week_1_-_Lecture_2_Binary_storage_and_version_control
drwxr-xr-x 2 root root 4096 Apr 26 19:36 Week_1_-_Lecture_3_Demo_of_Python_and_git
drwxr-xr-x 2 root root 4096 Apr 26 19:40 Week_2_-_Lecture_4_Continued_demo_of_Python_and_git
drwxr-xr-x 2 root root 4096 Apr 26 19:43 Week_2_-_Lecture_5_Python_language_features
drwxr-xr-x 2 root root 4096 Apr 26 19:47 Week_2_-_Lecture_6_NumPy_and_timing_Python_code
drwxr-xr-x 2 root root 4096 Apr 26 19:50 Week_2_-_Cloud_Computing_Amazon_Web_Service_Supplemental_Information
drwxr-xr-x 2 root root 4096 Apr 26 19:53 Week_3_-_Lecture_7_Python_debugging_and_Fortran_intro
drwxr-xr-x 2 root root 4096 Apr 26 19:56 Week_3_-_Lecture_8_Fortran_subroutines_functions_and_arrays
drwxr-xr-x 2 root root 4096 Apr 26 19:59 Week_3_-_Lecture_9_Multi-file_codes_and_Makefiles
drwxr-xr-x 2 root root 4096 Apr 26 20:02 Week_4_-_Lecture_10_Fortran_modules_and_Newtons_method
drwxr-xr-x 2 root root 4096 Apr 26 20:06 Week_4_-_Lecture_11_Computer_architecture_and_memory_optimization
drwxr-xr-x 2 root root 4096 Apr 26 20:09 Week_4_-_Lecture_12
drwxr-xr-x 2 root root 4096 Apr 26 20:12 Week_5_-_Lecture_13
drwxr-xr-x 2 root root 4096 Apr 26 20:16 Week_5_-_Lecture_14
drwxr-xr-x 2 root root 4096 Apr 26 20:17 Week_5_-_Lecture_15
drwxr-xr-x 2 root root 4096 Apr 26 20:20 Week_6_-_Lecture_16
drwxr-xr-x 2 root root 4096 Apr 26 20:22 Week_6_-_Lecture_17
drwxr-xr-x 2 root root 4096 Apr 26 20:26 Week_6_-_Lecture_18
drwxr-xr-x 2 root root 4096 Apr 26 20:30 Week_7_-_Lecture_19
drwxr-xr-x 2 root root 4096 Apr 26 20:33 Week_7_-_Lecture_20
drwxr-xr-x 2 root root 4096 Apr 26 20:35 Week_7_-_Lecture_21
drwxr-xr-x 2 root root 4096 Apr 26 20:38 Week_8_-_Lecture_22
drwxr-xr-x 2 root root 4096 Apr 26 20:39 Week_8_-_Lecture_23
-rw------- 1 root root 3386311 Apr 26 20:39 nohup.out
Monday, March 30, 2015
Linkstation returns "Structure needs cleaning" error message to applications when it started after a power failure
Today, my linkstation was not shutdown cleanly due to power failure.
After bringing it up, it showed some weird behavior. Sometimes it hung and the transmission application showed error message "Structure needs cleaning" for some torrents which were already in the download list.
Anyway I was able to log in to the linkstation and investigate the /var/log/message. It showed that the issue was with the XFS files system of the sda6 partition. You can find out the mount point of the sda6 using mount command or cat /proc/mounts command.
root@LS-VL406:~# cat /proc/mounts
rootfs / rootfs rw 0 0
/dev/root / ext3 rw,relatime,errors=continue,barrier=0,data=writeback 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
udev /dev tmpfs rw,nosuid,relatime,size=10240k,mode=755 0 0
devpts /dev/pts devpts rw,relatime,gid=4,mode=620 0 0
/dev/ram1 /mnt/ram tmpfs rw,relatime,size=15360k 0 0
/dev/sda1 /boot ext3 rw,relatime,errors=continue,barrier=1,data=writeback 0 0
/dev/disk1_6 /mnt/disk1 xfs rw,noatime,attr2,usrquota,grpquota 0 0
/dev/disk1_6 /opt xfs rw,noatime,attr2,usrquota,grpquota 0 0
I unmounted the /mnt/disk1 and executed xfs_repair as the crash report suggested.
Steps I followed to fix the issue,
1. Check whether the /mnt/disk1 is being used. kill or stop processes which are using the partition.
lsof | grep disk1
2. unmount the partition
umount /mnt/disk1
3. repair the partition
xfs_repair /dev/sda6
Then I rebooted the linkstation and it seems that the issue is resolved now.
Information which was available in the /var/log/messages file about the XFS corruption.
Mar 30 22:09:09 LS-VL406 kernel: Backtrace:
Mar 30 22:09:09 LS-VL406 kernel: [<c001b79c>] (dump_backtrace+0x0/0x114) from [<c001b8e4>] (dump_stack+0x18/0x1c)
Mar 30 22:09:09 LS-VL406 kernel: r6:c0481434 r5:c11dc800 r4:c01c870c
Mar 30 22:09:09 LS-VL406 kernel: [<c001b8cc>] (dump_stack+0x0/0x1c) from [<c018564c>] (xfs_error_report+0x54/0x64)
Mar 30 22:09:09 LS-VL406 kernel: [<c01855f8>] (xfs_error_report+0x0/0x64) from [<c01856b8>] (xfs_corruption_error+0x5c/0x78)
Mar 30 22:09:09 LS-VL406 kernel: [<c018565c>] (xfs_corruption_error+0x0/0x78) from [<c01aed28>] (xfs_bmap_read_extents+0x4f8/0x580)
Mar 30 22:09:09 LS-VL406 kernel: r6:00000000 r5:00000000 r4:c22bf000
Mar 30 22:09:09 LS-VL406 kernel: [<c01ae830>] (xfs_bmap_read_extents+0x0/0x580) from [<c01c870c>] (xfs_iread_extents+0x78/0xe0)
Mar 30 22:09:09 LS-VL406 kernel: [<c01c8694>] (xfs_iread_extents+0x0/0xe0) from [<c01a5dbc>] (xfs_bmapi_read+0xec/0x32c)
Mar 30 22:09:09 LS-VL406 kernel: r7:00000000 r6:c62b6240 r5:00000000 r4:c62b6270
Mar 30 22:09:09 LS-VL406 kernel: [<c01a5cd0>] (xfs_bmapi_read+0x0/0x32c) from [<c0181098>] (__xfs_get_blocks+0x180/0x524)
Mar 30 22:09:09 LS-VL406 kernel: [<c0180f18>] (__xfs_get_blocks+0x0/0x524) from [<c0181494>] (xfs_get_blocks+0x28/0x30)
Mar 30 22:09:09 LS-VL406 kernel: [<c018146c>] (xfs_get_blocks+0x0/0x30) from [<c0109658>] (__block_write_begin+0x1e4/0x4d4)
Mar 30 22:09:09 LS-VL406 kernel: [<c0109474>] (__block_write_begin+0x0/0x4d4) from [<c0109af8>] (block_write_begin+0x54/0x88)
Mar 30 22:09:09 LS-VL406 kernel: [<c0109aa4>] (block_write_begin+0x0/0x88) from [<c01816a0>] (xfs_vm_write_begin+0x48/0x7c)
Mar 30 22:09:09 LS-VL406 kernel: r6:18a07ebd r5:00000000 r4:18a07ebd
Mar 30 22:09:09 LS-VL406 kernel: [<c0181658>] (xfs_vm_write_begin+0x0/0x7c) from [<c00ac70c>] (generic_perform_write+0x198/0x20c)
Mar 30 22:09:09 LS-VL406 kernel: r8:cbd9e000 r7:00000000 r6:18a07ebd r5:00000143 r4:cbd9fd60
Mar 30 22:09:09 LS-VL406 kernel: [<c00ac574>] (generic_perform_write+0x0/0x20c) from [<c00ac7dc>] (generic_file_buffered_write+0x5c/0x90)
Mar 30 22:09:09 LS-VL406 kernel: [<c00ac780>] (generic_file_buffered_write+0x0/0x90) from [<c0186af0>] (xfs_file_buffered_aio_write+0xc0/0x150)
Mar 30 22:09:09 LS-VL406 kernel: r9:cbd9e000 r8:c62b6240 r6:c62b63f8 r5:00000000 r4:18a07ebd
Mar 30 22:09:09 LS-VL406 kernel: [<c0186a30>] (xfs_file_buffered_aio_write+0x0/0x150) from [<c0186f68>] (xfs_file_aio_write+0x174/0x1ec)
Mar 30 22:09:09 LS-VL406 kernel: [<c0186df4>] (xfs_file_aio_write+0x0/0x1ec) from [<c00e11a0>] (do_sync_write+0xa8/0xf0)
Mar 30 22:09:09 LS-VL406 kernel: [<c00e10f8>] (do_sync_write+0x0/0xf0) from [<c00e1a88>] (vfs_write+0xbc/0x150)
Mar 30 22:09:09 LS-VL406 kernel: r8:c000bca8 r7:cbd9ffa8 r6:007a81b0 r5:00010000 r4:c5c81f00
Mar 30 22:09:09 LS-VL406 kernel: [<c00e19cc>] (vfs_write+0x0/0x150) from [<c00e21dc>] (sys_pwrite64+0x80/0x94)
Mar 30 22:09:09 LS-VL406 kernel: r8:c000bca8 r7:000000b5 r6:c5c81f00 r5:00010000 r4:007a81b0
Mar 30 22:09:09 LS-VL406 kernel: [<c00e215c>] (sys_pwrite64+0x0/0x94) from [<c000bb00>] (ret_fast_syscall+0x0/0x2c)
Mar 30 22:09:09 LS-VL406 kernel: r6:00000000 r5:00000000 r4:18a07ebd
Mar 30 22:09:09 LS-VL406 kernel: XFS (sda6): Corruption detected. Unmount and run xfs_repair
After bringing it up, it showed some weird behavior. Sometimes it hung and the transmission application showed error message "Structure needs cleaning" for some torrents which were already in the download list.
Anyway I was able to log in to the linkstation and investigate the /var/log/message. It showed that the issue was with the XFS files system of the sda6 partition. You can find out the mount point of the sda6 using mount command or cat /proc/mounts command.
root@LS-VL406:~# cat /proc/mounts
rootfs / rootfs rw 0 0
/dev/root / ext3 rw,relatime,errors=continue,barrier=0,data=writeback 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
udev /dev tmpfs rw,nosuid,relatime,size=10240k,mode=755 0 0
devpts /dev/pts devpts rw,relatime,gid=4,mode=620 0 0
/dev/ram1 /mnt/ram tmpfs rw,relatime,size=15360k 0 0
/dev/sda1 /boot ext3 rw,relatime,errors=continue,barrier=1,data=writeback 0 0
/dev/disk1_6 /mnt/disk1 xfs rw,noatime,attr2,usrquota,grpquota 0 0
/dev/disk1_6 /opt xfs rw,noatime,attr2,usrquota,grpquota 0 0
root@LS-VL406:~# ls -la /dev/disk1_6
lrwxrwxrwx 1 root root 4 Mar 31 2015 /dev/disk1_6 -> sda6
Steps I followed to fix the issue,
1. Check whether the /mnt/disk1 is being used. kill or stop processes which are using the partition.
lsof | grep disk1
2. unmount the partition
umount /mnt/disk1
3. repair the partition
xfs_repair /dev/sda6
Then I rebooted the linkstation and it seems that the issue is resolved now.
Information which was available in the /var/log/messages file about the XFS corruption.
Mar 30 22:09:09 LS-VL406 kernel: Backtrace:
Mar 30 22:09:09 LS-VL406 kernel: [<c001b79c>] (dump_backtrace+0x0/0x114) from [<c001b8e4>] (dump_stack+0x18/0x1c)
Mar 30 22:09:09 LS-VL406 kernel: r6:c0481434 r5:c11dc800 r4:c01c870c
Mar 30 22:09:09 LS-VL406 kernel: [<c001b8cc>] (dump_stack+0x0/0x1c) from [<c018564c>] (xfs_error_report+0x54/0x64)
Mar 30 22:09:09 LS-VL406 kernel: [<c01855f8>] (xfs_error_report+0x0/0x64) from [<c01856b8>] (xfs_corruption_error+0x5c/0x78)
Mar 30 22:09:09 LS-VL406 kernel: [<c018565c>] (xfs_corruption_error+0x0/0x78) from [<c01aed28>] (xfs_bmap_read_extents+0x4f8/0x580)
Mar 30 22:09:09 LS-VL406 kernel: r6:00000000 r5:00000000 r4:c22bf000
Mar 30 22:09:09 LS-VL406 kernel: [<c01ae830>] (xfs_bmap_read_extents+0x0/0x580) from [<c01c870c>] (xfs_iread_extents+0x78/0xe0)
Mar 30 22:09:09 LS-VL406 kernel: [<c01c8694>] (xfs_iread_extents+0x0/0xe0) from [<c01a5dbc>] (xfs_bmapi_read+0xec/0x32c)
Mar 30 22:09:09 LS-VL406 kernel: r7:00000000 r6:c62b6240 r5:00000000 r4:c62b6270
Mar 30 22:09:09 LS-VL406 kernel: [<c01a5cd0>] (xfs_bmapi_read+0x0/0x32c) from [<c0181098>] (__xfs_get_blocks+0x180/0x524)
Mar 30 22:09:09 LS-VL406 kernel: [<c0180f18>] (__xfs_get_blocks+0x0/0x524) from [<c0181494>] (xfs_get_blocks+0x28/0x30)
Mar 30 22:09:09 LS-VL406 kernel: [<c018146c>] (xfs_get_blocks+0x0/0x30) from [<c0109658>] (__block_write_begin+0x1e4/0x4d4)
Mar 30 22:09:09 LS-VL406 kernel: [<c0109474>] (__block_write_begin+0x0/0x4d4) from [<c0109af8>] (block_write_begin+0x54/0x88)
Mar 30 22:09:09 LS-VL406 kernel: [<c0109aa4>] (block_write_begin+0x0/0x88) from [<c01816a0>] (xfs_vm_write_begin+0x48/0x7c)
Mar 30 22:09:09 LS-VL406 kernel: r6:18a07ebd r5:00000000 r4:18a07ebd
Mar 30 22:09:09 LS-VL406 kernel: [<c0181658>] (xfs_vm_write_begin+0x0/0x7c) from [<c00ac70c>] (generic_perform_write+0x198/0x20c)
Mar 30 22:09:09 LS-VL406 kernel: r8:cbd9e000 r7:00000000 r6:18a07ebd r5:00000143 r4:cbd9fd60
Mar 30 22:09:09 LS-VL406 kernel: [<c00ac574>] (generic_perform_write+0x0/0x20c) from [<c00ac7dc>] (generic_file_buffered_write+0x5c/0x90)
Mar 30 22:09:09 LS-VL406 kernel: [<c00ac780>] (generic_file_buffered_write+0x0/0x90) from [<c0186af0>] (xfs_file_buffered_aio_write+0xc0/0x150)
Mar 30 22:09:09 LS-VL406 kernel: r9:cbd9e000 r8:c62b6240 r6:c62b63f8 r5:00000000 r4:18a07ebd
Mar 30 22:09:09 LS-VL406 kernel: [<c0186a30>] (xfs_file_buffered_aio_write+0x0/0x150) from [<c0186f68>] (xfs_file_aio_write+0x174/0x1ec)
Mar 30 22:09:09 LS-VL406 kernel: [<c0186df4>] (xfs_file_aio_write+0x0/0x1ec) from [<c00e11a0>] (do_sync_write+0xa8/0xf0)
Mar 30 22:09:09 LS-VL406 kernel: [<c00e10f8>] (do_sync_write+0x0/0xf0) from [<c00e1a88>] (vfs_write+0xbc/0x150)
Mar 30 22:09:09 LS-VL406 kernel: r8:c000bca8 r7:cbd9ffa8 r6:007a81b0 r5:00010000 r4:c5c81f00
Mar 30 22:09:09 LS-VL406 kernel: [<c00e19cc>] (vfs_write+0x0/0x150) from [<c00e21dc>] (sys_pwrite64+0x80/0x94)
Mar 30 22:09:09 LS-VL406 kernel: r8:c000bca8 r7:000000b5 r6:c5c81f00 r5:00010000 r4:007a81b0
Mar 30 22:09:09 LS-VL406 kernel: [<c00e215c>] (sys_pwrite64+0x0/0x94) from [<c000bb00>] (ret_fast_syscall+0x0/0x2c)
Mar 30 22:09:09 LS-VL406 kernel: r6:00000000 r5:00000000 r4:18a07ebd
Mar 30 22:09:09 LS-VL406 kernel: XFS (sda6): Corruption detected. Unmount and run xfs_repair
Labels:
Buffalo,
Linkstation,
Linux,
NAS,
XFS,
xfs_repair
Saturday, February 28, 2015
Fix /opt/etc/init.d scripts not executing issue in LS VL Buffalo linkstation
I noticed that the transmission-daemon start up script (S95transmission.sh) added to /opt/etc/init.d/ directory does not get executed when the linkstation is started up.
Let's look at how startup scripts put in to /opt/etc/init.d/ directory are invoked.
1. /etc/init.d/rcS invokes /etc/init.d/rc.optware script. These are the last few lines in the rcS script.
/usr/local/bin/hdd_raid_syncspeed.sh
# Optware setup
[ -x /etc/init.d/rc.optware ] && /etc/init.d/rc.optware start
exit 0
2. Then /etc/init.d/rc.optware script mounts /opt partition and invokes /opt/etc/rc.optware script.
case "$1" in
start)
echo "Starting Optware."
if test -n "${REAL_OPT_DIR}"; then
if ! grep ' /opt ' /proc/mounts >/dev/null 2>&1 ; then
mkdir -p /opt
mount -o bind ${REAL_OPT_DIR} /opt
fi
fi
[ -x /opt/etc/rc.optware ] && /opt/etc/rc.optware
;;
reconfig)
3. This /opt/etc/rc.optware script simply executes scripts matches with S??* located in /opt/etc/init.d/ directory.
#!/bin/sh
# Start all init scripts in /opt/etc/init.d
# executing them in numerical order.
#
for i in /opt/etc/init.d/S??* ;do
# Ignore dangling symlinks (if any).
[ ! -f "$i" ] && continue
case "$i" in
*.sh)
# Source shell script for speed.
(
trap - INT QUIT TSTP
set start
. $i
)
So after some investigations I have found out that rcS script didn't execute it's last few lines. It seemed it exited just after executing /usr/local/bin/hdd_raid_syncspeed.sh line. The simple solution was to move this line to the bottom of the script so that the optware setup is executed first. Now the startup script added to the /opt/etc/rc.optware is started whenever the linkstation is rebooted. :)
The last few lines of rcS after the modification,
#/usr/local/bin/hdd_raid_syncspeed.sh
# Optware setup
[ -x /etc/init.d/rc.optware ] && /etc/init.d/rc.optware start
/usr/local/bin/hdd_raid_syncspeed.sh
exit 0
Let's look at how startup scripts put in to /opt/etc/init.d/ directory are invoked.
1. /etc/init.d/rcS invokes /etc/init.d/rc.optware script. These are the last few lines in the rcS script.
/usr/local/bin/hdd_raid_syncspeed.sh
# Optware setup
[ -x /etc/init.d/rc.optware ] && /etc/init.d/rc.optware start
exit 0
2. Then /etc/init.d/rc.optware script mounts /opt partition and invokes /opt/etc/rc.optware script.
case "$1" in
start)
echo "Starting Optware."
if test -n "${REAL_OPT_DIR}"; then
if ! grep ' /opt ' /proc/mounts >/dev/null 2>&1 ; then
mkdir -p /opt
mount -o bind ${REAL_OPT_DIR} /opt
fi
fi
[ -x /opt/etc/rc.optware ] && /opt/etc/rc.optware
;;
reconfig)
3. This /opt/etc/rc.optware script simply executes scripts matches with S??* located in /opt/etc/init.d/ directory.
#!/bin/sh
# Start all init scripts in /opt/etc/init.d
# executing them in numerical order.
#
for i in /opt/etc/init.d/S??* ;do
# Ignore dangling symlinks (if any).
[ ! -f "$i" ] && continue
case "$i" in
*.sh)
# Source shell script for speed.
(
trap - INT QUIT TSTP
set start
. $i
)
So after some investigations I have found out that rcS script didn't execute it's last few lines. It seemed it exited just after executing /usr/local/bin/hdd_raid_syncspeed.sh line. The simple solution was to move this line to the bottom of the script so that the optware setup is executed first. Now the startup script added to the /opt/etc/rc.optware is started whenever the linkstation is rebooted. :)
The last few lines of rcS after the modification,
#/usr/local/bin/hdd_raid_syncspeed.sh
# Optware setup
[ -x /etc/init.d/rc.optware ] && /etc/init.d/rc.optware start
/usr/local/bin/hdd_raid_syncspeed.sh
exit 0
Labels:
Buffalo,
init.d,
Linkstation,
Linux,
NAS,
shell script
Tuesday, January 20, 2015
Replace Buffalo linkstation ( LS VL ) HDD with a SSD
Replacing a 1 TB HDD with a low capacity SSD in a NAS may not makes sense. Because almost all the time NAS is used as a storage device. I mainly use the device as a torrent downloader so I think I can still live with a NAS which has a low capacity SSD for a while.
Anyway I always wanted to try replacing the original HDD with a new one and experiment. So I decided to replace the original HDD with a SSD as an experiment.
There are pros and cons using a SSD in a NAS. It is obvious that the disk capacity is the major disadvantage. Anyway so far the best things I noticed are the low heat dissemination and low noise.
Here is my experience on replacing the disk in my linkstation.
I did some Google search on how to replace the original HDD and found out that it can be done in several ways.
One method is clone the first partition of the original HDD to the new HDD and then rebuild the partition structure using the LSUpdater.exe. You need a PC to run the LSUpdater.exe.
Another method is create all the partitions manually and clone only the first partition. You don't need LSUpdater.exe for this method.
I tried both the methods and only the latter worked for me.
There are a couple of ways to create partitions and prepare the first partition of the SSD.
One is plug both drives in to a PC or a Linux host and do the partitioning. Another method is use a USB HDD enclosure to connect the SSD to the linkstation via the USB port and do the partitioning and cloning using the linkstation itself. I have a USB HDD enclosure, so I used the latter.
This wiki entry has clear instructions on creating custom partitions. However it does not show you how to create the first partition.
http://buffalo.nas-central.org/wiki/Custom_Partitions_on_the_LS_Pro#HowTo_setup_the_internal_HDD
Let's start. Connect the SSD which is now in the USB HDD enclosure to the USB port of the linkstation. Log in to the linkstation.
The new disk will be appeared as /dev/sdb
root@LS-VL406:~# cat /proc/partitions
major minor #blocks name
31 0 512 mtdblock0
8 0 976762584 sda
8 1 1000448 sda1
8 2 5000192 sda2
8 3 1024 sda3
8 4 1024 sda4
8 5 1000448 sda5
8 6 961750000 sda6
8 16 117220823 sdb
Let's start partitioning from the scratch. Detailed information of usage of these partitions are described in the wiki page mentioned above.
Be careful when you create the partitions. Specially if you use a Linux host, check the terminal which you use to enter fdisk commands. Sometimes the linkstation disconnects SSH connections so that you will be automatically put in to the host's terminal. If you didn't notice that you may end up with partitioning HDD of your host.
root@LS-VL406:~# fdisk /dev/sdb
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel. Changes will remain in memory only,
until you decide to write them. After that the previous content
won't be recoverable.
The number of cylinders for this disk is set to 14593.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)
Warning: invalid flag 0x00,0x00 of partition table 4 will be corrected by w(rite)
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-14593, default 1): <Press Enter>
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-14593, default 14593): +1024M
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 2
First cylinder (126-14593, default 126): <Press Enter>
Using default value 126
Last cylinder or +size or +sizeM or +sizeK (126-14593, default 14593): +3000M
Command (m for help): n
Command action
e extended
p primary partition (1-4)
e
Partition number (1-4): 4
First cylinder (492-14593, default 492): <Press Enter>
Using default value 492
Last cylinder or +size or +sizeM or +sizeK (492-14593, default 14593): <Press Enter>
Using default value 14593
Command (m for help): p
Disk /dev/sdb: 120.0 GB, 120034123264 bytes
255 heads, 63 sectors/track, 14593 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sdb1 1 125 1004031 83 Linux
/dev/sdb2 126 491 2939895 83 Linux
/dev/sdb4 492 14593 113274315 5 Extended
Command (m for help): t
Partition number (1-5): 4
Hex code (type L to list codes): L
0 Empty 1b Hidden Win95 FAT32 9f BSD/OS
1 FAT12 1c Hidden W95 FAT32 (LBA) a0 Thinkpad hibernation
4 FAT16 <32M 1e Hidden W95 FAT16 (LBA) a5 FreeBSD
5 Extended 3c Part.Magic recovery a6 OpenBSD
6 FAT16 41 PPC PReP Boot a8 Darwin UFS
7 HPFS/NTFS 42 SFS a9 NetBSD
a OS/2 Boot Manager 63 GNU HURD or SysV ab Darwin boot
b Win95 FAT32 80 Old Minix b7 BSDI fs
c Win95 FAT32 (LBA) 81 Minix / old Linux b8 BSDI swap
e Win95 FAT16 (LBA) 82 Linux swap be Solaris boot
f Win95 Ext'd (LBA) 83 Linux eb BeOS fs
11 Hidden FAT12 84 OS/2 hidden C: drive ee EFI GPT
12 Compaq diagnostics 85 Linux extended ef EFI (FAT-12/16/32)
14 Hidden FAT16 <32M 86 NTFS volume set f0 Linux/PA-RISC boot
16 Hidden FAT16 87 NTFS volume set f2 DOS secondary
17 Hidden HPFS/NTFS 8e Linux LVM fd Linux raid autodetect
Hex code (type L to list codes): f
Changed system type of partition 4 to f (Win95 Ext'd (LBA))
Command (m for help): p
Disk /dev/sdb: 120.0 GB, 120034123264 bytes
255 heads, 63 sectors/track, 14593 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sdb1 1 125 1004031 83 Linux
/dev/sdb2 126 491 2939895 83 Linux
/dev/sdb4 492 14593 113274315 f Win95 Ext'd (LBA)
Command (m for help): n
Command action
l logical (5 or over)
p primary partition (1-4)
l
First cylinder (492-14593, default 492): <Press Enter>
Using default value 492
Last cylinder or +size or +sizeM or +sizeK (492-14593, default 14593): +300M
Command (m for help): n
Command action
l logical (5 or over)
p primary partition (1-4)
l
First cylinder (529-14593, default 529): <Press Enter>
Using default value 529
Last cylinder or +size or +sizeM or +sizeK (529-14593, default 14593): <Press Enter>
Using default value 14593
Command (m for help): p
Disk /dev/sdb: 120.0 GB, 120034123264 bytes
255 heads, 63 sectors/track, 14593 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sdb1 1 125 1004031 83 Linux
/dev/sdb2 126 491 2939895 83 Linux
/dev/sdb4 492 14593 113274315 f Win95 Ext'd (LBA)
/dev/sdb5 492 528 297171 83 Linux
/dev/sdb6 529 14593 112977081 83 Linux
Command (m for help): t
Partition number (1-6): 5
Hex code (type L to list codes): L
0 Empty 1b Hidden Win95 FAT32 9f BSD/OS
1 FAT12 1c Hidden W95 FAT32 (LBA) a0 Thinkpad hibernation
4 FAT16 <32M 1e Hidden W95 FAT16 (LBA) a5 FreeBSD
5 Extended 3c Part.Magic recovery a6 OpenBSD
6 FAT16 41 PPC PReP Boot a8 Darwin UFS
7 HPFS/NTFS 42 SFS a9 NetBSD
a OS/2 Boot Manager 63 GNU HURD or SysV ab Darwin boot
b Win95 FAT32 80 Old Minix b7 BSDI fs
c Win95 FAT32 (LBA) 81 Minix / old Linux b8 BSDI swap
e Win95 FAT16 (LBA) 82 Linux swap be Solaris boot
f Win95 Ext'd (LBA) 83 Linux eb BeOS fs
11 Hidden FAT12 84 OS/2 hidden C: drive ee EFI GPT
12 Compaq diagnostics 85 Linux extended ef EFI (FAT-12/16/32)
14 Hidden FAT16 <32M 86 NTFS volume set f0 Linux/PA-RISC boot
16 Hidden FAT16 87 NTFS volume set f2 DOS secondary
17 Hidden HPFS/NTFS 8e Linux LVM fd Linux raid autodetect
Hex code (type L to list codes): 82
Changed system type of partition 5 to 82 (Linux swap)
Command (m for help): p
Disk /dev/sdb: 120.0 GB, 120034123264 bytes
255 heads, 63 sectors/track, 14593 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sdb1 1 125 1004031 83 Linux
/dev/sdb2 126 491 2939895 83 Linux
/dev/sdb4 492 14593 113274315 f Win95 Ext'd (LBA)
/dev/sdb5 492 528 297171 82 Linux swap
/dev/sdb6 529 14593 112977081 83 Linux
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table
root@LS-VL406:~#
After few seconds, the linkstation disconnect SSH sessions. Log in to the linkstation again and check the partition structure.
root@LS-VL406:~# partprobe /dev/sdb
root@LS-VL406:~# cat /proc/partitions
major minor #blocks name
31 0 512 mtdblock0
8 0 976762584 sda
8 1 1000448 sda1
8 2 5000192 sda2
8 3 1024 sda3
8 4 1024 sda4
8 5 1000448 sda5
8 6 961750000 sda6
8 16 117220823 sdb
8 17 1004031 sdb1
8 18 2939895 sdb2
8 20 1 sdb4
8 21 297171 sdb5
8 22 112977081 sdb6
Now create xfs file system on the data partition. (i.e. /dev/sdb6)
root@LS-VL406:~# mkfs.xfs /dev/sdb6
meta-data=/dev/sdb6 isize=256 agcount=4, agsize=7061068 blks
= sectsz=512 attr=2, projid32bit=0
data = bsize=4096 blocks=28244270, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0
log =internal log bsize=4096 blocks=13791, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
Then clone the /dev/sda1 to /dev/sdb1
root@LS-VL406:~# dd if=/dev/sda1 of=/dev/sdb1
2000896+0 records in
2000896+0 records out
root@LS-VL406:~# sync
root@LS-VL406:~#
Now switch off the linkstation and unplug the USB device. Remove the original HDD and plug the SSD to the linkstation directly. Then start your linkstation. Now it should be up and running with the SSD without any issue.
We are almost done. There is one thing we need to address. The linkstation needs it's "share" directory in the data partition and we haven't created it yet. We could have created it when we made the xfs file system. However the best way to create it is using the web interface so that it will be created with proper permissions.
So log into the linkstation using the web interface and remove the share directory shown in there and create it again with same permissions. That's it. You have the linkstation up and running with the SSD.
Anyway I always wanted to try replacing the original HDD with a new one and experiment. So I decided to replace the original HDD with a SSD as an experiment.
There are pros and cons using a SSD in a NAS. It is obvious that the disk capacity is the major disadvantage. Anyway so far the best things I noticed are the low heat dissemination and low noise.
Here is my experience on replacing the disk in my linkstation.
I did some Google search on how to replace the original HDD and found out that it can be done in several ways.
One method is clone the first partition of the original HDD to the new HDD and then rebuild the partition structure using the LSUpdater.exe. You need a PC to run the LSUpdater.exe.
Another method is create all the partitions manually and clone only the first partition. You don't need LSUpdater.exe for this method.
I tried both the methods and only the latter worked for me.
There are a couple of ways to create partitions and prepare the first partition of the SSD.
One is plug both drives in to a PC or a Linux host and do the partitioning. Another method is use a USB HDD enclosure to connect the SSD to the linkstation via the USB port and do the partitioning and cloning using the linkstation itself. I have a USB HDD enclosure, so I used the latter.
This wiki entry has clear instructions on creating custom partitions. However it does not show you how to create the first partition.
http://buffalo.nas-central.org/wiki/Custom_Partitions_on_the_LS_Pro#HowTo_setup_the_internal_HDD
Let's start. Connect the SSD which is now in the USB HDD enclosure to the USB port of the linkstation. Log in to the linkstation.
The new disk will be appeared as /dev/sdb
root@LS-VL406:~# cat /proc/partitions
major minor #blocks name
31 0 512 mtdblock0
8 0 976762584 sda
8 1 1000448 sda1
8 2 5000192 sda2
8 3 1024 sda3
8 4 1024 sda4
8 5 1000448 sda5
8 6 961750000 sda6
8 16 117220823 sdb
Let's start partitioning from the scratch. Detailed information of usage of these partitions are described in the wiki page mentioned above.
Be careful when you create the partitions. Specially if you use a Linux host, check the terminal which you use to enter fdisk commands. Sometimes the linkstation disconnects SSH connections so that you will be automatically put in to the host's terminal. If you didn't notice that you may end up with partitioning HDD of your host.
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel. Changes will remain in memory only,
until you decide to write them. After that the previous content
won't be recoverable.
The number of cylinders for this disk is set to 14593.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)
Warning: invalid flag 0x00,0x00 of partition table 4 will be corrected by w(rite)
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-14593, default 1): <Press Enter>
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-14593, default 14593): +1024M
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 2
First cylinder (126-14593, default 126): <Press Enter>
Using default value 126
Last cylinder or +size or +sizeM or +sizeK (126-14593, default 14593): +3000M
Command (m for help): n
Command action
e extended
p primary partition (1-4)
e
Partition number (1-4): 4
First cylinder (492-14593, default 492): <Press Enter>
Using default value 492
Last cylinder or +size or +sizeM or +sizeK (492-14593, default 14593): <Press Enter>
Using default value 14593
Command (m for help): p
Disk /dev/sdb: 120.0 GB, 120034123264 bytes
255 heads, 63 sectors/track, 14593 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sdb1 1 125 1004031 83 Linux
/dev/sdb2 126 491 2939895 83 Linux
/dev/sdb4 492 14593 113274315 5 Extended
Command (m for help): t
Partition number (1-5): 4
Hex code (type L to list codes): L
0 Empty 1b Hidden Win95 FAT32 9f BSD/OS
1 FAT12 1c Hidden W95 FAT32 (LBA) a0 Thinkpad hibernation
4 FAT16 <32M 1e Hidden W95 FAT16 (LBA) a5 FreeBSD
5 Extended 3c Part.Magic recovery a6 OpenBSD
6 FAT16 41 PPC PReP Boot a8 Darwin UFS
7 HPFS/NTFS 42 SFS a9 NetBSD
a OS/2 Boot Manager 63 GNU HURD or SysV ab Darwin boot
b Win95 FAT32 80 Old Minix b7 BSDI fs
c Win95 FAT32 (LBA) 81 Minix / old Linux b8 BSDI swap
e Win95 FAT16 (LBA) 82 Linux swap be Solaris boot
f Win95 Ext'd (LBA) 83 Linux eb BeOS fs
11 Hidden FAT12 84 OS/2 hidden C: drive ee EFI GPT
12 Compaq diagnostics 85 Linux extended ef EFI (FAT-12/16/32)
14 Hidden FAT16 <32M 86 NTFS volume set f0 Linux/PA-RISC boot
16 Hidden FAT16 87 NTFS volume set f2 DOS secondary
17 Hidden HPFS/NTFS 8e Linux LVM fd Linux raid autodetect
Hex code (type L to list codes): f
Changed system type of partition 4 to f (Win95 Ext'd (LBA))
Command (m for help): p
Disk /dev/sdb: 120.0 GB, 120034123264 bytes
255 heads, 63 sectors/track, 14593 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sdb1 1 125 1004031 83 Linux
/dev/sdb2 126 491 2939895 83 Linux
/dev/sdb4 492 14593 113274315 f Win95 Ext'd (LBA)
Command (m for help): n
Command action
l logical (5 or over)
p primary partition (1-4)
l
First cylinder (492-14593, default 492): <Press Enter>
Using default value 492
Last cylinder or +size or +sizeM or +sizeK (492-14593, default 14593): +300M
Command (m for help): n
Command action
l logical (5 or over)
p primary partition (1-4)
l
First cylinder (529-14593, default 529): <Press Enter>
Using default value 529
Last cylinder or +size or +sizeM or +sizeK (529-14593, default 14593): <Press Enter>
Using default value 14593
Command (m for help): p
Disk /dev/sdb: 120.0 GB, 120034123264 bytes
255 heads, 63 sectors/track, 14593 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sdb1 1 125 1004031 83 Linux
/dev/sdb2 126 491 2939895 83 Linux
/dev/sdb4 492 14593 113274315 f Win95 Ext'd (LBA)
/dev/sdb5 492 528 297171 83 Linux
/dev/sdb6 529 14593 112977081 83 Linux
Command (m for help): t
Partition number (1-6): 5
Hex code (type L to list codes): L
0 Empty 1b Hidden Win95 FAT32 9f BSD/OS
1 FAT12 1c Hidden W95 FAT32 (LBA) a0 Thinkpad hibernation
4 FAT16 <32M 1e Hidden W95 FAT16 (LBA) a5 FreeBSD
5 Extended 3c Part.Magic recovery a6 OpenBSD
6 FAT16 41 PPC PReP Boot a8 Darwin UFS
7 HPFS/NTFS 42 SFS a9 NetBSD
a OS/2 Boot Manager 63 GNU HURD or SysV ab Darwin boot
b Win95 FAT32 80 Old Minix b7 BSDI fs
c Win95 FAT32 (LBA) 81 Minix / old Linux b8 BSDI swap
e Win95 FAT16 (LBA) 82 Linux swap be Solaris boot
f Win95 Ext'd (LBA) 83 Linux eb BeOS fs
11 Hidden FAT12 84 OS/2 hidden C: drive ee EFI GPT
12 Compaq diagnostics 85 Linux extended ef EFI (FAT-12/16/32)
14 Hidden FAT16 <32M 86 NTFS volume set f0 Linux/PA-RISC boot
16 Hidden FAT16 87 NTFS volume set f2 DOS secondary
17 Hidden HPFS/NTFS 8e Linux LVM fd Linux raid autodetect
Hex code (type L to list codes): 82
Changed system type of partition 5 to 82 (Linux swap)
Command (m for help): p
Disk /dev/sdb: 120.0 GB, 120034123264 bytes
255 heads, 63 sectors/track, 14593 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sdb1 1 125 1004031 83 Linux
/dev/sdb2 126 491 2939895 83 Linux
/dev/sdb4 492 14593 113274315 f Win95 Ext'd (LBA)
/dev/sdb5 492 528 297171 82 Linux swap
/dev/sdb6 529 14593 112977081 83 Linux
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table
root@LS-VL406:~#
After few seconds, the linkstation disconnect SSH sessions. Log in to the linkstation again and check the partition structure.
root@LS-VL406:~# partprobe /dev/sdb
root@LS-VL406:~# cat /proc/partitions
major minor #blocks name
31 0 512 mtdblock0
8 0 976762584 sda
8 1 1000448 sda1
8 2 5000192 sda2
8 3 1024 sda3
8 4 1024 sda4
8 5 1000448 sda5
8 6 961750000 sda6
8 16 117220823 sdb
8 17 1004031 sdb1
8 18 2939895 sdb2
8 20 1 sdb4
8 21 297171 sdb5
8 22 112977081 sdb6
Now create xfs file system on the data partition. (i.e. /dev/sdb6)
root@LS-VL406:~# mkfs.xfs /dev/sdb6
meta-data=/dev/sdb6 isize=256 agcount=4, agsize=7061068 blks
= sectsz=512 attr=2, projid32bit=0
data = bsize=4096 blocks=28244270, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0
log =internal log bsize=4096 blocks=13791, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
Then clone the /dev/sda1 to /dev/sdb1
root@LS-VL406:~# dd if=/dev/sda1 of=/dev/sdb1
2000896+0 records in
2000896+0 records out
root@LS-VL406:~# sync
root@LS-VL406:~#
Now switch off the linkstation and unplug the USB device. Remove the original HDD and plug the SSD to the linkstation directly. Then start your linkstation. Now it should be up and running with the SSD without any issue.
We are almost done. There is one thing we need to address. The linkstation needs it's "share" directory in the data partition and we haven't created it yet. We could have created it when we made the xfs file system. However the best way to create it is using the web interface so that it will be created with proper permissions.
So log into the linkstation using the web interface and remove the share directory shown in there and create it again with same permissions. That's it. You have the linkstation up and running with the SSD.
Subscribe to:
Posts (Atom)