-
Notifications
You must be signed in to change notification settings - Fork 30
CoreOS 1855.4.0 AWS EBS Mount Lockup #2511
Comments
Thanks for the report. This probably isn't an Ignition bug but rather a kernel bug since Ignition didn't change between 1855.3.0 and 1855.4.0. Can you repro on alpha? |
Will check tomorrow :) |
@ajeddeloh - Same issue on alpha: Also please note previous working version was much older: |
This happens for me as well on the latest gen instances. Switching instances from t2 and t3 results into the system hanging on a systemd unit that's waiting for device "/dev/xvdg". Perhaps this has something to do with switching to the NVME names that t3 instances do. |
Fetched one of the logs from the machines, I see lots of these messages:
It eventually times out:
|
@enieuw Hey... how did you get that system log? My AWS EC2 system logs are blank :( |
It takes a while but eventually they show up under "Instance Settings -> Get system log". Which instance type are you running by the way? |
For this debug session I was running t2/t3/m5 (can't remember the exact size) |
Creating a VM as a t2 instance and then changing the instance type to t3 works, I actually see the symlinks working:
Creating a fresh T3 instance results in the hanging behaviour |
Ah I'm betting that's because when changing the instance type that Ignition doesn't run on the second boot. |
Yeah most likely. It doesn't trigger the wait for the systemd unit and then it does continue booting. If I specify /dev/nvme1n1 in my ignition file it does boot properly. Perhaps the call to systemd is done before udev has mapped the aliases added by #2399 |
@enieuw I think you are waiting for coreos/bootengine#149 to do that. |
Okay looks like a mismatch between assigning EBS to /dev/sdb in the AWS console and /dev/xvdb appearing in linux. ap-northeast-1
Results in:
Updating the config from sdb -> xvdb finishes the boot. Is there already a ticket for sdb vs xvdb? I think on some systems (can't remember) /dev/sdb shows up instead. |
As a follow on thought, it seems sometimes EBS volumes (add-on disks on AWS) show up as /dev/sdb and sometimes as /dev/xvdb. That makes ignition scripts fail if mismatched and makes it difficult to use the same script on various servers. Is there any guidance on /dev/sdb vs /dev/xvdb going forward in coreos? Perhaps following such guidance would have prevented this ticket. |
@pctj101 this is an unfortunate choice on AWS side, see #2399 (comment). Their volumes/instances/names grid is documented here: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/device_naming.html |
@lucab - Yes I too have seen where my EC2 launch spec and coreos device path mismatch. I think it's related to this item on the same page as the link you provided:
So it seems that the kernel configuration (and thus CoreOS) may also have some interaction. So it's not just "It's AWS", but "It's AWS and How CoreOS interact" which is why I'm bringing up this question. :) Anyways, yes I read the other thread you linked to. I can share with you that on device mapping I've abandoned Ignition and resorted to a series of shell scripts to format and mount things properly (despite instance type changes). I'm not sure if that's the long term way to do it, but I'm pretty sure the discussion either way is lengthy and has plenty of ideology to go with it :) When it comes to AWS totally changing device paths for NVMe, even I have trouble justifying automagic resolution with ignition. It's definitely a usability discussion rather than a bug discussion. |
Possibly related: #2481. |
Issue Report
Bug
Ignition crashes system if storage.filesystem is specified
CT Input
Convert to userdata
ct < test.ct
Container Linux Version
CoreOS-stable-1855.4.0-hvm (ami-086eb64b7f4485a72)
ct v0.9.0
Environment
AWS
Expected Behavior
At minimum format my block device
Actual Behavior
System does not boot
Can't login, so can't get logs
Screenshot
https://www.evernote.com/l/AE__MLODCjJN_p8vv9G_LkqC2nBnb6BbAqI
Reproduction Steps
Other Information
Worked before on older CoreOS-stable-1688.5.3-hvm (ami-a2b6a2de)
Manually booting without CT/Ignition allows manual format/mounting of /dev/sdb (mounting by label is also no problem)
The text was updated successfully, but these errors were encountered: