#36 0.38, problems detecting partitions

Jaroslaw Gorny

On HP ProLiant BL460c blades, using 0.38 version of G4L, root disks are not detected properly. Normally when you choose the (H) backup option, you're presented with the list of partitions which should look like:

[ ] /dev/cciss/c0d0
[ ] /dev/cciss/c0d0p0
[ ] /dev/cciss/c0d0p1
[ ] /dev/cciss/c0d0p2

but now the list looks like this:

[ ] /dev/cciss
[ ] /dev/cciss
[ ] /dev/cciss
[ ] /dev/cciss


  • Question?
    1. What does cat /proc/partitions show?
    2. Are you saying that older versions of g4l showed the /dev/cciss/c0d0 and 0.38 now shows just /dev/cciss?

    Is this with the same kernel, or not?

  • In a further check, I had added the use of fsarchiver probe to get additional partition, and it might be that it isn't working with cciss devices. A quick way to see if this is causing the problem would be to remove the fsarchiver programs from the setup by.

    rm /usr/local/sbin/fsarchiver*
    then run g4l again, and see it it reports the partitions.

    Could be possible to add code to get it to not using the part_info2 function if cciss exists on a system?

  • Note: Can you run fsarchiver probe and what exactly does it show for the devices?
    In looking, I am currently only pulling bytes 2 thru 5 for the name, but the space actually goes from 2-17.
    It that does contain the full partition path, I can just change it to use 2-17, but if it only shows cciss anyway, then
    having it not use part_info2 would have to be the method. I don't have access to any system that has cciss, so
    need the info.


  • I've created an updated version that now pulls the whole device field from positions 2-17 and it is available as:

    There is a link I found that seems to show that the / in the cciss/c0d0 might be changed into a !,
    If that is the case, I would have to modify that to put the / back in the variable.

    Not having access to any system with this controller, I need to get some feedback. If the alpha 15 shows it correctly, then the problem is resolved, if it has the ! that would be a quick fix. If it doesn't show the information correctly, then having it no use the part_info2 for any system that has a cciss controller would fix the issue. (Actually did do this in alpha14, but would prefer to have it work with the fsarchiver info). Also, there are a couple of other controllers that seem to be setup like the cciss, and would like to have it working for them as well.

    This is the link to the mention of the / and ! issue, but don't know if it is actually in the released 6.12 version of fsarchiver, or was in a testing version.


  • In the latest alpha's of 0.39 I believe this issue is resolved.