Does anyone use fstrim on an XFS formatted SSD partition?
I’ve got two systems with XFS root partitions that fstrim seems to do (almost) nothing on, but it seems to work correctly on another system with formatted with ext4.
Continue reading »
Jan 072012
This has been a minor annoyance for the last few months, and I've finally figured out how to fix it:
Sometime within the last few months, an upgrade prevented Chromium from finding its application icon…with the result that when minimised (or displayed in the panel window list or Alt-Tab) it used the default application icon.
It looks to me as if the problem is that Chromium is now looking for chromium-browser.svg but chromium.svg is what's on my debian system.
To restore, all you need to do is:
$ mkdir -p ~/.local/share/icons/hicolor/scalable/apps $ cd ~/.local/share/icons/hicolor/scalable/apps $ ln -s /usr/share/icons/hicolor/scalable/apps/chromium.svg chromium-browser.svg
great, done. Now my chromium windows don't look the same as my mrxvt windows in Alt-Tab, they're quite clearly Chromium windows. The icon now looks like this: 
rather than an icon i'd insert here if i knew what its filename is – it looks like a white window with a blue title bar and a thinner blue bar at the bottom (about half the height/thickness of the "title bar") I've spent half an hour searching for it and have given up – anyone know what it is?
alternatively, use cp rather than ln – just in case some future upgrade removes or renames the chromium.svg file
Nov 282011
I got home from work tonight and zfs had reported that one of the disks in my main pool was dying.
no great problem. insert a disk i had spare, and run zpool replace like so:
ganesh:~# zpool replace -f export scsi-SATA_WDC_WD10EARS-00_WD-WMAV50933036 scsi-SATA_ST31000528AS_9VP16X03
and now it’s just a matter of waiting until the data has “resilvered” and i can remove the old dying drive.
ganesh:~# zpool status export -v
pool: export
state: ONLINE
status: One or more devices is currently being resilvered. The pool will
continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
scan: resilver in progress since Mon Nov 28 19:25:49 2011
75.1G scanned out of 2.29T at 88.3M/s, 7h17m to go
18.0G resilvered, 3.21% done
config:
NAME STATE READ WRITE CKSUM
export ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
scsi-SATA_WDC_WD10EACS-00_WD-WCASJ2114122 ONLINE 0 0 0
scsi-SATA_WDC_WD10EACS-00_WD-WCASJ2195141 ONLINE 0 0 0
scsi-SATA_WDC_WD10EARS-00_WD-WMAV50817803 ONLINE 0 0 0
replacing-3 ONLINE 0 0 0
scsi-SATA_WDC_WD10EARS-00_WD-WMAV50933036 ONLINE 0 0 0
scsi-SATA_ST31000528AS_9VP16X03 ONLINE 0 0 0 (resilvering)
logs
scsi-SATA_Patriot_Torqx_278BF0715010800025492-part6 ONLINE 0 0 0
cache
scsi-SATA_Patriot_Torqx_278BF0715010800025492-part7 ONLINE 0 0 0
errors: No known data errors
(I use /dev/disk/by-id device names so I don’t have to care about the kernel detecting the disks and disk controllers in a different order on each reboot…also makes it easier to identify which disk is having a problem as I can squint at the front of the drives in my Lian Li 4-in-3 hotswap bays and read the serial number sticker)
OK, yeah, sure…it’s not that much different from replacing a dying drive in an mdadm or hardware raid array but one nice advantage of zfs over raid is that it only resyncs the data in use, not the empty or unused blocks. given that these are 1TB drives in a raidz vdev, and the pool is 63% used that means syncing only about 630GB rather than 1TB.
ps: in the time it’s taken to write this, it’s up to 10.11% done. 88MB/s reading data from the existing raidz drives and writing to a single drive isn’t too bad at all.
Dear lazyweb,
I bought an Aten CS1784A DVI+USB KVM switch a couple of months ago. I’m pretty happy with it except for one annoying problem.
It has a Dell multimedia USB keyboard plugged into it (picked it up from a swap meet for $15 – nice. it's a pretty good keyboard in its own right but i mostly bought it to match what I use at work), and a Logitech MX518 mouse connected. Also two computers – one runs Linux only. The other is switched off most of the time, but is occasionally powered up to boot into either Linux to experiment with stuff i don't want to do on my main system (like gnome 3) or sometimes Win7 to play games.
OK, that’s the background data. Here’s the problem
Whenever I reboot either of the Linux installations, the KVM stops recognising the keyboard. I have to unplug the keyboard and plug it back in before any input is recognised. Keyboard input doesn't get through to the currently active system, and I can't even use the KVM's magic key <ScrlLock><ScrlLock>n<Enter> to switch between systems – it doesn't even beep after the 2nd ScrlLock as it should, so it seems as if all keyboard input is ignored by the KVM, or the keyboard is totally confused and not sending anything. The mouse continues to work during this.
Rebooting Win7 doesn't do this. The keyboard just works as it should.
The problem occurs sometime between the time Linux is selected from the Grub2 menu and the gdm login screen is displayed (same result with both gdm on my main system and gdm3 on my secondary system).
The keyboard works when plugged directly into either system, without the KVM. I’d been using it for several months before I got the KVM, and I’ve tested that it still works correctly across a reboot if i plug it in directly.
Googling for "+linux +CS1784A" just gives me hundreds of pages from web sites selling the KVM, but no useful info.
Anyone seen anything like this before? Can anyone think of anything that linux might be doing in it's console or X initialisation that would confuse the KVM?
it's not a huge problem because I really don't reboot all that often – more of an annoyance that I'd like to go away.
-
Non-resizable configuration windows. I have a 1920×1200 screen but the window manager provides no way to resize windows like the System Settings window. Result is that the window is quite small and, worse, has a scroll bar for no good reason when another hundred or so vertical pixels would easily display everything. Even another 30 or so horizontal pixels would allow more icons per line under Hardware, reducing the number of lines, and again allowing the entire list of available settings to be displayed without a scroll bar. Instead, to see all of the options I have to scroll down. And these people call themselves user-interface and usability experts.
It's not up to the gnome developers to decide that I never need to resize certain windows or certain kinds of windows. It's up to me to decide that. They're not at my desktop, using my screen. I am.
-
No way to disable a shell extenstion from the command line. I installed the gnome-shell-extensions package and was trying out various extensions to see if they made gnome shell tolerable. Enabling one of them (i forget exactly which one), immediately displayed some "Oh no! Something has gone wrong. A problem has occured and the system can't recover. Please log out and try again." leaving me no option but to log out.
An absolutely fucking useless error message. "Something" has gone wrong. A little fucking detail might help me to diagnose the problem and fix it. Like a trace of whatever the fuck it was doing when "Something went wrong".
When i logged back in, it crashed again, with the same useless error screen. So, now I can't even log in to Gnome Shell. I've tried logging in to Fallback mode, but the Extensions tab is empty in gnome-tweak-tool (because, of course, nobody would want to configure Shell Extensions from fallback mode, would they?).
I can't even find any way of listing which shell extensions are enabled, let alone disable one of them. Hell, I'd settle for disabling all of them, and then carefully re-enabling them one-by-one until I rediscovered the culprit.
-
Oh, wait. I finally found /org/gnome/shell/enabled-extensions in dconf-editor. it's a text field with an array of items. so far, so good. The "editor" (and i use that term very loosely) for text fields is garbage. It can't even wrap lines so that it displays the whole field without a horizontal scroll bar – probably my all-time least favourite user-interface element. Have gnome devs never heard of multi-line text-edit fields?
Rather than fuck around with a crappy GUI editor, it's far easier to:
$ dconf read /org/gnome/shell/enabled-extensions > /tmp/extensions $ vi /tmp/extensions $ dconf write /org/gnome/shell/enabled-extensions "$(cat /tmp/extensions)"
I guess now it's time to log out from fallback mode to find out if I can log back in to Gnome Shell again. [ nope. didn't work ]
-
Add non-resizable user-interface elements to item 1. above. So far, Gnome devs are doing a great job of regressing to the crap usability of the Windows GUI
here’s a useful rule of thumb for things like that: Every single window, every single user-interface element should be resizable and tweakable by the user. And the system should remember all user changes so that they don’t have to waste a few minutes every time they run an app resizing things to suit their requirements.
Gnome 2 mostly had that. Gnome 3 seems to have lost a large part of it along the way
Second rule of thumb: If the user happens to replace their monitor or run it in a mode too small for the current settings, then they should revert to some sane default.
Even better, it should remember the settings for each resolution – choosing either sane defaults or the user’s settings for the nearest similar resolution if the user hasn’t created custom settings for that resolution yet.
-
Lack of documentation. here's a good example:
$ gnome-shell-extension-tool help Usage: gnome-shell-extension-tool [options] $ man gnome-shell-extension-tool No manual entry for gnome-shell-extension-tool See 'man 7 undocumented' for help when manual pages are not available.
What more needs to be said?
At least /usr/bin/dconf has built-in help. Which is great, since it doesn't have a man page either.
Update: About three hours of stuffing around later, and I’ve finally got Gnome Shell running again. I have NFI what actually fixed it, it could have any one of the dozens of settings I fucked around with. Nor do i have any idea what the actual problem was.
And after all that, the extensions I tried still don’t make Gnome Shell tolerable. They make it less *intolerable* (bottom-panel extension in particular), but that’s still a long way from being tolerable
i’m really trying hard to find some way to come to terms with Gnome 3. I’ve been trying for months now. But every time I give it another trial, I just end up hating it even more
I’m glad I have more than one desktop machine to use, so i can experiment with odious shit like Gnome Shell without fucking up my main working environment. So it’s back to my main desktop machine and gnome2. Eventually I’ll have to upgrade that, but xfce4 is looking to be my best option. I already switched to xfce4 on my desktop machine at work last week, and it’s pretty good…certainly far better than the Gnome 3 fallback mode i’ve been using there for the last 5 or 6 months.
Thanks, Gnome devs – you’re making a fantastic advertisement for XFCE. I wouldn’t have bothered trying it again if I hadn’t been forced to.
ps: before anyone says “wait for Gnome 3.2, it’s much better”. Todays waste of time *was* using Gnome 3.2
Nov 102011
I've been unable to solve this problem for a few weeks now, so i'll try posting it to my blog – maybe someone out there knows the answer. Would very much appreciate a clue on this one.
I've got a VM on a citrix xenserver 5.0.0 machine that won't start. it was running fine until it was rebooted on a Fri afternoon, a few weeks ago.
Starting it from the (windows-only) xencenter GUI results in:
"This VM cannot be started, as its network interfaces could not be connected. One of the NICs is in use elsewhere."
Starting it from the command line results in:
# xe vm-start uuid=88915b63-d794-e021-4f78-b03f46e352b0 Cannot plug VIF VIF: 5dfd3886-8b48-20e5-4231-30284d7b185d
anyone seen this before? know how to fix?
How to set gnome-fallback as the default session for gnome3 & gdm3.
The easiest way to do it in debian is to use update-alternatives to "install" a new alternative x-session-manager.
Jul 032008
or
^C doesn’t kill processes, SIGINT does
On the LUV mailing list recently, the perils of tty handling when booting with “init=/bin/bash” came up, and somebody asked why running ‘ping’ (without remembering to run stty or openvt first) will result in you having to reboot.
i.e. “why doesn’t ^C work in emergency mode”?
I wrote a fairly detailed, but comprehensible to a novice, answer and a friend suggested i should have written it as a blog post – which was the point of me setting up a blog in the first place.
So here’s a slightly edited version of it:
> Couldn’t you just open another console, run “top” and find the PID for
> ping and kill it? Or ps aux |grep ping and kill it? Is a reboot the
> only way to kill a ping where ^C is not available?
there’s nothing special about ^C except that by long convention it is mapped to the interrupt signal aka intr aka SIGINT. So, ^C itself doesn’t kill a program, the fact that it generates an interrupt signal does.
If you’ve rebooted for emergency maintenance (e.g. “init=/bin/bash” on the LILO or GRUB command line) then all you get is ONE instance of /bin/bash. Nothing else is running and nothing else has been run (because you’ve overriden the usual init with /bin/bash). No setup has been done on the terminal, and no other virtual terminals have been opened. The emergency environment is minimal (and deliberately so – you asked for it, you got it). It’s up to you to do whatever is needed to set up the environment so that you can do the required maintenance/repair work.
So if you run ping *before* remembering to set up the terminal (‘stty sane’) then ^C doesn’t work because ^C doesn’t generate SIGINT so there’s no way of telling ping to quit, and if you haven’t opened another virtual terminal with openvt (aka “open” – it got renamed some time ago) then there is no other shell available to run top or ps or kill.
BTW, it’s not just ping. You’ll see the same problem in the same environment with ANY program that runs continuously until it gets a signal to terminate it. ping’s just the most obvious and common example.
Most programs, especially simple programs like ping, don’t have a ^C handler. They don’t need one. They have a signal handler which, amongst other things, handles SIGINT however it’s generated – it can be generated by pressing ^C in a normal tty environment, or by sending the program a SIGINT (e.g. “kill -2″).
That, BTW, is a core difference between a SIGTERM (just plain ‘kill’ or ‘kill -15′) and SIGKILL (‘kill -9′).
SIGTERM is usually handled by the program by setting up a signal handler for it, and it voluntarily terminates when it receives the signal (usually cleaning up, closing files, etc before it does so). If the program hasn’t set up a handler for SIGTERM then the default action is to just terminate. A program can set up a handler which does nothing on SIGTERM, which effectively just ignores the signal.
SIGKILL is handled by the kernel and it just kills the process immediately – it can not be blocked or intercepted by the program.
(By common convention, SIGHUP or ‘kill -1′ tells a long running daemon process to just reload it’s config files. It’s also generated when the tty that the program is running on is terminated – e.g. you log out or the modem hangs up or the ssh session dies, hence the name “HUP” aka “HANGUP”. That’s why you need to use something like nohup or screen if you want a program to continue running after you log out)
In a way, ‘kill’ is a bit of a misnomer. It’s actually a generic tool for sending signals to running processes, but the default action for most of those signals is to terminate the program. Here’s a list of the signals which can be sent.
$ kill -l 1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5) SIGTRAP 6) SIGABRT 7) SIGBUS 8) SIGFPE 9) SIGKILL 10) SIGUSR1 11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15) SIGTERM 16) SIGSTKFLT 17) SIGCHLD 18) SIGCONT 19) SIGSTOP 20) SIGTSTP 21) SIGTTIN 22) SIGTTOU 23) SIGURG 24) SIGXCPU 25) SIGXFSZ 26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 29) SIGIO 30) SIGPWR 31) SIGSYS 34) SIGRTMIN 35) SIGRTMIN+1 36) SIGRTMIN+2 37) SIGRTMIN+3 38) SIGRTMIN+4 39) SIGRTMIN+5 40) SIGRTMIN+6 41) SIGRTMIN+7 42) SIGRTMIN+8 43) SIGRTMIN+9 44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13 48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52) SIGRTMAX-12 53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9 56) SIGRTMAX-8 57) SIGRTMAX-7 58) SIGRTMAX-6 59) SIGRTMAX-5 60) SIGRTMAX-4 61) SIGRTMAX-3 62) SIGRTMAX-2 63) SIGRTMAX-1 64) SIGRTMAX
See the man pages for init(8), kill(1), and especially signal(7) for more info on this topic.