27" Intel iMac 2017 (Model: iMac 18,3) met with fatal error : : Null while performing image capture from USB Bootable drive

[nssijt]

I have several 27" Intel iMac 2017 (Model: iMac 18,3) from my workplace which I am trying to re-purpose them which conditions are relatively good still.

A few months ago, I had managed to reformat the iMac to boot up solely on windows 10 without bootcamp. I have also successfully captured the image and deploy to 20 plus units of similar models iMacs with bootable USB iPXE which george1421 (Part 2a tutorial) has shared and taught https://forums.fogproject.org/topic/7727/building-usb-booting-fos-image/21?lang=en-US&page=2. Thanks george1421.

However, as I explored creating my master image in windows 11 without bootcamp, i do encounter challenges receiving this fatal error message as stipulated in the screenshot uploaded.

I thought it could be bzImage, bzImage32, init.xz and init_32.xz are not updated which I had tried recreating a new USB bootable drive but still to no resolution.

Greatly appreciate if anyone can provide me any insights or thoughts to share.

I am trying ssh into my master node and the master image iMac debug mode to see if I can pull out some meaningful logs.

[nssijt]

pull out logs from debug mode var/logs/message

not sure if it makes any sense to isolate the issue

[mastacontrola]

I'm not certain what the issue is as w don't get enough context, but if i had to hedge my bets, somehow you're using olderr init's but running a newer version of FOG (can you please tell us which version)? -- Looking at the post you used to build I see the why. I have updated the links to always prefer the latest kernels an inits instead of the specific 20230323 version that was there.

Please note the why this is occuring when in the past it may not have:

We had to put in a fix for FOG and FOS particularly because of the hinfo.txt piece. This "script" can contain sensitive information for your environment and without the locking/testing mechanism, it could leave exposure to malicious actors.

Basically:

Please update to the latest stable branch if you're not already there. Follow the instructions in the Forum post to rebuild your USB and you should have better luck.

Thank you,

[darksidemilk]

The debug logs photo is a bit small and I can't make out any of the text.
If you start the task in debug mode, then change the password in the debug session with passwd you can use ifconfig to get the IP and then ssh in to that debug session with root@ip and the password you'll have just set.

I second what @mastacontrola said, updating and rebuilding with the new init/kernel should help.
Unless you happen to have a post init script with an undefined parameter of nolock it's probably just that recent security fix and you need to get your usb's init/kernel in synced versions

[nssijt]

I had recently just updated to a few days ago's latest dev version.

Should I downgrade to stable version for my main nodes. If such. Should all my storage nodes be downgraded to the stable version also?

I particularly like dev version as I could remember once that dev version resolved some of the compatibility issue to install in debian 11 a few years back.

[darksidemilk]

As long as you're on the latest of whatever branch you're on it should be good. Just want to be sure you're on a recent version, if you're on a recent dev then it probably is just needing to update the kernel and init on the usb.

…

________________________________ From: nssijt ***@***.***> Sent: Tuesday, September 3, 2024 7:47:00 AM To: FOGProject/fogproject ***@***.***> Cc: JJ Fullmer ***@***.***>; Comment ***@***.***> Subject: [External]Re: [FOGProject/fogproject] 27" Intel iMac 2017 (Model: iMac 18,3) met with fatal error : : Null while performing image capture from USB Bootable drive (Issue #636) image.png (view on web)<https://github.com/user-attachments/assets/78c2cb2e-963c-4e00-b0d9-b017680aaa64> I had recently just updated to a few days ago's latest dev version. Should I downgrade to stable version for my main nodes. If such. Should all my storage nodes be downgraded to the stable version also? I particularly like dev version as I could remember once that dev version resolved some of the compatibility issue to install in debian 11 a few years back. — Reply to this email directly, view it on GitHub<#636 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AB3CO3A3UF5A5BYUFZYV4XDZUW4VJAVCNFSM6AAAAABNRVRT7GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMRWGU3TGMZWG4>. You are receiving this because you commented.Message ID: ***@***.***>

[nssijt]

Thanks for the prompt reply JJ Fuller.

I shall try that out when I am back to my test environment at work tomorrow (GMT+8 9.52pm now).

Another side qn, as I had prepared my master pc image with the current version of fog client.

If I am to upgrade to the latest recent version. Will that break the client that was already installed with an older fog client? I just wanted to be sure. Thanks.

[mastacontrola]

I should not break as teh FOG Client is not updated with as much frequency as the main UI/FOS side of things.

Currently FOG Client is at 0.13.0 I believe and that's been since at least 1.5.10 was released in March of last year.

[nssijt]

great and thanks @mastacontrola Tom, i shall get the main node updated to the latest soonest i can.

[nyp-jeremyt]

This works @mastacontrola Tom & @darksidemilk JJ Fuller.

I realised that the issue is caused when the main node is not in the main storage group

[mastacontrola]

Roger thank you. Closing!