| John | Hey guys, I'm having an issue with my MaaS | 00:03 |
|---|---|---|
| === John is now known as Guest68615 | ||
| Guest68615 | Wondering if any of you can help me out a bit | 00:03 |
| Guest68615 | Is there anyone on here? | 00:06 |
| roaksoax | jhova: shoot | 00:26 |
| roaksoax | err | 00:26 |
| roaksoax | sorry | 00:26 |
| jhova | hey thanks for the response | 00:27 |
| jhova | nm addressing different person | 00:27 |
| roaksoax | jhova: ok, so I was reading your issue | 00:28 |
| roaksoax | jhova: i dont fully understand | 00:28 |
| roaksoax | jhova: so it installs but it doesn't boot ? | 00:28 |
| roaksoax | jhova: what version of MAAS are you using (exact version) | 00:28 |
| jhova | Yes, basically it seems like it's trying to use UEFI boot characteristics even though UEFI is disabled. | 00:28 |
| jhova | 2.1.1+bzr5544-0ubuntu1~16.04.1 | 00:29 |
| jhova | menuentry 'Local' { | 00:30 |
| jhova | echo 'Booting local disk...' | 00:30 |
| jhova | search --set=root --file /efi/ubuntu/shimx64.efi | 00:30 |
| jhova | chainloader /efi/ubuntu/shimx64.efi | 00:30 |
| jhova | } | 00:30 |
| roaksoax | jhova: that's strange | 00:31 |
| roaksoax | jhova: if that's the case, that means that the machine booted UEFI | 00:31 |
| roaksoax | jhova: try to re-commission the machine | 00:31 |
| roaksoax | jhova: and try to deploy again | 00:31 |
| jhova | I have several times, I don't know what's happening. | 00:31 |
| jhova | If you hit escape during pxe it loads fine | 00:31 |
| jhova | All aspects of UEFI are disabled in the BIOS | 00:32 |
| jhova | Do I need to completely delete to machine and re add? I've just been recommissioning the existing node. | 00:33 |
| roaksoax | jhova: 1 sec, | 00:33 |
| roaksoax | jhova: /win 2 | 00:35 |
| roaksoax | err | 00:35 |
| roaksoax | jhova: ok, so the way MAAS discovers the machine is booting is by looking at the request it makes to MAAs | 00:36 |
| roaksoax | so if it make a request for EFI | 00:36 |
| jhova | OK, should I grab that from the packets coming in? | 00:36 |
| jhova | to see what it's requesting? | 00:37 |
| roaksoax | jhova: so, the way the machine is told to EFI boot or pxelinux boot is via DHCP | 00:37 |
| roaksoax | jhova: the machine sends a special code | 00:37 |
| roaksoax | and the dhcp server identifies that from the dhcp packet | 00:37 |
| roaksoax | jhova: and tells the machine to EFI boot or so on | 00:37 |
| roaksoax | jhova: so my guess is your firmware trying to do that | 00:37 |
| roaksoax | jhova: what if you enable EFI on your firmware ? | 00:37 |
| jhova | After install it just boots to EFI shell | 00:38 |
| jhova | http://pastebin.com/sV36sD5D | 00:40 |
| jhova | roaksoax there is the DHCP request coming into maas | 00:40 |
| jhova | http://pastebin.com/b8gRWGBU | 00:42 |
| jhova | and the reply which shows the FNAME as pxelinux.0 | 00:42 |
| roaksoax | jhova: yeah, the option 93 is 00000 | 00:42 |
| roaksoax | which means pxelinux | 00:42 |
| jhova | hmm wonder why grub is laying down a config for local boot to look for uefi shim | 00:43 |
| roaksoax | jhova: i'd suggest you file a bug for now, and I'll raise it to someone tomorrow to try to figure out what could be going wrong | 00:44 |
| roaksoax | but that's a very strange behavior | 00:45 |
| roaksoax | since we test against efi and non-efi systems without any similar issue | 00:45 |
| jhova | OK, sounds good. I saw this commit for an older version: https://code.launchpad.net/~allenap/maas/disable-uefi-temporarily/+merge/212150 | 00:45 |
| jhova | any way I can keep the shim from being installed and remove all uefi pieces? | 00:45 |
| roaksoax | jhova: that branch is quite old, so it doesn't really apply | 00:46 |
| roaksoax | jhova: so just so im clear. you machine PXE boots, grabs pxelinux.0, the machines is installed by MAAS | 00:47 |
| roaksoax | then it reboots | 00:47 |
| roaksoax | in PXE boots again but this time it is told to EFI boot ? | 00:47 |
| roaksoax | jhova: or, after the reboot, the machine tries to boot directly from the disk ? | 00:47 |
| jhova | That's what it appears like. Some machines complain about MBR magic and then stick at booting. Others go directly to booting local disk ... and drop to the prompt. | 00:48 |
| === CyberJacob is now known as zz_CyberJacob | ||
| roaksoax | jhova: i wonder if it is actually trying to boot from a different disk than the one where MAAS has installed .... | 00:51 |
| roaksoax | jhova: that could be the reason | 00:51 |
| jhova | Definitely could be. Where are the actual pxelinux configs on the maas server? | 00:51 |
| jhova | Are the rendered from database entries? | 00:51 |
| jhova | they* | 00:51 |
| roaksoax | jhova: they are dynamically rendered. Maybe the BIOS has X disk as boot disk, but Y disk is the one being surfaced to the OS as /dev/sda, which would cause MAAS to install the mbr in /dev/sda but default | 00:52 |
| roaksoax | jhova: but the BIOS is trying to boot from X | 00:52 |
| roaksoax | jhova: you can go to MAAS UI, under the storage section on a machine in 'ready' state | 00:52 |
| roaksoax | jhova: and you can select which disk is the "boot" disk | 00:53 |
| roaksoax | so you might as well be able to say that /dev/sdb is the "boot" disk | 00:53 |
| jhova | yeah, these servers have a SAS controller in them that might be the culprit | 00:53 |
| roaksoax | that will cause maas to install MBR in /dev/sdb | 00:53 |
| roaksoax | jhova: that could definitely be it | 00:53 |
| jhova | I've tried messing around with all of the options, but can't disable it completely | 00:53 |
| roaksoax | jhova: just try to select the right boot disk in the MAAS webui | 00:56 |
| roaksoax | jhova: or set the right boot disk in the BIOS | 00:56 |
| jhova | BIOS just says hard drive and not seeing a priority | 00:57 |
| jhova | will keep investigating | 00:58 |
| roaksoax | jhova: ok, so try to figure out which disk is the boot, and change the option in the MAAS webui | 01:00 |
| roaksoax | jwitko: if something else is providing DHCP, you could either do: 1. static assign, and select the IP address you want to use instead of the suggested one or 2. DHCP | 01:01 |
| jwitko | roaksoax, thanks for the response! what I'm trying to avoid here is user error | 04:04 |
| jwitko | I know how to literally avoid the issue by implementing a process around it | 04:05 |
| jwitko | but i'm trying to guard rail people who don't pay attention | 04:05 |
| === junaid1 is now known as junaidali | ||
| Mynard | so I'm entering day 3 of trying to get openstack deployed on MAAS as a POC to replace the existing M$ HyperV "private cloud". | 06:28 |
| Mynard | just doesn't seem like the components are all playing nicely together. | 06:28 |
| Mynard | currently using 16.04 LTS, should I maybe go back to 14.04 LTS? seems counter intuitive though .. | 06:29 |
| === zz_CyberJacob is now known as CyberJacob | ||
| mup | Bug #1643838 opened: ureadahead trying to read entire filesystem <landscape> <MAAS:New> <https://launchpad.net/bugs/1643838> | 10:57 |
| mup | Bug #1643838 changed: ureadahead trying to read entire filesystem <landscape> <curtin:New> <MAAS:Invalid> <https://launchpad.net/bugs/1643838> | 14:22 |
| === a0rora is now known as garym | ||
| apoz | Hi | 15:29 |
| apoz | I'm a newbie with MAAS | 15:29 |
| apoz | and I'm having some trouble to make it work | 15:29 |
| apoz | (the rackd is asked for the pxelinux.0 image from a client, but it does literally nothing) | 15:30 |
| apoz | how could I set debug logs in rackd? | 15:30 |
| apoz | Is there anything I have to do for the rackd to download the boot images? (I installed everything in a single node with apt install maas) | 15:32 |
| roaksoax | apoz: have you downloaded images | 15:33 |
| roaksoax | apoz: i.e. logged into the UI and downloaded the images you need ? | 15:33 |
| apoz | yes, I think so | 15:34 |
| roaksoax | apoz:what do you mean "it does literally nothing" ? | 15:34 |
| apoz | It just shows "pxelinux.0 requested from XXXXXXXX" | 15:34 |
| apoz | and the client times out | 15:34 |
| apoz | but it does not show any error in the log or anything | 15:35 |
| apoz | just that line everytime the client reattempts | 15:35 |
| apoz | (in the status is 'synced' of my images in the web CLI it means they are downloaded?) | 15:36 |
| apoz | (the dot in the image for 16.04 is green, so I'm assuming images are OK) | 15:36 |
| apoz | is there any way to boot the rackd with debug logs so I can investigate further? | 15:43 |
| jhegge | sweet | 15:45 |
| apoz | ? | 15:56 |
| mup | Bug #1643939 opened: UI shows custom boot source selected and incorrect boot source selections but CI shows seemingly valid resources <MAAS:New> <https://launchpad.net/bugs/1643939> | 16:07 |
| jhova | roaksoax got my issue worked out, thanks | 17:32 |
| jhova | Is there a python client available that supports maas v2 api? | 17:33 |
| jhova | or a client in any language would work | 17:33 |
| roaksoax | jhova: there is theolder client library, python-maas-client | 17:36 |
| roaksoax | jhova: but we are working on a new one | 17:36 |
| jhova | yeah, says it only supports v1 | 17:36 |
| jhova | ok, thanks | 17:36 |
| deej | Hey gents, I'm running 2.1 and hitting some problems using the CLI to get nodes with a specific tag | 21:02 |
| deej | It keeps telling me I'm trying to using 1.0 API which, as far as I can tell, is not the case | 21:02 |
| deej | $ maas-cli maas-root tag nodes os-cs | 21:02 |
| deej | The 1.0 API is no longer available. Please use API version 2.0. | 21:02 |
| deej | Any advice? | 21:03 |
| kiko | deej, it's a bug likely | 21:04 |
| mup | Bug #1516065 opened: [2.2, 2.1, 1.9] Unable to power manage IPMI if BMC does not support changing boot order <uosci> <MAAS:In Progress by newell-jensen> <MAAS | 21:05 |
| mup | 1.9:Fix Released by newell-jensen> <MAAS 2.1:In Progress by newell-jensen> <MAAS trunk:In Progress by newell-jensen> <https://launchpad.net/bugs/1516065> | 21:05 |
| deej | kiko: So I'm assuming my best bet is to access the API directly? | 21:06 |
| kiko | deej, well.. roaksoax, blake_r: ^^ | 21:09 |
| roaksoax | deej: use 'maas' not maas-cli | 21:16 |
| roaksoax | deej: and maybe you have logged into 1.0 api | 21:16 |
| deej | roaksoax: They return the same | 21:17 |
| roaksoax | maas login admin http://192.168.10.27:5240/MAAS/api/2.0/ | 21:17 |
| kiko | uhh | 21:18 |
| kiko | what is maas-cli? | 21:18 |
| roaksoax | kiko: that's the package name. maas-cli forwards to maas for backward compat | 21:18 |
| roaksoax | deej: maas --help | 21:18 |
| kiko | gotcha | 21:18 |
| roaksoax | deej: you shoudl see something like: | 21:18 |
| roaksoax | changepassword | 21:18 |
| roaksoax | Change a MAAS user's password. | 21:18 |
| roaksoax | admin Interact with http://192.168.10.27:5240/MAAS/api/2.0/ | 21:18 |
| deej | roaksoax: Ah! | 21:19 |
| deej | I had a leftover .maascli.db from maas 1.9 | 21:19 |
| deej | Nuking that and re-logging in did the trick, ta | 21:19 |
| mup | Bug #1644014 opened: maas 2.1 CLI does not allow listing of nodes with a specific tag <MAAS:New> <https://launchpad.net/bugs/1644014> | 21:20 |
| deej | That was me, Ill close | 21:20 |
| kiko | roaksoax, the .maascli.db file being left over and not warned is a bug though, is it not? | 21:26 |
| kiko | deej, ^^ | 21:26 |
| zeestrat | roaksoax:, what's the status on some kind of backup/restore utility or | 21:27 |
| zeestrat | * or some docs on that. | 21:27 |
| deej | kiko: Interesting point, I'm not sure you can clean that up per se, but the maas2 CLI could certainly warn if it found one | 21:30 |
| deej | Presumably anyway | 21:30 |
| jwitko | hi all, I just accidentally upgraded from maas 2.0 to maas 2.1 | 21:41 |
| jwitko | is there any way to reverse this process? | 21:41 |
| jwitko | the database seems to be in-tact | 21:41 |
| jwitko | I have an HA setup, will the failover process still work after an upgrade>? | 21:41 |
| jwitko | roaksoax, not sure if you're around but could really use your help | 21:43 |
| mup | Bug #1644014 changed: maas 2.1 CLI does not allow listing of nodes with a specific tag <MAAS:Invalid> <https://launchpad.net/bugs/1644014> | 21:50 |
| roaksoax | jwitko: not sure I follow. you have a MAAS in active/passive | 21:53 |
| roaksoax | jwitko: and you upgraded 1t to 2.1 | 21:53 |
| roaksoax | but not the other ? | 21:53 |
| jwitko | yes | 21:57 |
| jwitko | that is correct | 21:57 |
| jwitko | roaksoax I'm looking for a way to roll back | 21:58 |
| jwitko | and if i can't then at least to fail-back | 21:58 |
| jwitko | it appears my curtin file is not happy in 2.1 either | 22:25 |
| jwitko | "main_archive_hostname" is no longer defined? | 22:25 |
| roaksoax | jwitko: what does your curtin file look like ? | 22:31 |
| jwitko | It had some apt sections that were using variables from 2.0.0 that apparently no longer work in 2.1.1 | 22:45 |
| jwitko | i removed it and will deal with apt sources after the fact | 22:45 |
| jwitko | roaksoax, I'd prefer at this point to move forward on 2.1.1 but I'm having an issue with the API | 22:46 |
| jwitko | POST queries are returning "TypeError: 'Machine' not iterable" | 22:46 |
| jwitko | http://paste.ubuntu.com/23519335/ | 22:47 |
| jwitko | roaksoax, here is another issue in the curtin file regarding enabling HTTP proxy if its enabled within maas http://paste.ubuntu.com/23519338/ | 22:49 |
| jwitko | that worked in 2.0.0 | 22:49 |
| roaksoax | jwitko: ok, i jnow what that is | 22:57 |
| roaksoax | jwitko: id suggest you remove that whole snippet | 22:57 |
| jwitko | which one? the API or the Apt proxy stuff? | 22:57 |
| roaksoax | jwitko: it should just work without | 22:57 |
| jwitko | ok I've removed it | 22:57 |
| jwitko | any idea on those API errors>? | 22:57 |
| jwitko | I am getting them left and right | 22:58 |
| roaksoax | jwitko: no. do you have the call you used that showed those erros | 22:58 |
| jwitko | getting that now | 23:01 |
| jwitko | but its just standard POST calls | 23:01 |
| jwitko | roaksoax, here http://paste.ubuntu.com/23519387/ | 23:02 |
| jwitko | and here is another one that fails | 23:02 |
| jwitko | http://paste.ubuntu.com/23519388/ | 23:02 |
| jwitko | here is how the URL is generated http://paste.ubuntu.com/23519392/ | 23:03 |
| jwitko | on about 60-70% of requests I receive the error | 23:06 |
| roaksoax | jwitko: strge, | 23:16 |
| roaksoax | ltrager: ^^ any ideas? | 23:16 |
| ltrager | roaksoax: hmm not sure, trying to reproduce | 23:21 |
| ltrager | jwitko: I think part of the problem may be you're running in HA with 2.0 and 2.1. 2.1 brought in some data migrations which 2.0 may not be able to handle | 23:23 |
| jwitko | ltrager, we were getting the error in 2.0.0, the upgrade was an attempt to fix it | 23:27 |
| jwitko | but i didn't mean to go to 2.1, just to the latest 2.0.0 | 23:27 |
| jwitko | but that being said, it is the same exact error/message from 2.0.0 | 23:28 |
| ltrager | jwitko: did any region get upgraded to 2.1? | 23:28 |
| jwitko | ltrager, not sure what you mean? | 23:29 |
| jwitko | one region and one rack controller were upgraded | 23:29 |
| jwitko | they live on the same host | 23:29 |
| jwitko | the other host, which has a region and rack controller as well, were not upgrade | 23:29 |
| ltrager | jwitko: as part of the upgrade process MAAS runs database migrations. When running in HA mode all regions access the same database. So if one region was upgraded to 2.1 the database is now using a 2.1 format | 23:30 |
| ltrager | jwitko: that could cause problems if an older version of MAAS is trying to connect | 23:31 |
| ltrager | jwitko: all region and rack controllers in your system should be at the same version | 23:31 |
| jwitko | alright | 23:32 |
| jwitko | let me upgrade the other | 23:32 |
| ltrager | roaksoax, jwitko: btw I hacked together a script to list machines 100 times and I'm not seeing any errors | 23:38 |
| jwitko | ok 2nd rack and region controller updated | 23:45 |
| jwitko | both have status green | 23:45 |
| === CyberJacob is now known as zz_CyberJacob | ||
| nate_ | Hello! Could I get a hand configuring Juju for MAAS behind a corporate proxy? There seems to be very limited documentation available for the latest versions. | 23:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!