Long delay between GRUB and #! booting (almost 60s)

root2 · 2012-11-16 08:24:09

Hi there.

When booting #!10 without backports from my USB drive I experience a long delay - almost around 60s - after GRUB finishes and Statler begins booting.

During this delay I see a blank screen with no cursors or whatsoever blinking and the display doesn't enter sleep/powerdown mode. Afterwards linux starts booting as usual ("Loading, please wait") and finishes to the login screen in around 30s. When booting from the live CD this issue doesn't happen and there is almost no delay.

I already searched for similar things on google but it seems there are several "long delay" topics actually occurring:
- Long delay after GRUB with a blinking cursor (seems as if this is not my problem)
- Long delay after GRUB with sometimes having the system freeze completely (also not my kind of problem)
- Long delay after GRUB because of the configured wait time in GRUB config (seems also not to fit in my case - see bootchart images later on)
- LONG delay after GRUB because of using storage on USB, SD, CF cards, etc. (this one looks like my case but sadly there's not much info to be found for this). I tried this on two more USB thumbdrives with similar results.

Analyzing the boot sequence using bootchart stated a boot time of around 33s and produced images looking like these (not my actual ones but they look very similar):
Chart 1
Chart 2

You can see there's a delay of around 5-15 seconds after GRUB finishes and Linux starts utilizing things and booting up. I also have this delay of about 10s but that seems to be a delay set in GRUB or init config. Also my bootchart really stops at around 30s and not after 90s like it is in reality when using a watch to measure the boot time manually.

Can anyone provide some information on how to solve this problem if it's a known one?
Or maybe one can back my findings that it seems to be related using special kinds of storage media for a full #! install?

Every help is appreciated.

P.S.: I don't think it might be related to it but I'll give systemd a shot instead of using init if I find some spare time ...

Last edited by root2 (2012-11-16 08:52:06)

orionthehunter · 2012-11-16 08:29:56

I don't think systemd has been backported to stable. I could be wrong, but regardless the problem should be solvable without switching out sysVinit.

can you post results of

lspci

I'm not the expert on this, but I have an amateur's hunch that it has to do with your graphics card.

root2 · 2012-11-16 08:38:19

orionthehunter wrote:

I don't think systemd has been backported to stable. I could be wrong, but regardless the problem should be solvable without switching out sysVinit.
can you post results of
lspci
I'm not the expert on this, but I have an amateur's hunch that it has to do with your graphics card.

Thank you for your reply.

I'll give it a shot when I have access to the machine, again. From the mainboard's specs I see the IGP is a VIA Unichrome Pro processor. Maybe this helps in the meanwhile.

Best regards.

P.S.: I forgot to mention, that when booting the live CD there is almost no delay (also edited the main post accordingly).

Last edited by root2 (2012-11-16 08:52:49)

cchhrriiss121212 · 2012-11-16 10:43:05

root2 wrote:

Or maybe one can back my findings that it seems to be related using special kinds of storage media for a full #! install?

I think this is more than likely the issue, USB just doesn't have the I/O speed of a regular hard drive. I had a similar experience when doing a USB install.

root2 · 2012-11-16 11:03:55

cchhrriiss121212 wrote:

root2 wrote:
Or maybe one can back my findings that it seems to be related using special kinds of storage media for a full #! install?
I think this is more than likely the issue, USB just doesn't have the I/O speed of a regular hard drive. I had a similar experience when doing a USB install.

Thank you for your input!

Then it would be really interesting to know what the system does in this 60s between GRUB and linux booting. How might I be able to view this as bootchart doesn't cover this phase of booting?

cchhrriiss121212 · 2012-11-16 11:55:59

I guess it is just waiting for the disk, but I don't really know how to analyse it any further.

machinebacon · 2012-11-16 12:15:22

In GRUB's boot menu press "e" and replace "quiet" with "verbose" to see more output.

root2 · 2012-11-16 16:25:03

orionthehunter wrote:

I don't think systemd has been backported to stable. I could be wrong, but regardless the problem should be solvable without switching out sysVinit.
can you post results of
lspci
I'm not the expert on this, but I have an amateur's hunch that it has to do with your graphics card.

Here you are:

00:00.0 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge
00:00.1 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge
00:00.2 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge
00:00.3 Host bridge: VIA Technologies, Inc. PT890 Host Bridge
00:00.4 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge
00:00.7 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge
00:01.0 PCI bridge: VIA Technologies, Inc. VT8237/VX700 PCI Bridge
00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8110SC/8169SC Gigabit Ethernet (rev 10)
00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8110SC/8169SC Gigabit Ethernet (rev 10)
00:0f.0 IDE interface: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80)
00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
00:10.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86)
00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800/K8T890 South]
00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60)
01:00.0 VGA compatible controller: VIA Technologies, Inc. CN700/P4M800 Pro/P4M800 CE/VN800 [S3 UniChrome Pro] (rev 01)

