Opened 9 years ago

Closed 9 years ago

#6723 closed bug (fixed)

Certain burned Haiku install CDs have issues with Installer failing on Nightly builds/Live CD

Reported by: stargatefan Owned by: nobody
Priority: normal Milestone: R1/alpha3
Component: - General Version: R1/alpha2
Keywords: Cc:
Blocked By: Blocking: #6968
Has a Patch: no Platform: All

Description (last modified by scottmc)

2 files one in vision App folder cause installer failure on nightly builds. Has been a sporadic problem on and off for several months. Solution,remove vision from nightly builds. I have been doing this with Magic Iso on windows to resolve the problem.

The files are

CPRIVMSG.txt RFC1459.txt

I have no idea why this is a problem, but it is. Removing the entire folder for vision from the image resolved the issue. I have also had issues with PE doing the same thing. I remove both from the ISO image, burn it and install after I put the new image on. Fix's the problem 100% of the time.

The installer error is a General system Error could not copy xxxxx.txt.

Change History (35)

comment:1 by stargatefan, 9 years ago

Looks like ScottMc moved this to optional packages, did anyone remove it from the nigthly images ? if so close this ticket I installed the build from last night from the .iso cd, went fine.

comment:2 by anevilyak, 9 years ago

It's always been an optional package, all Scott did was update it so it's automatically built via haiku-ports. The reason for the copy failure is unclear to me though it might've been bad permissions on the files in the archive, but it's included on the nightlies along with a few other optional packages so the live CD images can be a bit more usable. If you're not seeing the issue any more, than chances are it was indeed just a permissions problem since otherwise those files aren't in any way special. Please confirm.

comment:3 by stargatefan, 9 years ago

its back in 39304 gcc4 hybrid

Version 0, edited 9 years ago by stargatefan (next)

comment:4 by scottmc, 9 years ago

Description: modified (diff)
Owner: changed from nobody to scottmc
Status: newassigned

Could be a file permission issue. if so let me know and I can adjust the .bep file to set the affected files.

comment:5 by scottmc, 9 years ago

Summary: Vision Cuasing Installer failure on Nightly builds/Live CD OK Still installer fials from Live Cd DesktopVision Causing Installer failure on Nightly builds/Live CD OK Still installer fials from Live Cd Desktop

comment:6 by scottmc, 9 years ago

Summary: Vision Causing Installer failure on Nightly builds/Live CD OK Still installer fials from Live Cd DesktopVision Causing Installer failure on Nightly builds/Live CD OK Still installer fails from Live Cd Desktop

in reply to:  4 comment:7 by anevilyak, 9 years ago

Replying to scottmc:

Could be a file permission issue. if so let me know and I can adjust the .bep file to set the affected files.

