Page 1 of 2

minimyth 0.25.0-80 (and 81b5) take a very long time to start

Posted: Mon May 21, 2012 11:29 am
by rjch
I've just upgraded to MythTV 0.25 from 0.24.1 (backend is Mythbuntu) and have run into a minor annoyance with both MiniMyth 0.25.0-80 and -81b5. The system picks up both the kernel and the rootfs from my NAS without a problem, but then stops at a black screen for 1-5 minutes. No display, no network activity that I can discenrn. Initially I suspected it was crashing at login and was about to revert to 0.24 when I got distracted for a few minutes and eventually MiniMyth booted normally and with the exception of a few buttons on the remote control (which I haven't had a chance to re-capture yet) not working, everything works fine.

/var/log/messages, of course contain no clues since nothing gets written to it until after syslog has started. dmesg's output looks normal to me. Output is as follows:-

Code: Select all

root@mythfr1:/var/log # dmesg
6>Switching to clocksource tsc
\
usb 2-7: new low-speed USB device number 2 using ohci_hcd
done.
VFS: Mounted root (squashfs filesystem) readonly on device 1:0.
Freeing unused kernel memory: 348k freed
Registering unionfs 2.5.11 (for 3.3.0-rc3)
>udevd[78]: starting version 182
NET: Registered protocol family 17
Real Time Clock Driver v1.12b
loop: module loaded
ppdev: user-space parallel port driver
input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input0
ACPI: Power Button [PWRB]
input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
ACPI: Power Button [PWRF]
wmi: Mapper loaded
i2c i2c-0: nForce2 SMBus adapter at 0x1c00
i2c i2c-1: nForce2 SMBus adapter at 0x1c80
input: iMON Panel, Knob and Mouse(15c2:0038) as /devices/pci0000:00/0000:00:04.0/usb2/2-7/2-7:1.0/input/input2
IR NEC protocol handler initialized
IR RC5(x) protocol handler initialized
snd_hda_intel 0000:00:09.0: power state changed by ACPI to D0
snd_hda_intel 0000:00:09.0: power state changed by ACPI to D0
ACPI: PCI Interrupt Link [AAZA] enabled at IRQ 20
hda_intel: Disabling MSI
snd_hda_intel 0000:00:09.0: setting latency timer to 64
it87: Found IT8718F chip at 0x290, revision 5
it87: Beeping is supported
Registered IR keymap rc-imon-pad
input: iMON Remote (15c2:0038) as /devices/pci0000:00/0000:00:04.0/usb2/2-7/2-7:1.0/rc/rc0/input3
rc0: iMON Remote (15c2:0038) as /devices/pci0000:00/0000:00:04.0/usb2/2-7/2-7:1.0/rc/rc0
imon 2-7:1.0: iMON device (15c2:0038, intf0) on usb<2:2> initialized
imon 2-7:1.1: iMON device (15c2:0038, intf1) on usb<2:2> initialized
usbcore: registered new interface driver imon
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
IR RC6 protocol handler initialized
IR JVC protocol handler initialized
IR Sony protocol handler initialized
IR SANYO protocol handler initialized
IR MCE Keyboard/mouse protocol handler initialized
lirc_dev: IR Remote Control driver registered, major 252 
IR LIRC bridge handler initialized
hda_codec: ALC889A: BIOS auto-probing.
p4-clockmod: Warning: EST-capable CPU detected. The acpi-cpufreq module offers voltage scaling in addition to frequency scaling. You should use that instead of p4-clockmod, if possible.
p4-clockmod: P4/Xeon(TM) CPU On-Demand Clock Modulation available
coretemp coretemp.0: Using relative temperature scale!
coretemp coretemp.0: Using relative temperature scale!
lirc_imon: module is from the staging directory, the quality is unknown, you have been warned.
usbcore: registered new interface driver lirc_imon
Linux agpgart interface v0.103
nvidia: module license 'NVIDIA' taints kernel.
Disabling lock debugging due to kernel taint
ACPI: PCI Interrupt Link [AIGP] enabled at IRQ 23
nvidia 0000:00:10.0: setting latency timer to 64
vgaarb: device changed decodes: PCI:0000:00:10.0,olddecodes=io+mem,decodes=none:owns=io+mem
NVRM: loading NVIDIA UNIX x86 Kernel Module  295.53  Fri May 11 23:13:15 PDT 2012
p4-clockmod: Warning: EST-capable CPU detected. The acpi-cpufreq module offers voltage scaling in addition to frequency scaling. You should use that instead of p4-clockmod, if possible.
p4-clockmod: P4/Xeon(TM) CPU On-Demand Clock Modulation available
unionfs: new lower inode mtime (bindex=0, name=certs)
unionfs: new lower inode mtime (bindex=0, name=libexec)
unionfs: new lower inode mtime (bindex=0, name=gdk-pixbuf-2.0)
This machine is now two or three years old and has worked without a problem up until the 0.25 release. The 0.24.1-77 image still loads and boots normally (at least until Myth starts and it can't connect to the newer version) The black screen after the rootfs has loaded there lasts only a couple of seconds.

Any ideas what might be causing this issue and how I might be able to get around it? It's not a critical problem by any stretch of the imagination since the machine does operate more or less normally after starting, but it is irritating to have to wait several minutes for the machine to boot.

Re: minimyth 0.25.0-80 (and 81b5) take a very long time to s

Posted: Wed May 23, 2012 3:20 am
by brown_m_k
Hi folks!

I'm running minimyth-0.24.2-80, and I also have a long delay between downloading the kernel and roots, and the splash screen/startup sequence. I'm not sure where the delay is coming from, but I can confirm it does exist. I don't have the same issue with a -76 instance.

Hope that helps!

/Mike

Re: minimyth 0.25.0-80 (and 81b5) take a very long time to s

Posted: Wed May 23, 2012 11:01 pm
by Pablo
What hardware do you have?

In particular that video hardware and the network hardware?

Re: minimyth 0.25.0-80 (and 81b5) take a very long time to s

Posted: Thu May 24, 2012 2:55 am
by brown_m_k
Hi Paul!

In my case, ASUS M2NPV-VM, dual core AMD, 2 GB RAM, and in this one, two Tuner cards (PVR-150's) and mceusb IR. It is running .24-80, and is a slave backend to a Master running 0.24-2 on Debian 6.05. I had to roll back my other ones due to the photo screensaver not working (won't display pictures, even though the directory is mounted), plus one other issue on a RADEON based AMD system (no sound over HDMI).

The delay wasn't a show stopper for me, and I had to upgrade that backend due to a MySQL upgrade on the Master. The others I'm leaving as-is for now on -76, as I'm working towards a 0.25 upgrade on everything.

Thanks!

/Mike

Re: minimyth 0.25.0-80 (and 81b5) take a very long time to s

Posted: Fri May 25, 2012 8:20 am
by rjch
Hi Pablo,

Ethernet controller: NVIDIA Corporation MCP73 Ethernet (rev a2) - hardware ID is 10de:07e1.
VGA compatible controller: NVIDIA Corporation C73 [GeForce 7100 / nForce 630i] (rev a2) - hardware ID is 10de:07e1.

Re: minimyth 0.25.0-80 (and 81b5) take a very long time to s

Posted: Sat May 26, 2012 5:50 am
by Pablo
rjch wrote:Hi Pablo,

Ethernet controller: NVIDIA Corporation MCP73 Ethernet (rev a2) - hardware ID is 10de:07e1.
VGA compatible controller: NVIDIA Corporation C73 [GeForce 7100 / nForce 630i] (rev a2) - hardware ID is 10de:07e1.
The vendor id for the Ethernet controller appeases odd. It has the same id as that graphics card.

Re: minimyth 0.25.0-80 (and 81b5) take a very long time to s

Posted: Sat May 26, 2012 9:20 am
by rjch
Pablo wrote:
rjch wrote:Ethernet controller: NVIDIA Corporation MCP73 Ethernet (rev a2) - hardware ID is 10de:07e1.
VGA compatible controller: NVIDIA Corporation C73 [GeForce 7100 / nForce 630i] (rev a2) - hardware ID is 10de:07e1.
The vendor id for the Ethernet controller appeases odd. It has the same id as that graphics card.
Yeah, that's a bad copy-and-paste on my part. :) The hardware ID for the ethernet controller is 10de:07dc.

Re: minimyth 0.25.0-80 (and 81b5) take a very long time to s

Posted: Sat May 26, 2012 8:18 pm
by ledhed
I just upgraded to 0.25.0-80 last night.
I'm experiencing the exact same thing. My FE stays black for approx 5 min (I'm unable to ping/telnet in during this time), then the splash pops up and proceeds normally.

