Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG]: Image customization assumes cloud-init on local images #941

Open
1 task done
steev opened this issue Oct 2, 2024 · 9 comments
Open
1 task done

[BUG]: Image customization assumes cloud-init on local images #941

steev opened this issue Oct 2, 2024 · 9 comments
Labels
bug Something isn't working

Comments

@steev
Copy link

steev commented Oct 2, 2024

What happened?

Heya!

I'm working on getting the customized options support in Kali Linux and what I've found is that if I write a release image, because we have init_format set to systemd in our json file, it does create the script.

However, if I attempt to use a locally created image, it seems like it defaults to thinking that the init_format is set to cloud_init

I did see #832 where you were considering just disabling customization, but it seems the conversation was taken offline, and I probably missed the updated pull request where this may now be worked around.

I am using 1.8.5 still because I get an undefined symbol with the 1.9.0 aarch64 AppImage.

Version

1.8.5

What host operating system were you using?

Debian and derivatives (eg Ubuntu)

Host OS Version

Kali Linux 2023.4

Selected OS

Custom

Which Raspberry Pi Device are you using?

Raspberry Pi 5

What kind of storage device are you using?

microSD Card in a USB reader

OS Customisation

  • Yes, I was using OS Customisation when the bug occurred.

Relevant log output

No response

@steev steev added the bug Something isn't working label Oct 2, 2024
@tdewey-rpi
Copy link
Collaborator

Thanks for the report, @steev

I'd be deeply interested in your AppImage launch failure - could you please raise a second issue for that? At first guess, it's going to be a glibc mismatch?

@tdewey-rpi
Copy link
Collaborator

Expanding on this further - if you're looking to add customisation support, I'd strongly encourage you to go down the cloud-init path. I'm currently pushing the Raspberry Pi OS toward cloud-init, with a view to marking the firstrun.sh-style customisation as deprecated in an upcoming Imager.

That said, using the 'custom image' function I'd absolutely not expect customisation to be applied - the window shouldn't be shown, nor should the choice to use customisation. If you're seeing any sign of customisation in this case, that's a concrete bug and needs to be squashed.

@steev
Copy link
Author

steev commented Oct 5, 2024

I definitely see it with a custom image I spin up on my local machine and

Choose Device-> RaspberryPi 5
Choose OS -> Use custom -> select from the location on my computer
Choose Storage -> choose the SDcard
Next

I get prompted "Use OS Customization?"

@tdewey-rpi
Copy link
Collaborator

I definitely see it with a custom image I spin up on my local machine and

Choose Device-> RaspberryPi 5 Choose OS -> Use custom -> select from the location on my computer Choose Storage -> choose the SDcard Next

I get prompted "Use OS Customization?"

Ooof! Yep, that's not what I expected at all. I'm going to take two actions as part of this issue:

  1. Identify the cloud-init default mode, because that doesn't feel safe for later development
  2. Reintroduce or fix up restrictions on customising the 'custom image' flow - the local repo flow will retain that capability.

@steev
Copy link
Author

steev commented Oct 7, 2024

I definitely see it with a custom image I spin up on my local machine and
Choose Device-> RaspberryPi 5 Choose OS -> Use custom -> select from the location on my computer Choose Storage -> choose the SDcard Next
I get prompted "Use OS Customization?"

Ooof! Yep, that's not what I expected at all. I'm going to take two actions as part of this issue:

  1. Identify the cloud-init default mode, because that doesn't feel safe for later development

Will we have to add network_renderer or something along these lines for our json? I don't mind testing with networkd, but me testing something and end users using something is a whole different ball game ;)

  1. Reintroduce or fix up restrictions on customising the 'custom image' flow - the local repo flow will retain that capability.

That makes sense.

As I noted in #942 once I was able to test 1.9.0 by using the Xorg backend for GNOME, I see the same on 1.9.0, it prompts me for customization options with a custom image.

@cmd0s
Copy link

cmd0s commented Oct 20, 2024

I have another use case where I intentionally use both "custom image" and "Use OS Customization" My image is a slightly modified version of Ubuntu, and the "Use OS Customization" option is still useful and even necessary for me.

I’m a developer on the Web3 Pi project, where, in simple terms, we provide a specialized image for Raspberry Pi. Once this image is flashed onto a memory card and the Raspberry Pi is booted, the installer will automatically configure and launch a Full Ethereum Node.

From my perspective, it would be ideal if you could avoid removing the "Use OS Customization" functionality for custom images.

You can find more information on our website: https://www.web3pi.io/welcome-box

@tdewey-rpi
Copy link
Collaborator

I have another use case where I intentionally use both "custom image" and "Use OS Customization" My image is a slightly modified version of Ubuntu, and the "Use OS Customization" option is still useful and even necessary for me.

I’m a developer on the Web3 Pi project, where, in simple terms, we provide a specialized image for Raspberry Pi. Once this image is flashed onto a memory card and the Raspberry Pi is booted, the installer will automatically configure and launch a Full Ethereum Node.

You can find more information on our website: https://www.web3pi.io/welcome-box

Have you considered listing your image in the Raspberry Pi Imager OS list? That would simplify your deployments and retain the option for OS customisation in a way that doesn't expose issues of guessing incorrectly.

@cmd0s
Copy link

cmd0s commented Oct 22, 2024

I have another use case where I intentionally use both "custom image" and "Use OS Customization" My image is a slightly modified version of Ubuntu, and the "Use OS Customization" option is still useful and even necessary for me.
I’m a developer on the Web3 Pi project, where, in simple terms, we provide a specialized image for Raspberry Pi. Once this image is flashed onto a memory card and the Raspberry Pi is booted, the installer will automatically configure and launch a Full Ethereum Node.

You can find more information on our website: https://www.web3pi.io/welcome-box

Have you considered listing your image in the Raspberry Pi Imager OS list? That would simplify your deployments and retain the option for OS customisation in a way that doesn't expose issues of guessing incorrectly.

Thanks for your message! It would indeed be fantastic if the Web3 Pi image could be selected directly from the Raspberry Pi Imager OS list. Is there any documentation or instructions on how to submit/add an image to the Raspberry Pi Imager application?

@tdewey-rpi
Copy link
Collaborator

Thanks for your message! It would indeed be fantastic if the Web3 Pi image could be selected directly from the Raspberry Pi Imager OS list. Is there any documentation or instructions on how to submit/add an image to the Raspberry Pi Imager application?

Best plan is to fill out this form, which includes an example of the sort of file you'd need to generate & host. Many projects choose to host the subitems JSON file on GitHub - and if you do, please remember to use the raw.github URL!

https://forms.gle/X7HpED5fYcjW1k8c7

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants