Fwd: Gnome-shell very slow on boot

On Thu, Nov 22, 2012 at 12:15 AM, Daniel Dalton <d.dalton@iinet.net.au>wrote:
I'm running debian testing with gnome 3.4.
The first time I start my GUI on a particular boot be it at boot up via gdm, invoking the gdm init script manually by hand after logging into the console or by using startx it takes an incredibly long time for the gnome-shell to load and become ready.
Yeah Gnome-shell is not quick at startup, but nowhere that slow. I'm running Gnome 3.6 in Ubuntu 12.10 and it does take longer to load (more than Unity and KDE 4.9) but not by a large margin.
I have auto-log in enabled and it takes about 50-60 seconds from the point I start gdm or startx until the gui is ready to use. I'm using a core I5 2.4 GHZ machine with 4 GB of ram so there is a bit of power.
Are you using a machanical hard disk? If yes, that has much more to do with the speed of loading things than your CPU and RAM. Throw in a SSD in there and you'll be amazed by the difference. On my 3.5 year old Phenom II box but with a SSD, gdm + gnome-shell barely take 15 seconds to completely load. Cheers -- Aryan

On Thu, 22 Nov 2012, Aryan Ameri wrote:
Throw in a SSD in there and you'll be amazed by the difference. On my 3.5 year old Phenom II box but with a SSD, gdm + gnome-shell barely take 15 seconds to completely load.
Using WindowMaker instead of Gnome has the same effect and saves a few dollars. I just miss the delay to get a fresh coffee after typing the password. More seriously, once I had a similar effect when the hostname was not resolving because of a typo in the /etc/hosts file. Some Gnome tools were talking to DNS instead and waited, because the network connection was not established yet. But I've got rid of Gnome. Since then I understand which programs are running on my computer, and I don't need to debug them anymore. Regards Peter

On Thu, Nov 22, 2012 at 2:17 PM, Peter Ross <Peter.Ross@bogen.in-berlin.de>wrote:
On Thu, 22 Nov 2012, Aryan Ameri wrote:
Throw in a SSD in there and you'll be amazed by the difference. On my 3.5
year old Phenom II box but with a SSD, gdm + gnome-shell barely take 15 seconds to completely load.
Using WindowMaker instead of Gnome has the same effect and saves a few dollars. I
I'm so glad that works out for you. Meanwhile the rest of us can well afford to spend $60 on a piece of equipment that dramatically improves our computer experience, something we have to use for hours in a day. I wish I could understand this bizarre fascination that in the FLOSS community have with being proud of running obsolete hardware! -- Aryan

On Thu, 22 Nov 2012, Aryan Ameri wrote:
On Thu, Nov 22, 2012 at 2:17 PM, Peter Ross <Peter.Ross@bogen.in-berlin.de> wrote: On Thu, 22 Nov 2012, Aryan Ameri wrote:
Throw in a SSD in there and you'll be amazed by the difference. On my 3.5 year old Phenom II box but with a SSD, gdm + gnome-shell barely take 15 seconds to completely load.
Using WindowMaker instead of Gnome has the same effect and saves a few dollars. I
I'm so glad that works out for you.
Meanwhile the rest of us can well afford to spend $60 on a piece of equipment that dramatically improves our computer experience, something we have to use for hours in a day.
I wish I could understand this bizarre fascination that in the FLOSS community have with being proud of running obsolete hardware!
The OP may have a problem with some weird daemon that is stuck when he logs in. With Windowmaker that daemon would not start in the first place. Problem solved. Even the SSD may not solve his problem - e.g. if the login waits for a 30 seconds network timeout before it proceeds. BTW, our computers here retire after five years, and before that we try to use them effeciently. My work computer is 2-3 years old, and not extremely low spec. (Intel i5@ 3.33GHz with 4GB RAM) Windowmaker makes it usable in less than 10 seconds even with traditional harddisk. I used Gnome and KDE before - and I cannot say that I miss anything of it (yes, I use programs from other environments but not the desktop). I feel happier because my computer is snappier, compared to Gnome and KDE desktops, actually. Okay, enough coffee, back to work. Regards Peter

Peter Ross <Peter.Ross@bogen.in-berlin.de> wrote:
BTW, our computers here retire after five years, and before that we try to use them effeciently. My work computer is 2-3 years old, and not extremely low spec. (Intel i5@ 3.33GHz with 4GB RAM)
Mine is six years old now (two Xeon 5140 CPUs at 2.33 ghz, 4GB RAM) and still more than adequate. The boot time is undoubtedly helped by the SAS drives. If I were buying a new machine, though, I'd consider an SSD. Incidentally, I bought it used, at a very large discount and the SAS disks were a surprise.
Windowmaker makes it usable in less than 10 seconds even with traditional harddisk. I used Gnome and KDE before - and I cannot say that I miss anything of it (yes, I use programs from other environments but not the desktop).
I only ever use the desktop to run whatever X application I want; I do almost all of my work from the shell, so it wouldn't much matter to me if it were Gnome, XFCE, LXCE or anything else, except for braille/speech-related accessibility issues. I think XFCE 4.10 could be an option in this regard but I haven't tried it. It would be interesting to know whether distributions based on Systemd achieve much of an advantage in boot times. (I know improving the boot time is far from the only rationale for systemd. I also know that some on this list don't like Systemd, but let's try to avoid recapitulating that discussion).

On Thu, 22 Nov 2012, Jason White <jason@jasonjgw.net> wrote:
Mine is six years old now (two Xeon 5140 CPUs at 2.33 ghz, 4GB RAM) and still more than adequate. The boot time is undoubtedly helped by the SAS drives. If I were buying a new machine, though, I'd consider an SSD. Incidentally, I bought it used, at a very large discount and the SAS disks were a surprise.
If you aren't using systemd then I doubt that SAS disks gain you anything. The advantage of SAS is command queuing and that's not much of an advantage if you have mostly a single process accessing the disk. It's only when systemd launches lots of daemons at the same time that command queuing can give an advantage. Also if you were to compare 6yo SAS disks with modern SATA disks at the same rotational speed then I expect that SATA would win. More data per track means fewer and shorter seeks. Also Intel SSD costs about $1 per gig. It's really not expensive nowadays, and Intel is probably the most expensive SSD. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/

Russell Coker <russell@coker.com.au> writes:
On Thu, 22 Nov 2012, Jason White <jason@jasonjgw.net> wrote:
Mine is six years old now (two Xeon 5140 CPUs at 2.33 ghz, 4GB RAM) and still more than adequate. The boot time is undoubtedly helped by the SAS drives. If I were buying a new machine, though, I'd consider an SSD. Incidentally, I bought it used, at a very large discount and the SAS disks were a surprise.
If you aren't using systemd then I doubt that SAS disks gain you anything. The advantage of SAS is command queuing and that's not much of an advantage if you have mostly a single process accessing the disk. It's only when systemd launches lots of daemons at the same time that command queuing can give an advantage.
Uh, wtf? systemd doesn't have a monopoly on starting services in parallel. e.g. startpar is enabled by default in Debian 6. http://manpages.debian.net/cgi-bin/man.cgi?query=startpar http://manpages.debian.net/cgi-bin/man.cgi?query=insserv $ ls /etc/rc2.d README S02cron S03busybox-klogd S01lxc S02motd S04bootlogs S02acpid S02rsync S05rc.local S02atd S02ssh S05rmnologin S02binfmt-support S02sudo S05stop-bootlogd S02busybox-syslogd S02webfs All those S02s start in parallel. Having said that, boot speed is a bloody silly reason to pick SAS vs. SATA.

On Thu, 22 Nov 2012, Trent W. Buck wrote:
Uh, wtf? systemd doesn't have a monopoly on starting services in parallel. e.g. startpar is enabled by default in Debian 6.
http://manpages.debian.net/cgi-bin/man.cgi?query=startpar http://manpages.debian.net/cgi-bin/man.cgi?query=insserv
$ ls /etc/rc2.d README S02cron S03busybox-klogd S01lxc S02motd S04bootlogs S02acpid S02rsync S05rc.local S02atd S02ssh S05rmnologin S02binfmt-support S02sudo S05stop-bootlogd S02busybox-syslogd S02webfs
All those S02s start in parallel.
That sounds like a reasonable cautious approach. FreeBSD introduced rcorder few years ago (the scripts are ordered by depencies). Afterwards there was the idea of concurrency - and it caused more problems than it's worth it, especially if you have to cover the "unusual" setups as well (boots over net, network directory services, slow dynamic DHCP, to name a few) My best slowdown under Linux (back under CentOS 5.x) was using LDAP in /etc/nsswitch with files as fallback. Configured it, worked with it, all good - until next boot. Ping, ping.. no answer, one, two, three minutes. Walking over, seeing udev timing out.. for every device it configures it waits for LDAP .. which cannot be reached because there is no network yet. Amusing was the pingpong of the bug reports I found - init, udev and nsswitch - everybody reckons it was the other project's fault;-) Red Hat closed it and declared it a non-issue. Regards Peter

