- <title>How to fix a Thinkpad X230 with a broken 180 GB SSD disk</title>
- <link>http://people.skolelinux.org/pere/blog/How_to_fix_a_Thinkpad_X230_with_a_broken_180_GB_SSD_disk.html</link>
- <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/How_to_fix_a_Thinkpad_X230_with_a_broken_180_GB_SSD_disk.html</guid>
- <pubDate>Wed, 17 Jul 2013 23:50:00 +0200</pubDate>
- <description><p>Today I switched to
-<a href="http://people.skolelinux.org/pere/blog/The_Thinkpad_is_dead__long_live_the_Thinkpad_X230_.html">my
-new laptop</a>. I've previously written about the problems I had with
-my new Thinkpad X230, which was delivered with an
-<a href="http://people.skolelinux.org/pere/blog/Intel_SSD_520_Series_180_GB_with_Lenovo_firmware_still_lock_up_from_sustained_writes.html">180
-GB Intel SSD disk with Lenovo firmware</a> that did not handle
-sustained writes. My hardware supplier have been very forthcoming in
-trying to find a solution, and after first trying with another
-identical 180 GB disks they decided to send me a 256 GB Samsung SSD
-disk instead to fix it once and for all. The Samsung disk survived
-the installation of Debian with encrypted disks (filling the disk with
-random data during installation killed the first two), and I thus
-decided to trust it with my data. I have installed it as a Debian Edu
-Wheezy roaming workstation hooked up with my Debian Edu Squeeze main
-server at home using Kerberos and LDAP, and will use it as my work
-station from now on.</p>
-
-<p>As this is a solid state disk with no moving parts, I believe the
-Debian Wheezy default installation need to be tuned a bit to increase
-performance and increase life time of the disk. The Linux kernel and
-user space applications do not yet adjust automatically to such
-environment. To make it easier for my self, I created a draft Debian
-package <tt>ssd-setup</tt> to handle this tuning. The
-<a href="http://anonscm.debian.org/gitweb/?p=collab-maint/ssd-setup.git">source
-for the ssd-setup package</a> is available from collab-maint, and it
-is set up to adjust the setup of the machine by just installing the
-package. If there is any non-SSD disk in the machine, the package
-will refuse to install, as I did not try to write any logic to sort
-file systems in SSD and non-SSD file systems.</p>
-
-<p>I consider the package a draft, as I am a bit unsure how to best
-set up Debian Wheezy with an SSD. It is adjusted to my use case,
-where I set up the machine with one large encrypted partition (in
-addition to /boot), put LVM on top of this and set up partitions on
-top of this again. See the README file in the package source for the
-references I used to pick the settings. At the moment these
-parameters are tuned:</p>
-
-<ul>
-
-<li>Set up cryptsetup to pass TRIM commands to the physical disk
- (adding discard to /etc/crypttab)</li>
-
-<li>Set up LVM to pass on TRIM commands to the underlying device (in
- this case a cryptsetup partition) by changing issue_discards from
- 0 to 1 in /etc/lvm/lvm.conf.</li>
-
-<li>Set relatime as a file system option for ext3 and ext4 file
- systems.</li>
-
-<li>Tell swap to use TRIM commands by adding 'discard' to
- /etc/fstab.</li>
-
-<li>Change I/O scheduler from cfq to deadline using a udev rule.</li>
-
-<li>Run fstrim on every ext3 and ext4 file system every night (from
- cron.daily).</li>
-
-<li>Adjust sysctl values vm.swappiness to 1 and vm.vfs_cache_pressure
- to 50 to reduce the kernel eagerness to swap out processes.</li>
-
-</ul>
-
-<p>During installation, I cancelled the part where the installer fill
-the disk with random data, as this would kill the SSD performance for
-little gain. My goal with the encrypted file system is to ensure
-those stealing my laptop end up with a brick and not a working
-computer. I have no hope in keeping the really resourceful people
-from getting the data on the disk (see
-<a href="http://xkcd.com/538/">XKCD #538</a> for an explanation why).
-Thus I concluded that adding the discard option to crypttab is the
-right thing to do.</p>
-
-<p>I considered using the noop I/O scheduler, as several recommended
-it for SSD, but others recommended deadline and a benchmark I found
-indicated that deadline might be better for interactive use.</p>
-
-<p>I also considered using the 'discard' file system option for ext3
-and ext4, but read that it would give a performance hit ever time a
-file is removed, and thought it best to that that slowdown once a day
-instead of during my work.</p>
-
-<p>My package do not set up tmpfs on /var/run, /var/lock and /tmp, as
-this is already done by Debian Edu.</p>
-
-<p>I have not yet started on the user space tuning. I expect
-iceweasel need some tuning, and perhaps other applications too, but
-have not yet had time to investigate those parts.</p>
-
-<p>The package should work on Ubuntu too, but I have not yet tested it
-there.</p>
-
-<p>As for the answer to the question in the title of this blog post,
-as far as I know, the only solution is to replace the disk. It might
-be possible to flash it with Intel firmware instead of the Lenovo
-firmware. But I have not tried and did not want to do so without
-approval from Lenovo as I wanted to keep the warranty on the disk
-until a solution was found and they wanted the broken disks back.</p>
-</description>
- </item>
-
- <item>
- <title>Intel SSD 520 Series 180 GB with Lenovo firmware still lock up from sustained writes</title>
- <link>http://people.skolelinux.org/pere/blog/Intel_SSD_520_Series_180_GB_with_Lenovo_firmware_still_lock_up_from_sustained_writes.html</link>
- <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Intel_SSD_520_Series_180_GB_with_Lenovo_firmware_still_lock_up_from_sustained_writes.html</guid>
- <pubDate>Wed, 10 Jul 2013 13:30:00 +0200</pubDate>
- <description><p>A few days ago, I wrote about
-<a href="http://people.skolelinux.org/pere/blog/The_Thinkpad_is_dead__long_live_the_Thinkpad_X230_.html">the
-problems I experienced with my new X230 and its SSD disk</a>, which
-was dying during installation because it is unable to cope with
-sustained write. My supplier is in contact with
-<a href="http://www.lenovo.com/">Lenovo</a>, and they wanted to send a
-replacement disk to try to fix the problem. They decided to send an
-identical model, so my hopes for a permanent fix was slim.</p>
-
-<p>Anyway, today I got the replacement disk and tried to install
-Debian Edu Wheezy with encrypted disk on it. The new disk have the
-same firmware version as the original. This time my hope raised
-slightly as the installation progressed, as the original disk used to
-die after 4-7% of the disk was written to, while this time it kept
-going past 10%, 20%, 40% and even past 50%. But around 60%, the disk
-died again and I was back on square one. I still do not have a new
-laptop with a disk I can trust. I can not live with a disk that might
-lock up when I download a new
-<a href="http://www.skolelinux.org/">Debian Edu / Skolelinux</a> ISO or
-other large files. I look forward to hearing from my supplier with
-the next proposal from Lenovo.</p>
-
-<p>The original disk is marked Intel SSD 520 Series 180 GB,
-11S0C38722Z1ZNME35X1TR, ISN: CVCV321407HB180EGN, SA: G57560302, FW:
-LF1i, 29MAY2013, PBA: G39779-300, LBA 351,651,888, LI P/N: 0C38722,
-Pb-free 2LI, LC P/N: 16-200366, WWN: 55CD2E40002756C4, Model:
-SSDSC2BW180A3L 2.5" 6Gb/s SATA SSD 180G 5V 1A, ASM P/N 0C38732, FRU
-P/N 45N8295, P0C38732.</p>
-
-<p>The replacement disk is marked Intel SSD 520 Series 180 GB,
-11S0C38722Z1ZNDE34N0L0, ISN: CVCV315306RK180EGN, SA: G57560-302, FW:
-LF1i, 22APR2013, PBA: G39779-300, LBA 351,651,888, LI P/N: 0C38722,
-Pb-free 2LI, LC P/N: 16-200366, WWN: 55CD2E40000AB69E, Model:
-SSDSC2BW180A3L 2.5" 6Gb/s SATA SSD 180G 5V 1A, ASM P/N 0C38732, FRU
-P/N 45N8295, P0C38732.</p>
-
-<p>The only difference is in the first number (serial number?), ISN,
-SA, date and WNPP values. Mentioning all the details here in case
-someone is able to use the information to find a way to identify the
-failing disk among working ones (if any such working disk actually
-exist).</p>
-</description>
- </item>
-
- <item>
- <title>July 13th: Debian/Ubuntu BSP and Skolelinux/Debian Edu developer gathering in Oslo</title>
- <link>http://people.skolelinux.org/pere/blog/July_13th__Debian_Ubuntu_BSP_and_Skolelinux_Debian_Edu_developer_gathering_in_Oslo.html</link>
- <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/July_13th__Debian_Ubuntu_BSP_and_Skolelinux_Debian_Edu_developer_gathering_in_Oslo.html</guid>
- <pubDate>Tue, 9 Jul 2013 10:40:00 +0200</pubDate>
- <description><p>The upcoming Saturday, 2013-07-13, we are organising a combined
-Debian Edu developer gathering and Debian and Ubuntu bug squashing
-party in Oslo. It is organised by <a href="http://www.nuug.no/">the
-member assosiation NUUG</a> and
-<a href="http://www.skolelinux.org/">the Debian Edu / Skolelinux
-project</a> together with <a href="http://bitraf.no/">the hack space
-Bitraf</a>.</p>
-
-<p>It starts 10:00 and continue until late evening. Everyone is
-welcome, and there is no fee to participate. There is on the other
-hand limited space, and only room for 30 people. Please put your name
-on <a href="http://wiki.debian.org/BSP/2013/07/13/no/Oslo">the event
-wiki page</a> if you plan to join us.</p>
+ <title>Testing sysvinit from experimental in Debian Hurd</title>
+ <link>http://people.skolelinux.org/pere/blog/Testing_sysvinit_from_experimental_in_Debian_Hurd.html</link>
+ <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Testing_sysvinit_from_experimental_in_Debian_Hurd.html</guid>
+ <pubDate>Mon, 3 Feb 2014 13:40:00 +0100</pubDate>
+ <description><p>A few days ago I decided to try to help the Hurd people to get
+their changes into sysvinit, to allow them to use the normal sysvinit
+boot system instead of their old one. This follow up on the
+<a href="https://teythoon.cryptobitch.de//categories/gsoc.html">great
+Google Summer of Code work</a> done last summer by Justus Winter to
+get Debian on Hurd working more like Debian on Linux. To get started,
+I downloaded a prebuilt hard disk image from
+<a href="http://ftp.debian-ports.org/debian-cd/hurd-i386/current/debian-hurd.img.tar.gz">http://ftp.debian-ports.org/debian-cd/hurd-i386/current/debian-hurd.img.tar.gz</a>,
+and started it using virt-manager.</p>
+
+<p>The first think I had to do after logging in (root without any
+password) was to get the network operational. I followed
+<a href="https://www.debian.org/ports/hurd/hurd-install">the
+instructions on the Debian GNU/Hurd ports page</a> and ran these
+commands as root to get the machine to accept a IP address from the
+kvm internal DHCP server:</p>
+
+<p><blockquote><pre>
+settrans -fgap /dev/netdde /hurd/netdde
+pkill pfinet
+pkill devnode
+dhclient -v /dev/eth0
+</pre></blockquote></p>
+
+<p>After this, the machine had internet connectivity, and I could
+upgrade it and install the sysvinit packages from experimental and
+enable it as the default boot system in Hurd.</p>
+
+<p>But before I did that, I set a password on the root user, as ssh is
+running on the machine it for ssh login to work a password need to be
+set. Also, note that a bug somewhere in openssh on Hurd block
+compression from working. Remember to turn that off on the client
+side.</p>
+
+<p>Run these commands as root to upgrade and test the new sysvinit
+stuff:</p>
+
+<p><blockquote><pre>
+cat > /etc/apt/sources.list.d/experimental.list &lt;&lt;EOF
+deb http://http.debian.net/debian/ experimental main
+EOF
+apt-get update
+apt-get dist-upgrade
+apt-get install -t experimental initscripts sysv-rc sysvinit \
+ sysvinit-core sysvinit-utils
+update-alternatives --config runsystem
+</pre></blockquote></p>
+
+<p>To reboot after switching boot system, you have to use
+<tt>reboot-hurd</tt> instead of just <tt>reboot</tt>, as there is not
+yet a sysvinit process able to receive the signals from the normal
+'reboot' command. After switching to sysvinit as the boot system,
+upgrading every package and rebooting, the network come up with DHCP
+after boot as it should, and the settrans/pkill hack mentioned at the
+start is no longer needed. But for some strange reason, there are no
+longer any login prompt in the virtual console, so I logged in using
+ssh instead.
+
+<p>Note that there are some race conditions in Hurd making the boot
+fail some times. No idea what the cause is, but hope the Hurd porters
+figure it out. At least Justus said on IRC (#debian-hurd on
+irc.debian.org) that they are aware of the problem. A way to reduce
+the impact is to upgrade to the Hurd packages built by Justus by
+adding this repository to the machine:</p>
+
+<p><blockquote><pre>
+cat > /etc/apt/sources.list.d/hurd-ci.list &lt;&lt;EOF
+deb http://darnassus.sceen.net/~teythoon/hurd-ci/ sid main
+EOF
+</pre></blockquote></p>
+
+<p>At the moment the prebuilt virtual machine get some packages from
+http://ftp.debian-ports.org/debian, because some of the packages in
+unstable do not yet include the required patches that are lingering in
+BTS. This is the completely list of "unofficial" packages installed:</p>
+
+<p><blockquote><pre>
+# aptitude search '?narrow(?version(CURRENT),?origin(Debian Ports))'
+i emacs - GNU Emacs editor (metapackage)
+i gdb - GNU Debugger
+i hurd-recommended - Miscellaneous translators
+i isc-dhcp-client - ISC DHCP client
+i isc-dhcp-common - common files used by all the isc-dhcp* packages
+i libc-bin - Embedded GNU C Library: Binaries
+i libc-dev-bin - Embedded GNU C Library: Development binaries
+i libc0.3 - Embedded GNU C Library: Shared libraries
+i A libc0.3-dbg - Embedded GNU C Library: detached debugging symbols
+i libc0.3-dev - Embedded GNU C Library: Development Libraries and Hea
+i multiarch-support - Transitional package to ensure multiarch compatibilit
+i A x11-common - X Window System (X.Org) infrastructure
+i xorg - X.Org X Window System
+i A xserver-xorg - X.Org X server
+i A xserver-xorg-input-all - X.Org X server -- input driver metapackage
+#
+</pre></blockquote></p>
+
+<p>All in all, testing hurd has been an interesting experience. :)
+X.org did not work out of the box and I never took the time to follow
+the porters instructions to fix it. This time I was interested in the
+command line stuff.<p>