-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
panic: runtime error: index out of range #49
Comments
I'm glad the tool has been useful. It could be that the disks are somehow already attached, in which case my code ignores them - I believe that's a corner case that I hadn't thought through, I could proceed to the next steps (Mount, etc.) even if the disks are already attached. How do you create EC2 machines + EBS vols? Terraform? Do you have an example of a log from a successful run stored somewhere? I believe the emptiness between steps 2-3 and 3-4 could indicate the "disks already attached therefore my code doesn't add them to the array of disks to mount" hypothesis. |
Thanks for the speedy response. I've just downgraded to 0.6.0 which seems to have got things working again. That's certainly quite possible. Goat is running at boot, so it may well have failed to mount because of some other reason, after having already attached all the volumes, then died. I'm then running I'll try upgrading back to 1.0.2 shortly and running it with no volumes attached to see what happens there. Sounds like I'm potentially running into two different issues |
Ok, with everything detached, I get a different problem
Interestingly, that volume took longer to attach than goat was willing to wait. |
Can you test this hotfix? https://github.com/sevagh/goat/releases/tag/1.0.3-rc0 |
@sevagh That appears to have resolved the original issue 👍 I'm now getting this:
We're using nvme, which is probably why - it should be |
I should be getting that attached device name from the AWS API: https://docs.aws.amazon.com/sdk-for-go/api/service/ec2/#VolumeAttachment |
@sevagh Do you want me to raise a new issue for the above? then you can close this one off |
This same issue is OK. I'll get back to you soon. |
Can you print the logs surrounding the above error message? There are some additional functions related to nvme (which another user helped contribute) - I'm not very well versed in Nitro and nvme devices. |
Sure, here you go:
The issue with nvme volumes is that the attachment info shows as The volume ID is embedded in the serial for the device identification, so that might be the easiest way of determining it, but would require having the utility installed:
|
Actually, looking at the code, there is already some nvme logic using go-ebsnvme - which seems to try and find the correct nvme device using the attachment devicename. Potentially better sticking with that, as it doesn't require an external package (nvme-cli). |
Just had a quick look and have a feeling that the issue is potentially here: Lines 52 to 53 in 81f1aa3
Basically, the logic to determine the nvme device name is skipped over completely when the device already has a label, which will always be the case on the second mounting attempt |
Nice sleuthing - it looks like I should put a call to this function, GetActualBlockDeviceName, somewhere: Line 38 in b6af4b2
Maybe when writing the fstab entry - but I'm having trouble discovering where the link between the label and nvme device name exists. |
I'm building a 1.0.3-rc1 |
https://github.com/sevagh/goat/releases/tag/1.0.3-rc1 The gist is that I put the "GetActualBlockDeviceName" call early in the code to have the real nvme name in the volume struct rather than substituting it in the future. |
What's funny is that I think all of this workaround comes from me choosing |
Made some progress, it's now failing to mount, but using the correct device name in the log message:
/dev/nvme4n1 does exist, so presumably it's still trying to mount the old assumed /dev/xvd* behind the log message |
If you run |
Nope, they all point to the correct nvme devices. Bear in mind the labels were created some time ago |
I might have found a leftover place where I don't correct the AttachedName for nvme. Hold tight for rc2... |
https://github.com/sevagh/goat/releases/tag/1.0.3-rc2 I'm cutting rcs frequently since it's a safe way for us to share trusted binaries (vs me emailing you a binary). |
Yeah, no worries. Same error, although interestingly, it has now managed to mount two volumes before bombing out. It's only put one of the above volumes into /etc/fstab as well |
Also, as a side note, it bombs out if something is already mounted, even though potentially it was Goat that mounted it in the first place (i.e. on a second run). Feels like it should just break out of the loop for that paticular volume, rather than exiting completely. Admitadly I guess it being run multiple times (as opposed to just at boot) wasn't an originally intended use-case |
Idempotence is a good goal to have - it's strange for a tool to panic because of something it did a few minutes ago. Unfortunately I don't use AWS (and haven't, since writing this tool) so I can't easily iterate over code to solve this issue. |
I'll have a play locally and see if I can get it working, then submit a PR back |
Submitted a PR for this. Not ideal, but it works. FWIW, we're fairly heavy users of Goat, and an AWS consultancy. We'd be happy to take over maintenance if you're not using AWS at your current place. |
Thanks for PR - re: taking over, that's a good idea. What's the best way to denote the change? Perhaps a note in the description that https://github.com/steamhaus/goat is official? And I could archive this one. |
Sure. I'm pretty sure within the repo settings, there's a 'transfer' option. That then keeps a redirect in place from segagh/goat to steamhaus/goat. I'd need to get rid of the fork first though |
I've removed the fork, so feel free to do the transfer if you'd like |
I'd prefer not to do a transfer. Would you be OK with continuing main development on your fork? Like I said, I'll point to it from this repo. |
Sure, can do that if you'd prefer. Will fork it again later this evening |
Thanks @bilco105 - I'll go ahead and archive goat for now. If you have any questions about the build process, etc. let me know (but |
Hi @sevagh
First of all, really appreciate the work you've put into this tool - we use it a lot.
Recently though, I've randomly started encountering a problem that I've not seen before, specifically this error:
The EBS volumes attach fine, however, they fail to mount. This looked the same as #47 initially, however, I've upgraded to 1.0.2 and the error persists.
The tagging all appears to be correct, GOAT-IN:FsType, GOAT-IN:MountPath, GOAT-IN:NodeId, GOAT-IN:Prefix, & GOAT-IN:VolumeName are all set, and I've verified the IAM permissionns are correct.
Any ideas?
The text was updated successfully, but these errors were encountered: