Yes, I’m too lazy: I love NOPASSWD in my sudoers. Yes, this is bad security practice. Anyway, after installing Hardy I couldn’t make it work.
Finally I found that sudo takes the last appropriate entry that matches, not the first, as other tools do.
So after moving my custom sudoers rule to the end of /etc/sudoers, I now can continue my bad habits …
Running xfce on my new Lifebook, I was completely locked out after I ran xflock4 (which in turn calls gnome-screensaver-command –lock).
Back to the prompt I saw a lot of segfaults reported by the kernel like this one:
May 19 12:54:07 lulu kernel: [ 1166.757433] gnome-screensav[8313]:
segfault at 31 rip 7f8a51b1c8d4 rsp 7fff5b3d9a10 error 4
Fortunately using xscreensaver instead of gnome-screensaver is a work around.
Running Hardy means using Firefox 3 Beta 5 per default. When I first visited the http-server of one of the devices in my customers datacenter, the screen was frozen after a second. Unfortunately the device’s http-server stayed frozen. There was no further connection possible. Even worse: This could be fixed only by cutting the device’s power.
Currently I have no idea how to work around.
Edit:
There is a workaround. Install firefox-2. Set up a new profile foobar:
firefox -profilemanager -no-remote firefox
Start firefox-2 like this:
firefox-2 -P foobar -no-remote &
Yesterday I had my new Lifebook the first day in production. Unfortunately I had issues with a Java application which refused to start with the default Java in Hardy (I have to run Avocent DSView 3 to get server consoles and this is implemented in Java …).
So with openjdk-6-jre etc. and icedtea-gcjwebplugin as Web Browser Plugin
the application hung while loading. So I tried to switch back to sun-java5-jre but I had to learn that there is no package sun-java5-plugin for x86_64.
I can’t live without that ugly application - so in the evening I reinstalled my Lifebook with i386.
This is not fun - suggestions welcome !
My shiny brandnew Fujitsu Lifebook E8410 running Ubuntu Hardy has a significant drawback: As soon as GRUB takes over control the fan starts to run at maximum speed. It runs at maximum all the time Hardy is up. When I shutdown the system it will turn down just before the system is powered off.
See my bug report at Launchpad.
There seems to be a workaround: After I installed nvidia-glx-new, the fan goes down as soon as the X-Server is started !!!
But I’m unsure about this workaround. acpi -V always gives me 27 °C for the CPU. On a HP notebook with the same chipset I saw
Thermal 1: ok, 36.0 degrees C
Thermal 2: ok, 37.0 degrees C
Thermal 3: ok, 50.0 degrees C
Thermal 4: active[3], 45.0 degrees C
Thermal 5: ok, 40.0 degrees C
dmesg says:
[ 62.903304] CPU0: Thermal monitoring handled by SMI
[ 63.494350] CPU1: Thermal monitoring enabled (TM2)
[ 65.594267] ACPI: Thermal Zone [TZ3] (42 C)
[ 65.597322] ACPI: Thermal Zone [TZ4] (40 C)
[ 65.598384] ACPI: Thermal Zone [TZ5] (0 C)
[ 65.606739] ACPI: Thermal Zone [TZ0] (61 C)
[ 65.610104] ACPI: Thermal Zone [TZ1] (59 C)
5 thermal zones !
The Fujitsu tells me
root@lulu:/proc/acpi/thermal_zone/TZ00# dmesg | grep -i therm
[ 17.074771] CPU0: Thermal monitoring enabled (TM2)
[ 17.517967] CPU1: Thermal monitoring enabled (TM2)
[ 19.371052] ACPI: Thermal Zone [TZ00] (27 C)
[ 19.371330] ACPI: Thermal Zone [TZ01] (27 C)
root@lulu:/proc/acpi/thermal_zone/TZ00# cat trip_points
critical (S5): 100 C
passive: 95 C: tc1=0 tc2=10 tsp=2 devices=CPU0 CPU1
Is this reasonable ?
P.S.:
Due to some java incompabilities I had to reinstall my Lifebook using i386. Nothing changed. Fan runs at maximum speed until I installed nvidia-glx-new.
When I installed Hardy first on my Lifebook, I chose i386. wlan worked out of the box. Due to the fan issue I reinstalled using x86_64. As described the fan turned down as soon as the non free Nvidia driver was installed. With this configuration wlan does no longer work.
Using the Hardy x86_64 lifecd is fine.
dmesg says:
wlan0: RX WEP frame, decrypt failed
No solution yet.
There is a solution. It is very simple: I doublechecked my WLAN key - but there was a typo.
Next I installed skype-static. I used this package because I do not want to have all KDE-libraries and their dependencies on the box (I normally avoid KDE apps).
Doing a Skype test call led to a next issue: The speakers did not mute when a headphone was plugged in. According to
root@lulu:/home/bavn# lspci | grep -i audio
Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)
and
root@lulu:/proc/asound/card0# grep -i codec codec#0
Codec: Realtek ALC262
dmesg told me:
hda_codec: Unknown model for ALC262, trying auto-probe from BIOS...
As a workaround configure the model parameter of the snd-hda-intel driver:
root@lulu:/home/bavn# tail -1 /etc/modprobe.d/alsa-base
options snd-hda-intel model=fujitsu
Since this is active, hda_codec no longer complains about unknown model. The speakers are automuted as soon as the headphone jack is plugged in.
in.
BTW, this is skype 2.0.0.68. It works well with the builtin video device of the Lifebook E8410. dmesg says:
uvcvideo: Found UVC 1.00 device OEM Camera (046d:09b2)
Recently I got an new Fujitsu Lifebook E8410. I wiped out the preinstalled Vista and installed Hardy. After the first problems came up I decided to share my experiences here in detail.
I hope that some people will find this helpful.
Emacs is still my favorite editor. So I installed emacs22-gtk and as always it came up really ugly. The default font and window size are not appropriate for people of my age. For quite a couple of years I have been fine with
Emacs.font: -misc-fixed-medium-r-normal--20-200-75-75-c-100-iso8859-15
in my .Xdefaults. With the new display at 1680×1050 pixels and a resolution of 133×133 dots per inch this is far too small for my eyes. So again I started Googling. Soon I found hints, that there is a package emacs-snapshot which is able to use xft-fonts. But it didn’t work. I simply had
lulu:/home/bavn> cat .Xdefaults
Emacs.font: Monospace-13
and I did
lulu:/home/bavn> xrdb -merge .Xdefaults
but it didn’t work. At this time I had the Hardy emacs package emacs22-gtk I started with and the new package emacs-snapshot installed. I purged emacs22-gtk and then Emacs came up with Monospace. WoW !
One last step was missing. I had to call xrdb on the command line. Finally I found that having
lulu:/home/bavn> cat .Xresources
Emacs.font: Monospace-13
solved this last issue. Emacs now works with a nice font on my new Lifebook.
As shown in yesterday’s blog entry, I failed to recover my Feisty laptop due to missing links. Remembering the old saying “Every fool may do a backup” I now managed to find my mistake.
The error may be shown using localhost, so here we go:
First I started the listening netcat like this:
cd /tmp
netcat -l -p 2342 | tar xvf -
Then I backuped /sbin using:
cd /
tar cf - sbin | netcat localhost 2342
Both processes do not stop, until you hit CTRL-C. And at this point I did a mistake: I hit CTRL-C on the receiving side (I saw no further files coming in). DO NOT DO THIS - IT WILL EVENTUALLY LEAVE YOU WITH BROKEN LINKS. E.g. instead of
root@lulu:/tmp# ls -l sbin/ip
lrwxrwxrwx 1 root root 7 2008-01-16 11:33 sbin/ip -> /bin/ip
you will have
root@lulu:/tmp# ls -l sbin/ip
———- 1 root root 0 2008-01-16 11:28 sbin/ip
Let us dig a little bit deeper using strace. Again start the listening side and then the sending side. Do not hit CTRL-C. Looking at the process list you will see that the sending tar has finished, the receiving tar is still there. Strace this process and hit CTRL-C on the sending side. Check sbin/ip and you will find a link correctly pointing to /bin/ip.
This is the strace output:
root@lulu:/tmp# cat receiving-tar.strace
8394 read(0, “”, 10240) = 0
8394 clock_gettime(CLOCK_REALTIME, {1200479622, 923188961}) = 0
8394 clock_gettime(CLOCK_REALTIME, {1200479622, 923263552}) = 0
8394 close(0) = 0
8394 SYS_299(0xffffff9c, 0×808e6a5, 0xbfd650fc, 0×808e6a5, 0xb7f6eff4) = 0
8394 chmod(”sbin”, 0755) = 0
8394 chown32(”sbin”, 0, 0) = 0
8394 lstat64(”sbin/lsmod”, {st_mode=S_IFREG, st_size=0, …}) = 0
8394 unlink(”sbin/lsmod”) = 0
8394 symlink(”/bin/lsmod”, “sbin/lsmod”) = 0
8394 lchown32(”sbin/lsmod”, 0, 0) = 0
8394 lstat64(”sbin/ip”, {st_mode=S_IFREG, st_size=0, …}) = 0
8394 unlink(”sbin/ip”) = 0
8394 symlink(”/bin/ip”, “sbin/ip”) = 0
8394 lchown32(”sbin/ip”, 0, 0) = 0
8394 close(1) = 0
8394 munmap(0xb7cff000, 4096) = 0
8394 exit_group(0) = ?
root@lulu:/tmp#
Obviously tar handles the symbolic links not in the moment as they appear but in some final procedure. When I hitted CTRL-C on the receiving side I prevented tar to run that final procedure as this strace clearly shows:
root@lulu:/tmp# cat receiving-tar-ctrl-c
8495 read(0, “”, 10240) = 0
8495 — SIGINT (Interrupt) @ 0 (0) —
root@lulu:/tmp#
So you really must hit CTRL-C only on the sending side, interrupting netcat, which is safe as the sending tar already has gone.
Even better: Use netcat’s q option for the sending netcat, e.g.
Receiving process:
root@lulu:/tmp# netcat -l -p 2342 | tar xvf -
Sending side:
root@lulu:/# tar cf - sbin | netcat -q 2 localhost 2342
root@lulu:/#
With -q 2, netcat stop go away 2 secs after detecting EOF on stdin. The receiving netcat then will go away too.
So my conclusion:
Always use tar + netcat this way:
Receiving side:
netcat -l -p 2342 | tar xvf -
Sending side:
tar cf - whatever-you-want-to-backup | netcat -q 2 localhost 2342
Never omit -q !
Update:
Just a hint for those using e.g. SuSE: Though netcat version is 1.10 (same as in Feisty) option -q ist not available (there are others missing too). So in SuSE you must hit CTRL-C on the right side …
