cloudymax / pxeless Goto Github PK

Dockerhub readme needs to be in-sync with main repo

Hi!
This is a question and not an issue!

Is there any way to install debian packages before creating the ISO? Ubuntu cloud-init needs access to the Internet to install packages, so I am looking for a solution to inject packages during image creation.

Downloading debian packages and injecting through extras file could be a solution, but managing package dependecies is not easy!

The another possible solution could be chroot, but in which step of the script I should do?

Br,
Meraj

Hi,

thanks for picking up the slack after covertsh/ubuntu-autoinstall-generator died.

My issue: Even if I choose to download a release, -r it will be kept with a filename including the download data and will not be picked up the following day.

I have some ready, wait for it.

I used docker run --rm --volume "$(pwd):/data" --user $(id -u):$(id -g) deserializeme/pxeless \ -a -u user-data.basic -n jammy to create a bootable drive. When ssh'ing into the machine I am unable to access it using the default username and password, vmadmin and password

The user-data.advanced file contains the runcmd module, however, this does not work on autoinstall or at least with the current version. Did u test it?

Hi,

Thanks for doing so much of the heavy lifting in terms of providing a solution that allows features like cloud-init to be useful.

One thing you have the following example in your readme.md

docker build -t iso-generator . &&
docker run -it --mount type=bind,source="$(pwd)",target=/app iso-generator
ubuntu-autoinstall-generator.sh -a -u user-data.example -n jammy

The version of ubuntu-autoinstall-generator.sh over at covertsh/ubuntu-autoinstall-generator does not have an -n option.

Currently, it is not clear if you have a typo in your example or maybe an extended version of the script.

Thanks again

Need to fix the CI pipeline to properly version the docker images on tagged releases

Thanks for continuing this development.

My main goal is to add toram fsck.mode=skip to the boot parameters. I've done this locally, but would like to upstream it, soliciting feedback on a good approach.

The use-case is that we deploy remote sites, where all we know is the BMC IP of the server and no personell on-site. So generating a server-specific ISO with an approproate cloud-init helps us bootstrap the initial infrastructure node before we have machine provisioning established. The BMC is configured to mount and boot the ISO over the network.

Some of these sites are very remote with high latency (up to a second RTT), which poses some challenges. It all seems to work well with these two parameters added.

So before I submit a PR, how would you like these to be added? An arbitrary --kernel-args, or individual switches (--toram, --skip-fsck)?

The image-create script has been coded to take the path from which it is run and then use it as the root directory for certain other steps. This is all handled by the use of the SCRIPT_DIR variable.

This does not cause any issues if everything is placed in a single directory or the script is placed at the top level of any tree structure that is defined. It does cause a complication if the script itself is placed in a sub-directory.

In the environment I am putting together the impact is on the -d --destination switch as any path passed must be offset from the location of the script, rather than the 'root' directory. -s --source does not have this issue as the function extract_images has not been written to use SCRIPT_DIR.

The result is that the command line for image-create ends up looking something like this

bin/image-create.sh -a
-k
-n jammy
-u config_files/scaleway-1-network-basic
-s iso_store/ubuntu-22.04.1-live-server-amd64.iso
-d ../iso_output/ubuntu-22.04.1-test-amd64.iso

So

• the script is found in bin/
• config files are in config_files/
• source iso image is in iso_store/
• destination iso is placed in iso_output/ but must be defined as a path offset from bin/

You may be wondering why I'm making such a complex structure. My aim is to have an environment that can create a number of different ISOs for CI and production environments, which will be complicated even more by the use of ytt Carvel tools which will allow me to have a far more dynamic YAML environment.

Thanks for taking over the ubuntu-autoinstall-iso-generator repro ❤️

Is there a working example known for an automatic install of ubuntu 22.04.1?
I'm having issues on setting it up correctly.

When I'm trying to use the provided sample and execute the builder with a pre-downloaded ubuntu iso and the command

./image-create.sh --no-verify --all-in-one --user-data basic-config.yml -s ubuntu-22.04.1-desktop-amd64.iso -d install-22.iso -n jammy

the iso is successfully created.

Now when booted from this iso in a VM, selected the default grup entry, the automatic procedure is not started correctly and I'm seeing the install wizard.

I looked into the syslog and the commands in the kernel seem to be correct. Any clues where to look at?

Noticed that this function was expanded quite a bit and "sudo" is now a dependency (which broke CI builds for me in Bitbucket). Perhaps we could make sudo optional if not running as root or in CI runners?... like:

#!/bin/bash
if [ ! "$CI" ]; then
  if [ "$USER" != "root" ]; then
    SUDO="sudo "
  fi
fi

I've had a quick look and they seem to be related to #27 . Though I never had issues adding extra files in Ubuntu Focal (20.04). So there must be something more to it... I hope to dig a little bit deeper on the following days, for now I will lock this submodule to the previous commit.

BTW - Kudos @cloudymax for maintaining this tool :)

For context, I created my user-data file using the user-data.basic as a base.

I created the image but I can't log in to the server at all with the created user.

I thought it was my configuration but I used the user-data.basic and still can't login.

Anyone with a similar problem?

I'm trying to figure out how to take the additional files I've added to the iso and have them copied to the hard-drive of the machine being built.

I originally used -x to add a directory to the iso..but I didn't see that directory in the / dir of the newly installed machine. Next I tried adding a cp -R /root/my_additional_stuff /root/ to see if that would copy over my additional directory but that didn't seem to work either.

What would be the preferred method to accomplish getting some custom files copied from the iso to the new machine?

v0.0.7 and v0.0.8 is broken:
$ docker run --rm --volume "$(pwd):/data" --user $(id -u):$(id -g) deserializeme/pxeless:v0.0.7 -a -u user-data.basic -n jammy -r
Digest: sha256:7a1862ac4d38c493a9cebed3dc31a57f7cf1e843bdd0a04e42ad05b09f193826
Status: Downloaded newer image for deserializeme/pxeless:v0.0.7
docker: Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: exec: "/data/image-create.sh": stat /data/image-create.sh: no such file or directory: unknown.

v0.0.6 is works:
$ docker run --rm --volume "$(pwd):/data" --user $(id -u):$(id -g) deserializeme/pxeless:v0.0.6 -a -u user-data.basic -n jammy -r
Digest: sha256:0df39c1aeabdc9cb4518a648b99aa682444cd3fe8d69536ab187ae2b146c0e85
Status: Downloaded newer image for deserializeme/pxeless:v0.0.6
[2023-05-18 20:12:39] 📁 Created temporary working directory /tmp/tmp.hAZYqs7Mux
....

I assume this issue has been missed as it (probably) works if you have image-create.sh in $(pwd)

This is to address the issue uncovered while troubleshooting #33

The problem is that in order to mount the squashfs, we need sudo access.

This is problematic because we dont want to run containers as root in production

The only compromise I can think of is to add a user account with passwordless sudo access into the container, and then run the container with the user ID and group ID of the new account.

This should allow sudo access to the squashfs while fulfilling the technical requirement for a non-root account to run the container - though it's still not ideal to have the user account with sudo access.

I imagine through that most people using this script do so as a one-shot job and don't leave the container running for long, which should mean the risks are minimal

I hope you don't mind me raising issues like this as I don't have the time or really the skills to do direct modifications and pull requests.

Your script has a problem when trying to use the -s (source) switch as you also need to define the -n (code-name) switch as the script still tries to run function latest_release which will fail on the first curl as it can not retrieve a valid file without a code name being provided.