Peter Ross wrote:
Afterwards there was the idea of concurrency - and it caused more problems than it's worth it, especially if you have to cover the "unusual" setups as well (boots over net, network directory services, slow dynamic DHCP, to name a few)
Ubuntu 10.04 actually has a cyclic dependency if you NFS boot.
My best slowdown under Linux (back under CentOS 5.x) was using LDAP in /etc/nsswitch with files as fallback.
Bind softly instead of hard. Caveats are same as NFS soft vs. hard binding. And yeah, files should probably be first.
Configured it, worked with it, all good - until next boot. Ping, ping.. no answer, one, two, three minutes. Walking over, seeing udev timing out.. for every device it configures it waits for LDAP .. which cannot be reached because there is no network yet.
I ran into such a thing on a CentOS4 box once. What happened was this: 1. stupid local sysadmin creates a file /etc/sysconfig/networking/foo with an LDAP group. 2. stupid RH init script does something like ifcfg_scripts=$(ls /etc/sysconfig/networking | grep ifcfg) 3. ls dutifully tries to resolve foo's group. group doesn't resolve via files, so it asks LDAP Network isn't up yet (duh), so that hangs. Hangs for TWENTY MINUTES, because its hard-bound, and each (sequential) LDAP takes 10s or something to time out, and for some reason there's a whole lot of LDAP queries even though there's just that one file. 4. I go crazy for half a day, isolating which init script it hangs at, then which line, then finally going "wtf? how can ls hang for twenty minutes?!" before finally working it out. chgrp root foo, problem immediately goes away. Sigh. greybot> ls is a tool for interactively looking at file greybot> information. Its output is formatted for humans and will greybot> cause bugs in scripts. Use globs or find instead. Understand greybot> why: http://mywiki.wooledge.org/ParsingLs
Amusing was the pingpong of the bug reports I found - init, udev and nsswitch - everybody reckons it was the other project's fault;-)
Red Hat closed it and declared it a non-issue.
Typical.

On Fri, 23 Nov 2012, Trent W. Buck wrote:
Peter Ross wrote:
My best slowdown under Linux (back under CentOS 5.x) was using LDAP in /etc/nsswitch with files as fallback.
Bind softly instead of hard. Caveats are same as NFS soft vs. hard binding. And yeah, files should probably be first.
The task I was given included: unify admin access to the boxes using a directory service. If you have local files in nsswitch.conf first, it looks for admin passwords there first.. So it defeats the purpose. I abandoned the whole idea and went for ssh keys instead, I think. Regards Peter

On Thu, 22 Nov 2012, Jason White <jason@jasonjgw.net> wrote:
Russell Coker <russell@coker.com.au> wrote:
Also Intel SSD costs about $1 per gig. It's really not expensive nowadays, and Intel is probably the most expensive SSD.
So a good workstation configuration would be: an SSD for / and a SATA disk for /home.
Use SSD for /home too and use SATA only for some less used larger data. My personal workstation has only a Intel 120G SSD, that's more than enough local storage and the NFS server is used for big things. My mother in law has a 120G Intel SSD as the only storage in her home, it's more than she needs. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/

On Thu, 22 Nov 2012 05:29:08 PM Jason White wrote:
Russell Coker <russell@coker.com.au> wrote:
Also Intel SSD costs about $1 per gig. It's really not expensive nowadays, and Intel is probably the most expensive SSD.
So a good workstation configuration would be: an SSD for / and a SATA disk for /home.
I changed over to doing that a few weeks ago. That, SATA3 and a faster M/B and 4Ghz 8 core cpu made this computer seem really fast for a couple of days until I got used to it.

Before anyone tries to rope me in on the hardware debate let me say I'm using an Elitebook, quad core i7 with 8G ram and an twin SSDs - no hardware bottlenecks at all. Now that we can put the rulers away; I'm having the same problem as the OP. Gnome on FC17 takes ages to boot for me too, using autologin as well (all partitions are two factor encrypted so local login password is redundant) It hangs for longer than normal on a service called *plymouth-quit-wait.service* I've gooogled it and tried the suggested "disable" commands for this, but it still happens. OP: When you hit <esc> during boot, what is the last message you see? There is definitely something here, when I've used ubuntu on the same machine in it's default configuration I've not had this problem, also it seems to have occurred after an update, the fresh install didn't hang like this. I'm sure it's something real, and there will be a cause for this problem (other than the FOSS community and our love of resurrecting ancient hardware =] ) Michael. http://mikelindner.wordpress.com

On Fri, 23 Nov 2012, Michael Lindner wrote:
It hangs for longer than normal on a service called plymouth-quit-wait.service
I had a bit of a look around, and /bin/plymouth (formerly unknown to me) is a fancy splash screen during boot that has to be cancelled before X can start (If I understand correctly) I find bug reports for Red Hat https://bugzilla.redhat.com/show_bug.cgi?id=710737 and Suse http://lists.opensuse.org/opensuse-bugs/2012-06/msg03718.html
I've gooogled it and tried the suggested "disable" commands for this, but it still happens.
I wonder whether you could symlink /bin/plymouth to /bin/true ;-) I wonder what happens if you try another minimal window manager. Does it have the delay too?
There is definitely something here, when I've used ubuntu on the same machine in it's default configuration I've not had this problem, also it seems to have occurred after an update, the fresh install didn't hang like this.
I believe I see a change in a recent update of a Ubuntu 12.04 LTS machine. I do not see the GRUB selection screen anymore. I am pretty sure I had that before but I was too lazy to figure out what changed (I don't have the boot delay). On Sat, 24 Nov 2012, Jeremy Visser wrote,
On 22/11/2012 15:01, Peter Ross wrote:
The OP may have a problem with some weird daemon that is stuck when he logs in.
With Windowmaker that daemon would not start in the first place. Problem solved.
I cannot even begin to express just how completely dumb the logic is in the above statement, and just how far removed it is from the concept of problem solving.
Sometimes it is more efficient to swap the tools, instead of fiddling around with broken or complicated ones. There are fancy corkscrews and basic ones. I am confident to open the bottle in 10 seconds. If I choose the basic model. IMHO Gnome became so complicated it "just works" (lucky you) or it doesn't, and then you end up with bug reports as quoted above. Now systemd seems to add another dimension to it. Cheers Peter

On Mon, Nov 26, 2012 at 10:24:08AM +1100, Peter Ross wrote:
On Fri, 23 Nov 2012, Michael Lindner wrote:
It hangs for longer than normal on a service called plymouth-quit-wait.service
I had a bit of a look around, and /bin/plymouth (formerly unknown to me)
solution: apt-get purge $(apt-cache pkgnames plymouth)
I believe I see a change in a recent update of a Ubuntu 12.04 LTS machine. I do not see the GRUB selection screen anymore.
ubuntu's grub configuration is fucked up. it was bad enough in previous releases, and it has only got worse in Precise and Quantal. to make it sane, you need to: 1. comment out or delete all the GRUB_HIDDEN_* shit in /etc/default/grub and replace it with non-hidden versions. and if you want the machine to be able boot again without manual intervention after a boot failure, you need to disable their cretinous recordfail "feature" with GRUB_RECORDFAIL_TIMEOUT=x (the default of -1 just makes it sit at the grub prompt forever, which is a PITA if you don't have access to the console) e.g. here's /etc/default/grub from one of my ubuntu VMs: (you probably don't need the 'console=ttyS0', that's just to make sure I get a console.log file on the openstack compute-node). GRUB_TERMINAL=console is useful for getting rid of any stupid boot splash screens so you can see what's happening when the machine boots. ---cut here--- # If you change this file, run 'update-grub' afterwards to update # /boot/grub/grub.cfg. # For full documentation of the options in this file, see: # info -f grub -n 'Simple configuration' GRUB_DEFAULT=saved GRUB_SAVEDEFAULT=true #GRUB_HIDDEN_TIMEOUT=0 #GRUB_HIDDEN_TIMEOUT_QUIET=true GRUB_TIMEOUT=5 GRUB_RECORDFAIL_TIMEOUT=5 GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian` GRUB_CMDLINE_LINUX_DEFAULT="console=ttyS0" GRUB_CMDLINE_LINUX="" # Uncomment to enable BadRAM filtering, modify to suit your needs # This works with Linux (no patch required) and with any kernel that obtains # the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...) #GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef" # Uncomment to disable graphical terminal (grub-pc only) GRUB_TERMINAL=console # The resolution used on graphical terminal # note that you can use only modes which your graphic card supports via VBE # you can see them in real GRUB with the command `vbeinfo' #GRUB_GFXMODE=640x480 # Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux #GRUB_DISABLE_LINUX_UUID=true # Uncomment to disable generation of recovery mode menu entries #GRUB_DISABLE_RECOVERY="true" # Uncomment to get a beep at grub start #GRUB_INIT_TUNE="480 440 1" ---cut here--- 2. disable the brain-damaged submenu shit in /etc/grub.d/10_linux (it's annoying, and it breaks the grub-set-default and grub-reboot commands) --- 10_linux.dpkg-dist 2012-04-17 17:57:08.000000000 +0000 +++ 10_linux 2012-07-31 07:28:37.144068799 +0000 @@ -194,7 +194,6 @@ if [ "\${linux_gfx_mode}" != "text" ]; then load_video; fi EOF -in_submenu=false while [ "x$list" != "x" ] ; do linux=`version_find_latest $list` echo "Found linux image: $linux" >&2 @@ -254,12 +253,5 @@ list=`echo $list | tr ' ' '\n' | grep -vx $linux | tr '\n' ' '` - if [ "$list" ] && ! $in_submenu; then - echo "submenu \"Previous Linux versions\" {" - in_submenu=: - fi done -if $in_submenu; then - echo "}" -fi 3. run "update-grub". craig -- craig sanders <cas@taz.net.au> BOFH excuse #320: You've been infected by the Telescoping Hubble virus.

On Mon, Nov 26, 2012 at 12:01:32PM +1100, Craig Sanders wrote:
apt-get purge $(apt-cache pkgnames plymouth)
actually, this won't work because ubuntu's mountall package depends on libplymouth2. because it makes perfect sense to make a low level system function to mount all disks on boot dependant on some graphical boot logo bullshit. so, you're stuck with plymouth whether you want it or not. craig -- craig sanders <cas@taz.net.au>

On Mon, 26 Nov 2012, Craig Sanders wrote:
On Mon, Nov 26, 2012 at 12:01:32PM +1100, Craig Sanders wrote:
apt-get purge $(apt-cache pkgnames plymouth)
actually, this won't work because ubuntu's mountall package depends on libplymouth2.
because it makes perfect sense to make a low level system function to mount all disks on boot dependant on some graphical boot logo bullshit.
so, you're stuck with plymouth whether you want it or not.
You can deinstall plymouth(which has all the boot magic in it) and leave just the libplymouth2 there, I think. Thanks for the GRUB related notes. I recently gave up on an attempt to understand what Ubuntu's GRUB is doing. I am tempted to go for a handwritten /boot/grub.conf with the basics next time. Or I install the FreeBSD boot loader to start Ubuntu;-) Apologies for mentioning systemd last time. Ubuntu has upstart. Regards Peter

