Out of curiosity, how come this was marked as solved?
Not sure if you noticed but this is an old topic that was marked solved even before you posted. That’s one of the reasons why we keep telling people to open their very own topics and post all their details in that new one. Makes things a lot clearer. If you think a lot of the information is in the old topic, then just link to it from your new one.
Please add details like the exact commands used to prepare the files and version of GParted you use as this might make a difference. As well post if you boot in UEFI or legacy BIOS mode and if it’s a VM setup or on hardware.
Thanks. I have used both of those commands before trying to get it to autostart on boot. I haven’t used them since running sudo systemctl enable dnsmasq , which was the one that got dnsmasq starting on boot for me. Perhaps since I used those commands prior it is all good?
I went through my bash history and saw I almost used sudo systemctl enable dnsmasq I had the syntax messed up though. I used sudo systemctl dnsmasq enable
I am really starting to like Linux. I digress, I am mostly a casual so I doubt I will ever have it on my daily driver but I am thinking about trying it on a laptop. I don’t know though, sometimes, I just like to point and click.
Did I do something out of sequence or something? Why would it create the directory with the mac address name instead of the unique name I listed in the directory?
When everything works as expected the capture goes to the MAC address named directory in /images/dev first. Then when the client sends the final ok to the FOG server it’s moved to /images and re-named. If that did not happen it’s likely the final step has failed. So I suggest you pay close attention to the last messages on the PC/VM’s screen when you capture next time.
From what I can tell, FOG is handling the UUID’s correctly…
Would say so too from what we discovered so far. It’s interesting you can capture/deploy from/to VM<->VM and machine<->machine but not “across”.
For further debugging I suggest to dig into the dracut emergency shell/mode more. First run ls -al /dev/disk/by-uuid/ on the dracut command prompt and post a picture of that here. As well you might also follow the instrcutions printed, run journalctl and look through the log for hints on why it fails booting. Also take a look at the file /run/initramfs/rdsosreport.txt mentioned. Feel free to share the file here and I’ll take a look as well.
Sounds like the initramfs might be generated differently on your VM and bare metal install. Both are missing a driver for the other one. If that turns out to be true you need to find out which one is missing and manually regenerate initramfs with dracut e.g. on your VM before capturing the image to be deployed to hardware.
@mstabrin Good to hear the BTRFS resize code is working for you! Thanks again for your work on this.
For a long time FOG would not move partitions if they were recognized as “fixed” because moving e.g. a recovery partition in the old MBR days would render it useless because of static sector addressing in boot loaders and such. Now as we all move towards UEFI and GPT partition layouts we have updated this logic to handle “fixed” partitions as fixed in size but not fixed in position anymore. For more details read this topic: https://forums.fogproject.org/topic/15025/move-partitions-on-gpt-layouts-need-people-to-test
@sebastian-roth It sure is!
But I love how flexible FOG is with its postinit and postdownload scripts and the API functionality.
I can really create everything I need, really things as complex as this problem here, by simple using the FOS binaries as building blocks.
I have to say that FOG is indeed an amazing product!