| opendevreview | TaylorTao proposed openstack/ironic master: Fix SOL releated issue https://review.opendev.org/c/openstack/ironic/+/823050 | 07:07 |
|---|---|---|
| opendevreview | TaylorTao proposed openstack/ironic master: Fix SOL releated issue https://review.opendev.org/c/openstack/ironic/+/823050 | 10:25 |
| opendevreview | Maksim Malchuk proposed openstack/bifrost master: Create the log file for the disk-image-create command https://review.opendev.org/c/openstack/bifrost/+/822895 | 14:43 |
| rm_work | I know it's a longshot, but if anyone is actually here, I would love some help understanding the ironic boot process, so I can debug a grub error I'm getting on (what I believe is the final stage of) a new instance booting | 15:52 |
| holtgrewe | rm_work: about to leave, ironic will boot an ironic-python-agent (IPA) image that does inspection | 15:53 |
| holtgrewe | on deployment the same image will be booted and - by my understanding - by default write your image to the hard drive | 15:54 |
| rm_work | so, the instance made it all the way to ACTIVE | 15:54 |
| holtgrewe | where on first boot cloud-init is used (by default) to initialize the settings | 15:54 |
| rm_work | I THINK it's on the final (target) image? | 15:54 |
| rm_work | is there a good way to verify that? | 15:54 |
| holtgrewe | It *should* be | 15:54 |
| holtgrewe | It could be tricky to find out | 15:54 |
| rm_work | I booted via nova, with an image tag for a rhel7 image | 15:55 |
| rm_work | (a custom one that is in my Glance) | 15:55 |
| holtgrewe | in the worst case you will have to login via serial console | 15:55 |
| rm_work | hmm | 15:55 |
| holtgrewe | and you might need to build an image with a known password | 15:55 |
| holtgrewe | that is what I needed to do | 15:55 |
| holtgrewe | you can look at the ironic logs | 15:55 |
| holtgrewe | ironic conductor logs will tell you whether it tried to write the image | 15:55 |
| holtgrewe | and you will see some image | 15:55 |
| rm_work | conductor log? I assume | 15:56 |
| holtgrewe | while IPA is doing its work adn writing the image, you can look at the journalctl logs | 15:56 |
| holtgrewe | *some logs | 15:56 |
| holtgrewe | sorry, about to leave now | 15:56 |
| rm_work | yeah np | 15:56 |
| rm_work | I just see all kinds of other images like ipa-ramdisk initfs and kernel | 15:57 |
| rm_work | and a stage2 squashfs... | 15:57 |
| holtgrewe | this might help https://docs.openstack.org/ironic-python-agent/latest/ | 15:57 |
| rm_work | wanted to make sure it is definitely booting the rhel7 image so I don't waste all my time trying to track down an error in that image when it isn't even booted yet | 15:57 |
| holtgrewe | hm, can't you look on the serial console? | 15:58 |
| holtgrewe | .e.g., OS Xena uses a CentOS 8 for IPA | 15:58 |
| rm_work | this is what I see in the console log: | 15:58 |
| rm_work | https://paste.opendev.org/show/811874/ | 15:58 |
| rm_work | I am ASSUMING that is a broken rhel7 image (the image ID I passed to nova for the instance) | 15:59 |
| holtgrewe | sorry, can't help you here | 16:00 |
| holtgrewe | during normal work days the channel is super active and helpful though | 16:00 |
| rm_work | yeah I will own figuring out the image issue | 16:00 |
| rm_work | I just want to make sure it's actually THAT IMAGE that's booted at this stage | 16:00 |
| rm_work | and not one of these intermediary things | 16:00 |
| holtgrewe | You might want to clean / wipe / zap the disk once | 16:00 |
| holtgrewe | I don't think that IPA will touch existing partitioning | 16:01 |
| rm_work | yeah clean works, doesn't affect this | 16:01 |
| rm_work | (this is, for the record, in a sort of ... devstack-esque test environment) | 16:01 |
| rm_work | i have cleaned all my test nodes a bunch during the testing process. I guess it could also be possible something in the cleaning left them in a bad state? heh | 16:02 |
| rm_work | appreciate the info 😛 I'll read up more | 16:02 |
| holtgrewe | hmm, should not happen but ppl here will be able to tell you more in January when they're back | 16:03 |
| rm_work | yeah, I guess I just beat my head on this wildly and hope I get lucky until then XD | 16:03 |
| rm_work | maybe I'll figure it out! | 16:03 |
| holtgrewe | if you have virtual device support in your server's BMC, you might want to try to boot an grlm image and look at the disk contents | 16:04 |
| holtgrewe | that helped me (worked fine with Dell iDRAC but should also work with HPE ILO or SM BMC) | 16:05 |
| rm_work | the server is ... technically not real hardware 😀 | 16:05 |
| rm_work | it's virtual (devstack-esque testing environment) | 16:05 |
| rm_work | ironic is just configured to think this is a real server, heh | 16:05 |
| rm_work | could also be something with that emulation that's broken, but I THINK it worked before for some people | 16:06 |
| holtgrewe | Oh, you're missing out of a lot of nasty problems, then! All the pain figuring out hardware :-) | 16:06 |
| rm_work | my problem is that I'm not even close to an expert and the rest of my team is on vacation still 😛 | 16:06 |
| rm_work | I do loadbalancers >_< | 16:06 |
| holtgrewe | My speciality is getting stuck ;-) | 16:07 |
| holtgrewe | no matter the topic | 16:07 |
| holtgrewe | So if you're into load balancers you're already ahead of me. You'll figure it out. | 16:07 |
| holtgrewe | If it's virtual, could you not just mount the image somewhere and inspect it there with fdisk or something? | 16:08 |
| rm_work | maybe | 16:08 |
| holtgrewe | That is what I would try | 16:08 |
| rm_work | the issue is that I can look at the FS but I think grub is ... special? lol | 16:08 |
| holtgrewe | if it's a qemu/kvm machine there are tools that let you mount virtual disks easily | 16:08 |
| holtgrewe | here's a pretty picture of the provisioning process https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/10/html-single/bare_metal_provisioning/index | 16:11 |
| holtgrewe | btw | 16:11 |
| rm_work | cool, thanks! | 16:13 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!