On 2012-11-26 14:38, Peter Ross wrote:
On Mon, 26 Nov 2012, Craig Sanders wrote:
On Mon, Nov 26, 2012 at 12:01:32PM +1100, Craig Sanders wrote:
apt-get purge $(apt-cache pkgnames plymouth)
actually, this won't work because ubuntu's mountall package depends on libplymouth2.
because it makes perfect sense to make a low level system function to mount all disks on boot dependant on some graphical boot logo bullshit.
so, you're stuck with plymouth whether you want it or not.
You can deinstall plymouth(which has all the boot magic in it) and leave just the libplymouth2 there, I think.
Thanks for the GRUB related notes.
I recently gave up on an attempt to understand what Ubuntu's GRUB is doing.
I am tempted to go for a handwritten /boot/grub.conf with the basics next time. Or I install the FreeBSD boot loader to start Ubuntu;-)
Apologies for mentioning systemd last time. Ubuntu has upstart.
I recommend switching to Extlinux instead of GRUB. It's far more simple and stupid (i.e. doesn't try to be clever). http://www.cyber.com.au/~twb/snarf/extlinux.txt That file from Trent (most notably the Deployment section) has mostly current information on how to set it up (aside from the kernel versions etc. that are shown). -- Regards, Matthew Cengia

On Mon, Nov 26, 2012 at 12:01 PM, Craig Sanders <cas@taz.net.au> wrote:
ubuntu's grub configuration is fucked up. it was bad enough in previous releases, and it has only got worse in Precise and Quantal.
to make it sane, you need to:
It isn't just grub in ubuntu it is the whole approach they have to moving to embedded devices (tablets/car dashboards etc) , I was running a HP tablet pc with wacom digitiser and was using ubuntu as it pretty much just worked, then along came unity (utter crap) so I switched to Xubuntu I went along with it for a while and in the last two months just said fuck it, gave the tablet to my brother who does art with it and I got a desktop and a Galaxy TAB 10.1 for the touch screen stuff when I need it. As I am now running a desktop with pretty standard hardware I don't have to rely on using an ubuntu (or variant) install to get the laptop/tablet stuff working and am now running Debian and couldn't be happier. -- Mark "Pockets" Clohesy Mob Phone: (+61) 406 417 877 Email: hiddensoul@twistedsouls.com G-Talk: mark.clohesy@gmail.com - GNU/Linux.. Linux Counter #457297 "I would love to change the world, but they won't give me the source code" "Linux is user friendly...its just selective about who its friends are" "Never underestimate the bandwidth of a V8 station wagon full of tapes hurtling down the highway" "The difference between e-mail and regular mail is that computers handle e-mail, and computers never decide to come to work one day and shoot all the other computers"

