We help IT Professionals succeed at work.

Virtualized Linux box keeps looking for original RAID controller

MiddleAgeMan
MiddleAgeMan asked
on
I am in the process of upgrading a currently working linux-based virtual machine of an appliance device with a newer version of the appliance's software. Once the update is applied however, the VM attempts to load the 3Ware RAID array controller driver that is in the original appliance. When I do a side-by-side comparison of the two VMs booting, right after the "Initializing SCSI [OK]" occurs on the older version of the appliance VM it reads:

/code
   Initializing SCSI                              [OK]
   VMWare Machine Detected
   Adding pcnet32 modules
   MODULE [OK]
   Setting up /data/local_0
   ...
/code

and continues the booting procedure. On the updated VM right after the SCSI initialization on boot-up it shows:

/code
   Initializing SCSI                             [OK]
   loading arcmsr
   Detect devfs or udev  [OK]
   Waiting for Adapter...........Get adapters (0)
-------------------------------------
 Setting rollcall pause
-------------------------------------
tw_get_controller_id_list() found 0 Controller(s)

-------------------------------------
  Updating controller map
-------------------------------------

-------------------------------------
 Checking Database Partition
-------------------------------------

   Local_0 Not Mounted
   ...
/code

The tw_contro.. is part of the driver for the 3Ware array controller driver so I know that that is where it is failing.

I am running the VMs in VirtualBox version 4.3.6 r91406.
The linux versions of the appliance are customized versions of the Mandrake distribution using the 2.6 kernel.

So with the given information above, here is what I am looking for help with - Since I can run the two boxes side-by-side, I can do a comparison between the config files in each version, but I need to know which files I should start with. I've started to compare the files in /etc/init.d but there were very few differences there. When I made the changes to the new VM config files to match the old VM config files, the VM still looked for the 3Ware controller, so I am obviously looking in the wrong place.

Which files and in what location should I be looking for to get this working?
Comment
Watch Question

View Solution Only

nociSoftware Engineer
Distinguished Expert 2019

Commented:
chkconfig --list should provide a list of services that are known.
One of those is not needed.... (can you provide it here?)

Also you may need to validate the /etc/fstab to contain the right device names for mounting.
MiddleAgeMan

Author

Commented:
Here is the output from chkconfig --list:

random         	0:off	1:off	2:off	3:on	4:on	5:on	6:off
hotplug        	0:off	1:off	2:on	3:on	4:on	5:on	6:off
dm             	0:off	1:off	2:off	3:off	4:off	5:off	6:off
kheader        	0:off	1:off	2:off	3:off	4:off	5:off	6:off
udev           	0:off	1:off	2:on	3:on	4:on	5:on	6:off
partmon        	0:off	1:off	2:off	3:off	4:off	5:off	6:off
rawdevices     	0:off	1:off	2:off	3:off	4:off	5:off	6:off
keytable       	0:off	1:off	2:off	3:off	4:off	5:off	6:off
netfs          	0:off	1:off	2:off	3:off	4:off	5:off	6:off
numlock        	0:off	1:off	2:off	3:on	4:on	5:on	6:off
syslog         	0:off	1:off	2:off	3:off	4:off	5:off	6:off
ntpd     	0:off	1:off	2:on	3:on	4:on	5:on	6:off
iptables       	0:off	1:off	2:on	3:on	4:on	5:on	6:off
sshd           	0:off	1:off	2:on	3:on	4:on	5:on	6:off
crond          	0:off	1:off	2:on	3:on	4:on	5:on	6:off
netplugd       	0:off	1:off	2:off	3:off	4:off	5:off	6:off
network        	0:off	1:off	2:on	3:on	4:on	5:on	6:off
acpid          	0:off	1:off	2:off	3:on	4:on	5:on	6:off
ntpd           	0:off	1:off	2:on	3:on	4:on	5:on	6:off
lm_sensors     	0:off	1:off	2:on	3:on	4:on	5:on	6:off
dhcpd          	0:off	1:off	2:off	3:off	4:off	5:off	6:off
hddtemp        	0:off	1:off	2:off	3:off	4:off	5:off	6:off
httpd          	0:off	1:off	2:on	3:on	4:on	5:on	6:off
jexec          	0:off	1:on	2:on	3:on	4:on	5:on	6:off
sdxsettings    	0:off	1:off	2:on	3:on	4:on	5:on	6:off
nsxd           	0:off	1:off	2:on	3:on	4:on	5:on	6:off
postgresql     	0:off	1:off	2:on	3:on	4:on	5:on	6:off
initiator      	0:off	1:off	2:off	3:off	4:off	5:off	6:off
syslog-ng      	0:off	1:off	2:on	3:on	4:on	5:on	6:off
PgAutoVacuum   	0:off	1:off	2:off	3:off	4:off	5:off	6:off
permissions    	0:off	1:off	2:on	3:on	4:on	5:on	6:off
ndad           	0:off	1:off	2:off	3:off	4:off	5:off	6:off
nsdd           	0:off	1:off	2:off	3:off	4:off	5:off	6:off
changenotifierd	0:off	1:off	2:off	3:off	4:off	5:off	6:off
grestored      	0:off	1:off	2:on	3:on	4:off	5:off	6:off
nsmd           	0:off	1:off	2:off	3:off	4:off	5:off	6:off
nspd           	0:off	1:off	2:off	3:off	4:off	5:off	6:off
networkconfigd 	0:off	1:off	2:off	3:off	4:off	5:off	6:off
pald           	0:off	1:off	2:on	3:on	4:off	5:off	6:off
pal3d          	0:off	1:off	2:on	3:on	4:on	5:on	6:off
mbrd           	0:off	1:off	2:on	3:on	4:on	5:on	6:off
devicealiveinterface	0:off	1:off	2:off	3:off	4:off	5:off	6:off
passrot        	0:off	1:off	2:off	3:off	4:off	5:off	6:off
snmp      	0:off	1:off	2:on	3:on	4:on	5:on	6:off
auditd         	0:off	1:off	2:off	3:off	4:off	5:off	6:off
watchdogd      	0:off	1:off	2:on	3:on	4:on	5:on	6:off
swapd          	0:off	1:off	2:on	3:on	4:on	5:on	6:off
mount-thirdparty	0:off	1:off	2:off	3:on	4:on	5:on	6:off
ddfHandler     	0:off	1:off	2:on	3:on	4:on	5:on	6:off

Open in new window


local_0 is not loaded from fstab, it is loaded by one of the appliance scripts after it checks to see if the array is present.
nociSoftware Engineer
Distinguished Expert 2019

Commented:
sdxsettings  seems a likely candidate to check the script for (/etc/init.d/sdxsettings)
likewise: mount-thirdparty
nsxd is VMware related.
pald/pal3d seem 3d printer related, otherwise they need verify too.
mbrd, ddfHandler i cannot find references for,

The boot order can be found in /etc/rc2.d (for level 2), rc3.d for level 3 up to level 5.
the files are executed in alphfabetical order.
level 0 = shutdown, level 1 = singleuser, level 6 = reboot.
Scripts starting with S start something, with K stop something.

in /etc/inittab you should be able to find the default entry  for which level gets booted.
Commented:
A co-worker and I found the issue. A script in /mbr called addvmware was making a reference to a drive that did not exist. We were able to get the system working by using the following command:

sed -i 's/hdd/hdc/' /mbr/addvmware

Open in new window


Thanks for the assist, noci.
MiddleAgeMan

Author

Commented:
The problem was solved outside of the Expert Exchange community however I want to make sure that people who read the thread later understand the solution and  know that the issue is closed so they don't make other comments.