Hi! I'm trying to use automatic installation script with debian-11.6.0-amd64-netinst.iso and cloud-config iso which was created with cloud-localds command. My cloud-config is very basic and I have used it with Ubuntu automatic installation without problems. I tried with qemu script which I use with Ubuntu where $SEED is cloud-init iso and $LOCATION is netinst iso:
/usr/bin/qemu-system-x86_64 \
-smp 2 \
-cpu host \
-name "$NAME" \
-device virtio-net,netdev=user.0 \
-netdev bridge,id=user.0,br=virbr0 \
-m 1024 \
-boot once=d \
-drive file="$DPATH",if=virtio,cache=none,discard=ignore,format=qcow2 \
-drive file="$LOCATION",media=cdrom \
-drive file="$SEED",format=raw,cache=none,if=virtio \
-machine type=q35,accel=kvm,usb=off \
-nographic \
-nodefaults \
-serial stdio \
-no-reboot \
-rtc base=localtime,clock=host,driftfix=slew \
-kernel /cdrom/install.amd/vmlinuz \
-initrd /cdrom/install.amd/initrd.gz \
-append 'console=tty0 console=ttyS0,115200n8 autoinstall net.ifnames=0 biosdevname=0 ip=dhcp ipv6.disable=1 serial=ds=nocloud'
image was created with qemu-img create and my host libvirt KVM.
I also tried with virt-install:
virt-install \
--virt-type kvm \
--connect qemu:///system \
--name "$NAME" \
--description "$DESCRIPTION" \
--ram 1024 \
--vcpus 1 \
--disk path="$DPATH",device=disk,bus=virtio \
--disk path="$SEED",device=cdrom \
--os-variant detect=on \
--network bridge=virbr0 \
--graphics none \
--debug \
--noreboot \
--console pty,target_type=serial \
--location "$LOCATION,initrd=install.amd/initrd.gz,kernel=install.amd/vmlinuz" \
--extra-args "auto console=tty0 console=ttyS0,115200n8 serial DEBIAN_FRONTEND=text priority=critical" \
--qemu-commandline='-smbios type=1' \
--rng /dev/urandom \
--clock offset=localtime \
--import
Any help, I can't get this working? I have virt-install automation which is working ok with preseed.cfg and --initrd-inject but can't get this working with cloud-config.
Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230
autoinstall from netinst iso
Re: autoinstall from netinst iso
Add to my question: I am aware of official debian cloud images, but what I would like to do is to do initial install process from iso and choose what will be installed and configured with cloud-config as I can do with Ubuntu iso. I can do this with kickstart cfg file, but not with cloud-config and my question is if cloud-config is supported that way?
Re: autoinstall from netinst iso
@jouros , hey, have you figured it out?
I'm also trying to figure out if I can reuse Ubuntu's Autoinstall with NoCloud / USB (CIDATA) that have user-data (globally - subiquity, but with user-data cloud-init compartible section in it) and meta-data files on it
I'm also trying to figure out if I can reuse Ubuntu's Autoinstall with NoCloud / USB (CIDATA) that have user-data (globally - subiquity, but with user-data cloud-init compartible section in it) and meta-data files on it
Re: autoinstall from netinst iso
Just in case, Ubuntu's autoinstall script, though called user-data, is not the same user-data that will be accepted by Debian (at least by manually installed cloud-init).
Ubuntu's autoinstall script is for subiquity, where user-data is just one of sections inside it (though the file must be called user-data if you supply it via USB labelled as CIDATA).
Debian can only accept content of user-data section of that file providing it's the topmost nodes. It fails to "extract" content of that section from the Ubuntu's file and requires admin to supply just the content of user-data section in user-data file. So it's the same content that one would supply as user-data section into various cloud providers (DigitalOcean, Vultr, etc).
At least that's my experience. Dunno if that's what caused TS to run into issues.
Ubuntu's autoinstall script is for subiquity, where user-data is just one of sections inside it (though the file must be called user-data if you supply it via USB labelled as CIDATA).
Debian can only accept content of user-data section of that file providing it's the topmost nodes. It fails to "extract" content of that section from the Ubuntu's file and requires admin to supply just the content of user-data section in user-data file. So it's the same content that one would supply as user-data section into various cloud providers (DigitalOcean, Vultr, etc).
At least that's my experience. Dunno if that's what caused TS to run into issues.