Re: [CentOS] is udev necessary?

[Phil Schaffner]

Rudi Ahlers wrote:
...

I have managed to kill udev on start-up (with CTRL + C), and then it boots up.


Try mkinitrd for the current hardware configuration.

Phil

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] is udev necessary?

[Rudi Ahlers]

Hi all

I recently setup a CentOS 5.2 server, running XEN (using HyperVM), and
then moved the hard drive from my test box to my Intel server.The
problem I now have, is that it doesn't bootup properly. Shortly after
I see the udev service started, the machine reboots. This keeps on
going the whole time.

I have managed to kill udev on start-up (with CTRL + C), and then it boots up.
So, do I need udev? And what is it's purpose?

-- 

Kind Regards
Rudi Ahlers
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] is udev necessary?

[Berend Dekens]

Rudi Ahlers schreef:

I have managed to kill udev on start-up (with CTRL + C), and then it boots up.
So, do I need udev? And what is it's purpose?
Udev is a device probing layer. In the old days we had a /dev system 
prepped for standard use which would be complemented with other bootup 
scripts to make nodes for all hardware in your system.


Udev is the successor of this system (the one line history version 
anyway) and builds up the /dev folder with all your devices. In theory 
this is great but most systems (and I'm fairly sure CentOS as well) 
still have a number of base nodes in /dev before udev is fully started. 
This helps the system boot and in case of emergency (udev crashing or a 
broken probing like you have) this would allow the system to boot and 
find its primary devices (if you are lucky this might include all 
neccesary devices, in my case for example, when udev won't start I only 
have one of 2 SATA controllers online).


So in short, you might be able to turn off udev but adding new hardware, 
plugging in usb devices or similar or starting some non-standard 
hardware won't work any more. Perhaps there are more serious issues 
(like soft-raids ignoring the raid and just using one drive).


You might be able to see in the kernel console (ctrl+f10) what happens 
just before the system reboots - if it is a module which fails (most 
likely) you could blacklist it. That would solve the reboots. If the 
module is in fact critical for some piece of hardware you might be able 
to tweak it instead of disabling udev altogether.


Do the system logs contain any clues what is going on or does the system 
kills itself before logging to harddisc comes on?


Regards,
Berend Dekens
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] is udev necessary?

[Rudi Ahlers]

On Mon, Nov 17, 2008 at 2:32 AM, Berend Dekens [EMAIL PROTECTED] wrote:
 Rudi Ahlers schreef:

 I have managed to kill udev on start-up (with CTRL + C), and then it boots
 up.
 So, do I need udev? And what is it's purpose?

 Udev is a device probing layer. In the old days we had a /dev system prepped
 for standard use which would be complemented with other bootup scripts to
 make nodes for all hardware in your system.

 Udev is the successor of this system (the one line history version anyway)
 and builds up the /dev folder with all your devices. In theory this is great
 but most systems (and I'm fairly sure CentOS as well) still have a number of
 base nodes in /dev before udev is fully started. This helps the system boot
 and in case of emergency (udev crashing or a broken probing like you have)
 this would allow the system to boot and find its primary devices (if you are
 lucky this might include all neccesary devices, in my case for example, when
 udev won't start I only have one of 2 SATA controllers online).

 So in short, you might be able to turn off udev but adding new hardware,
 plugging in usb devices or similar or starting some non-standard hardware
 won't work any more. Perhaps there are more serious issues (like soft-raids
 ignoring the raid and just using one drive).

 You might be able to see in the kernel console (ctrl+f10) what happens just
 before the system reboots - if it is a module which fails (most likely) you
 could blacklist it. That would solve the reboots. If the module is in fact
 critical for some piece of hardware you might be able to tweak it instead of
 disabling udev altogether.

 Do the system logs contain any clues what is going on or does the system
 kills itself before logging to harddisc comes on?

 Regards,
 Berend Dekens
 ___

Hi Barend,

Thanx for the info :)

Unfortunately I don't see anything useful in the logs. If I let it
bootup by itself, then it reboots just after booting udev. If,
however, I press CTRL+C the moment I see udev on the screen, I have
attached a snippet from /var/log/message - which doesn't show me
anything at all.


-- 

