22 Nov
2012
22 Nov
'12
2:06 p.m.
On Thu, Nov 22, 2012 at 12:15 AM, Daniel Dalton <d.dalton(a)iinet.net.au>wrote;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
22 Nov
22 Nov
2:17 p.m.
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
2:28 p.m.
On Thu, Nov 22, 2012 at 2:17 PM, Peter Ross
<Peter.Ross(a)bogen.in-berlin.de>wrote;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
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
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
3:01 p.m.
On Thu, 22 Nov 2012, Aryan Ameri wrote:
On Thu, Nov 22, 2012 at 2:17 PM, Peter Ross
<Peter.Ross(a)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
4:27 p.m.
Peter Ross <Peter.Ross(a)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).
4:42 p.m.
On Thu, 22 Nov 2012, Jason White <jason(a)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/
5:01 p.m.
Russell Coker <russell(a)coker.com.au> writes:
On Thu, 22 Nov 2012, Jason White
<jason(a)jasonjgw.net> 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.
Having said that, boot speed is a bloody silly reason to pick SAS
vs. SATA.
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.
23 Nov
23 Nov
10:08 a.m.
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
11:05 a.m.
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.
11:16 a.m.
On Fri, 23 Nov 2012, Trent W. Buck wrote:
Peter Ross wrote:
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
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.
6:10 p.m.
On Thu, 22 Nov 2012, Jason White <jason(a)jasonjgw.net> wrote:
Russell Coker <russell(a)coker.com.au> wrote:
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/
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. 
6:35 p.m.
On Thu, 22 Nov 2012 05:29:08 PM Jason White wrote:
Russell Coker <russell(a)coker.com.au> wrote:
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.
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. 
23 Nov
23 Nov
10:28 p.m.
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
26 Nov
26 Nov
10:24 a.m.
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
12:01 p.m.
On Mon, Nov 26, 2012 at 10:24:08AM +1100, Peter Ross wrote:
On Fri, 23 Nov 2012, Michael Lindner wrote:
solution:
apt-get purge $(apt-cache pkgnames plymouth)
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) 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(a)taz.net.au>
BOFH excuse #320:
You've been infected by the Telescoping Hubble virus.
2:11 p.m.
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(a)taz.net.au>
2:38 p.m.
On Mon, 26 Nov 2012, Craig Sanders wrote:
On Mon, Nov 26, 2012 at 12:01:32PM +1100, Craig
Sanders wrote:
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
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. 
3:08 p.m.
On 2012-11-26 14:38, Peter Ross wrote:
On Mon, 26 Nov 2012, Craig Sanders wrote:
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:32PM +1100, Craig
Sanders wrote:
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. 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. 
6:23 p.m.
On Mon, Nov 26, 2012 at 12:01 PM, Craig Sanders <cas(a)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(a)twistedsouls.com
G-Talk: mark.clohesy(a)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"
27 Nov
27 Nov
9:53 a.m.
Craig Sanders writes:
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.
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. [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).
10:41 a.m.
On Tue, Nov 27, 2012 at 09:53:02AM +1100, Trent W. Buck wrote:
i don't see grub as being the problem. in fact, i like grub. the problem is
misconfiguration of grub.
craig
--
craig sanders <cas(a)taz.net.au>
Craig Sanders writes:
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 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. 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...
2:01 p.m.
Craig Sanders <cas(a)taz.net.au> writes:
On Tue, Nov 27, 2012 at 09:53:02AM +1100, Trent W.
Buck wrote:
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.)
Craig Sanders writes:
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 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.
3:22 p.m.
On Tue, Nov 27, 2012 at 02:01:55PM +1100, Trent W. Buck wrote:
Craig Sanders <cas(a)taz.net.au> writes:
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(a)taz.net.au>
On Tue, Nov 27, 2012 at 09:53:02AM +1100, Trent
W. Buck wrote:
I think you're talking about something else. 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. [...]
26 Nov
26 Nov
5:09 p.m.
Peter Ross <Peter.Ross(a)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.
5:27 p.m.
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(a)taz.net.au>
5:43 p.m.
New subject: CADT (was: Gnome-shell very slow on boot)
On 26/11/12 17:27, Craig Sanders wrote:
On Mon, Nov 26, 2012 at 05:09:28PM +1100, Jason White
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"
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)
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?
6:03 p.m.
New subject: CADT (was: Gnome-shell very slow on boot)
Toby Corkindale <toby.corkindale(a)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.
6:51 p.m.
New subject: CADT (was: Gnome-shell very slow on boot)
On Mon, 26 Nov 2012, Jason White <jason(a)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/
27 Nov
27 Nov
10:26 a.m.
New subject: CADT
On 26/11/12 18:51, Russell Coker wrote:
On Mon, 26 Nov 2012, Jason White
<jason(a)jasonjgw.net> 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.
Just because software doesn't do what YOU want/expect, doesn't mean that
it isn't working exactly as designed.
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.
12:37 p.m.
New subject: CADT
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(a)taz.net.au>
10:04 a.m.
New subject: CADT
Jason White <jason(a)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.
26 Nov
26 Nov
5:52 p.m.
On Mon, 26 Nov 2012, Craig Sanders <cas(a)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/
27 Nov
27 Nov
10:13 a.m.
Russell Coker <russell(a)coker.com.au> writes:
On Mon, 26 Nov 2012, Craig Sanders
<cas(a)taz.net.au> wrote:
\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}
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.
10:33 a.m.
trentbuck(a)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/
12:55 p.m.
On Tue, Nov 27, 2012 at 10:33:31AM +1100, Trent W. Buck wrote:
trentbuck(a)gmail.com (Trent W. Buck)
writes:
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(a)taz.net.au>
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/
1:56 p.m.
Craig Sanders <cas(a)taz.net.au> writes:
On Tue, Nov 27, 2012 at 10:33:31AM +1100, Trent W.
Buck wrote:
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 ;-)
trentbuck(a)gmail.com (Trent W. Buck)
writes:
wow. that's amazing!
compared to sysvinit+startpar, systemd improves boot time by 1.1
seconds, and upstart improves it by 0.62 seconds. 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/ 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).
3:20 p.m.
On Tue, 27 Nov 2012, Trent W. Buck wrote:
Craig Sanders <cas(a)taz.net.au> writes:
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:-)
On Tue, Nov 27, 2012 at 10:33:31AM +1100, Trent
W. Buck wrote:
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). 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. 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
4:51 a.m.
Quoting Craig Sanders (cas(a)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(a)linuxmafia.com
McQ! (4x80)
9:34 a.m.
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.
26 Nov
26 Nov
3:44 p.m.
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
27 Nov
27 Nov
10:18 a.m.
Daniel Dalton <d.dalton(a)iinet.net.au> writes:
On Fri, Nov 23, 2012 at 10:28:17PM +1100, Michael
Lindner wrote:
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*.
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.
Did you have any luck with bootchartd?
Assuming you're using runlevel 2, please attach output of
ls -ld /etc/rc[S206].d/*
5:35 p.m.
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
8:05 p.m.
Daniel Dalton <d.dalton(a)iinet.net.au> writes:
On Tue, Nov 27, 2012 at 10:18:26AM +1100, Trent W.
Buck wrote:
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.
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. 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.
1 Dec
1 Dec
1:35 a.m.
On Tue, Nov 27, 2012 at 08:05:50PM +1100, Trent W. Buck wrote:
Yeah, I have. Attempt to decrease boot time slightly.
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 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
9:58 p.m.
Daniel Dalton <d.dalton(a)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.
23 Nov
23 Nov
2:33 p.m.
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
2:47 p.m.
Daniel Dalton <d.dalton(a)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.
2:52 p.m.
On Fri, 23 Nov 2012, Daniel Dalton wrote:
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 Thu, Nov 22, 2012 at 03:01:54PM +1100, Peter Ross
wrote:
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.
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... 
24 Nov
24 Nov
1:50 p.m.
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.
23 Nov
23 Nov
1:46 p.m.
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(a)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
3:10 p.m.
Daniel Dalton <d.dalton(a)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.
27 Nov
27 Nov
5:37 p.m.
On Fri, Nov 23, 2012 at 03:10:50PM +1100, Trent W. Buck wrote:
Daniel Dalton <d.dalton(a)iinet.net.au> writes:
Maybe it could just be processor then, but I was thinking it was the
disk.
It didn't sound particularly unhealthy to me though....
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?
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
8:07 p.m.
Daniel Dalton <d.dalton(a)iinet.net.au> writes:
On Fri, Nov 23, 2012 at 03:10:50PM +1100, Trent W.
Buck wrote:
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.)
Daniel Dalton <d.dalton(a)iinet.net.au>
writes:
Maybe it could just be processor then, but I was thinking it was the
disk. 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? It is command not found. What to install to do this?
smartmontools -- as "apt-file search bin/smartctl" would tell you.
3770
days inactive
3779
days old
53 comments
15 participants
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