I'm trying to do a test run of g4l for my boss, in order to do a comparison with g4u in order to determine which direction to do on our HD imaging project.
I've filled out all the parameters to do the transfer, and it looks like it's logging in to our ftp server just fine, but when the transfer is supposed to take place, the progress bar just jumps from 0 to 100% immediately (I think we're talking about creating an image for a 10 gig drive, so this seems - er, ah - a little fast to me) and of course there's no image file being transferred to the ftp server at all.
Anyone else out there having this kind of a problem?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Glad you found it. g4l is basically the root id for the image, that is how it was in version 0.14, and I saw no reason to change it. I did make it auto login on the first tty, since it saves a step. I try to point out that it is the letter g, number 4, and letter l. Several have had entered the number 41 instead of 41.
Note: If you are going to work with the development kit, it must be done as root, since the devices will not be made with non-root user.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is almost always because you did not create a subdirectory called img. The earlier versions of g4l defaulted to using this subdirectory rather than placing the image file in the default directory. I've added the ability to change this directory, but the default directory is still the img. So, the easiest solutions, is to just created the img directory and it should work. An additional suggestion, I recommend using an image with .lzo extention and lzop compress. If you are passing the parameters, or using the front end, the image name will get it to default. I've found that the image creation time is about 1/2 for lzop, but does produce and image about 15% larger. Restore time is about the same for both. Also, make sure to use the blank5 or cleandrive scripts to clear unused sectors before doing an image. Will greatly increase speed, and decrease size of image.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No, actually I did try that, having noticed what the default was set to. I'm sending (or rather, attempting to send) to an FTP server on a Windows workstation. The default directory name for the FTP server on that workstation is named ftproot, if I remember correctly. I've tried setting the default directory name to (blank), to "img" (after I created a subdirectory in ftproot named img); I've tried \ftproot; I've tried \inetpub\ftproot. Nothing works.
I have noticed the following error message when I try to use the "Display Time" option: "error on stdout (0xc)"; is the program writing the options to stdout and the file is not being created or something?
I've tried different boot options, I've tried everything I can think of to get this thing to go, and all I get is the same response, 0 to 100 in about 2 seconds, and no file transferred.
Any other suggestions?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We solved our problem by going with a different FTP client than the Windows one; FileZilla worked for us. G4L looks like it's designed to use passive mode commands that the Windows FTP server didn't understand or know how to handle. Once we switched to FileZilla, everything worked like a charm.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well mine is still doing the same thing with VSFTPD and FileZilla.
Here is the out file from the tmp dir for both vsftpd and FIleZilla
LibNcFTP 3.1.9 (March 19, 2005) compiled for linux-x86
Uname: Linux|g4l|2.6.13.4|#2 SMP Wed Oct 19 01:10:20 ChST 2005|i686
Glibc: 2.3.5 (stable)
220: (vsFTPd 1.2.1)
Connected to 192.168.10.54.
Cmd: USER admin
331: Please specify the password.
Cmd: PASS xxxxxxxx
230: Login successful.
Cmd: PWD
257: "/"
Logged in to 192.168.10.54 as admin.
Cmd: FEAT
211: Features:
MDTM
REST STREAM
SIZE
End
Cmd: HELP SITE
214: The following commands are recognized.
ABOR ACCT ALLO APPE CDUP CWD DELE EPRT EPSV FEAT HELP LIST MDTM MKD
MODE NLST NOOP OPTS PASS PASV PORT PWD QUIT REIN REST RETR RMD RNFR
RNTO SITE SIZE SMNT STAT STOR STOU STRU SYST TYPE USER XCUP XCWD XMKD
XPWD XRMD
Help OK.
Cmd: CLNT NcFTPPut 3.1.9 linux-x86
500: Unknown command.
Cmd: TYPE I
200: Switching to Binary mode.
Cmd: PASV
227: Entering Passive Mode (192,168,10,54,24,209)
Cmd: STOR img/gungadin.lzo
150: Ok to send data.
226: File receive OK.
Cmd: MDTM 20051123144428 img/gungadin.lzo
550: Could not get file modification time.
Cmd: QUIT
221: Goodbye.
LibNcFTP 3.1.9 (March 19, 2005) compiled for linux-x86
Uname: Linux|g4l|2.6.13.4|#2 SMP Wed Oct 19 01:10:20 ChST 2005|i686
Glibc: 2.3.5 (stable)
220: FileZilla Server version 0.9.11 beta
written by Tim Kosse (Tim.Kosse@gmx.de)
Please visit http://sourceforge.net/projects/filezilla/
Connected to 192.168.10.61.
Cmd: USER admin
331: Password required for admin
Cmd: PASS xxxxxxxx
230: Logged on
Cmd: PWD
257: "/" is current directory.
Logged in to 192.168.10.61 as admin.
Cmd: FEAT
211: Features:
MDTM
REST STREAM
SIZE
MLST type;size;modify*;
End
Cmd: HELP SITE
502: Command SITE is not recognized or supported by FileZilla Server
Cmd: CLNT NcFTPPut 3.1.9 linux-x86
500: Syntax error, command unrecognized.
Cmd: TYPE I
200: Type set to I
Cmd: PASV
227: Entering Passive Mode (192,168,10,61,13,146)
Cmd: STOR img/gungadin.lzo
150: Connection accepted
226: Transfer OK
Cmd: MDTM 20051123144517 img/gungadin.lzo
550: File not found
Cmd: QUIT
221: Goodbye
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What kind of id are you using on the windows server? You must have write access to the directories. On linux, I just create a user, and that users /home/user directory is the default ftp directory, so the /home/user/img directory is the one that it should write to.
The program using ncftp, so, you could download the windows version, and test that you can log into the directory and upload a file.
ncftp -u user -p password ipaddress
cd img
put testfile
quit
If that works, you can try the g4l, and then change into another terminal with Ctrl-Alt f2, and login with g4l, and check the files in the /tmp directory. The ncftp files might have some kind of error message.
It might be a problem with ncftp and the ftp server your using. I'm working on an updated version with the newer kernel, and newer version of ncftp (I believe), and I think that something about getting it to work with additional ftp servers. It is available on my other machine as a test download, since I haven't finished all the things I want to do, and test it, but I am using it.
ftp://amd64gcc.dyndns.org
The latest is the 17p version that add support to the kernel for pcmcia.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Could you see what happens with a machine just useing the ncftp client.
Create some testfile with data in it, size doesn't really matter.
Then use ncftp with you ftp server, and the correct user and password, and IP, and see if you can connect, and upload the file.
ncftp -u user -p password ipaddress
cd img
put testfile
quit
That can determine if the ftp process is working, and the permissions are correct.
I once made the mistake of creating the img directory as root in the user directory, and then the user didn't have the rights to create files in the directory. Just had to reset the owner of the directory.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What's the root password on the ISO? (I did try finding it before asking: I don't see any documentation in the doc section, and searching on "root password" with "must contain all words" found this and one other post, neither of which contain the root password. Then I searched Google, but found nobody asking about this so perhaps I just don't know where to look...)
The reason I'm asking is I just booted into the 0.18 CD ISO, but I forgot to create a filesystem on the other partition. So I was going to do it in the (Ctrl+Alt+2) other terminal, but I can't log in. (I tried "", "root", and "g4l".)
Thanks,
Ken Beal
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Rather than user root, I tried user "g4l" and it logged right in with a "#" (root) prompt. I'm replying to myself in case others are as inept as me and come looking for the root password here in the forums. ;-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Actually that's how I got the out file off of the box. I used ncftp to transfer it to the FileZilla box and it worked fine. Just seems on the raw write it fails
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was wondering if it might be hardware/driver related so I decided to try g4l on my Windows laptop (ide drive) and it appears it is working. G4L does recognize the drive on the original server but they are SCSI U320 drives in a hardware mirror. I do believe they use the cciss driver. The drive shows as /dev/cciss/c0d0
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That might be the problem... With Linux/Unix system, when you blank out the directory, the program replaces it with ./ to tell it to start in the users home directory instead of using ./img. The program actually sends/recieves the file using ncftpget and ncftpput, so it must all be passed in the parameters. It might be that the ftp server you are using handles this in a different way. I would suggest creating the img directory, and seeing if it works that way, and then we can try and figure a way to get it to work with either another directory, or no subdirectory at all.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm having similar problems with an HP DL380G4 (HP SmartArray 6i using the cciss driver).
G4L sees all the partitions, but when I try to create an image, only a tiny file (~40 bytes) is written. No errors shown in the ncftp log file - login OK, STOR command executed (successfully, so it thinks) but nothing written to the FTP server.
I've tried with Win2K FTP Server and FileZilla Server, with the same results.
How recent is the cciss driver in the kernel? I can't easily see it, nor is there any source code provided for the kernel build. Any help would be much appreciated.
Kippy
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The configs for the kernels are at the ftp site.
ftp://fedoragcc.dyndns.org
bzImaged.config is the lastest configuration file, and is based on the kernel.org source with the matching to the kernel. The lastest 0.17e file at the site has the 2.6.14.3 kernel.
Also, you need to check the /tmp/out file, since that is the debug output from the ncftp. You can do a Ctrl-Alt F2, login with g4l, and change into the tmp directory, and cat the out file.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I did check the /tmp/out file, and as I said in my previous post, the FTP conversation looks OK - it logs in, switches to passive mode, executes the STOR command and thinks it has completed successfully. No errors. However, the file on the FTP server is only a few bytes in size. Unfortunately I don't have direct access to the machine at the moment, so cannot post an exact copy of the log. However, given that there were no errors on the FTP side, I am wondering if the problem is with reading from the RAID array using the cciss driver.
Mark
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What device is the system using for the raid?
What does the df show for this?
It could be a problem with how it sees the raid system. I've had problems with raid systems that only have specific drivers for spefic versions of the kernel (Compac that only have drivers for Red Hat).
It either has to be at that lower level, or it could be that something like readsize isn't working with the raid array.
The process comes down to a dd command with piping.
dd bs=1M if=$disk 2>/dev/null
That is where it copies from the device
| jetcat-mod -p $readsize 2>/tmp/progress.out
That is where it passes the data thru the program to feed the progress graph. If $readsize isn't getting the right number, it might be the cause.
| lzop -c -
That is one of the various compression options.
| ncftp $useridpass -c -d /tmp/out $server "$ftppath/$netimagename" 2>>/tmp/ncftpstatus.out
That is the piping of the compressed data to the ftp site. Looks like ncftpstatus.out would be another file to check for information.
So probable seeing exactly what df shows, and what the ncftpstatus.out might show something.
Could see that dd if=/dev/raiddevice of=/tmp/test does, where raiddevice is the correct name for the device. If it gives a similar small file, it is with the dd process. If it fails by filling up the ram drive, then it is something else.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've tried again with your new release, 0.17-15 with the default bzimageu kernel.
Hardware is an HP DL380 G4 with an HP SmartArray 6i SCSI RAID controller.
G4L lists the partitions as:
cciss/c0d0
cciss/c0d0p1
through cciss/c0d0p6
I assume the first entry represents the entire logical drive (the reported size is correct) and the others are the individual partitions.
However, the Drive Models section is blank. I assume that since this is a RAID array, G4L is unable to access and identify the individual drives.
I tried your test of creating a small file and using ncftp to transfer it to the FTP server; this worked correctly.
I tried using dd locally, and hit a problem. There is no entry in /dev for cciss (I assume this should be the device entry as reported by G4L, or does it map to something else?) There are many entries for hdaxx to hdtxx, sdaxx to sdtxx but nothing for cciss. I wonder if this is the cause of the problem? Any ideas as to what's happening with the RAID driver? Obviously it can see the logical drive and partitions somehow, but when I start the backup, after a couple of seconds the progress bar jumps to 100% and a file of only a few bytes is written to the FTP server.
It would be great to get this working!
Many thanks,
Mark
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A couple of questions, on what OS are you running this, and what dev does it come up with in the /dev directory. It might be a matter of using mknod to create the necessary nods to support it. I don't see anything like you mentioned on my systems. I have added all the raid stuff in the kernel.org system, but that might be limited to software raid.
As a second option, you could try finnix to see if it Linux could see the raid system. It is about 100MB image, so has a lot more support. You could see if it recognizes the raid system. If it does, I created a special file that has the files that are needed for g4l that don't exist on the finnix cd. I downloaded it to a directory in the path, and then ran the g4l26 script.
ftp://202.128.73.28/g4lfin.zip
Only problem I had was that I got a territble transfer speed. I got 3MB per second versus 20MB with the g4l kernel. 15 minutes for a test partition with g4l, but took 1 hour and 40 minutes with the finnix, but if it works, it might give an ideal on what would need to be added.
One final addition might need to be added the script original limited to looking for the letter d in the device names for hd? and sd? and perhaps md?.
Thanks for checking back...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It was indeed the entries in /dev that were missing.
I did the following from a second terminal screen:
mkdir /dev/cciss
mknod /dev/cciss/c0d0 b 104 0
This only created the first entry for the entire drive, rather than each individual partition, but I can now successfully create a drive image to the FTP server.
Do you have enough information from this to implement a fix? There is quite a lot of documentation around for the cciss driver (eg. google mknod cciss) I think the terminology is cXdXpX where the c part is the controller, d is the logical disk, p is the partition, eg. c0d0p1, c0d0p2 etc. etc.
Thanks,
Mark
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just changed the directory from /dev/cciss to the path under the development diretory /dev.
What I would be interested in seeing is if this makes changes the /proc/partitions when you boot up. If so, what does it put there, and does it show up in g4l as an option. It might require some modification depending on what it puts there or even more if it doesn't.
Thanks again.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The correct entries in /proc/partitions were always created (even in earlier versions) - this is what gave me the idea that the entries in /dev were missing.
/proc/partitions lists the entries as:
cciss/c0d0
cciss/c0d0p1
etc
etc
g4l's front-end menu always listed these correctly.
The new version does create the entries in /dev correctly, and from initial tests works successfully! Compaq/HP users will be very happy.
One small problem I noticed - when I select menu item E to specify the filename on the FTP server, there is a 30 second delay before the next dialog box is displayed. Any ideas?
Thanks for all your efforts,
Mark
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm trying to do a test run of g4l for my boss, in order to do a comparison with g4u in order to determine which direction to do on our HD imaging project.
I've filled out all the parameters to do the transfer, and it looks like it's logging in to our ftp server just fine, but when the transfer is supposed to take place, the progress bar just jumps from 0 to 100% immediately (I think we're talking about creating an image for a 10 gig drive, so this seems - er, ah - a little fast to me) and of course there's no image file being transferred to the ftp server at all.
Anyone else out there having this kind of a problem?
Glad you found it. g4l is basically the root id for the image, that is how it was in version 0.14, and I saw no reason to change it. I did make it auto login on the first tty, since it saves a step. I try to point out that it is the letter g, number 4, and letter l. Several have had entered the number 41 instead of 41.
Note: If you are going to work with the development kit, it must be done as root, since the devices will not be made with non-root user.
This is almost always because you did not create a subdirectory called img. The earlier versions of g4l defaulted to using this subdirectory rather than placing the image file in the default directory. I've added the ability to change this directory, but the default directory is still the img. So, the easiest solutions, is to just created the img directory and it should work. An additional suggestion, I recommend using an image with .lzo extention and lzop compress. If you are passing the parameters, or using the front end, the image name will get it to default. I've found that the image creation time is about 1/2 for lzop, but does produce and image about 15% larger. Restore time is about the same for both. Also, make sure to use the blank5 or cleandrive scripts to clear unused sectors before doing an image. Will greatly increase speed, and decrease size of image.
No, actually I did try that, having noticed what the default was set to. I'm sending (or rather, attempting to send) to an FTP server on a Windows workstation. The default directory name for the FTP server on that workstation is named ftproot, if I remember correctly. I've tried setting the default directory name to (blank), to "img" (after I created a subdirectory in ftproot named img); I've tried \ftproot; I've tried \inetpub\ftproot. Nothing works.
I have noticed the following error message when I try to use the "Display Time" option: "error on stdout (0xc)"; is the program writing the options to stdout and the file is not being created or something?
I've tried different boot options, I've tried everything I can think of to get this thing to go, and all I get is the same response, 0 to 100 in about 2 seconds, and no file transferred.
Any other suggestions?
We solved our problem by going with a different FTP client than the Windows one; FileZilla worked for us. G4L looks like it's designed to use passive mode commands that the Windows FTP server didn't understand or know how to handle. Once we switched to FileZilla, everything worked like a charm.
Well mine is still doing the same thing with VSFTPD and FileZilla.
Here is the out file from the tmp dir for both vsftpd and FIleZilla
LibNcFTP 3.1.9 (March 19, 2005) compiled for linux-x86
Uname: Linux|g4l|2.6.13.4|#2 SMP Wed Oct 19 01:10:20 ChST 2005|i686
Glibc: 2.3.5 (stable)
220: (vsFTPd 1.2.1)
Connected to 192.168.10.54.
Cmd: USER admin
331: Please specify the password.
Cmd: PASS xxxxxxxx
230: Login successful.
Cmd: PWD
257: "/"
Logged in to 192.168.10.54 as admin.
Cmd: FEAT
211: Features:
MDTM
REST STREAM
SIZE
End
Cmd: HELP SITE
214: The following commands are recognized.
ABOR ACCT ALLO APPE CDUP CWD DELE EPRT EPSV FEAT HELP LIST MDTM MKD
MODE NLST NOOP OPTS PASS PASV PORT PWD QUIT REIN REST RETR RMD RNFR
RNTO SITE SIZE SMNT STAT STOR STOU STRU SYST TYPE USER XCUP XCWD XMKD
XPWD XRMD
Help OK.
Cmd: CLNT NcFTPPut 3.1.9 linux-x86
500: Unknown command.
Cmd: TYPE I
200: Switching to Binary mode.
Cmd: PASV
227: Entering Passive Mode (192,168,10,54,24,209)
Cmd: STOR img/gungadin.lzo
150: Ok to send data.
226: File receive OK.
Cmd: MDTM 20051123144428 img/gungadin.lzo
550: Could not get file modification time.
Cmd: QUIT
221: Goodbye.
LibNcFTP 3.1.9 (March 19, 2005) compiled for linux-x86
Uname: Linux|g4l|2.6.13.4|#2 SMP Wed Oct 19 01:10:20 ChST 2005|i686
Glibc: 2.3.5 (stable)
220: FileZilla Server version 0.9.11 beta
written by Tim Kosse (Tim.Kosse@gmx.de)
Please visit http://sourceforge.net/projects/filezilla/
Connected to 192.168.10.61.
Cmd: USER admin
331: Password required for admin
Cmd: PASS xxxxxxxx
230: Logged on
Cmd: PWD
257: "/" is current directory.
Logged in to 192.168.10.61 as admin.
Cmd: FEAT
211: Features:
MDTM
REST STREAM
SIZE
MLST type;size;modify*;
End
Cmd: HELP SITE
502: Command SITE is not recognized or supported by FileZilla Server
Cmd: CLNT NcFTPPut 3.1.9 linux-x86
500: Syntax error, command unrecognized.
Cmd: TYPE I
200: Type set to I
Cmd: PASV
227: Entering Passive Mode (192,168,10,61,13,146)
Cmd: STOR img/gungadin.lzo
150: Connection accepted
226: Transfer OK
Cmd: MDTM 20051123144517 img/gungadin.lzo
550: File not found
Cmd: QUIT
221: Goodbye
Thanks for the info. I just got done installing RedHat with vsftpd on another server to try. I am downloading FileZilla as we speak.
What kind of id are you using on the windows server? You must have write access to the directories. On linux, I just create a user, and that users /home/user directory is the default ftp directory, so the /home/user/img directory is the one that it should write to.
The program using ncftp, so, you could download the windows version, and test that you can log into the directory and upload a file.
ncftp -u user -p password ipaddress
cd img
put testfile
quit
If that works, you can try the g4l, and then change into another terminal with Ctrl-Alt f2, and login with g4l, and check the files in the /tmp directory. The ncftp files might have some kind of error message.
It might be a problem with ncftp and the ftp server your using. I'm working on an updated version with the newer kernel, and newer version of ncftp (I believe), and I think that something about getting it to work with additional ftp servers. It is available on my other machine as a test download, since I haven't finished all the things I want to do, and test it, but I am using it.
ftp://amd64gcc.dyndns.org
The latest is the 17p version that add support to the kernel for pcmcia.
I'm having the same issue except a 0 byte file actually gets created on the M$ FTP server.
Could you see what happens with a machine just useing the ncftp client.
Create some testfile with data in it, size doesn't really matter.
Then use ncftp with you ftp server, and the correct user and password, and IP, and see if you can connect, and upload the file.
ncftp -u user -p password ipaddress
cd img
put testfile
quit
That can determine if the ftp process is working, and the permissions are correct.
I once made the mistake of creating the img directory as root in the user directory, and then the user didn't have the rights to create files in the directory. Just had to reset the owner of the directory.
Hi,
What's the root password on the ISO? (I did try finding it before asking: I don't see any documentation in the doc section, and searching on "root password" with "must contain all words" found this and one other post, neither of which contain the root password. Then I searched Google, but found nobody asking about this so perhaps I just don't know where to look...)
The reason I'm asking is I just booted into the 0.18 CD ISO, but I forgot to create a filesystem on the other partition. So I was going to do it in the (Ctrl+Alt+2) other terminal, but I can't log in. (I tried "", "root", and "g4l".)
Thanks,
Ken Beal
Rather than user root, I tried user "g4l" and it logged right in with a "#" (root) prompt. I'm replying to myself in case others are as inept as me and come looking for the root password here in the forums. ;-)
I didn't bother messing around with the img subdirectory. I just blank out the subdirectory name before I up- or download.
Actually that's how I got the out file off of the box. I used ncftp to transfer it to the FileZilla box and it worked fine. Just seems on the raw write it fails
I was wondering if it might be hardware/driver related so I decided to try g4l on my Windows laptop (ide drive) and it appears it is working. G4L does recognize the drive on the original server but they are SCSI U320 drives in a hardware mirror. I do believe they use the cciss driver. The drive shows as /dev/cciss/c0d0
That might be the problem... With Linux/Unix system, when you blank out the directory, the program replaces it with ./ to tell it to start in the users home directory instead of using ./img. The program actually sends/recieves the file using ncftpget and ncftpput, so it must all be passed in the parameters. It might be that the ftp server you are using handles this in a different way. I would suggest creating the img directory, and seeing if it works that way, and then we can try and figure a way to get it to work with either another directory, or no subdirectory at all.
Hi everyone,
I'm having similar problems with an HP DL380G4 (HP SmartArray 6i using the cciss driver).
G4L sees all the partitions, but when I try to create an image, only a tiny file (~40 bytes) is written. No errors shown in the ncftp log file - login OK, STOR command executed (successfully, so it thinks) but nothing written to the FTP server.
I've tried with Win2K FTP Server and FileZilla Server, with the same results.
How recent is the cciss driver in the kernel? I can't easily see it, nor is there any source code provided for the kernel build. Any help would be much appreciated.
Kippy
The configs for the kernels are at the ftp site.
ftp://fedoragcc.dyndns.org
bzImaged.config is the lastest configuration file, and is based on the kernel.org source with the matching to the kernel. The lastest 0.17e file at the site has the 2.6.14.3 kernel.
Also, you need to check the /tmp/out file, since that is the debug output from the ncftp. You can do a Ctrl-Alt F2, login with g4l, and change into the tmp directory, and cat the out file.
Hi Michael,
I did check the /tmp/out file, and as I said in my previous post, the FTP conversation looks OK - it logs in, switches to passive mode, executes the STOR command and thinks it has completed successfully. No errors. However, the file on the FTP server is only a few bytes in size. Unfortunately I don't have direct access to the machine at the moment, so cannot post an exact copy of the log. However, given that there were no errors on the FTP side, I am wondering if the problem is with reading from the RAID array using the cciss driver.
Mark
What device is the system using for the raid?
What does the df show for this?
It could be a problem with how it sees the raid system. I've had problems with raid systems that only have specific drivers for spefic versions of the kernel (Compac that only have drivers for Red Hat).
It either has to be at that lower level, or it could be that something like readsize isn't working with the raid array.
The process comes down to a dd command with piping.
dd bs=1M if=$disk 2>/dev/null
That is where it copies from the device
| jetcat-mod -p $readsize 2>/tmp/progress.out
That is where it passes the data thru the program to feed the progress graph. If $readsize isn't getting the right number, it might be the cause.
| lzop -c -
That is one of the various compression options.
| ncftp $useridpass -c -d /tmp/out $server "$ftppath/$netimagename" 2>>/tmp/ncftpstatus.out
That is the piping of the compressed data to the ftp site. Looks like ncftpstatus.out would be another file to check for information.
So probable seeing exactly what df shows, and what the ncftpstatus.out might show something.
Could see that dd if=/dev/raiddevice of=/tmp/test does, where raiddevice is the correct name for the device. If it gives a similar small file, it is with the dd process. If it fails by filling up the ram drive, then it is something else.
Hi Michael,
I've tried again with your new release, 0.17-15 with the default bzimageu kernel.
Hardware is an HP DL380 G4 with an HP SmartArray 6i SCSI RAID controller.
G4L lists the partitions as:
cciss/c0d0
cciss/c0d0p1
through cciss/c0d0p6
I assume the first entry represents the entire logical drive (the reported size is correct) and the others are the individual partitions.
However, the Drive Models section is blank. I assume that since this is a RAID array, G4L is unable to access and identify the individual drives.
I tried your test of creating a small file and using ncftp to transfer it to the FTP server; this worked correctly.
I tried using dd locally, and hit a problem. There is no entry in /dev for cciss (I assume this should be the device entry as reported by G4L, or does it map to something else?) There are many entries for hdaxx to hdtxx, sdaxx to sdtxx but nothing for cciss. I wonder if this is the cause of the problem? Any ideas as to what's happening with the RAID driver? Obviously it can see the logical drive and partitions somehow, but when I start the backup, after a couple of seconds the progress bar jumps to 100% and a file of only a few bytes is written to the FTP server.
It would be great to get this working!
Many thanks,
Mark
A couple of questions, on what OS are you running this, and what dev does it come up with in the /dev directory. It might be a matter of using mknod to create the necessary nods to support it. I don't see anything like you mentioned on my systems. I have added all the raid stuff in the kernel.org system, but that might be limited to software raid.
As a second option, you could try finnix to see if it Linux could see the raid system. It is about 100MB image, so has a lot more support. You could see if it recognizes the raid system. If it does, I created a special file that has the files that are needed for g4l that don't exist on the finnix cd. I downloaded it to a directory in the path, and then ran the g4l26 script.
ftp://202.128.73.28/g4lfin.zip
Only problem I had was that I got a territble transfer speed. I got 3MB per second versus 20MB with the g4l kernel. 15 minutes for a test partition with g4l, but took 1 hour and 40 minutes with the finnix, but if it works, it might give an ideal on what would need to be added.
One final addition might need to be added the script original limited to looking for the letter d in the device names for hd? and sd? and perhaps md?.
Thanks for checking back...
Progress for HP/Compaq SmartArray users!!!
It was indeed the entries in /dev that were missing.
I did the following from a second terminal screen:
mkdir /dev/cciss
mknod /dev/cciss/c0d0 b 104 0
This only created the first entry for the entire drive, rather than each individual partition, but I can now successfully create a drive image to the FTP server.
Do you have enough information from this to implement a fix? There is quite a lot of documentation around for the cciss driver (eg. google mknod cciss) I think the terminology is cXdXpX where the c part is the controller, d is the logical disk, p is the partition, eg. c0d0p1, c0d0p2 etc. etc.
Thanks,
Mark
ftp://amd64gcc.dyndns.org/boot-17-15x.iso
Is a new boot image that I created after making the directory and creating the nods by modifying a script that I found at:
http://www.linuxhq.com/kernel/v2.6/11/Documentation/mkdev.cciss
Just changed the directory from /dev/cciss to the path under the development diretory /dev.
What I would be interested in seeing is if this makes changes the /proc/partitions when you boot up. If so, what does it put there, and does it show up in g4l as an option. It might require some modification depending on what it puts there or even more if it doesn't.
Thanks again.
Hi Michael, thanks for the fast update!
The correct entries in /proc/partitions were always created (even in earlier versions) - this is what gave me the idea that the entries in /dev were missing.
/proc/partitions lists the entries as:
cciss/c0d0
cciss/c0d0p1
etc
etc
g4l's front-end menu always listed these correctly.
The new version does create the entries in /dev correctly, and from initial tests works successfully! Compaq/HP users will be very happy.
One small problem I noticed - when I select menu item E to specify the filename on the FTP server, there is a 30 second delay before the next dialog box is displayed. Any ideas?
Thanks for all your efforts,
Mark