Posts made by Junkhacker

@george1421 i found a copy of the init_p3 file i downloaded from you yesterday before you rebuit with 2.89, so i’ll work with that

edit: nevermind, that file is from May 1 not yesterday, is that one good enough for testing?

@george1421 could you provide me with your latest copy of the init with 0.3.12
I’d like to test it some more and see if i can get the same failures you did. the inits provide by @Sebastian-Roth here https://forums.fogproject.org/post/119056 didn’t give me the problems you’ve seen after edits to the funcs.sh

@Sebastian-Roth that seems like the right thing to do. those who do use this feature often rely on it heavily, so it’s best to not break existing configurations on an update.

@george1421 and this image deploys properly with the standard inits with 0.2.89? this just seems so bizarre to me

@george1421 when it fails to work for you, do you see any unexpected behavior in the imaging process?

@george1421 said in The future of partclone and therefore FOG as it is:

Not what I wanted to do but I rebuilt the inits without any of my edits and only with the 0.3.12 partclone build.

you must edit the funcs.sh file to remove the --ignore_crc flags or 0.3.12 will not work properly

@MediumToast i thought this might interest you https://forums.fogproject.org/post/123288

@Junkhacker i’ve finished reading through that thread and i still don’t understand why the code was changed to require the menu to have #!ipxe entered manually

@Sebastian-Roth maybe so. i was able to make my advanced menu work properly by adding #!ipxe to the top of my advanced menu text box. that wasn’t needed before, since it was automatically put in in previous versions.

@Junkhacker found that someone else had what looks like the same bug https://forums.fogproject.org/post/123064 mine didn’t beep, but i’m not certain i have a speaker for it to beep with.

after upgrading from 1.4.4 to 1.5.6 the advanced menu no longer automatically had #!ipxe at the top, resulting in the computer just sitting at a blinking cursor

@Sebastian-Roth only by reverting back to previous inits

@Sebastian-Roth redownloaded today in my browser and now the hashs are different from before and now match what you posted. I’ll update my server again and see if it works
edit:updated server and it failed, checked checksum and it’s still the old init. guess it’s gettting pulled from a cache somewhere?
edit2:manually downloaded inits to server using the https://fogproject.org/binaries1.5.6.zip link and the hashs match yours. testing with that now
edit3: ok, that was giving me kernel panics. not sure what was going on there

@Sebastian-Roth in place and testing now
edit: i just tested and had the same problem. i just compared the an MD5 hash of what i downloaded earlier and what i downloaded just now. the files are the same

@Sebastian-Roth are the init’s being pushed for release 1.5.6 or will the init’s for that release continue to have the bug?

@Tom-Elliott yeah, definitely doesn’t look like a UUID (sorry the image is shrank and funny, was trying to get the image size down to upload)

@Sebastian-Roth

@george1421 more info for you, my dev server is 1.5.5 my prod is 1.4.4. not sure what versions the images files would have all been captured on, but i’ve tested 1.4.4 or earlier (not sure) though captures with 1.5.5.

@george1421 that’s the same as i’m doing. i just thought maybe in your testing an upload might have taken place with 0.3.12 by accident. i’ve been deploying images using my dev server, some of which i copied over from my production server. i haven’t seen any problems other than the UUID thing i posted.

downloaded the init_p3 file and tried again. got the UUID error again, but it boots fine.