Bugs item #639197, was opened at 2002-11-15 18:40
Message generated for change (Comment added) made by dannf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100259&aid=639197&group_id=259

Category: Initial RAM Disk
Group: None
>Status: Closed
Resolution: Fixed
Priority: 8
Submitted By: dann frazier (dannf)
Assigned to: dann frazier (dannf)
Summary: devfs vs. cciss & cpqarray

Initial Comment:
version 2.9.4

if you create an image w/ 2.9.4 and have cciss or

cpqarray devices

(and you're not using devfs), things break because we

don't have

the proper special files in the ramdisk.



for example, on a non devfs system, you would have:

  /dev/ida/c0d0     # first disk on first controller

  /dev/ida/c0d0p1  # first partition on first disk on

first controller



on a devfs system, you would have:

  /dev/ida/c0d0/disc1 # first disk on first controller

  /dev/ida/c0d0/part1  # first partition on first disk

on first controller



i thought about teaching devfsd about the difference &

letting

it make compatability symlinks.  this won't work.

the problem is that you can't symlink 

/dev/ida/c0d0 -> /dev/ida/c0d0/disc1, since the former

contains the latter.







----------------------------------------------------------------------

>Comment By: dann frazier (dannf)
Date: 2003-09-14 23:37

Message:
Logged In: YES 
user_id=146718

closing again - nothing but sucessful reports w/ the latest

transform code.  please add any reports to the contrary.

----------------------------------------------------------------------

Comment By: dann frazier (dannf)
Date: 2003-06-25 17:31

Message:
Logged In: YES 
user_id=146718

> So the autoinstall script that gets created during the image

> creation is no good and running mkautoinstallscript later

> will fix that?



if the first script was created with an earlier version of

SI, and the second script was created with a current

version, then yes - it will potentially fix the problem.



i just got me a dl360 w/ an onboard cciss controller & did

an install w/ the code from head.  it worked w/o problems. 

i don't know of anything that changed between 3.0.1 and head

that would have fixed this.



the commands *should* be running on /dev/cciss/disc0/disc in

your .master script.  this is the devfs equivalent of

/dev/cciss/c0d0.

we use devfs during the install, so we transform the names

in the .master script to use the devfs names.  however, when

your clients boot back up, they'll be using the non-devfs names.



please provide you autoinstallscript.conf and .master file

if you think there's still a problem in 3.0.1.  even though

it probably won't be fixed in the 3.0 series (3.2 is

imminent), i'd like to know what you are seeing to make sure

its not something that still exists in cvs.



----------------------------------------------------------------------

Comment By: Steven A. DuChene (sad)
Date: 2003-06-25 10:17

Message:
Logged In: YES 
user_id=2347

So the autoinstall script that gets created during the image

creation is no good and running mkautoinstallscript later

will fix that? If that is true why is the first one get

created with the /dev/cciss/c0d0p which doesn't actually

work if you believe the mkautoinstallscript will fix it?

Recall I had to hand edit the master script so all of the

part commands were being run on /dev/cciss/disc0/disc instead.

----------------------------------------------------------------------

Comment By: dann frazier (dannf)
Date: 2003-06-21 13:37

Message:
Logged In: YES 
user_id=146718

from a duplicate bug report:



 I am working with some HP/Compaq systems that have

cpqarray disk controllers that are hung off of

/dev/cciss device tree. When the imagename.master

script is created the script is attempting to create

partitions on devices as /dev/cciss/c0d0p however this

does not exist at the time the master scriot is run

during installation. In order to get the master script

to work I have to alter it so the partioning is being

done against /de/cciss/disc0/disc instead. This gets

the system installed but when the systems reboot after

install they have a problem mounting their partitions

correctly.

----------------------------------------------------------------------

Comment By: dann frazier (dannf)
Date: 2003-06-19 09:06

Message:
Logged In: YES 
user_id=146718

ok - i'll reopen then.

however, people using 1 controller have reported success w/

3.0.1.

did you run mkautoinstallscript to update your scripts?



if there's still a problem, provide your

autoinstallscript.conf & the generated .master script for

your image.

----------------------------------------------------------------------

Comment By: Steven A. DuChene (sad)
Date: 2003-06-19 07:37

Message:
Logged In: YES 
user_id=2347

This may be marked fixed but I am still seeing problems in

3.0.1 stuff I downloaded a couple of weeks ago. And I do NOT

have disks hung off of multiple channels.

----------------------------------------------------------------------

Comment By: dann frazier (dannf)
Date: 2003-01-22 19:36

Message:
Logged In: YES 
user_id=146718

fixed in cvs - will be fixed in 3.0.1

----------------------------------------------------------------------

Comment By: Brian Elliott Finley (brianfinley)
Date: 2003-01-22 18:24

Message:
Logged In: YES 
user_id=140

dannf, is this fixed?  Should we change it's Status to Closed?

----------------------------------------------------------------------

Comment By: dann frazier (dannf)
Date: 2003-01-17 23:34

Message:
Logged In: YES 
user_id=146718

oops - i guess the patch never made it.

here's the one that got committed:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/systemimager/systemimager/lib/SystemImager/Server.pm.diff?r1=1.56.4.2&r2=1.56.4.3&only_with_tag=v3_0_x



----------------------------------------------------------------------

Comment By: David K Livingstone (living03)
Date: 2003-01-14 08:11

Message:
Logged In: YES 
user_id=79389

Where is the patch ? I just attempted to image a cciss

device(see

[SystemImager-discuss] Attempting to image Suse 7.2(w LVM)

using 3.0.0)

And had the following error while booting from floppy and

running the

autoinstall script : 

Partitioning /dev/cciss/c0d0/disc ...

Error : Could not stat device /dev/cciss/c0d0/disc - No such

file or directory.

>From the floppy the device is named :

/dev/cciss/disc0/disc

----------------------------------------------------------------------

Comment By: David K Livingstone (living03)
Date: 2003-01-14 08:10

Message:
Logged In: YES 
user_id=79389

Where is the patch ? I just attempted to image a cciss

device(see

[SystemImager-discuss] Attempting to image Suse 7.2(w LVM)

using 3.0.0)

And had the following error while booting from floppy and

running the

autoinstall script : 

Partitioning /dev/cciss/c0d0/disc ...

Error : Could not stat device /dev/cciss/c0d0/disc - No such

file or directory.

>From the floppy the device is named :

/dev/cciss/disc0/disc

----------------------------------------------------------------------

Comment By: dann frazier (dannf)
Date: 2003-01-06 00:20

Message:
Logged In: YES 
user_id=146718

a patch from james stroehmann is attached.

it fixes cciss devices.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100259&aid=639197&group_id=259


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Sisuite-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/sisuite-devel

Reply via email to