machinebacon wrote:

In GRUB's boot menu press "e" and replace "quiet" with "verbose" to see more output.

Thank you for your reply.

I did this and the delay exists still even with more info displayed. The timestamp at the beginning of each logged line when booting linux ends at around 30s so I think the issues is not while booting linux.

Last edited by root2 (2012-11-16 16:40:52)

machinebacon · 2012-11-17 10:44:47

01:00.0 VGA compatible controller: VIA Technologies, Inc. CN700/P4M800 Pro/P4M800 CE/VN800 [S3 UniChrome Pro] (rev 01)

Can you check if the driver is actually installed? S3 Chrome can be a PITA sometimes...

apt-cache policy xserver-xorg-video-openchrome

root2 · 2012-11-19 21:13:17

machinebacon wrote:

01:00.0 VGA compatible controller: VIA Technologies, Inc. CN700/P4M800 Pro/P4M800 CE/VN800 [S3 UniChrome Pro] (rev 01)
Can you check if the driver is actually installed? S3 Chrome can be a PITA sometimes...
apt-cache policy xserver-xorg-video-openchrome

Hi.

When issuing your command I get this:

root2@CrunchWall:~$ apt-cache policy xserver-xorg-video-openchrome
xserver-xorg-video-openchrome:
  Installiert: 1:0.2.904+svn842-2
  Kandidat:    1:0.2.904+svn842-2
  Versionstabelle:
     1:0.2.904+svn920-1~bpo60+1 0
        100 http://backports.debian.org/debian-backports/ squeeze-backports/main i386 Packages
 *** 1:0.2.904+svn842-2 0
        500 http://ftp.debian.org/debian/ squeeze/main i386 Packages
        100 /var/lib/dpkg/status
root2@CrunchWall:~$

So it seems as if the package is already installed.

I found another post about the driver issues here: http://forums.debian.net/viewtopic.php?f=5&t=39452
Maybe I will give this a try later on:

...
To complete the job, install:
libgl1-mesa-dri
libgl1-mesa-glx
libglu1-mesa
mesa-utils (to confirm glxinfo and glxgears)
libdrm2
...

Thanks for your input!

machinebacon · 2012-11-20 03:47:55

^ This listens itself already once good on big_smile (Das hoert sich schon mal gut an)

For some more points like maximum resolution etc you can have a look at the 'modeline setting' (this is not always needed, but I do have to use this on my netbook) at http://forums.debian.net/viewtopic.php?f=5&t=58294
If you're lucky, it all works out of the box nicely.

root2 · 2012-11-20 09:30:01

Thanks, machinebacon.
I'll give it a shot when I have the time to and try to upload the latest bootchart I created for you to review.

BTW: I'm running the S3 Chrome @ 1680x1050 in #! 10 (at least that's what my TFT tells me, I think).
After all it's not a real PITA to wait 90s for the system to boot up (instead of maybe 40s) but hey, when it can do the same thing faster I really want to give it a try smile

CrunchBang Linux

SEARCH

#1 2012-11-16 08:24:09

Long delay between GRUB and #! booting (almost 60s)

#2 2012-11-16 08:29:56

Re: Long delay between GRUB and #! booting (almost 60s)

#3 2012-11-16 08:38:19

Re: Long delay between GRUB and #! booting (almost 60s)

#4 2012-11-16 10:43:05

Re: Long delay between GRUB and #! booting (almost 60s)

#5 2012-11-16 11:03:55

Re: Long delay between GRUB and #! booting (almost 60s)

#6 2012-11-16 11:55:59

Re: Long delay between GRUB and #! booting (almost 60s)

#7 2012-11-16 12:15:22

Re: Long delay between GRUB and #! booting (almost 60s)

#8 2012-11-16 16:25:03

Re: Long delay between GRUB and #! booting (almost 60s)

#9 2012-11-17 10:44:47

Re: Long delay between GRUB and #! booting (almost 60s)

#10 2012-11-19 21:13:17

Re: Long delay between GRUB and #! booting (almost 60s)

#11 2012-11-20 03:47:55

Re: Long delay between GRUB and #! booting (almost 60s)

#12 2012-11-20 09:30:01

Re: Long delay between GRUB and #! booting (almost 60s)

Board footer