* eoli3n <1907...@bugs.launchpad.net> [2020-12-08 11:50]: > > I can say that the Ubuntu Server installer isn't typically used to install > > Ubuntu Desktop. > I use it because i can't find any netboot installer which supports > autoinstall and EFI installation. I used legacy netboot (60MB) for my > kickstart install but now i need to autoinstall an EFI system.
OK > > > have you looked at just using the Ubuntu Desktop installer with OEM > > mode? > > https://help.ubuntu.com/community/Ubuntu_OEM_Installer_Overview > I just want a way to automate installation from a pxe boot, with an > "answer file", i did with kickstart in a "script" model, i want to do > the same with autoinstall. Sure > > cloud-init is configured to write to the console by default; that's > > why you see output from cloud-init on your tty. > It seems to me a little bit buggy, don't you think ? Well, that's not a bug. It's the default configuration for cloud-init as it runs in places where there's no access to tty or console; just the output that a cloud platform may show you. You may want to remove/override the StandardOutput setting in the cloud-init service units (cloud-init-local, cloud-init, cloud-config, cloud-final). The default is to log to both journal and console. # Output needs to appear in instance console output StandardOutput=journal+console It's something that subiquity could configure differently since in this scenario, the target system would have user-facing console. > I think cloud-config.service should defaulty have a stronger > dependency as Before=getty.target for exemple. Possibly. If you want to test that out, you can add this as a drop-in conf, before for boot the target OS you can: mkdir -p /target/lib/systemd/system/cloud-config.service.d echo -e "[Unit]\nBefore=getty.target > /target/lib/systemd/cloud-config.service.d/10-before-getty.conf > > Why don't the installer configure everything during the install process > ? Generating locales, write /etc/default/locale and set /etc/timezone > are not hard tasks. Even if cloud-init embeed those configuration, you > could tell the installer to setup what in cloud-config as default > config. The design is based on the idea of a template image. The Ubuntu server image is ready to boot and on first boot cloud-init handles the tasks to "instantiate the image". Doesn't the autoinstall input generatea cloud-init config that configures these things? > > If you can't avoid that first startup scripts, you should start as early > as possible in the init process, before any process that could use what > it setup/modify. Does that seem illogical ? It's not. Cloud-init does start up as early as possible (after local fs is mounted). However some tasks require to be run later; for example package install cannot run without networking being configured. At this point, I don't think there is a bug in cloud-init. For your use-case, you may need change some of the defaults that are already cofigured in the image. It's probably worth looking at your working solution to see what, if anything, could be configured by subiquity; or if it makes sense to tweak a default. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1907107 Title: cloud-init runs too late at first startup after ubuntu autoinstall To manage notifications about this bug go to: https://bugs.launchpad.net/subiquity/+bug/1907107/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