Craig Sanders writes:
I believe I see a change in a recent update of a Ubuntu 12.04 LTS machine. I do not see the GRUB selection screen anymore.
ubuntu's grub configuration is fucked up. it was bad enough in previous releases, and it has only got worse in Precise and Quantal.
Worse than needing to hit shift at exactly the right second, after waiting five minutes for the HP/IBM/SuperMicro BIOS to POST? At least extlinux will check CapsLock and ScrollLock, so you can turn on either during POST and it'll still trip extlinux out of "hidden" state.
[How to fix Ubuntu's grub config]
That more or less matches my notes, however I prefer to throw away grub entirely and use the same bootloader I use on CDs, USB keys and PXE... http://www.cyber.com.au/~twb/snarf/extlinux.txt http://www.cyber.com.au/~twb/snarf/extlinux-gpt.page PS: on 3TB disks, extlinux 4.05 worked but 4.06 and 5.something-pre would segfault, I'm not sure if it was the GPT or the deliberately degraded md RAID (was migrating to a larger RAID1 pair).

On Tue, Nov 27, 2012 at 09:53:02AM +1100, Trent W. Buck wrote:
Craig Sanders writes:
I believe I see a change in a recent update of a Ubuntu 12.04 LTS machine. I do not see the GRUB selection screen anymore.
ubuntu's grub configuration is fucked up. it was bad enough in previous releases, and it has only got worse in Precise and Quantal.
Worse than needing to hit shift at exactly the right second, after waiting five minutes for the HP/IBM/SuperMicro BIOS to POST?
yeah, the recordfail anti-feature. the default value of -1 makes grub wait for user input on every reboot after any boot failure. not a huge problem on a desktop machine, but a PITA on a remote server or a VM. in precise, recordfail=-1 is hard-coded. in quantal (and precise-updates, IIRC) they at least provided an override variable.
At least extlinux will check CapsLock and ScrollLock, so you can turn on either during POST and it'll still trip extlinux out of "hidden" state.
useful.
[How to fix Ubuntu's grub config]
That more or less matches my notes, however I prefer to throw away grub entirely and use the same bootloader I use on CDs, USB keys and PXE...
i don't see grub as being the problem. in fact, i like grub. the problem is misconfiguration of grub. craig -- craig sanders <cas@taz.net.au>

Craig Sanders <cas@taz.net.au> writes:
On Tue, Nov 27, 2012 at 09:53:02AM +1100, Trent W. Buck wrote:
Craig Sanders writes:
I believe I see a change in a recent update of a Ubuntu 12.04 LTS machine. I do not see the GRUB selection screen anymore.
ubuntu's grub configuration is fucked up. it was bad enough in previous releases, and it has only got worse in Precise and Quantal.
Worse than needing to hit shift at exactly the right second, after waiting five minutes for the HP/IBM/SuperMicro BIOS to POST?
yeah, the recordfail anti-feature. the default value of -1 makes grub wait for user input on every reboot after any boot failure. not a huge problem on a desktop machine, but a PITA on a remote server or a VM.
in precise, recordfail=-1 is hard-coded. in quantal (and precise-updates, IIRC) they at least provided an override variable.
I think you're talking about something else. I'm talking about when they change hardy's one-second timeout, to a zero-second timeout. It looks to see if you're holding down shift or alt, and if you are, it pops up the GRUB prompt. Otherwise, it just boots the default option. Except, of course, you can't just hold shift down, because the key down event will be eaten by the BIOS before grub loads. (Hence why extlinux, when set to hide the prompt, accepts locks as well as mods.)

On Tue, Nov 27, 2012 at 02:01:55PM +1100, Trent W. Buck wrote:
Craig Sanders <cas@taz.net.au> writes:
On Tue, Nov 27, 2012 at 09:53:02AM +1100, Trent W. Buck wrote:
Worse than needing to hit shift at exactly the right second, after waiting five minutes for the HP/IBM/SuperMicro BIOS to POST?
yeah, the recordfail anti-feature. [...]
I think you're talking about something else.
yep, i know. you asked "worse than ...?", and i said 'yeah, recordfail". "worse than" is, of course, subjective. so far recordfail has pissed me off more than zero-second timeout, so it wins (loses?). recordfail has made me suffer using the java crapware IPMIView for remote console access to supermicro machines more than i would otherwise, whereas with the zero-second timeout i was already experiencing the torture of ipmiview...a pinprick of extra pain makes little difference. craig -- craig sanders <cas@taz.net.au>

Peter Ross <Peter.Ross@bogen.in-berlin.de> wrote:
IMHO Gnome became so complicated it "just works" (lucky you) or it doesn't, and then you end up with bug reports as quoted above. Now systemd seems to add another dimension to it.
Gnome is indeed large and complex. I think there is much to be said for simplicity of design and implementation, which in essence is what the Arch Linux project aims to achieve. (They've embraced Systemd, but Gnome is of course optional, along with other window managers/desktop environments). I still work mostly from the console, partly for accessibility reasons (the console-based tools are much more reliable and have features I need), and partly because most of the software that I like happens to be text-based. I pop into Gnome occasionally as required. (The accessibility-related tools that I need in an X environment all derive from Gnome, although it's apparently possible to run them with XFCE 4.10). For maximum reliability I'd generally recommend running a minimalist window manager or desktop environment. Complex GUIs tend to come hand in hand with millions of lines of code and a system that becomes hard to work with when problems arise.

On Mon, Nov 26, 2012 at 05:09:28PM +1100, Jason White wrote:
Complex GUIs tend to come hand in hand with millions of lines of code and a system that becomes hard to work with when problems arise.
gnome also suffers greatly from CADT http://www.jwz.org/doc/cadt.html it's always more fun to rewrite from scratch than to do boring stuff like fix bugs, even though that probably means throwing out years worth of bug fixes and usability improvements. after all, why bother fixing an old half-arsed incomplete implementation when you can write a brand new half-arsed incomplete implementation? craig ps: systemd is CADT with the goal of fucking up your init system and syslogd rather than just your window manager. -- craig sanders <cas@taz.net.au>

On 26/11/12 17:27, Craig Sanders wrote:
On Mon, Nov 26, 2012 at 05:09:28PM +1100, Jason White wrote:
Complex GUIs tend to come hand in hand with millions of lines of code and a system that becomes hard to work with when problems arise.
gnome also suffers greatly from CADT http://www.jwz.org/doc/cadt.html
it's always more fun to rewrite from scratch than to do boring stuff like fix bugs, even though that probably means throwing out years worth of bug fixes and usability improvements.
after all, why bother fixing an old half-arsed incomplete implementation when you can write a brand new half-arsed incomplete implementation?
But as Zawinski says: "That's what happens when there is no incentive for people to do the parts of programming that aren't fun. Fixing bugs isn't fun; going through the bug list isn't fun; but rewriting everything from scratch is fun" There's more to it than that though. Sometimes fixing hard bugs isn't possible without changing the underlying system a lot, which will inevitably create some new less-hard-to-fix bugs.(Although those ones shouldn't require major rewrites of the underlying system to fix, so in the end you move forwards)

Toby Corkindale <toby.corkindale@strategicdata.com.au> wrote:
But as Zawinski says: "That's what happens when there is no incentive for people to do the parts of programming that aren't fun. Fixing bugs isn't fun; going through the bug list isn't fun; but rewriting everything from scratch is fun"
Perhaps that's one reason why most of the best software that I use was written by programmers who are also users of said software, i.e., they're writing in part for themselves and their friends/colleagues, who don't have a high tolerance for bugs. Then some of the feedback comes from direct experience rather than only from reports by users who are not involved in development.

On Mon, 26 Nov 2012, Jason White <jason@jasonjgw.net> wrote:
Perhaps that's one reason why most of the best software that I use was written by programmers who are also users of said software, i.e., they're writing in part for themselves and their friends/colleagues, who don't have a high tolerance for bugs. Then some of the feedback comes from direct experience rather than only from reports by users who are not involved in development.
Presumably the GNOME developers all use the software they develop and the same can probably be said for all the free software that is being discussed in this thread. I guess that conclusion would be that people who don't develop reliable software have their own systems running rather unreliably. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/

On 26/11/12 18:51, Russell Coker wrote:
On Mon, 26 Nov 2012, Jason White <jason@jasonjgw.net> wrote:
Perhaps that's one reason why most of the best software that I use was written by programmers who are also users of said software, i.e., they're writing in part for themselves and their friends/colleagues, who don't have a high tolerance for bugs. Then some of the feedback comes from direct experience rather than only from reports by users who are not involved in development.
Presumably the GNOME developers all use the software they develop and the same can probably be said for all the free software that is being discussed in this thread. I guess that conclusion would be that people who don't develop reliable software have their own systems running rather unreliably.
That's one possible conclusion, but another completely possible one is: The software works very well for the GNOME developers, and they don't know what all the fuss is about. Just because software doesn't do what YOU want/expect, doesn't mean that it isn't working exactly as designed.

On Tue, Nov 27, 2012 at 10:26:45AM +1100, Toby Corkindale wrote:
That's one possible conclusion, but another completely possible one is: The software works very well for the GNOME developers, and they don't know what all the fuss is about.
this technique works particularly well if you refuse to listen to the users you are allegedly catering for - most of whom were happy enough with gnome2 and just wanted bugfixes and improvements, not the radical change that gnome3 brought....evolution, not revolution. bonus points for telling anyone who doesn't like the direction gnome is heading that they are idiots and "not the target audience". just who the gnome devs think their target audience, i have NFI. I don't think they, or anyone else does either. It certainly isn't existing users, and it's not mac or windows users because they're also reasonably happy with what they've got. For some strange reason there doesn't appear to be a huge number of people who want a third-rate clone of an Apple phone or tablet touchscreen UI on their desktop PC or laptop. gnome3 has done wonders for XFCE's popularity. it's pretty close to what gnome2 users actually wanted, incremental improvements to the UI they had gotten used to for years. same for LXDE, to a lesser extent.
Just because software doesn't do what YOU want/expect, doesn't mean that it isn't working exactly as designed.
true enough. OTOH, just because it's working as designed doesn't mean that the design isn't brain-damaged. craig -- craig sanders <cas@taz.net.au>

Jason White <jason@jasonjgw.net> writes:
Perhaps that's one reason why most of the best software that I use was written by programmers who are also users of said software
This also lets you completely bypass requirements elicitation, because you intuitively know (well, hopefully) what *you* need and want the system to do.

On Mon, 26 Nov 2012, Craig Sanders <cas@taz.net.au> wrote:
ps: systemd is CADT with the goal of fucking up your init system and syslogd rather than just your window manager.
The difference is that systemd provides some real benefits. It gives a much faster boot (apart from some bugs related to encrypted disks and fsck failures). Eventually it should give a more reliable system than the current set of shell scripts which currently do everything. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/

Russell Coker <russell@coker.com.au> writes:
On Mon, 26 Nov 2012, Craig Sanders <cas@taz.net.au> wrote:
ps: systemd is CADT with the goal of fucking up your init system and syslogd rather than just your window manager.
The difference is that systemd provides some real benefits. It gives a much faster boot (apart from some bugs related to encrypted disks and fsck failures). Eventually it should give a more reliable system than the current set of shell scripts which currently do everything.
\begin{rant} Compared to Debian 6, or compared to what you remember booting being like five years ago? ISTR Ubuntu people making the assertions that their installer was much "easier to use" than Debian's, despite them being EXACTLY THE SAME (this was before ubiquity), simply because they hadn't bothered to actually compare contemporary versions side-by-side. How often do you actually boot anyway? My servers ideally boot about once a year. I would MUCH rather have them boot reliably in five minutes every time, than decide one time in five to just shit themselves for no reason and require another two hours of unscheduled pissing around because the fancy new init daemon decided to have a cyclic dependency, or to panic because fsck failed on an unimportant LV because it was flagged immutable and e2fsck didn't like that. (Granted, those issues were with upstart.) And for laptops, presumably your power management is good enough now that you suspend to RAM or disk, you don't power off entirely. Last time I measured it, my Eee PC 1005 -- an atom, hardly stellar -- booted Debian 6, including POST, in about fifteen seconds. Even if that could be reduced to zero, and I rebooted *every day*, I really don't give a shit about "optimizing" away fifteen seconds a day. If I did, I'd switch to instant coffee, not systemd. \end{rant}

trentbuck@gmail.com (Trent W. Buck) writes:
Compared to Debian 6, or compared to what you remember booting being like five years ago?
Apropos, this just appeared on LWN: http://web.dodds.net/~vorlon/wiki/blog/Upstart_in_Debian/

On Tue, Nov 27, 2012 at 10:33:31AM +1100, Trent W. Buck wrote:
trentbuck@gmail.com (Trent W. Buck) writes:
Compared to Debian 6, or compared to what you remember booting being like five years ago?
Apropos, this just appeared on LWN: http://web.dodds.net/~vorlon/wiki/blog/Upstart_in_Debian/
wow. that's amazing! compared to sysvinit+startpar, systemd improves boot time by 1.1 seconds, and upstart improves it by 0.62 seconds. that's really worth getting excited about. I can save around a second every six months or so!!!! and just remember kids, shell scripts are bad. lennart pottering says so...and what unix really needs is yet another minimalist domain-specific configuration language that requires you to learn its peculiarities and limitations. also, unix sucks and linux should be made to work more like mac or nextstep, because grotesquely long variable and setting names, 500+ character command-lines for trivial changes, and piss-poor documentation are a great way of forcing everyone to use a pretty-but-limited GUI to configure their systems. craig -- craig sanders <cas@taz.net.au>

Craig Sanders <cas@taz.net.au> writes:
On Tue, Nov 27, 2012 at 10:33:31AM +1100, Trent W. Buck wrote:
trentbuck@gmail.com (Trent W. Buck) writes:
Compared to Debian 6, or compared to what you remember booting being like five years ago?
Apropos, this just appeared on LWN: http://web.dodds.net/~vorlon/wiki/blog/Upstart_in_Debian/
wow. that's amazing!
compared to sysvinit+startpar, systemd improves boot time by 1.1 seconds, and upstart improves it by 0.62 seconds.
To be fair, that is a VM with a minimal install. I bet if you installed NetworkManager and pulseaudio, systemd's speed gain would jump to as much as five seconds ;-)
and just remember kids, shell scripts are bad. lennart pottering says so...and what unix really needs is yet another minimalist ^^^^ BZZT, wrong. Lennart cares *Linux* not unix. Debian kfbsd and Debian GNU can FOAD as far as he's concerned.
domain-specific configuration language that requires you to learn its peculiarities and limitations.
Personally I liked minit/cinit's approach -- "config files? What is that?" -- you had something like /etc/minit/smbd/exec -> /usr/sbin/smbd /etc/minit/smbd/args /etc/minit/smbd/depends/nmbd where "args" is newline-delimited list of arguments. You could just about use xattrs, and avoid ever open a file at all. Oh, and if you can't do it in a one-liner, your exec symlink is to a sh shebang script (or whatever the hell else you want). Allegedly it was inspired by qmail's config format -- I can't comment on that. It certainly makes sense to me to avoid heavyweight parsing when your init's target environment is ucLinux-level embedded systems (as at about eight years ago).
also, unix sucks and linux should be made to work more like mac or nextstep, because grotesquely long variable and setting names
XML-based config files (written in a binary serialization, so you can't view or edit them with TECO even if you wanted to).

On Tue, 27 Nov 2012, Trent W. Buck wrote:
Craig Sanders <cas@taz.net.au> writes:
On Tue, Nov 27, 2012 at 10:33:31AM +1100, Trent W. Buck wrote:
Apropos, this just appeared on LWN: http://web.dodds.net/~vorlon/wiki/blog/Upstart_in_Debian/
compared to sysvinit+startpar, systemd improves boot time by 1.1 seconds, and upstart improves it by 0.62 seconds.
To be fair, that is a VM with a minimal install. I bet if you installed NetworkManager and pulseaudio, systemd's speed gain would jump to as much as five seconds ;-)
Personally I liked minit/cinit's approach -- "config files? What is that?" -- you had something like
/etc/minit/smbd/exec -> /usr/sbin/smbd /etc/minit/smbd/args /etc/minit/smbd/depends/nmbd
where "args" is newline-delimited list of arguments. You could just about use xattrs, and avoid ever open a file at all.
Oh, and if you can't do it in a one-liner, your exec symlink is to a sh shebang script (or whatever the hell else you want).
Allegedly it was inspired by qmail's config format -- I can't comment on that. It certainly makes sense to me to avoid heavyweight parsing when your init's target environment is ucLinux-level embedded systems (as at about eight years ago).
The "boot stuff" was discussed on FreeBSD mailing lists many times. I just revisited some and found an own mail related to it.. back in 2008. Here some summary: - In many cases boots are not frequent (servers running continuously, sleep/resume szenarios) - BIOS+kernel boot account for more than 50% of overall time on a desktop - kernel can be made faster by avoiding probes for devices unneeded at boot (e.g. USB if you do not want to boot of a USB) A customized kernel helps in embedded systems a lot - You can speed up rc parsing significantly by using SSDs (And if you like, just use a smaller SSD for the root partition) In general: there is always a faster boot medium - No, you don't want to restart a service that died If a service dies you want to know about it and investigate why - Parallel startups add problems and save 15-20% of "rc time" if you include BIOS+kernel it is typically below 10% of overall boot All in all there was nobody convincing enough to make another boot process than traditional init/rc the _default_ for FreeBSD. Of course you are free to roll your own if you want, and alternatives exist, e.g. OpenRC used by Gentoo. Personally, I still enjoy the ability to see all relevant information under /etc/rc.conf:-)
Lennart cares *Linux* not unix. Debian kfbsd and Debian GNU can FOAD as far as he's concerned.
In the case of Gnome, this attitude made it harder for the FreeBSD project to implement and support Gnome (and I guess Solaris has the same problem). It adds to the Gnome fragmentation and less contribution goes in every "Gnome derivate". BTW: It is interesting to hear what people say about Windows 8, especially desktops using a GUI designed for tablets. I thought the same about Ubuntu's Unity desktop. Fortunately under Unix/Linux we can choose the GUI:-) Regards Peter

Quoting Craig Sanders (cas@taz.net.au):
gnome also suffers greatly from CADT http://www.jwz.org/doc/cadt.html
Last week, I was at a party with Luis Villa of the GNOME Project, and he admitted to having been the Attention-Deficit Teenager who closed Zawinski's GNOME 1.4 bug. I said 'You're famous, dude!' -- Cheers, "The only good goth is a shoggoth...." Rick Moen -- Alistair J.R. Young, in r.a.sf.w.r-j rick@linuxmafia.com McQ! (4x80)

Peter Ross writes:
I had a bit of a look around, and /bin/plymouth (formerly unknown to me) is a fancy splash screen during boot that has to be cancelled before X can start (If I understand correctly)
Yep. To my *immense* disgust, as at Ubuntu 10.04 it is a hard dependency of upstart, meaning that you cannot have an Ubuntu system -- even a server! -- without stupid plymouth splash crap installed. #ubuntu-boot assured me that was an oversight and it should be opt-out in 12.04, but I haven't checked yet. You can turn it off (mostly), thought IIRC that causes it to hard-hang if the boot-time fsck returns non-zero, such that you need a live medium to fix it. I can look up my notes if anyone's interested.
I've gooogled it and tried the suggested "disable" commands for this, but it still happens.
Remove "splash" from bootloader options is supposed to stop it, though IIRC what actually happens is that plymouth simply uses a text theme.

On Fri, Nov 23, 2012 at 10:28:17PM +1100, Michael Lindner wrote:
It hangs for longer than normal on a service called plymouth-quit-wait.service
Hmm, this can't be my problem as that package is not installed... Strange thing is that the ubuntu boot of gnome 3 on the same machine as the problematic debian install boots at a reasonable time. Dan

Daniel Dalton <d.dalton@iinet.net.au> writes:
On Fri, Nov 23, 2012 at 10:28:17PM +1100, Michael Lindner wrote:
It hangs for longer than normal on a service called plymouth-quit-wait.service
Hmm, this can't be my problem as that package is not installed...
That file is a systemdism. The equivalent under upstart would be /etc/init/plymouth*.conf; the equivalent for sysvinit would be /etc/rc?.d/???plymouth* symlinks to /etc/init.d/plymouth*.
Strange thing is that the ubuntu boot of gnome 3 on the same machine as the problematic debian install boots at a reasonable time.
Did you have any luck with bootchartd? Assuming you're using runlevel 2, please attach output of ls -ld /etc/rc[S206].d/*

On Tue, Nov 27, 2012 at 10:18:26AM +1100, Trent W. Buck wrote:
Did you have any luck with bootchartd?
Well, no, I haven't tried it yet. Going to need sighted help for this one, so I'll try over the next few days...
Assuming you're using runlevel 2, please attach output of
ls -ld /etc/rc[S206].d/*
Wow.. there is quite a lot. lrwxrwxrwx 1 root root 17 Oct 7 2011 /etc/rc0.d/K01anacron -> ../init.d/anacron lrwxrwxrwx 1 root root 17 Oct 7 2011 /etc/rc0.d/K01apache2 -> ../init.d/apache2 lrwxrwxrwx 1 root root 13 Oct 7 2011 /etc/rc0.d/K01atd -> ../init.d/atd lrwxrwxrwx 1 root root 23 Oct 17 2011 /etc/rc0.d/K01battery-stats -> ../init.d/battery-stats lrwxrwxrwx 1 root root 17 Nov 18 23:20 /etc/rc0.d/K01bitlbee -> ../init.d/bitlbee lrwxrwxrwx 1 root root 19 Nov 21 19:23 /etc/rc0.d/K01bluetooth -> ../init.d/bluetooth lrwxrwxrwx 1 root root 15 Oct 17 2011 /etc/rc0.d/K01exim4 -> ../init.d/exim4 lrwxrwxrwx 1 root root 14 Nov 23 13:49 /etc/rc0.d/K01gdm3 -> ../init.d/gdm3 lrwxrwxrwx 1 root root 13 Oct 7 2011 /etc/rc0.d/K01gpm -> ../init.d/gpm lrwxrwxrwx 1 root root 17 Nov 18 11:54 /etc/rc0.d/K01hostapd -> ../init.d/hostapd lrwxrwxrwx 1 root root 25 Nov 18 11:54 /etc/rc0.d/K01isc-dhcp-server -> ../init.d/isc-dhcp-server lrwxrwxrwx 1 root root 19 Oct 11 2011 /etc/rc0.d/K01isdnutils -> ../init.d/isdnutils lrwxrwxrwx 1 root root 24 Nov 18 11:54 /etc/rc0.d/K01isdnutils-base -> ../init.d/isdnutils-base lrwxrwxrwx 1 root root 20 Oct 7 2011 /etc/rc0.d/K01kerneloops -> ../init.d/kerneloops lrwxrwxrwx 1 root root 21 Jan 15 2012 /etc/rc0.d/K01laptop-mode -> ../init.d/laptop-mode lrwxrwxrwx 1 root root 14 Oct 7 2011 /etc/rc0.d/K01lirc -> ../init.d/lirc lrwxrwxrwx 1 root root 19 Nov 18 11:54 /etc/rc0.d/K01minissdpd -> ../init.d/minissdpd lrwxrwxrwx 1 root root 13 Jan 15 2012 /etc/rc0.d/K01mpd -> ../init.d/mpd lrwxrwxrwx 1 root root 18 Nov 18 11:54 /etc/rc0.d/K01quotarpc -> ../init.d/quotarpc lrwxrwxrwx 1 root root 20 Nov 18 11:54 /etc/rc0.d/K01resolvconf -> ../init.d/resolvconf lrwxrwxrwx 1 root root 15 Oct 7 2011 /etc/rc0.d/K01samba -> ../init.d/samba lrwxrwxrwx 1 root root 15 Nov 18 23:20 /etc/rc0.d/K01saned -> ../init.d/saned lrwxrwxrwx 1 root root 16 Nov 18 11:54 /etc/rc0.d/K01sleepd -> ../init.d/sleepd lrwxrwxrwx 1 root root 27 Nov 18 11:54 /etc/rc0.d/K01speech-dispatcher -> ../init.d/speech-dispatcher lrwxrwxrwx 1 root root 29 Oct 7 2011 /etc/rc0.d/K01unattended-upgrades -> ../init.d/unattended-upgrades lrwxrwxrwx 1 root root 17 Mar 3 2012 /etc/rc0.d/K01uptimed -> ../init.d/uptimed lrwxrwxrwx 1 root root 17 Oct 7 2011 /etc/rc0.d/K01urandom -> ../init.d/urandom lrwxrwxrwx 1 root root 16 Mar 3 2012 /etc/rc0.d/K01vnstat -> ../init.d/vnstat lrwxrwxrwx 1 root root 17 Nov 18 11:54 /etc/rc0.d/K01winbind -> ../init.d/winbind lrwxrwxrwx 1 root root 16 Nov 18 23:20 /etc/rc0.d/K01xinetd -> ../init.d/xinetd lrwxrwxrwx 1 root root 20 Nov 20 20:30 /etc/rc0.d/K02alsa-utils -> ../init.d/alsa-utils lrwxrwxrwx 1 root root 22 Oct 7 2011 /etc/rc0.d/K02avahi-daemon -> ../init.d/avahi-daemon lrwxrwxrwx 1 root root 15 Mar 3 2012 /etc/rc0.d/K02mysql -> ../init.d/mysql lrwxrwxrwx 1 root root 20 Nov 21 17:51 /etc/rc0.d/K02pulseaudio -> ../init.d/pulseaudio lrwxrwxrwx 1 root root 15 Nov 18 11:54 /etc/rc0.d/K02quota -> ../init.d/quota lrwxrwxrwx 1 root root 22 Oct 17 2011 /etc/rc0.d/K02spamassassin -> ../init.d/spamassassin lrwxrwxrwx 1 root root 25 Nov 21 19:23 /etc/rc0.d/K03network-manager -> ../init.d/network-manager lrwxrwxrwx 1 root root 18 Nov 19 23:03 /etc/rc0.d/K04sendsigs -> ../init.d/sendsigs lrwxrwxrwx 1 root root 17 Nov 19 23:03 /etc/rc0.d/K05rsyslog -> ../init.d/rsyslog lrwxrwxrwx 1 root root 22 Nov 19 23:03 /etc/rc0.d/K06umountnfs.sh -> ../init.d/umountnfs.sh lrwxrwxrwx 1 root root 20 Nov 19 23:03 /etc/rc0.d/K07networking -> ../init.d/networking lrwxrwxrwx 1 root root 20 Nov 19 23:03 /etc/rc0.d/K07nfs-common -> ../init.d/nfs-common lrwxrwxrwx 1 root root 20 Nov 19 23:03 /etc/rc0.d/K08hwclock.sh -> ../init.d/hwclock.sh lrwxrwxrwx 1 root root 18 Nov 19 23:03 /etc/rc0.d/K09umountfs -> ../init.d/umountfs lrwxrwxrwx 1 root root 20 Nov 19 23:03 /etc/rc0.d/K10umountroot -> ../init.d/umountroot lrwxrwxrwx 1 root root 14 Nov 19 23:03 /etc/rc0.d/K11halt -> ../init.d/halt -rw-r--r-- 1 root root 353 May 25 2012 /etc/rc0.d/README lrwxrwxrwx 1 root root 17 Oct 7 2011 /etc/rc2.d/K01apache2 -> ../init.d/apache2 lrwxrwxrwx 1 root root 23 Oct 17 2011 /etc/rc2.d/K01battery-stats -> ../init.d/battery-stats lrwxrwxrwx 1 root root 17 Nov 18 23:20 /etc/rc2.d/K01bitlbee -> ../init.d/bitlbee lrwxrwxrwx 1 root root 15 Nov 18 11:54 /etc/rc2.d/K01dictd -> ../init.d/dictd lrwxrwxrwx 1 root root 15 Oct 17 2011 /etc/rc2.d/K01exim4 -> ../init.d/exim4 lrwxrwxrwx 1 root root 14 Nov 23 13:49 /etc/rc2.d/K01gdm3 -> ../init.d/gdm3 lrwxrwxrwx 1 root root 13 Oct 7 2011 /etc/rc2.d/K01gpm -> ../init.d/gpm lrwxrwxrwx 1 root root 17 Nov 18 11:54 /etc/rc2.d/K01hostapd -> ../init.d/hostapd lrwxrwxrwx 1 root root 25 Nov 18 11:54 /etc/rc2.d/K01isc-dhcp-server -> ../init.d/isc-dhcp-server lrwxrwxrwx 1 root root 19 Oct 11 2011 /etc/rc2.d/K01isdnutils -> ../init.d/isdnutils lrwxrwxrwx 1 root root 24 Nov 18 11:54 /etc/rc2.d/K01isdnutils-base -> ../init.d/isdnutils-base lrwxrwxrwx 1 root root 14 Oct 7 2011 /etc/rc2.d/K01lirc -> ../init.d/lirc lrwxrwxrwx 1 root root 19 Nov 18 11:54 /etc/rc2.d/K01minissdpd -> ../init.d/minissdpd lrwxrwxrwx 1 root root 13 Jan 15 2012 /etc/rc2.d/K01mpd -> ../init.d/mpd lrwxrwxrwx 1 root root 18 Nov 18 11:54 /etc/rc2.d/K01quotarpc -> ../init.d/quotarpc lrwxrwxrwx 1 root root 15 Nov 18 23:20 /etc/rc2.d/K01saned -> ../init.d/saned lrwxrwxrwx 1 root root 16 Nov 18 11:54 /etc/rc2.d/K01sleepd -> ../init.d/sleepd lrwxrwxrwx 1 root root 27 Nov 18 11:54 /etc/rc2.d/K01speech-dispatcher -> ../init.d/speech-dispatcher lrwxrwxrwx 1 root root 17 Mar 3 2012 /etc/rc2.d/K01uptimed -> ../init.d/uptimed lrwxrwxrwx 1 root root 16 Mar 3 2012 /etc/rc2.d/K01vnstat -> ../init.d/vnstat lrwxrwxrwx 1 root root 17 Nov 18 11:54 /etc/rc2.d/K01winbind -> ../init.d/winbind lrwxrwxrwx 1 root root 16 Nov 18 23:20 /etc/rc2.d/K01xinetd -> ../init.d/xinetd lrwxrwxrwx 1 root root 14 Nov 18 23:20 /etc/rc2.d/K02cups -> ../init.d/cups lrwxrwxrwx 1 root root 15 Mar 3 2012 /etc/rc2.d/K02mysql -> ../init.d/mysql lrwxrwxrwx 1 root root 20 Nov 21 17:51 /etc/rc2.d/K02pulseaudio -> ../init.d/pulseaudio lrwxrwxrwx 1 root root 22 Oct 17 2011 /etc/rc2.d/K02spamassassin -> ../init.d/spamassassin -rw-r--r-- 1 root root 677 Sep 1 08:11 /etc/rc2.d/README lrwxrwxrwx 1 root root 20 Nov 18 11:54 /etc/rc2.d/S08nfs-common -> ../init.d/nfs-common lrwxrwxrwx 1 root root 24 Nov 18 11:54 /etc/rc2.d/S13binfmt-support -> ../init.d/binfmt-support lrwxrwxrwx 1 root root 20 Nov 19 14:28 /etc/rc2.d/S13fancontrol -> ../init.d/fancontrol lrwxrwxrwx 1 root root 17 Nov 18 11:54 /etc/rc2.d/S13rsyslog -> ../init.d/rsyslog lrwxrwxrwx 1 root root 15 Nov 18 23:20 /etc/rc2.d/S13samba -> ../init.d/samba lrwxrwxrwx 1 root root 14 Nov 18 11:54 /etc/rc2.d/S13sudo -> ../init.d/sudo lrwxrwxrwx 1 root root 15 Nov 18 11:54 /etc/rc2.d/S14acpid -> ../init.d/acpid lrwxrwxrwx 1 root root 17 Nov 18 11:54 /etc/rc2.d/S14anacron -> ../init.d/anacron lrwxrwxrwx 1 root root 13 Nov 18 11:54 /etc/rc2.d/S14atd -> ../init.d/atd lrwxrwxrwx 1 root root 14 Nov 18 11:54 /etc/rc2.d/S14cron -> ../init.d/cron lrwxrwxrwx 1 root root 14 Nov 18 11:54 /etc/rc2.d/S14dbus -> ../init.d/dbus lrwxrwxrwx 1 root root 20 Nov 18 11:54 /etc/rc2.d/S14kerneloops -> ../init.d/kerneloops lrwxrwxrwx 1 root root 21 Nov 18 11:54 /etc/rc2.d/S14loadcpufreq -> ../init.d/loadcpufreq lrwxrwxrwx 1 root root 15 Nov 18 11:54 /etc/rc2.d/S14rsync -> ../init.d/rsync lrwxrwxrwx 1 root root 13 Nov 18 11:54 /etc/rc2.d/S14ssh -> ../init.d/ssh lrwxrwxrwx 1 root root 22 Nov 18 11:54 /etc/rc2.d/S15avahi-daemon -> ../init.d/avahi-daemon lrwxrwxrwx 1 root root 19 Nov 21 19:23 /etc/rc2.d/S15bluetooth -> ../init.d/bluetooth lrwxrwxrwx 1 root root 22 Nov 18 11:54 /etc/rc2.d/S15cpufrequtils -> ../init.d/cpufrequtils lrwxrwxrwx 1 root root 25 Nov 21 19:23 /etc/rc2.d/S15network-manager -> ../init.d/network-manager lrwxrwxrwx 1 root root 18 Nov 23 13:49 /etc/rc2.d/S16bootlogs -> ../init.d/bootlogs lrwxrwxrwx 1 root root 21 Nov 23 13:49 /etc/rc2.d/S17laptop-mode -> ../init.d/laptop-mode lrwxrwxrwx 1 root root 18 Nov 23 13:49 /etc/rc2.d/S17rc.local -> ../init.d/rc.local lrwxrwxrwx 1 root root 19 Nov 23 13:49 /etc/rc2.d/S17rmnologin -> ../init.d/rmnologin lrwxrwxrwx 1 root root 23 Nov 23 13:49 /etc/rc2.d/S17stop-bootlogd -> ../init.d/stop-bootlogd lrwxrwxrwx 1 root root 17 Oct 7 2011 /etc/rc6.d/K01anacron -> ../init.d/anacron lrwxrwxrwx 1 root root 17 Oct 7 2011 /etc/rc6.d/K01apache2 -> ../init.d/apache2 lrwxrwxrwx 1 root root 13 Oct 7 2011 /etc/rc6.d/K01atd -> ../init.d/atd lrwxrwxrwx 1 root root 23 Oct 17 2011 /etc/rc6.d/K01battery-stats -> ../init.d/battery-stats lrwxrwxrwx 1 root root 17 Nov 18 23:20 /etc/rc6.d/K01bitlbee -> ../init.d/bitlbee lrwxrwxrwx 1 root root 19 Nov 21 19:23 /etc/rc6.d/K01bluetooth -> ../init.d/bluetooth lrwxrwxrwx 1 root root 15 Oct 17 2011 /etc/rc6.d/K01exim4 -> ../init.d/exim4 lrwxrwxrwx 1 root root 14 Nov 23 13:49 /etc/rc6.d/K01gdm3 -> ../init.d/gdm3 lrwxrwxrwx 1 root root 13 Oct 7 2011 /etc/rc6.d/K01gpm -> ../init.d/gpm lrwxrwxrwx 1 root root 17 Nov 18 11:54 /etc/rc6.d/K01hostapd -> ../init.d/hostapd lrwxrwxrwx 1 root root 25 Nov 18 11:54 /etc/rc6.d/K01isc-dhcp-server -> ../init.d/isc-dhcp-server lrwxrwxrwx 1 root root 19 Oct 11 2011 /etc/rc6.d/K01isdnutils -> ../init.d/isdnutils lrwxrwxrwx 1 root root 24 Nov 18 11:54 /etc/rc6.d/K01isdnutils-base -> ../init.d/isdnutils-base lrwxrwxrwx 1 root root 20 Oct 7 2011 /etc/rc6.d/K01kerneloops -> ../init.d/kerneloops lrwxrwxrwx 1 root root 21 Jan 15 2012 /etc/rc6.d/K01laptop-mode -> ../init.d/laptop-mode lrwxrwxrwx 1 root root 14 Oct 7 2011 /etc/rc6.d/K01lirc -> ../init.d/lirc lrwxrwxrwx 1 root root 19 Nov 18 11:54 /etc/rc6.d/K01minissdpd -> ../init.d/minissdpd lrwxrwxrwx 1 root root 13 Jan 15 2012 /etc/rc6.d/K01mpd -> ../init.d/mpd lrwxrwxrwx 1 root root 18 Nov 18 11:54 /etc/rc6.d/K01quotarpc -> ../init.d/quotarpc lrwxrwxrwx 1 root root 20 Nov 18 11:54 /etc/rc6.d/K01resolvconf -> ../init.d/resolvconf lrwxrwxrwx 1 root root 15 Oct 7 2011 /etc/rc6.d/K01samba -> ../init.d/samba lrwxrwxrwx 1 root root 15 Nov 18 23:20 /etc/rc6.d/K01saned -> ../init.d/saned lrwxrwxrwx 1 root root 16 Nov 18 11:54 /etc/rc6.d/K01sleepd -> ../init.d/sleepd lrwxrwxrwx 1 root root 27 Nov 18 11:54 /etc/rc6.d/K01speech-dispatcher -> ../init.d/speech-dispatcher lrwxrwxrwx 1 root root 29 Oct 7 2011 /etc/rc6.d/K01unattended-upgrades -> ../init.d/unattended-upgrades lrwxrwxrwx 1 root root 17 Mar 3 2012 /etc/rc6.d/K01uptimed -> ../init.d/uptimed lrwxrwxrwx 1 root root 17 Oct 7 2011 /etc/rc6.d/K01urandom -> ../init.d/urandom lrwxrwxrwx 1 root root 16 Mar 3 2012 /etc/rc6.d/K01vnstat -> ../init.d/vnstat lrwxrwxrwx 1 root root 17 Nov 18 11:54 /etc/rc6.d/K01winbind -> ../init.d/winbind lrwxrwxrwx 1 root root 16 Nov 18 23:20 /etc/rc6.d/K01xinetd -> ../init.d/xinetd lrwxrwxrwx 1 root root 20 Nov 20 20:30 /etc/rc6.d/K02alsa-utils -> ../init.d/alsa-utils lrwxrwxrwx 1 root root 22 Oct 7 2011 /etc/rc6.d/K02avahi-daemon -> ../init.d/avahi-daemon lrwxrwxrwx 1 root root 15 Mar 3 2012 /etc/rc6.d/K02mysql -> ../init.d/mysql lrwxrwxrwx 1 root root 20 Nov 21 17:51 /etc/rc6.d/K02pulseaudio -> ../init.d/pulseaudio lrwxrwxrwx 1 root root 15 Nov 18 11:54 /etc/rc6.d/K02quota -> ../init.d/quota lrwxrwxrwx 1 root root 22 Oct 17 2011 /etc/rc6.d/K02spamassassin -> ../init.d/spamassassin lrwxrwxrwx 1 root root 25 Nov 21 19:23 /etc/rc6.d/K03network-manager -> ../init.d/network-manager lrwxrwxrwx 1 root root 18 Nov 19 23:03 /etc/rc6.d/K04sendsigs -> ../init.d/sendsigs lrwxrwxrwx 1 root root 17 Nov 19 23:03 /etc/rc6.d/K05rsyslog -> ../init.d/rsyslog lrwxrwxrwx 1 root root 22 Nov 19 23:03 /etc/rc6.d/K06umountnfs.sh -> ../init.d/umountnfs.sh lrwxrwxrwx 1 root root 20 Nov 19 23:03 /etc/rc6.d/K07networking -> ../init.d/networking lrwxrwxrwx 1 root root 20 Nov 19 23:03 /etc/rc6.d/K07nfs-common -> ../init.d/nfs-common lrwxrwxrwx 1 root root 20 Nov 19 23:03 /etc/rc6.d/K08hwclock.sh -> ../init.d/hwclock.sh lrwxrwxrwx 1 root root 18 Nov 19 23:03 /etc/rc6.d/K09umountfs -> ../init.d/umountfs lrwxrwxrwx 1 root root 20 Nov 19 23:03 /etc/rc6.d/K10umountroot -> ../init.d/umountroot lrwxrwxrwx 1 root root 16 Nov 19 23:03 /etc/rc6.d/K11reboot -> ../init.d/reboot -rw-r--r-- 1 root root 351 May 25 2012 /etc/rc6.d/README lrwxrwxrwx 1 root root 20 Nov 18 11:54 /etc/rcS.d/K11resolvconf -> ../init.d/resolvconf lrwxrwxrwx 1 root root 17 Nov 18 11:54 /etc/rcS.d/K13rpcbind -> ../init.d/rpcbind lrwxrwxrwx 1 root root 15 Nov 18 11:54 /etc/rcS.d/K16quota -> ../init.d/quota -rw-r--r-- 1 root root 447 May 25 2012 /etc/rcS.d/README lrwxrwxrwx 1 root root 24 Oct 7 2011 /etc/rcS.d/S01mountkernfs.sh -> ../init.d/mountkernfs.sh lrwxrwxrwx 1 root root 14 Oct 7 2011 /etc/rcS.d/S02udev -> ../init.d/udev lrwxrwxrwx 1 root root 16 Jun 4 14:56 /etc/rcS.d/S03brltty -> ../init.d/brltty lrwxrwxrwx 1 root root 26 Oct 7 2011 /etc/rcS.d/S03mountdevsubfs.sh -> ../init.d/mountdevsubfs.sh lrwxrwxrwx 1 root root 18 Oct 7 2011 /etc/rcS.d/S04bootlogd -> ../init.d/bootlogd lrwxrwxrwx 1 root root 24 Oct 7 2011 /etc/rcS.d/S05keyboard-setup -> ../init.d/keyboard-setup lrwxrwxrwx 1 root root 16 Oct 7 2011 /etc/rcS.d/S06hdparm -> ../init.d/hdparm lrwxrwxrwx 1 root root 21 Oct 7 2011 /etc/rcS.d/S06hostname.sh -> ../init.d/hostname.sh lrwxrwxrwx 1 root root 20 Sep 29 23:05 /etc/rcS.d/S06hwclock.sh -> ../init.d/hwclock.sh lrwxrwxrwx 1 root root 22 Oct 7 2011 /etc/rcS.d/S07checkroot.sh -> ../init.d/checkroot.sh lrwxrwxrwx 1 root root 17 Oct 7 2011 /etc/rcS.d/S08mtab.sh -> ../init.d/mtab.sh lrwxrwxrwx 1 root root 20 Nov 18 11:54 /etc/rcS.d/S08nfs-common -> ../init.d/nfs-common lrwxrwxrwx 1 root root 20 Oct 7 2011 /etc/rcS.d/S09checkfs.sh -> ../init.d/checkfs.sh lrwxrwxrwx 1 root root 21 Oct 7 2011 /etc/rcS.d/S10mountall.sh -> ../init.d/mountall.sh lrwxrwxrwx 1 root root 31 Oct 7 2011 /etc/rcS.d/S11mountall-bootclean.sh -> ../init.d/mountall-bootclean.sh lrwxrwxrwx 1 root root 20 Nov 18 11:54 /etc/rcS.d/S11networking -> ../init.d/networking lrwxrwxrwx 1 root root 18 Sep 3 13:10 /etc/rcS.d/S11pppd-dns -> ../init.d/pppd-dns lrwxrwxrwx 1 root root 16 Sep 3 13:10 /etc/rcS.d/S11procps -> ../init.d/procps lrwxrwxrwx 1 root root 19 Sep 3 13:10 /etc/rcS.d/S11udev-mtab -> ../init.d/udev-mtab lrwxrwxrwx 1 root root 17 Sep 3 13:10 /etc/rcS.d/S11urandom -> ../init.d/urandom lrwxrwxrwx 1 root root 21 Nov 18 11:54 /etc/rcS.d/S12mountnfs.sh -> ../init.d/mountnfs.sh lrwxrwxrwx 1 root root 31 Nov 18 11:54 /etc/rcS.d/S13mountnfs-bootclean.sh -> ../init.d/mountnfs-bootclean.sh lrwxrwxrwx 1 root root 13 Nov 18 11:54 /etc/rcS.d/S14kbd -> ../init.d/kbd lrwxrwxrwx 1 root root 23 Nov 18 11:54 /etc/rcS.d/S15console-setup -> ../init.d/console-setup lrwxrwxrwx 1 root root 20 Nov 20 20:30 /etc/rcS.d/S16alsa-utils -> ../init.d/alsa-utils lrwxrwxrwx 1 root root 21 Nov 18 11:54 /etc/rcS.d/S16bootmisc.sh -> ../init.d/bootmisc.sh lrwxrwxrwx 1 root root 18 Nov 21 17:52 /etc/rcS.d/S16espeakup -> ../init.d/espeakup lrwxrwxrwx 1 root root 14 Nov 18 11:54 /etc/rcS.d/S16fuse -> ../init.d/fuse lrwxrwxrwx 1 root root 24 Nov 18 11:54 /etc/rcS.d/S16screen-cleanup -> ../init.d/screen-cleanup lrwxrwxrwx 1 root root 20 Nov 18 11:54 /etc/rcS.d/S16x11-common -> ../init.d/x11-common lrwxrwxrwx 1 root root 30 Nov 18 11:54 /etc/rcS.d/S17stop-bootlogd-single -> ../init.d/stop-bootlogd-single Seems to boot to the prompt just fine, but it takes a little while when I try start gdm3. Thanks for your help. Cheers, Dan

Daniel Dalton <d.dalton@iinet.net.au> writes:
On Tue, Nov 27, 2012 at 10:18:26AM +1100, Trent W. Buck wrote:
Did you have any luck with bootchartd?
Well, no, I haven't tried it yet. Going to need sighted help for this one, so I'll try over the next few days...
Assuming you're using runlevel 2, please attach output of
ls -ld /etc/rc[S206].d/*
Wow.. there is quite a lot.
Eh, it's within sigma for a GUI laptop. I notice lot of them are KNN, which is unusual unless you're been explicitly disabling them e.g. update-rc.d foo disable.
Seems to boot to the prompt just fine, but it takes a little while when I try start gdm3.
OK, so then we start debugging /etc/X11/Xsession.d/, your .xsession or .xinitrc (if any), and wherever the gdm-specific session code is (probably /etc/gdm3/default.Xsession or something). I'd probably just drop some timing lines into those files willy nilly and see how they turn up in ~/.xsessions-errors. You *did* already look at .xsession-errors, right? If the problem code is further down the line than that, it means its somewhere in the gnome3 session code, which I'm not familiar with. IIRC there was a program called something like 'gnome-session' that used to start gnome-settings-daemon and nautilus and gnome-panel and friends, so I'd be looking for someting like that.

On Tue, Nov 27, 2012 at 08:05:50PM +1100, Trent W. Buck wrote:
Wow.. there is quite a lot.
Eh, it's within sigma for a GUI laptop. I notice lot of them are KNN, which is unusual unless you're been explicitly disabling them
Yeah, I have. Attempt to decrease boot time slightly.
OK, so then we start debugging /etc/X11/Xsession.d/, your .xsession or .xinitrc (if any), and wherever the gdm-specific session code is (probably /etc/gdm3/default.Xsession or something).
I'd probably just drop some timing lines into those files willy nilly and see how they turn up in ~/.xsessions-errors. You *did* already look at .xsession-errors, right?
OK. Sounds like this one is going to take a fair bit of time/effort... Would purging the whole xserver/gnome/gdm/whatever else achieve the same end goal? As in hopefully resolving the long gdm start time. I've already tried that and unfortunately it didn't really help. If not of course I'd like to get to the bottom of this one, but since I've now got an ubuntu partition on the same system, and I was always considering switching to that I might just stick with ubuntu until I can find a couple of days to do this tedious work :) Whenever I get a bit of free time though, I'll definitely investigate with bootchart and then start to investigate the files you mentioned. Thanks very much for your help. Cheers, Dan

Daniel Dalton <d.dalton@iinet.net.au> writes:
Sounds like this one is going to take a fair bit of time/effort... Would purging the whole xserver/gnome/gdm/whatever else achieve the same end goal? As in hopefully resolving the long gdm start time.
NFI. I don't have any key suspects yet, which is why I told you to investigate further.
I've already tried that and unfortunately it didn't really help.
It sounds like you already answered your question.

On Thu, Nov 22, 2012 at 03:01:54PM +1100, Peter Ross wrote:
The OP may have a problem with some weird daemon that is stuck when he logs in.
So I disabled gdm on boot and decided to try startx from a console. I checked the network was up and running including dns. Then I ran startx. It took approximately 40 seconds for everything to become ready to use. So about 10 seconds faster than gdm I suppose. Is this still an unreasonable delay and if so does this rule out the daemon waiting for dns to become functional first...?
With Windowmaker that daemon would not start in the first place. Problem solved.
Hmm, maybe I will look into this. Though I wonder if there are any accessibility implications since I use orca... Cheers, Dan

Daniel Dalton <d.dalton@iinet.net.au> wrote:
So I disabled gdm on boot and decided to try startx from a console. I checked the network was up and running including dns. Then I ran startx. It took approximately 40 seconds for everything to become ready to use. So about 10 seconds faster than gdm I suppose.
Is this still an unreasonable delay and if so does this rule out the daemon waiting for dns to become functional first...?
It took about 8 seconds to do the same on my desktop machine running Debian Sid, i.e., I typed startx and everything was ready about 8 seconds later. It's a lot slower on my laptop, though, which has a 5400 RPM SATA disk. The drives on the desktop machine are 15000 RPM SAS. At some point I'll make sure Gnome is properly functional on the laptop and time it.

On Fri, 23 Nov 2012, Daniel Dalton wrote:
On Thu, Nov 22, 2012 at 03:01:54PM +1100, Peter Ross wrote:
The OP may have a problem with some weird daemon that is stuck when he logs in.
So I disabled gdm on boot and decided to try startx from a console. I checked the network was up and running including dns. Then I ran startx. It took approximately 40 seconds for everything to become ready to use. So about 10 seconds faster than gdm I suppose.
Is this still an unreasonable delay and if so does this rule out the daemon waiting for dns to become functional first...?
I think so, the problem may be somewhere else. You could to switch to a virtual console (Ctrl-Alt-F[1..6]) and have tcpdump on it, seeing what the traffic is. You also could run strace there, seeing what the processes are doing. Maybe even top may give you an indication what's going on.
With Windowmaker that daemon would not start in the first place. Problem solved.
Hmm, maybe I will look into this. Though I wonder if there are any accessibility implications since I use orca...
Hmmh, I don't know how orca works with "non-gnome desktop" and apps. Although, Windowmaker does not prevent you from using gnome apps. I use eog and evince, there is gnome-terminal etc. But I don't know how orca is commuicating with the Gnome apps, whether it needs a Gnome specific messaging system running or so (Even with Windowmaker I am running dbus at least). Regards Peter

On 22/11/2012 15:01, Peter Ross wrote:
The OP may have a problem with some weird daemon that is stuck when he logs in.
With Windowmaker that daemon would not start in the first place. Problem solved.
I cannot even begin to express just how completely dumb the logic is in the above statement, and just how far removed it is from the concept of problem solving.

On Thu, Nov 22, 2012 at 02:06:35PM +1100, Aryan Ameri wrote:
On Thu, Nov 22, 2012 at 12:15 AM, Daniel Dalton <[1]d.dalton@iinet.net.au> wrote:
I'm running debian testing with gnome 3.4.
The first time I start my GUI on a particular boot be it at boot up via gdm, invoking the gdm init script manually by hand after logging into the console or by using startx it takes an incredibly long time for the gnome-shell to load and become ready.
Yeah Gnome-shell is not quick at startup, but nowhere that slow. I'm running Gnome 3.6 in Ubuntu 12.10 and it does take longer to load (more than Unity and KDE 4.9) but not by a large margin.
Hey Aryan, I'm actually dual booting debian and ubuntu so decided to install gnome-shell onto the ubuntu side and see how long it takes. It is slightly slower than unity, but much faster than the debian set up probably takes about half the time. So I think something must not be quite right here on debian...
I'm using a core I5 2.4 GHZ machine with 4 GB of ram so there is a bit of power.
Are you using a machanical hard disk? If yes, that has much more to do with the speed of loading things than your CPU and RAM. Throw in a SSD in
Yeah... I can actually hear the drive doing lots of groaning as gdm/gnome fires up... However, I don't really know what it is actually doing...
box but with a SSD, gdm + gnome-shell barely take 15 seconds to completely load.
Hmm, always considered an ssd drive maybe I'll do it one day, but for now I still believe something is incorrect if debian gnome is taking much longer than ubuntu gnome on the same hardware... Thanks for your help. Cheers, Dan

Daniel Dalton <d.dalton@iinet.net.au> writes:
Yeah... I can actually hear the drive doing lots of groaning as gdm/gnome fires up...
That still happens? On spinning metal that *isn't* sick? How old are the disks, and when was the last time you ran a SMART self-test on them? map smartctl -t short -- /dev/sd[abc] # or long watch map smartctl -l selftest -- /dev/sd[abc] Note that Seagate controllers report in-progress self-tests; WDs do not report a test until it has finished/failed/aborted.

On Fri, Nov 23, 2012 at 03:10:50PM +1100, Trent W. Buck wrote:
Daniel Dalton <d.dalton@iinet.net.au> writes:
Yeah... I can actually hear the drive doing lots of groaning as gdm/gnome fires up...
That still happens? On spinning metal that *isn't* sick?
Maybe it could just be processor then, but I was thinking it was the disk. It didn't sound particularly unhealthy to me though....
How old are the disks, and when was the last time you ran a SMART self-test on them?
1 year old disks. Don't think I've done that.
map smartctl -t short -- /dev/sd[abc] # or long watch map smartctl -l selftest -- /dev/sd[abc]
It is command not found. What to install to do this? Tried looking it up, but I'm not really familiar with this... Thanks, Dan

Daniel Dalton <d.dalton@iinet.net.au> writes:
On Fri, Nov 23, 2012 at 03:10:50PM +1100, Trent W. Buck wrote:
Daniel Dalton <d.dalton@iinet.net.au> writes:
Yeah... I can actually hear the drive doing lots of groaning as gdm/gnome fires up...
That still happens? On spinning metal that *isn't* sick?
Maybe it could just be processor then, but I was thinking it was the disk.
It makes kind of a clicky-whirry sound. I associate clickiness with old, sick drives, but maybe it's normal for 5400s or something. The CPU is solid state, NO way it should make any noise. (Except the CPU fan, of course.)
It is command not found. What to install to do this?
smartmontools -- as "apt-file search bin/smartctl" would tell you.
participants (15)
-
Aryan Ameri
-
Craig Sanders
-
Daniel Dalton
-
Hiddensoul (Mark Clohesy)
-
Jason White
-
Jeremy Visser
-
Matthew Cengia
-
Michael Lindner
-
Peter Ross
-
Rick Moen
-
Russell Coker
-
Shane Deering
-
Toby Corkindale
-
Trent W. Buck
-
trentbuck@gmail.com