Closed skycastlelily closed 4 years ago
Thanks for the report. We have CI testing this exact flow so it's unlikely (but still possible) that it regressed.
Can you please check the node console as soon as it completes booting? It should mention that an authorized key for the core
user has been added by Ignition.
It would also be helpful to reboot into single
mode (steps described in our docs) and extract the full logs from the first boot (see journalctl --list-boots
), to attach here.
There is no grub menu showed,I added the following to the yaml password_hash:"$6$ansiogjasd0io9u3$9E1vMbLbXW14grtguedFGVjvhyBz1T.KIA3MJl1SWnGbtTpiXIAjbazIQAUKRNkNIEmd3mI0NCkFIVBrN41fZ." but failed to login the newly installed system:
fedora login: core Password: [ 211.931797] audit: type=1100 audit(1604670355.421:194): pid=1913 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='op=PAM:authentication grantors=? acct="core" exe="/usr/bin/login" hostname=fedora addr=? terminal=ttyS0 res=failed' Login incorrect
fedora login: [ 213.639122] audit: type=1112 audit(1604670357.127:195): pid=1913 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='op=login id=1000 exe="/usr/bin/login" hostname=fedora addr=? terminal=ttyS0 res=failed'
Are you on a platform with SELinux enabled? Make sure that your Ignition config is labelled correctly (e.g. chcon -t svirt_home_t /home/lnie/test.ign
).
Are you starting from scratch with a fresh machine every time you change the Ignition config? Contrary to cloud-init, Ignition only runs once, and will thus not pick changes if you keep the same virtual machine with a new Ignition config.
I also ran into issues when testing the latest next release 33.20201104.1.0 using Vagrant. This is related to the removal of ssh-rsa
from the PubkeyAcceptedKeyTypes.
sshd[2117]: userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedKeyTypes [preauth]
Most recent SSH clients are still able to connect with ssh-rsa keys by using a sha2-256/512 signature algorithm. But the pure rubygem used by Vagrant net::ssh, a pure ruby implementation of ssh, that is shipped in Fedora 33 does not seem to do this.
@skycastlelily - what OS/Version is your host machine?
Can you try switching to a non-rsa key type (not required as mentioned by @basvdlei, but is an easy way to test if that's the issue) and see if you still have the problem?
Make sure that your Ignition config is labelled correctly (e.g. chcon -t svirt_home_t /home/lnie/test.ign).
I ran "chcon --verbose unconfined_u:object_r:svirt_home_t:s0 /home/lnie/test.ign"
Are you starting from scratch with a fresh machine every time you change the Ignition config?
yes
what OS/Version is your host machine?
I found it on f32 workstation host
Can you try switching to a non-rsa key type (not required as mentioned by @basvdlei, but is an easy way to test if that's the issue) and see if you still have the problem?
I switched to dsa key,still doesn't work
The weird thing is: It works well on remote beaker machines,then I reinstalled my local machine with Fedora-Workstation-Live-x86_64-32-1.6.iso, the virt-install command asked me to active default network(beaker machine didn't ask me to do that),and after I active the default network,and run the virt-install command,it failed as described.All the beaker machines has latest stable packages installed by default,I thought that's the difference,then I dnf update my local machine,and reboot,and run the virt-install again,still failed....
I switched to dsa key,still doesn't work
Can you try ed25519 or ecdsa?
I've tried with ed25519 and ecdsa,what also weird is that fedora-coreos-32.20200601.2.1-qemu.x86_64.qcow2 works well on the same host
The latest stable
stream release is 32.20201018.3.0
.
The latest next
stream release is 33.20201104.1.0
.
If I understand you correctly it seems like the problem was introduced with F33. Can you verify that 32.20201018.3.0
works for you, but 33.20201104.1.0
doesn't?
Checked, yes,32.20201018.3.0 works,but 33.20201104.1.0 doesn't.
@skycastlelily - any chance you can provide us the full logs from the boot from the attempt with 33.20201104.1.0
?
Sure:
[ 0.026037] Kernel command line: BOOT_IMAGE=(hd0,gpt1)/ostree/fedora-coreos-14059d645b77576ea5cdbebce512902b2eacc22c855efc181e3099c389d174e1/vmlinuz-5.8.17-300.fc33.x86_64 mitigations=auto,nosmt systemd.unified_cgroup_hierarchy=0 console=tty0 console=ttyS0,115200n8 ignition.platform.id=qemu ostree=/ostree/boot.1/fedora-coreos/14059d645b77576ea5cdbebce512902b2eacc22c855efc181e3099c389d174e1/0 root=UUID=22e21fee-abb1-4e69-8e86-dcc1b91d0bb9 rw rootflags=prjquota
This shows an 33.20201104.1.0
which has been booted already (note the lack of any ignition.firstboot
kargs). As it has already gone through the first-boot successfully in the past, Ignition will not run on this instance anymore. Thus, no further configuration will be applied.
If this was supposed to be the first-boot for a fresh instance, make sure you are using the pristine qcow2 image and not a re-used disk image.
yes,it works now,thanks for your hint,and sorry for the confusion
I also ran into issues when testing the latest next release 33.20201104.1.0 using Vagrant. This is related to the removal of
ssh-rsa
from the PubkeyAcceptedKeyTypes.sshd[2117]: userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedKeyTypes [preauth]
Did I miss the warning about this issue in the installation procedure ?!? Because it's a pretty big trap that made me retry and double check everything 4 times before stumbling on this ! Swapping to a ED25519 key solved it !
There's probably an opportunity for us to do better here. In the very least adding something to our documentation. Sources are here: https://github.com/coreos/fedora-coreos-docs
Here is the ign file I used:
and here is the command I used to create the VM:
Expected behavior I'm able to login by run "ssh core@ip_address" with lnie
Actual behavior
System details
Additional information I try to add the following to the yaml which helped me automatically login to VM created with older versions,didn't work