plotly
Figure label auto-positioning
This is a customer requested feature. In both R and MatPlotLib there are extensions which allow figure labels to auto-position for readability by preventing overlap. See gif below.
It is possible to acheive this effect in MatPlotLib and R
At least one customer has requested, and it's a feature which is not possible for a client to easily implement by themeselves. Current label positioning options are not dynamic in this way, and as a result we don't see a lot of client figures using labels, especially when there are more than a few points on the figure. Most clients default to hover, but that isn't viable for everyone, especially in settings where apps are being viewed on different devices. It's potentially also an accessibility improvement.
Launching a VM manually with the ISO files works fine, the same configs as yesterday are failing, so the image seems to be isolated to the base images that AL is creating.
I guess it is not a bug in AL as we would have faced the issue somewhere else then.
What happens if you create a differencing disk based on one of the AL base disks using the Hyper-V management tools and use that in a new VM you create with the Hyper-V tools as well?
Same issue. Created a differencing disk from the base image and then created the vm from the differencing disk and it gives me the same error.
If i use the ISO file that is being used for the base image then the machine boots fine, so the problem appears to be somewhere between it going from ISO to AL making the base image.
What generation is your new VM from? And what generation is the machine you created with AL? The hard disc layout for gen1 and gen2 is different.
Is there a way to check the BASE image and see if AL (or hyper-v cmdlets) thinks it should be compatible or maybe provide a more verbose error on why the image is failing?
Or is there a way to force AL to boot from the ISO and not perform the base image build, since I know it works from the ISO?
Or is there a way to force AL to boot from the ISO and not perform the base image build, since I know it works from the ISO?
No, base images are required.
Is there a way to check the BASE image and see if AL (or hyper-v cmdlets) thinks it should be compatible or maybe provide a more verbose error on why the image is failing?
This is happening within the OS and we have no control of the error message.
Just to double check: If you remove all base images and start a simple deployment of a Gen 2 machine, you get the error shown in the screenshot, right?
Yes I have tried new base images, new isos, other operating system versions (you are seeing win 10 evaluation above but have tried all server versions for eval). If I use AL then I get this error in all cases now. A few days ago it was only every now and again, and then I would remove the base and lab and then try again and would be fine.
Then we need to take a closer look at the base disc. I'll make a Gen 1 and a Gen 2 tomorrow to see the differences. It's been too long to know off the top of my head.
I am going on holiday for the next 2 weeks so I wont be able to respond until the 23rd btw but pls do keep open, I would love to get this sorted and be able to use AL. Thanks!
I am back now and this is still occurring, any help in debugging would be appreciated.
Sorry, @PhilKeeble, I was on vacation for quite a while. Did you solve the issue in the meantime?
No worries, I did not. Strangely if I deploy a windows vm in hyperv and allow nested virtualisation I can use that vm to use automatedlab. I have tried getting rid of AL completely, downgrading it, reinstalling it, but if I do it on my base hyper-v instance it just won't launch from the disks it creates which is very strange, but does appear to be isolated to some factor on my machine (although I have no idea what).
Honestly, having the exact same issue. Another person in my org is also having problems, but I can create the VMs on another machine. Thinking this may be related to a security setting, but haven't tracked it down.
Comparing VMs that are working to the VM that is not, the boot settings are different. Working machines have their firmware set to Boot from file
Non-working VMs have the firmware set to boot from Hard Drive, pointing to the differenced disk. I don't believe this is an issue with AL at all.
EDIT:
Confirmed the SHA256 hash of the BASE_Windows11EnterpriseEvaluation_10.0.26100.1742_50.vhdx from the working machine is different than the hash of the base image on the non-working machine. Additionally, transferring the base VHDX from the working machine to the non-working machine and re-deploying the lab results in the VMs booting appropriately.
I have seen the same as mentioned above, with bases being built on a nested hyperv instance working. I have now just got a nested hyperv for building the bases then copying them out to the host and running the labs from there. Interestingly I have now seen this issue occur for all members of my team that are trying to use AutomatedLab. These are on corporate machines so I am wondering if it is due to some other setting on the system, as it does reliably work in the nested hyperv with no controls on it.
This issue has been automatically marked as stale because it has not had activity from the community in the last 30 days. It will be closed if no further activity occurs within 10 days. If the issue is labelled with any of the work labels (e.g bug, enhancement, documentation, or tests) then the issue will not auto-close.
![stale[bot] avatar](https://avatars.githubusercontent.com/in/1724?v=4 "Published by a pub.dev verified publisher"){kind=small}
I'm having the same experience. @PhilKeeble I think this is a sound suggestion. I'm on a corporate laptop and would not be surprised if some GPO setting is interfering. I have no idea what it could be though. I'll keep digging in that direction though and report back if find anything. Would love to be able to start using automate lab but have not had any luck so far :(
This issue has been automatically marked as stale because it has not had activity from the community in the last 30 days. It will be closed if no further activity occurs within 10 days. If the issue is labelled with any of the work labels (e.g bug, enhancement, documentation, or tests) then the issue will not auto-close.