Kind Regards
Rudi Ahlers
Nov 17 03:07:25 zaxen01 yum: Erased: mhash
Nov 17 03:24:42 zaxen01 shutdown[3219]: shutting down for system reboot
Nov 17 03:24:42 zaxen01 gdm[1995]: Failed to start X server several times in a 
short time period; disabling display :0
Nov 17 03:24:44 zaxen01 avahi-daemon[1579]: Got SIGTERM, quitting.
Nov 17 03:24:44 zaxen01 avahi-daemon[1579]: Leaving mDNS multicast group on 
interface eth0.IPv6 with address fe80::21c:c0ff:fe52:6ad8.
Nov 17 03:24:44 zaxen01 avahi-daemon[1579]: Leaving mDNS multicast group on 
interface eth0.IPv4 with address 196.34.136.110.
Nov 17 03:24:51 zaxen01 auditd[1052]: The audit daemon is exiting.
Nov 17 03:24:51 zaxen01 kernel: audit(1226885091.615:25): audit_pid=0 old=1052 
by auid=4294967295
Nov 17 03:24:51 zaxen01 kernel: Kernel logging (proc) stopped.
Nov 17 03:24:51 zaxen01 kernel: Kernel log daemon terminating.
Nov 17 03:24:52 zaxen01 exiting on signal 15
Nov 17 03:28:42 zaxen01 syslogd 1.4.1: restart.
Nov 17 03:28:42 zaxen01 kernel: klogd 1.4.1, log source = /proc/kmsg started.
Nov 17 03:28:42 zaxen01 kernel: Linux version 2.6.18-92.1.18.el5xen ([EMAIL 
PROTECTED]) (gcc version 4.1.2 20071124 (Red Hat 4.1.2-42)) #1 SMP Wed Nov 12 
10:35:03 EST 2008
Nov 17 03:28:42 zaxen01 kernel: BIOS-provided physical RAM map:
Nov 17 03:28:42 zaxen01 kernel:  Xen:  - 0001f33a8000 
(usable)
Nov 17 03:28:42 zaxen01 kernel: 7259MB HIGHMEM available.
Nov 17 03:28:42 zaxen01 kernel: 727MB LOWMEM available.
Nov 17 03:28:42 zaxen01 kernel: Using x86 segment limits to approximate NX 
protection
Nov 17 03:28:42 zaxen01 kernel: found SMP MP-table at 000fe200
Nov 17 03:28:42 zaxen01 kernel: DMI 2.4 present.
Nov 17 03:28:42 zaxen01 kernel: ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] 
enabled)
Nov 17 03:28:42 zaxen01 kernel: ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] 
enabled)
Nov 17 03:28:42 zaxen01 kernel: ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] 
enabled)
Nov 17 03:28:42 zaxen01 kernel: ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] 
enabled)
Nov 17 03:28:42 zaxen01 kernel: ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl 
lint[0x1])
Nov 17 03:28:42 zaxen01 kernel: ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl 
lint[0x1])
Nov 17 03:28:42 zaxen01 kernel: ACPI: IOAPIC (id[0x02] address[0xfec0] 
gsi_base[0])
Nov 17 03:28:42 zaxen01 kernel: IOAPIC[0]: apic_id 2, version 32, address 
0xfec0, GSI 0-23
Nov 17 03:28:42 zaxen01 kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 
dfl dfl)
Nov 17 03:28:42 zaxen01 kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 
high level)
Nov 17 03:28:42 zaxen01 kernel: Enabling APIC mode:  Flat.  Using 1 I/O APICs
Nov 17 03:28:42 zaxen01 kernel: Using ACPI (MADT) for SMP configuration 
information
Nov 17 03:28:42 zaxen01 kernel: Built 1 zonelists.  Total pages: 2044840
Nov 17 03:28:42 zaxen01 kernel: Kernel 

Re: [CentOS] is udev necessary?

[Berend Dekens]

Rudi Ahlers schreef:

Unfortunately I don't see anything useful in the logs. If I let it
bootup by itself, then it reboots just after booting udev. If,
however, I press CTRL+C the moment I see udev on the screen, I have
attached a snippet from /var/log/message - which doesn't show me
anything at all.
  
Indeed - I see some error messages about memory being assign to weird 
places and ata1 claiming to be a dummy... But nothing that should 
warrant something like a reboot...


I did however see some Xen messages. I am no expert so I can't see if 
this is a hypervisor kernel or a virtual machine kernel. If you are not 
planning on using the machine for or in an Xen environment, you could 
try to switch to a regular one (even if it is for testing). I have had 
some strange behaviour from systems which reacted poorly to 
virtualisation software (most of those get fixed but they can send you 
into the wrong direction).


Another thing that came to mind was that udev might finish properly but 
the next task might crash the system. I would however expect something 
in the message output. Did you check if the udev service claimed to be 
started if you ctrl+c out of it? Its unlikely but can't hurt to test.


If all else fails, you could probably disable udev for now and check if 
everything is working (make sure you don't need pluggable device 
support, otherwise you really do need udev). Plan B would be to Google 
for a debugging mode in udev - unless someone on the list knows how to 
activate that. My guess would be to edit the udev script and pass 
something to the program (most of the time its something like '-v' or 
'-vv' or '-d' or something - look for verbose or debug options).


Good luck,
Berend
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos