Debian Squeeze on LS-CHLv2 - Revision history

Lsuser1985: Add category `Squeeze`.

Lsuser1985 — Fri, 18 Jan 2013 15:52:32 GMT

Add category `Squeeze`.

← Older revision		Revision as of 15:52, 18 January 2013
Line 624:		Line 624:
	* http://en.gentoo-wiki.com/wiki/Initramfs		* http://en.gentoo-wiki.com/wiki/Initramfs

-	[[Category:LS-CHLv2]][[Category:Debian]]	+	[[Category:LS-CHLv2]][[Category:Debian]][[Category:Squeeze]]

Threecoloursred: /* Stuff to follow up */ hardware detection links

Threecoloursred — Fri, 20 Jan 2012 20:22:51 GMT

Stuff to follow up: hardware detection links

← Older revision		Revision as of 20:22, 20 January 2012
Line 533:		Line 533:
	LS-CHL-V23D0 kernel: Marvell Development Board (LSP Version KW_LSP_5.1.3_patch13)-- MVLSXL Soc: 88F6281 A1 LE		LS-CHL-V23D0 kernel: Marvell Development Board (LSP Version KW_LSP_5.1.3_patch13)-- MVLSXL Soc: 88F6281 A1 LE
	* Also re. uBoot / firmware: The Sheevaplug uses the same Marvell processor as the LS-CHLv2, as well as uBoot. I wonder if it's possible to adjust NVRAM variables using the approach in [http://blog.bofh.it/debian/id_265 this Sheevaplug article]		* Also re. uBoot / firmware: The Sheevaplug uses the same Marvell processor as the LS-CHLv2, as well as uBoot. I wonder if it's possible to adjust NVRAM variables using the approach in [http://blog.bofh.it/debian/id_265 this Sheevaplug article]
		+	*Hardware detection links: [http://linux.koolsolutions.com/2009/06/09/info-10-usefull-hardware-information-extraction-utilities-in-debian-linux/] [ftp://linuxmafia.com/faq/Debian/hardware-detection.html] [http://wiki.debian.org/HardwareAutodetection] [http://www.justlinux.com/forum/showthread.php?t=11868]

	=HALT!=		=HALT!=

Threecoloursred: /* In chroot: Setup /etc/fstab */ Correction: /dev/sda2 is an ext3 FS

Threecoloursred — Fri, 20 Jan 2012 07:45:20 GMT

In chroot: Setup /etc/fstab: Correction: /dev/sda2 is an ext3 FS

← Older revision		Revision as of 07:45, 20 January 2012
Line 141:		Line 141:
	# file system mount point type options dump pass		# file system mount point type options dump pass
	/dev/sda1 /boot ext3 nosuid,nodev 0 2		/dev/sda1 /boot ext3 nosuid,nodev 0 2
-	/dev/sda2 / ~~xfs~~ defaults 0 1	+	/dev/sda2 / ext3 defaults 0 1
	/dev/sda5 none swap sw 0 0		/dev/sda5 none swap sw 0 0
	/dev/sda6 /home xfs defaults 0 2		/dev/sda6 /home xfs defaults 0 2

Threecoloursred at 13:48, 19 January 2012

Threecoloursred — Thu, 19 Jan 2012 13:48:41 GMT

← Older revision		Revision as of 13:48, 19 January 2012
Line 527:		Line 527:
	apt-get update		apt-get update
	apt-get upgrade		apt-get upgrade
-
-	~~=HALT!=~~
-	~~The items below here are cut and pasted from other pages of the wiki. They look to be relevant but I think they need tweaking before they work properly on the Linkstation.~~

	===Stuff to follow up===		===Stuff to follow up===
Line 536:		Line 533:
	LS-CHL-V23D0 kernel: Marvell Development Board (LSP Version KW_LSP_5.1.3_patch13)-- MVLSXL Soc: 88F6281 A1 LE		LS-CHL-V23D0 kernel: Marvell Development Board (LSP Version KW_LSP_5.1.3_patch13)-- MVLSXL Soc: 88F6281 A1 LE
	* Also re. uBoot / firmware: The Sheevaplug uses the same Marvell processor as the LS-CHLv2, as well as uBoot. I wonder if it's possible to adjust NVRAM variables using the approach in [http://blog.bofh.it/debian/id_265 this Sheevaplug article]		* Also re. uBoot / firmware: The Sheevaplug uses the same Marvell processor as the LS-CHLv2, as well as uBoot. I wonder if it's possible to adjust NVRAM variables using the approach in [http://blog.bofh.it/debian/id_265 this Sheevaplug article]
		+
		+	=HALT!=
		+	The items below here are cut and pasted from other pages of the wiki. They look to be relevant but I think they need tweaking before they work properly on the Linkstation.

	===blstools===		===blstools===

Threecoloursred: Notes on stuff to follow up to help complete this guide

Threecoloursred — Thu, 19 Jan 2012 13:46:51 GMT

Notes on stuff to follow up to help complete this guide

← Older revision		Revision as of 13:46, 19 January 2012
Line 20:		Line 20:
	* Devices: I've suggested not running MAKEDEV in the steps below because I think Squeeze does things differently, but I may have been wrong: if you can run MAKEDEV that might address the 2 problems above (I think this is what you'd do: cd /dev; ./MAKEDEV)		* Devices: I've suggested not running MAKEDEV in the steps below because I think Squeeze does things differently, but I may have been wrong: if you can run MAKEDEV that might address the 2 problems above (I think this is what you'd do: cd /dev; ./MAKEDEV)
	* initrd: Currently a dummy (empty) initrd is proposed. However this means that the boot and root partitions can't be fsck-ed at boot-time, which could lead to filesystem corruption (of these partitions). So although a dummy initrd is fine to get things working initially, a proper initrd will be needed to keep these partitions in good shape.		* initrd: Currently a dummy (empty) initrd is proposed. However this means that the boot and root partitions can't be fsck-ed at boot-time, which could lead to filesystem corruption (of these partitions). So although a dummy initrd is fine to get things working initially, a proper initrd will be needed to keep these partitions in good shape.
-	* Kernel: I'm not sure the procedure for generating the Squeeze kernel is correct. [[http://users.wowway.com/~zlinuxman/Kernel.htm this guide]] looks like an excellent explanation of how to build Debian kernels and is probably appropriate here - that way it should be possible to select the appropriate bits needed for the Linkstation to give a compact kernel whilst also providing full device support.	+	* Kernel: I'm not sure the procedure for generating the Squeeze kernel is correct. [[http://users.wowway.com/~zlinuxman/Kernel.htm this guide]] looks like an excellent explanation of how to build Debian kernels and is probably appropriate here - that way it should be possible to select the appropriate bits needed for the Linkstation to give a compact kernel whilst also providing full device support. Also see [http://kernel-handbook.alioth.debian.org/ch-common-tasks.html]

	=Requirements, Background info, Warnings=		=Requirements, Background info, Warnings=
Line 530:		Line 530:
	=HALT!=		=HALT!=
	The items below here are cut and pasted from other pages of the wiki. They look to be relevant but I think they need tweaking before they work properly on the Linkstation.		The items below here are cut and pasted from other pages of the wiki. They look to be relevant but I think they need tweaking before they work properly on the Linkstation.
		+
		+	===Stuff to follow up===
		+	A few links to places that might be relevant in completing this guide, kept here for convenience,
		+	* Possible incantations to pass the machine type to the kernel/initrd from uBoot: [http://us.generation-nt.com/answer/pbm-installing-debian-sheevaplug-help-204276021.html] [http://linux.derkeiler.com/Mailing-Lists/Kernel/2009-04/msg13379.html]. Specifying the device as a Marvell Development Board may work since /var/log/messages from a stock Linkstation says
		+	LS-CHL-V23D0 kernel: Marvell Development Board (LSP Version KW_LSP_5.1.3_patch13)-- MVLSXL Soc: 88F6281 A1 LE
		+	* Also re. uBoot / firmware: The Sheevaplug uses the same Marvell processor as the LS-CHLv2, as well as uBoot. I wonder if it's possible to adjust NVRAM variables using the approach in [http://blog.bofh.it/debian/id_265 this Sheevaplug article]

	===blstools===		===blstools===

Threecoloursred: Added status notes

Threecoloursred — Thu, 19 Jan 2012 13:29:12 GMT

Added status notes

← Older revision		Revision as of 13:29, 19 January 2012
Line 13:		Line 13:
	* build a new kernel+ modules		* build a new kernel+ modules
	* replace the Buffalo kernel & modules		* replace the Buffalo kernel & modules
		+
		+	=Current Status=
		+	This document is incomplete: Although the instructions are sufficient to get Debian Squeeze running on the Linkstation there are some things that are incomplete, including:
		+	* LED control: Currently the indicator LED is not enabled; it looks like lsmonitor from blstools needs tweaking to work with this
		+	* Fan control: Currently the fan runs at unnecessarily high speed, so it's noisy. This needs closer attention to fix.
		+	* Devices: I've suggested not running MAKEDEV in the steps below because I think Squeeze does things differently, but I may have been wrong: if you can run MAKEDEV that might address the 2 problems above (I think this is what you'd do: cd /dev; ./MAKEDEV)
		+	* initrd: Currently a dummy (empty) initrd is proposed. However this means that the boot and root partitions can't be fsck-ed at boot-time, which could lead to filesystem corruption (of these partitions). So although a dummy initrd is fine to get things working initially, a proper initrd will be needed to keep these partitions in good shape.
		+	* Kernel: I'm not sure the procedure for generating the Squeeze kernel is correct. [[http://users.wowway.com/~zlinuxman/Kernel.htm this guide]] looks like an excellent explanation of how to build Debian kernels and is probably appropriate here - that way it should be possible to select the appropriate bits needed for the Linkstation to give a compact kernel whilst also providing full device support.

	=Requirements, Background info, Warnings=		=Requirements, Background info, Warnings=
Line 520:		Line 528:
	apt-get upgrade		apt-get upgrade

-		+	=HALT!=
-		+	The items below here are cut and pasted from other pages of the wiki. They look to be relevant but I think they need tweaking before they work properly on the Linkstation.
-		+
-	== ~~'''WORK IN PROGRESS (17th Jan 2012) PLEASE COME BACK LATER''' ==~~	+
-	~~== '''WORK IN PROGRESS (17th Jan 2012) PLEASE COME BACK LATER''' ==~~	+
-	~~== '''WORK IN PROGRESS (17th Jan 2012) PLEASE COME BACK LATER''' ==~~	+
-		+
-		+
-		+

	===blstools===		===blstools===
Line 568:		Line 569:

	to disable the USB device.		to disable the USB device.
		+
		+	==blstools Replacement==
		+
		+	This is the replacement [http://pastebin.com/9yWQBnhW lsmonitor] script. This uses the sysfs GPIO interface instead of the buffalo specific proc interface. Also this script monitors the temperature of both drives.

	===NFS kernel===		===NFS kernel===
Line 602:		Line 607:

	For more information, please refers to [[Webmin to remotely administer your LinkStation]]		For more information, please refers to [[Webmin to remotely administer your LinkStation]]
-
-
-
-
-
-	~~==blstools Replacement==~~
-
-	This is the replacement [http://pastebin.com/9yWQBnhW lsmonitor] script. This uses the sysfs GPIO interface instead of the buffalo specific proc interface. Also this script monitors the temperature of both drives.

	=References=		=References=
Line 619:		Line 616:
	* http://forum.buffalo.nas-central.org/viewtopic.php?f=39&t=13551		* http://forum.buffalo.nas-central.org/viewtopic.php?f=39&t=13551
	* http://en.gentoo-wiki.com/wiki/Initramfs		* http://en.gentoo-wiki.com/wiki/Initramfs
-

	[[Category:LS-CHLv2]][[Category:Debian]]		[[Category:LS-CHLv2]][[Category:Debian]]

Threecoloursred: /* In chroot: Turn on bootlogging */

Threecoloursred — Thu, 19 Jan 2012 12:30:36 GMT

In chroot: Turn on bootlogging

← Older revision		Revision as of 12:30, 19 January 2012
Line 252:		Line 252:

	===In chroot: Turn on bootlogging===		===In chroot: Turn on bootlogging===
-	Create /etc/default/bootlogd,	+	Create/edit /etc/default/bootlogd,
	BOOTLOGD_ENABLE=yes		BOOTLOGD_ENABLE=yes

Threecoloursred: /* In chroot: Cleanup */ Add bootlogging

Threecoloursred — Thu, 19 Jan 2012 12:28:07 GMT

In chroot: Cleanup: Add bootlogging

← Older revision		Revision as of 12:28, 19 January 2012
Line 250:		Line 250:
	mkdir /root/.ssh		mkdir /root/.ssh
	chmod go-rwx /root/.ssh		chmod go-rwx /root/.ssh
		+
		+	===In chroot: Turn on bootlogging===
		+	Create /etc/default/bootlogd,
		+	BOOTLOGD_ENABLE=yes

	===In chroot: Cleanup===		===In chroot: Cleanup===

Threecoloursred at 15:19, 18 January 2012

Threecoloursred — Wed, 18 Jan 2012 15:19:18 GMT

← Older revision		Revision as of 15:19, 18 January 2012
Line 1:		Line 1:
-	This guide will explain how to install Debian GNU/Linux "Squeeze" on the LinkStation™ LS-CHLv2 using the Debian "debootstrap" procedure. The original kernel will be preserved, as well as the original bootloader (U-Boot).	+	This guide will explain how to install Debian GNU/Linux "Squeeze" on the LinkStation™ LS-CHLv2 using the Debian "debootstrap" procedure to generate a hybrid system still using the original Buffalo kernel, then complete the process by generating a true Debian Squeeze kernel to replace the Buffalo one. The original kernel will be preserved, as well as the original bootloader (U-Boot).

	This document is largely based on material from [[Debian Lenny on LS-WXL]] with a sprinkling of stuff from elsewhere including [[Debian_Squeeze_on_'V'_and_'X'_Series_(LS-WXL_and_others)]]; you may find these other pages help clarify steps here if you get stuck. These other Linkstation models are close relatives of the LS-CHLv2, so their instructions are very similar.		This document is largely based on material from [[Debian Lenny on LS-WXL]] with a sprinkling of stuff from elsewhere including [[Debian_Squeeze_on_'V'_and_'X'_Series_(LS-WXL_and_others)]]; you may find these other pages help clarify steps here if you get stuck. These other Linkstation models are close relatives of the LS-CHLv2, so their instructions are very similar.
Line 424:		Line 424:
	You'll probably find that the indicator light constantly flashes blue. I recommend moving the On/Auto/Off switch to Off. This '''won't''' turn off the device, but it will stop it restarting when you issue a shutdown command. Until the kernel is replaced (below), such a restart without a power off is likely to panic the Linkstation.		You'll probably find that the indicator light constantly flashes blue. I recommend moving the On/Auto/Off switch to Off. This '''won't''' turn off the device, but it will stop it restarting when you issue a shutdown command. Until the kernel is replaced (below), such a restart without a power off is likely to panic the Linkstation.

-	You have the option to stop at this point with this hybrid setup. You can install blstools to deal with the LED indicator lights & fan. Take care however when switching off the device: Keep the switch at Off (just briefly move it to Auto or On when switching it on); you should shutdown the device by using the shutdown command (shutdown -h now), and then take care to fully power off the device: Leaving it in standby will result in it being unable to reboot until after a full power off. Avoid those troubles by replacing the kernel (below).	+	You have the option to stop at this point with this hybrid setup. You can install [[http://sourceforge.net/projects/blstools/ blstools]] to deal with the LED indicator lights & fan. Take care however when switching off the device: Keep the switch at Off (just briefly move it to Auto or On when switching it on); you should shutdown the device by using the shutdown command (shutdown -h now), and then take care to fully power off the device: Leaving it in standby will result in it being unable to reboot until after a full power off. Avoid those troubles by replacing the kernel (below).

	=Complete the Squeeze installation: Replace the kernel & kernel modules=		=Complete the Squeeze installation: Replace the kernel & kernel modules=

Threecoloursred: /* Hardware */ corrections re. memory (only 64MByte in device)

Threecoloursred — Wed, 18 Jan 2012 14:51:41 GMT

Hardware: corrections re. memory (only 64MByte in device)

← Older revision		Revision as of 14:51, 18 January 2012
Line 33:		Line 33:

	==Hardware==		==Hardware==
-	Described elsewhere on the wiki in more detail, but key features are: ARM Kirkwood processor, ~~128~~ MByte RAM, 2 ethernet ports (only one installed), serial port (not enabled), indicator LED blue/red switchable; front function button, rear on/auto/off switch. Time is not stored between reboots, so ntpd is helpful to keep the time.	+	Described elsewhere on the wiki in more detail, but key features are: ARM Kirkwood processor, 64 MByte RAM, 2 ethernet ports (only one installed), serial port (not enabled), indicator LED blue/red switchable; front function button, rear on/auto/off switch. Time is not stored between reboots, so ntpd is helpful to keep the time.
	===Memory===		===Memory===
-	Although the device has ~~128MByte~~ of memory, by the time Debian gets to see it, there's only 50 MByte. I think this is due to the firmware / uBoot setting aside ~~half of the~~ memory ~~for a ramdisk, uBoot reserving a couple of MByte for itself~~ that it doesn't give back, and ~~presumably there's memory taken away~~ for ~~some other~~ stuff ~~too~~. It may be possible to adjust the uBoot setup to ~~stop it taking away so much~~ memory. Given that Debian ~~recommends~~ 64MByte as a minimum memory requirement, only having 50 MByte is ~~annoying to say the least, esp. when physically there's 128MByte in the device~~.	+	Although the device has 64MByte of memory, by the time Debian gets to see it, there's only 50 MByte. I think this is due to the firmware / uBoot setting aside some memory that it doesn't give back, and some will be reserved for hardware I/O stuff. It may be possible to adjust the uBoot setup to reduce the amount of memory it grabs. Given that Debian states 64MByte as a minimum memory requirement, only having 50 MByte is frustrating.

-	I've found that using the ramdisk memory for /tmp by mounting it as tmpfs is unreliable (at least in debootstrap-derived Debian mode; poss. not once you've completed this guide and have pure Debian), leading to memory errors for big tasks (like the step to apt-get the kernel sources). I understand tmpfs to merge the ramdisk with any available swap space and to 'do the right thing'. Given the memory errors encountered, I feel it's safer just to use swap space as needed, not merged with the ramdisk, and to have /tmp as just an ordinary directory in the root filesystem (or you may prefer to alter /tmp to live on the larger data partition instead).	+	I've found that using the ramdisk memory for /tmp by mounting it as tmpfs is unreliable (at least in debootstrap-derived Debian mode; poss. not once you've completed this guide and have pure Debian), leading to memory errors for big tasks (like the step to apt-get the kernel sources). I understand tmpfs to merge the ramdisk with any available swap space and to 'do the right thing'. Given the memory errors encountered, I feel it's safer just to use swap space as needed, not merged with the ramdisk, and to have /tmp as just an ordinary directory in the root filesystem (or you may prefer to alter /tmp to live on the larger data partition instead). Also given the above limited memory to start with, it seems pointless to squander it on a ramdisk - I'd rather give it all to the kernel so it doesn't get stuck.
-		+
-	~~I think~~ it ~~should be possible~~ to ~~setup the~~ ramdisk ~~as swap space, and~~ give it ~~priority over~~ the ~~disk-based swap. This would be an improvement. I~~'~~ve not tried this~~.	+

	===micro_evtd===		===micro_evtd===