Not knowing the installer code, that would be my only logical guess, since those files are plain text and aren't otherwise in any way special. That having been said, they don't really need to be included in the distribution zip at all, though the template settings file that the previous packages included does (c.f. ticket #6040). Not sure how easy that part is to incorporate into your .bep though, as I'd simply added that to the archive manually in the past.

Last edited 9 years ago by anevilyak (previous) (diff)

comment:8 by stargatefan, 9 years ago

My suggestion is a such, remove vision from the nightly image iso's and those of us who know how to install webpositive can just add vision via optional packages in the mean time while this is investigated. I am testing with guetenprint and its a annoying problem when I am constantly updating to track and report for guetenprint. My solution thus far has been to boot into live Cd mode delete the vision folder and remove it from the optional package txt file, run the installer and then clean up the intalation problem once I boot back in.

I need to file a ticket on some other issues with instilation from livecd though. When you do this the preflets for volume, process monitor and volume control do no install to the task bar and if you install them they do not stick upon reboot.

its only a problem if you install from anyboot or livecd desktop.

comment:9 by stargatefan, 9 years ago

still present in 39327 and when you install the optional vision package from terminal the prefrences files do not make it with prefrences.

comment:10 by stargatefan, 9 years ago

OK I found out a new component to the problem. I have 2 machines running Haiku, one with IDE drives and the other with sata2 drives.

This file copy issue on install only occurs on the sata2 drives. The IDe machine is uneffected.

comment:11 by scottmc, 9 years ago

I think this issue is related to your CD drive and/or defective media. Probably related to the issue we same with the Alpha2 CD and the general system errors when it was trying to install web+ https://dev.haiku-os.org/wiki/R1/Alpha2/ReleaseAddendum Try burning a fresh nightly CD image and see if it fails on exactly the same files again and if so let us know the exact error, perhaps press the printscreen key and save the image and attach it to this ticket. Also run cdrecord --scanbus in terminal on the PC that is having the issue and paste that result to this ticket as well. Attach the output of listdev run in a terminal as well.

in reply to:  11 comment:12 by stargatefan, 9 years ago

I used the same CD in both PC's. I think the issue is related to the sata driver somehow, this started I think when axle fixed the issue with the system hanging on inserted CD's not being recognized until a reboot.

How that would happen is beyond me but doesn't sata act alot like USB in its behavoir or vice versa ?

Replying to scottmc:

I think this issue is related to your CD drive and/or defective media. Probably related to the issue we same with the Alpha2 CD and the general system errors when it was trying to install web+ https://dev.haiku-os.org/wiki/R1/Alpha2/ReleaseAddendum Try burning a fresh nightly CD image and see if it fails on exactly the same files again and if so let us know the exact error, perhaps press the printscreen key and save the image and attach it to this ticket. Also run cdrecord --scanbus in terminal on the PC that is having the issue and paste that result to this ticket as well. Attach the output of listdev run in a terminal as well.

comment:13 by stargatefan, 9 years ago

Scott I did a bit more testing and this problem is only occuring on sata2 machines. Could it be that it is a buffer underun issue between the hosting and recieving drive ? IE the drive speeds on sata2 and transfer rates are signifcantly higher then on IDE and sata.

comment:14 by scottmc, 9 years ago

see comment 11, we're still waiting for info on the systems that aren't working. This may help track done the issue. So far you are the only one that appears to have this issue, perhaps with the details of your hardware we can test elsewhere.

comment:15 by stargatefan, 9 years ago

i'll try to get the info for you, still trying to get competent with the debugger.

comment:16 by stargatefan, 9 years ago

Scott I tried to manually copy the files in the app/vision/protocol folder from the disk to the drive and it still fails.

Permissions are r-rw-r-r

BTW its fialing on a read/write issue so far as I can tell. BTW on todays nightly it fialed on 1 IDE machine passed on 3 others and still fials fiarly consistenly on the sata2 machines.

So its certainly not a media issues. I will note that it only seems to be effecting machines which have higher speed drives.

I tried invokining the debugger but it doesn't give output for file copy failures.

comment:17 by stargatefan, 9 years ago

I burned a anyboot to cd.

not a problem on any machine.the same nightly on ISO.more problems.

Last edited 9 years ago by stargatefan (previous) (diff)

comment:18 by stargatefan, 9 years ago

Scott go ahead and close this. seems to have fixed itself about a week ago when the BOM got brought back into synce with the trunk. Must have been a bug in the Build O matic.

comment:19 by scottmc, 9 years ago

Resolution: fixed
Status: assignedclosed

comment:20 by scottmc, 9 years ago

Resolution: fixed
Status: closedreopened

This one is sounding like the issue we had with the Alpha2 CD: http://dev.haiku-os.org/wiki/R1/Alpha2/ReleaseAddendum Where it gets tripped up installing from CD almost always on a specific file and then only on some systems with certain media. Reopening until we can figure it out and get it fixed.

comment:21 by anevilyak, 9 years ago

Blocking: 6968 added

(In #6968) That's indeed the same problem as #6723, though the additional info presented here certainly helps.

comment:22 by anevilyak, 9 years ago

#6968 may have pinpointed the underlying cause, though it seems to imply something's wrong with how the ISOs are being generated.

comment:23 by mmadia, 9 years ago

I'm not sure if this helps or matters -- here's the mkisofs information from the machine that builds the nightly (and release) images:

[mmadia@1156 ~]$ mkisofs -v 
Setting input-charset to 'UTF-8' from locale. 
2.01.01a79 (i386-unknown-freebsd8.0) 
mkisofs: Missing pathspec. 
Usage: mkisofs [options] [-find] file... [find expression] 
 
Use mkisofs -help 
to get a list all of valid options. 
 
Use mkisofs -find -help 
to get a list of all valid -find options. 
 
Most important Options: 
        -posix-H                Follow sylinks encountered on command line 
        -posix-L                Follow all symlinks 
        -posix-P                Do not follow symlinks (default) 
        -o FILE, -output FILE   Set output file name 
        -R, -rock               Generate Rock Ridge directory information 
        -r, -rational-rock      Generate rationalized Rock Ridge directory info 
        -J, -joliet             Generate Joliet directory information 
        -print-size             Print estimated filesystem size and exit 
        -UDF                    Generate UDF file system 
        -dvd-video              Generate DVD-Video compliant UDF file system 
        -iso-level LEVEL        Set ISO9660 level (1..3) or 4 for ISO9660 v 2 
        -V ID, -volid ID        Set Volume ID 
        -graft-points           Allow to use graft points for filenames 
        -M FILE, -prev-session FILE     Set path to previous session to merge 
[mmadia@1156 ~]$ 

in reply to:  22 comment:24 by bonefish, 9 years ago

Replying to anevilyak:

#6968 may have pinpointed the underlying cause, though it seems to imply something's wrong with how the ISOs are being generated.

No, not at all. It implies that one of CD burning applications doesn't burn the CD incorrectly -- no clue if they are allowed to add padding and, if so, how much -- and/or that Haiku doesn't deal correctly with such a CD.

A syslog would be a helpful starting point.

comment:25 by stargatefan, 9 years ago

had trouble last night with gcc2h 39792 but not with gcc4h 39792 both burned with cdrecord in haiku.

comment:26 by stargatefan, 9 years ago

I think the issue may be structural in nature. IE certain files sizes seem to not have a issue and some do. Depending on how these files are place in the ISO it could create trouble. The files we are having issues with are small and oddly sized. It could be a combination of how the ISO is generated the CD is written and the way the installer handles it.

comment:27 by nielx, 9 years ago

Milestone: R1R1/alpha3
Priority: normalblocker

Moving to R1Alpha3 and nominating as blocker (see email thread).

comment:28 by scottmc, 9 years ago

Owner: changed from scottmc to nobody
Status: reopenedassigned

This issue does not seem to be tied to a specific optional package, but more to how the CD image is created and/or written, thus I am probably not the best choice as owner of this one.

comment:29 by scottmc, 9 years ago

Summary: Vision Causing Installer failure on Nightly builds/Live CD OK Still installer fails from Live Cd DesktopCertain burned Haiku install CDs have issues with Installer failing on Nightly builds/Live CD

comment:30 by scottmc, 9 years ago

Priority: blockernormal

Moving this one from a "blocker" to "normal". If it isn't fixed in time for Alpha3, then we should add a note to the release notes as we did with Alpha2. It seems this only happens when the image is burned using certain media, or with certain burning software. So thorough testing the the release candidates for Alpha3 should allow us to know if this is still an issue and if so what combinations are questionable.

in reply to:  30 comment:31 by nielx, 9 years ago

Replying to scottmc:

Moving this one from a "blocker" to "normal". If it isn't fixed in time for Alpha3, then we should add a note to the release notes as we did with Alpha2. It seems this only happens when the image is burned using certain media, or with certain burning software. So thorough testing the the release candidates for Alpha3 should allow us to know if this is still an issue and if so what combinations are questionable.

Shouldn't this stay a blocker then, which can be downgraded when we have a list of those burning tools that cause problems?

comment:32 by stargatefan, 9 years ago

I have not had problems with ISO's compiled on a Haiku system, but lots of problems with the actual nightlys/alphas generated by the build bot.

comment:33 by pulkomandy, 9 years ago

The build bot was updated this week to use a mor erecent mkisofs. May you try again with a fresh build ?

comment:34 by stargatefan, 9 years ago

I retested with the following programs on winxp and win7

Isomagic,Nero,Hamster and built in cd dvd burning in win7. I burned a total of 20 dics over the course of 4 days. All worked fine.

suggest to close now

comment:35 by scottmc, 9 years ago

Resolution: fixed
Status: assignedclosed

Thanks for the testing. This was probably fixed by updates to the build system.

Note: See TracTickets for help on using tickets.