minimyth.log reports the following:

Code: Select all

Can't exec "/sbin/udevadm": No such file or directory at /etc/rc.d/init/modules_automatic.pm line 36. 
Can't exec "/sbin/udevadm": No such file or directory at /etc/rc.d/init/modules_automatic.pm line 37.
Unknown username "avahi" in message bus configuration file
Unknown group "netdev" in message bus configuration file
-LedHed

Re: minimyth 0.25.0-80 (and 81b5) take a very long time to s

Posted: Sun May 27, 2012 5:26 am
by Pablo
ledhed wrote:

Code: Select all

Can't exec "/sbin/udevadm": No such file or directory at /etc/rc.d/init/modules_automatic.pm line 36. 
Can't exec "/sbin/udevadm": No such file or directory at /etc/rc.d/init/modules_automatic.pm line 37.
Unknown username "avahi" in message bus configuration file
Unknown group "netdev" in message bus configuration file
That should be fixed now. Does 81b5 work?

Re: minimyth 0.25.0-80 (and 81b5) take a very long time to s

Posted: Sun May 27, 2012 7:34 pm
by ledhed
Pablo,

81b5 indeed fixes the errors I posted above, but does not fix the black screen issue.

Is there any other info I can post to help track down this issue?

Re: minimyth 0.25.0-80 (and 81b5) take a very long time to s

Posted: Mon May 28, 2012 8:04 am
by rjch
Pablo wrote:Does 81b5 work?
Same here - black screen on boot is still there in 81b5.

Re: minimyth 0.25.0-80 (and 81b5) take a very long time to s

Posted: Thu Jun 14, 2012 9:05 pm
by bcromwell
Using NFS to boot or for mounting shares?

Re: minimyth 0.25.0-80 (and 81b5) take a very long time to s

Posted: Sat Jun 16, 2012 5:49 pm
by ledhed
I use RAM-minimyth, but I also mount some additional shares via NFS.

Re: minimyth 0.25.0-80 (and 81b5) take a very long time to s

Posted: Sun Jul 29, 2012 4:30 pm
by Pablo
ledhed wrote:Pablo,

81b5 indeed fixes the errors I posted above, but does not fix the black screen issue.

Is there any other info I can post to help track down this issue?
Could you try MiniMyth 81?

Re: minimyth 0.25.0-80 (and 81b5) take a very long time to s

Posted: Sat Aug 04, 2012 6:02 am
by rjch
Pablo wrote:Could you try MiniMyth 81?
0.25.2-81 still has the really long delay after reading rootfs from TFTP before it boots.

I finally had the thought to turn on debugging messages to see where it might be hanging in the boot sequence. Rather than capturing the log, here's a photo of the screen:-

Image

The little spinner is where the kernel stops for a minute or two.