Bug#403136: XServe G5 has no hardware deffect, so this *IS* a udev bug :/
On Fri, Jan 26, 2007 at 11:52:12AM +0100, David Härdeman wrote:
> On Fri, Jan 26, 2007 at 10:52:39AM +0100, Sven Luther wrote:
> >Next step would be :
> >
> > 1) write a program writing to stdout and dropping the actual error message
> > somewhere.
>
> How about this:
>
> #include
> #include
> #include
> #include
>
> #define LOGFILE "/stdouttest.log"
> #define TESTMSG "This is a test string\n"
>
> int
> main(int argc, char **argv, char **envp)
> {
> FILE *logfile;
> int printerrno;
> char *printerror;
> int retval = EXIT_FAILURE;
> int result;
>
> /* Setup a log file */
> logfile = fopen(LOGFILE, "a");
> if (!logfile)
> exit(retval);
>
> fprintf(logfile, "Program %s started\n", argv[0]);
>
> /* Print to stdout */
> result = fprintf(stdout, TESTMSG);
>
> /* Log results */
> if (result < 0) {
> printerrno = errno;
> printerror = strerror(printerrno);
> fprintf(logfile, "Printing failed (%i): %s\n",
> printerrno, printerror);
> } else if (result < strlen(TESTMSG)) {
> fprintf(logfile, "Printing was truncated to %i bytes\n",
> result);
> } else {
> fprintf(logfile, "Printing successful\n");
> retval = EXIT_SUCCESS;
> }
>
> /* We're done */
> fclose(logfile);
> exit(retval);
> }
Thanks, i will try, but i won't have time until i am back from solution linux
next thursday.
Friendly,
Sven Luther
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403136: XServe G5 has no hardware deffect, so this *IS* a udev bug :/
On Fri, Jan 26, 2007 at 10:52:39AM +0100, Sven Luther wrote:
Next step would be :
1) write a program writing to stdout and dropping the actual error message
somewhere.
How about this:
#include
#include
#include
#include
#define LOGFILE "/stdouttest.log"
#define TESTMSG "This is a test string\n"
int
main(int argc, char **argv, char **envp)
{
FILE *logfile;
int printerrno;
char *printerror;
int retval = EXIT_FAILURE;
int result;
/* Setup a log file */
logfile = fopen(LOGFILE, "a");
if (!logfile)
exit(retval);
fprintf(logfile, "Program %s started\n", argv[0]);
/* Print to stdout */
result = fprintf(stdout, TESTMSG);
/* Log results */
if (result < 0) {
printerrno = errno;
printerror = strerror(printerrno);
fprintf(logfile, "Printing failed (%i): %s\n",
printerrno, printerror);
} else if (result < strlen(TESTMSG)) {
fprintf(logfile, "Printing was truncated to %i bytes\n",
result);
} else {
fprintf(logfile, "Printing successful\n");
retval = EXIT_SUCCESS;
}
/* We're done */
fclose(logfile);
exit(retval);
}
2) contact udev author and ask for his help, since Marco said he didn't have
a further clue, and this may be an upstream problem.
Sounds like a good idea...the upstream mailing list is very active.
--
David Härdeman
Bug#403136: XServe G5 has no hardware deffect, so this *IS* a udev bug :/
On Fri, Jan 26, 2007 at 11:11:45AM +0100, Marco d'Itri wrote: > On Jan 26, Sven Luther <[EMAIL PROTECTED]> wrote: > > > 1) write a program writing to stdout and dropping the actual error message > > somewhere. > Just add something like this to the top of the affected scripts: > > exec >> /dev/xxx.log 2>&1 It tells me that the pipe was closed by the other side, not very helpful, the other side being udevd. The idea was to try to find out more about the exact error, but i guess maybe adding explicit debugging to udevd is the only way out here. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403136: XServe G5 has no hardware deffect, so this *IS* a udev bug :/
On Jan 26, Sven Luther <[EMAIL PROTECTED]> wrote: > 1) write a program writing to stdout and dropping the actual error message > somewhere. Just add something like this to the top of the affected scripts: exec >> /dev/xxx.log 2>&1 -- ciao, Marco signature.asc Description: Digital signature
Bug#403136: XServe G5 has no hardware deffect, so this *IS* a udev bug :/
tags 403136 + d-i tags 403136 + needhelp thanks Well, After speaking some with various folks, and someone else testing the same d-i which failed here on other XServe's, altough maybe not from the same generation (mine is from september 2005 i was told), i became suspicious, and brang the machine to an apple technical center, for defect testing. The machine came back today, and it was working perfectly, passed all apple hardware diagnostic tests, and ran full tests of mac-os-x during various days without problems. Furthermore, YDL 4.1 installs fine, and also has no problems whatsoever with the (somewhat older) udev installation there, and since this is an issue which surfaced around november rather suddenly (it was in a datacenter a couple of weeks, then upgraded, and at the first reboot, everything broke), i suspect it is indeed some strange udev issue. Let's again summarize the situation : 1) udev does not create the /dev/sd* device nodes, either in initramfs-tools or in d-i. Probably other nodes are affected. 2) the udev d-i scsi-devfs.sh scripts, which is in charge of creating that node, dies when writing to stdout, which is piped to udevd. 3) ubuntu (of late november) exhibited the same problem. 4) yaird did not work, but for some other reason (not recognizing a given node, didn't investigate more). This makes the box fully unusable and unsuported both in d-i and in normal debian, thus the RC status, furthermore something very strange is going on with udev. Next step would be : 1) write a program writing to stdout and dropping the actual error message somewhere. 2) contact udev author and ask for his help, since Marco said he didn't have a further clue, and this may be an upstream problem. 3) fix yaird to work on it, and see if the machine is stable with yaird and without udev. More to this once i have the box back, and am back from the Solution Linux show in paris. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
