User talk:Engelsman

From Lunar Linux
(Difference between revisions)
Jump to: navigation, search
(Observations on 1.6.4 and 1.6.5)
m (1.6.5 Installation Times)
 
(6 intermediate revisions by one user not shown)
Line 21: Line 21:
  
 
==Installing Lunar Linux 1.6.4 (Lacus Autumni)==
 
==Installing Lunar Linux 1.6.4 (Lacus Autumni)==
<p>Lunar Linux 1.6.4 (Lacus Autumni) was [http://foo-projects.org/pipermail/lunar/2008-December/008144.html announced] in December 2008, and installation and update was initially pretty smooth and uneventful. But as 2009 rolled on, and new versions of certain key modules were rolled out and were out of step with each other, upgrading from the 1.6.4 ISO became difficult. Here's the [http://foo-projects.org/pipermail/lunar-dev/2009-September/006906.html Update Workaround HOWTO] that I put together in September. Soon after this, other key module releases brought harmony again, and these instructions became obsolete.</p>
+
<p>Lunar Linux 1.6.4 (Lacus Autumni) was [http://foo-projects.org/pipermail/lunar/2008-December/008144.html announced] in December 2008, and installation and update was initially pretty smooth and uneventful. But as 2009 rolled on, and new versions of certain key modules were rolled out and were out of step with each other, upgrading from the 1.6.4 ISO became difficult. Here's the [http://foo-projects.org/pipermail/lunar-dev/2009-September/006906.html Update Workaround HOWTO] that I put together in September. This is no longer required! Soon after this, other key module releases brought harmony again, and these instructions became obsolete.</p>
<p>In February 2010, with the 2.6.32.8 kernel, updating udev from 141 to 151 caught me out. I don't remember the exact wording, but udev-151 requires that SYSFS_DEPRECATED is disabled in the kernel configuration. Finding SYSFS_DEPRECATED_V2 in the kernel didn't take long, but it took a lot longer to track down that GFS_FS also needed to be disabled...
+
<p>In February 2010, with the 2.6.32.8 kernel, updating udev from 141 to 151 caught me out. I don't remember the exact wording, but udev-151 requires that SYSFS_DEPRECATED is disabled in the kernel configuration. Finding SYSFS_DEPRECATED_V2 in the kernel didn't take long, but it took a lot longer to track down that GFS_FS also needed to be disabled...</p>
</p>
+
<p>Also in February 2010, installed 1.6.4 on a new Acer-AX5810 box with NVIDIA GeForce G210 card. This obviously requires the some kernel settings, and to install the NVIDIA module. All well and good, but after every kernel update and reboot you need to '''lrm NVIDIA''', and then '''lin -rc NVIDIA''' again otherwise it won't install properly. This has bitten me several times after a '''lunar update'''...</p>
  
==Installing Lunar Linux 1.6.5 (Name Forgotten)==
+
==Installing Lunar Linux 1.6.5 (Mare Ingenii)==
 
After corruption of the superblock on my /boot partition on an HP Pavilion t3190(?), I decided to installed the 1.6.5-beta1 ISO. The initial installation and update went without problem. XOrg7 appeared to install OK, but when I ran 'startx' the console went blank. Searching the web, and asking on #lunar revealed that I needed the i915 driver for my Intel graphics card, with an entry in /etc/modules for 'i915 modeset=1'. Close, but no cigar! That's when my troubles started, with the console going into powersave mode on reboot. After much trial and error, I discovered that the kernel requires:
 
After corruption of the superblock on my /boot partition on an HP Pavilion t3190(?), I decided to installed the 1.6.5-beta1 ISO. The initial installation and update went without problem. XOrg7 appeared to install OK, but when I ran 'startx' the console went blank. Searching the web, and asking on #lunar revealed that I needed the i915 driver for my Intel graphics card, with an entry in /etc/modules for 'i915 modeset=1'. Close, but no cigar! That's when my troubles started, with the console going into powersave mode on reboot. After much trial and error, I discovered that the kernel requires:
  
Line 37: Line 37:
 
     label = 2.6.32.9-acpi
 
     label = 2.6.32.9-acpi
 
     append="acpi=off"
 
     append="acpi=off"
 +
 +
At a certain point, there was an update to the linux-2.6 module that took it from 2.6.33.4 to 2.6.34.1, which I duly installed on my new test box, only to find that I couldn't reboot. The previous kernels had identified the disk as /dev/sda, but the new kernel decided it was /dev/sdb instead. This could be overcome by adding 'root=/dev/sdb3' on the lilo boot line, but then gave problems with /etc/fstab. To cut a long story short, I rebooted to the old kernel and changed /dev/fstab to use UUID instead. To find/create the UUIDs:
 +
 +
  tune2fs -l /dev/sda1
 +
  swapoff -a          # I'm lazy
 +
  mkswap /dev/sda2    # mkswap creates with UUID by default
 +
  swapon -a
 +
  tune2fs -l /dev/sda3
 +
 +
I even updated /etc/lilo.conf to add an 'append="root=/dev/sdb3"' for the 2.6.34.1 entry, and I could reboot, *and* mount the file systems.
 +
 +
Soon after this the 1.6.5-rc1 ISO was released, and as this was a test box anyway, with nothing really installed on it except for gnome test system that was inconsistent and didn't work, I wiped the system and re-installed from scratch.
 +
 +
===1.6.5 Installation Times===
 +
 +
Just out of curiosity, and for information to others, I decided to time how long it took to install a "minimal" desktop system from scratch
 +
on a relatively new system and a 9-year-old relic. I have two 5-year-old boxes I might add in the future.
 +
 +
It's clear that you probably don't want to install Lunar on really old hardware, unless you have a lot of patience, or can use <code>distcc</code>.
 +
 +
 +
{| border="1"
 +
! System
 +
! CPUs*bogomips [1]
 +
! RAM
 +
! Disk [2]
 +
! Install
 +
! lin gcc...
 +
! lin linux-2.6
 +
! lunar update
 +
! lin XOrg7
 +
! lin xfce4
 +
! TOTAL
 +
|- align="center"
 +
| Acer AX5810
 +
| 4 * 4988
 +
| 6 Gb
 +
| 1681 / 129 MB/s
 +
| 0h11
 +
| 1h01
 +
| 0h12
 +
| 0h20
 +
| 0h23
 +
| 0h14
 +
! 2h21
 +
|- align="center"
 +
| Vaio FX401
 +
| 1 * 1600
 +
| 512Mb
 +
| 179 / 17 MB/s
 +
| 0h18
 +
| 11h26
 +
| 3h37
 +
| 2h44
 +
| 3h12
 +
| 2h15
 +
! 23h32
 +
|}
 +
 +
# <code>grep bogomips /proc/cpuinfo</code>
 +
# <code>hdparm -t -T /dev/sdX</code>
 +
 +
 +
The basic procedure:
 +
* install from the ISO, and take the pre-compiled kernel, and reboot
 +
* run <code>lin moonbase</code>
 +
* run <code>lunar</code> and set number of parallel makes to 4 in ''Options / Optimize Architecture''
 +
* do the <code>lin gcc glibc gcc bash coreutils tar wget</code> dance from <code>man lfirsttime</code>
 +
* use <code>lin linux-2.6</code> to explicitly build a new kernel, and reboot
 +
* run <code>lunar update</code> to rebuild any outdated parts of the core system
 +
* run <code>lin XOrg7</code> to build X
 +
* run <code>lin xfce4</code> to build Xfce4
 +
 +
After the first reboot I primed the system by copying sources from /var/spool/lunar on another up-to-date machine to avoid download delays and glitches.
 +
 +
When asked questions about optional depends, etc. I simply hit return to accept the default values. I did not reconfigure the kernel. I used <code>lin --deps</code> for the XOrg7 and xfce4 builds to pre-answer the questions before kicking off the real builds so I could leave them unattended without adding delays for prompts to timeout.
 +
 +
NOTE: this procedure is for timing purposes only, I still have to go back and install the correct drivers for X, etc.
  
 
'''To be continued...'''
 
'''To be continued...'''

Latest revision as of 00:18, 19 September 2010

Contents


I have moved the original contents of this page elsewhere, reformatting and updating on the way. However, I have provided so many references to this page in the Lunar Forums that I can't remove it completely, and so I leave a skeleton to show the way, just like Billy Bones in Treasure Island.

Please follow the appropriate link to the updated page.

A Newbie's experience installing, and upgrading, Lunar Linux 1.5.1

I started using Unix V7 on a PDP-11/70 back in 1983, even modifying some existing kernel drivers for the Cambridge Ring local area network. After that I dabbled in system administration of various Sun and Apollo systems until 1991, and HP boxes up until 2000, but my main task has always been application software development, nothing on the hardware or kernel side. Since 2000 we've had dedicated system administrators at work. We had switched from NCD X-terminals over to Linux desktops (first RedHat, but then Lunar) and I realized that what little I knew had become well out of date. I installed RedHat on an old 90MHz PC at home more than five years ago, but without a LAN or modem connection it was too difficult to keep up to date, I lost interest, and that died. Since then I've had an itch to develop a spiffy FLTK user interace for some old command line tools using Cygwin/Mingw on a WinXP laptop (with modem) but the machine is (a) painfully slow, and (b) painfully Windows. The time had come to get some new hardware, install an operating system that doesn't thwart you at every turn, and set up a programming environment of my own choice. Read more...

Installing Lunar Linux 1.6.0 (coming soon, maybe)

In April 2006, the Lunar-1.6.0-i686 ISO was released, but I don't have enough spare time to look at installing it. Not just yet anyway.

Installing Lunar Linux 1.6.4 (Lacus Autumni)

Lunar Linux 1.6.4 (Lacus Autumni) was announced in December 2008, and installation and update was initially pretty smooth and uneventful. But as 2009 rolled on, and new versions of certain key modules were rolled out and were out of step with each other, upgrading from the 1.6.4 ISO became difficult. Here's the Update Workaround HOWTO that I put together in September. This is no longer required! Soon after this, other key module releases brought harmony again, and these instructions became obsolete.

In February 2010, with the 2.6.32.8 kernel, updating udev from 141 to 151 caught me out. I don't remember the exact wording, but udev-151 requires that SYSFS_DEPRECATED is disabled in the kernel configuration. Finding SYSFS_DEPRECATED_V2 in the kernel didn't take long, but it took a lot longer to track down that GFS_FS also needed to be disabled...

Also in February 2010, installed 1.6.4 on a new Acer-AX5810 box with NVIDIA GeForce G210 card. This obviously requires the some kernel settings, and to install the NVIDIA module. All well and good, but after every kernel update and reboot you need to lrm NVIDIA, and then lin -rc NVIDIA again otherwise it won't install properly. This has bitten me several times after a lunar update...

Installing Lunar Linux 1.6.5 (Mare Ingenii)

After corruption of the superblock on my /boot partition on an HP Pavilion t3190(?), I decided to installed the 1.6.5-beta1 ISO. The initial installation and update went without problem. XOrg7 appeared to install OK, but when I ran 'startx' the console went blank. Searching the web, and asking on #lunar revealed that I needed the i915 driver for my Intel graphics card, with an entry in /etc/modules for 'i915 modeset=1'. Close, but no cigar! That's when my troubles started, with the console going into powersave mode on reboot. After much trial and error, I discovered that the kernel requires:

 CONFIG_DRM_I915=m
 CONFIG_DRM_I915_KMS=y
 CONFIG_FRAMEBUFFER_CONSOLE=m

The first would imply having i915 in /etc/modules, but in fact it is trumped by the second, and you don't need the i915 module at all. But the KMS line also enables ACPI in the kernel, which causes the console blanking. To solve that problem, you do need to have fbcon in /etc/modules. Or to disable the powersave mode settings while you configure all of this, you need a lilo.conf entry such as the following

 image = /boot/2.6.32.9-i686
   label = 2.6.32.9-acpi
   append="acpi=off"

At a certain point, there was an update to the linux-2.6 module that took it from 2.6.33.4 to 2.6.34.1, which I duly installed on my new test box, only to find that I couldn't reboot. The previous kernels had identified the disk as /dev/sda, but the new kernel decided it was /dev/sdb instead. This could be overcome by adding 'root=/dev/sdb3' on the lilo boot line, but then gave problems with /etc/fstab. To cut a long story short, I rebooted to the old kernel and changed /dev/fstab to use UUID instead. To find/create the UUIDs:

 tune2fs -l /dev/sda1
 swapoff -a          # I'm lazy
 mkswap /dev/sda2    # mkswap creates with UUID by default
 swapon -a
 tune2fs -l /dev/sda3

I even updated /etc/lilo.conf to add an 'append="root=/dev/sdb3"' for the 2.6.34.1 entry, and I could reboot, *and* mount the file systems.

Soon after this the 1.6.5-rc1 ISO was released, and as this was a test box anyway, with nothing really installed on it except for gnome test system that was inconsistent and didn't work, I wiped the system and re-installed from scratch.

1.6.5 Installation Times

Just out of curiosity, and for information to others, I decided to time how long it took to install a "minimal" desktop system from scratch on a relatively new system and a 9-year-old relic. I have two 5-year-old boxes I might add in the future.

It's clear that you probably don't want to install Lunar on really old hardware, unless you have a lot of patience, or can use distcc.


System CPUs*bogomips [1] RAM Disk [2] Install lin gcc... lin linux-2.6 lunar update lin XOrg7 lin xfce4 TOTAL
Acer AX5810 4 * 4988 6 Gb 1681 / 129 MB/s 0h11 1h01 0h12 0h20 0h23 0h14 2h21
Vaio FX401 1 * 1600 512Mb 179 / 17 MB/s 0h18 11h26 3h37 2h44 3h12 2h15 23h32
  1. grep bogomips /proc/cpuinfo
  2. hdparm -t -T /dev/sdX


The basic procedure:

  • install from the ISO, and take the pre-compiled kernel, and reboot
  • run lin moonbase
  • run lunar and set number of parallel makes to 4 in Options / Optimize Architecture
  • do the lin gcc glibc gcc bash coreutils tar wget dance from man lfirsttime
  • use lin linux-2.6 to explicitly build a new kernel, and reboot
  • run lunar update to rebuild any outdated parts of the core system
  • run lin XOrg7 to build X
  • run lin xfce4 to build Xfce4

After the first reboot I primed the system by copying sources from /var/spool/lunar on another up-to-date machine to avoid download delays and glitches.

When asked questions about optional depends, etc. I simply hit return to accept the default values. I did not reconfigure the kernel. I used lin --deps for the XOrg7 and xfce4 builds to pre-answer the questions before kicking off the real builds so I could leave them unattended without adding delays for prompts to timeout.

NOTE: this procedure is for timing purposes only, I still have to go back and install the correct drivers for X, etc.

To be continued...

Personal tools
Namespaces
Variants
Actions
Wiki Navigation
Project Sites
Toolbox