Posts made by dholtz-docbox

@Tom-Elliott : Okay. Let me purge this log and get a clean log for you.

-Dustin

Yeah, that was what the output below was from, actually.

#!ipxe
set fog-ip 10.1.10.42
set fog-webroot fog
set boot-url http://${fog-ip}/${fog-webroot}
exit

edit: I hit ‘s’ to enter PXE before booting, otherwise it stated that chainloading failed…

-Dustin

@Tom-Elliott : After executing boot.php. Let me go take a picture of it with my phone.

-Dustin

@Tom-Elliott : Correct.

-Dustin

I see where it chains into boot.php in the /tftpboot directory, but am fumbling around determining what it is trying to chain into next still. I feel like this is the end of its chain, but it doesn’t realize it - when using exit.

edit: I stumbled across the following document and am trying it: https://wiki.fogproject.org/wiki/index.php?title=Boot_looping_and_Chainloading

-Dustin

First, we aren’t quite there yet. Second, things have progressed I believe.

boot.php now returns…

#!ipxe
set fog-ip 10.1.10.42
set fog-webroot fog
set boot-url http://${fog-ip}/${fog-webroot}
exit

However, there is still a chain-loading issue. I am unsure if this is in the boot class or not - I assume it is, given its proximity. That said, I am not sure at what step it has a chain-loading issue yet.

edit: I am still using RC11, should I try pulling down the dev-RC12 branch in its entirety and applying it?

-Dustin

Oh, awesome! Let me give it a whirl!

-Dustin

I am going to perform a test, defaulting it to ‘exit’ in the event that the type is unknown. I will be right back.

edit: Well, that certainly eliminated the hangup, but the system fails during chain-loading now and enters a reboot loop.

-Dustin

Did it get removed at some point? Looking at the GIT trunk reflects this as well: https://github.com/FOGProject/fogproject/blob/2718a13d2bd11d4d9ccd4be7f2f005a67000da3e/packages/web/lib/fog/bootmenu.class.php. What should it be updated to reflect? Because exit is not present in the array, I believe it hits @ l.339 …

        if (!$exit || !in_array($exit, array_keys(self::$_exitTypes))) {
            $exit = 'sanboot';
        }

… and defaults to sanboot instead of the selected exit type.

-Dustin

So I took a look at what service/ipxe/boot.php did, and had a question/concern looking at lib/fog/bootmenu.php. In the constructor, _exitTypes is defined as…

self::$_exitTypes = array(
            'sanboot' => $sanboot,
            'grub' => $grub['basic'],
            'grub_first_hdd' => $grub['basic'],
            'grub_first_cdrom' => $grub['1cd'],
            'grub_first_found_windows' => $grub['1fw'],
            'refind_efi' => $refind,
);

Shouldn’t this also include the ‘exit’ type? I was trying to determine why it ignored my request for the ‘exit’ type in lieu of ‘sanboot’, and wasn’t sure if this was why just yet. I am still reading through the code to better understand the process though.

-Dustin

Server

• FOG Version: 1.3.0-RC11
• OS: Ubuntu 14.04

Description

When this system boots into PXE and has no tasks, it hangs after prompting, “Boot from SAN device 0X80.” I have read several articles related to resolving this, and they have not been very successful.

For starts, here is the output of: fog/service/ipxe/boot.php?mac=…&arch=x86_64…

#!ipxe
set fog-ip 10.1.10.42
set fog-webroot fog
set boot-url http://${fog-ip}/${fog-webroot}
sanboot --no-describe --drive 0x80

I have configured everything to boot with EXIT, so I am not sure why it is still trying to boot with SANBOOT either.

I have…

• Configured everything to boot with EXIT, but the host seems unaffected
• Checked the SATA configuration - it is set to IDE
• Checked the BIOS for SECURE BOOT - there is no option for SECURE BOOT

Another item to note, the system has two drives. Would drive ordering matter? Only one drive has a bootable OS, and has no issue booting without going through PXE.

This will probably be my next test, changing the drive boot order - we boot off the second drive, for this system.

edit: The boot order is irrelevant. I am also currently reading through: https://forums.fogproject.org/topic/5607/stuck-uploading-image-booting-from-san-device0x80 - it has been the most relevant so far.

-Dustin

Very cool, thanks! I set the image type back to Single Disk - Resizable and everything is kicking off like I would expect now.

-Dustin

Server

• FOG Version: 1.3.0-RC11
• OS: Ubuntu 14.04

Description

I am trying to image a machine with multiple drives and partitions on it. This drive is configured such that /sda is the data drive and /sdb is the primary drive everything runs from. Is there a process for JUST imaging the second drive?

When editing the image properties, I see that it allows me to specify the partition. I have tried setting this to both Everything and just partition 2. I have also tried options 1-3 for the Image Type as well. Options 1 and 2 fails, prompting that the partition tables were invalid. If I capture the disk with option 3, multiple partitions multiple disks, then no information is generated for disk 1 - I have information for disk 2. As such, when you go to deploy the image, it fails because it is missing disk 1’s MBR - which is true, if I navigate to /images directory for the image assigned to the host in question.

I thought about editing the contents of the /images directory to reflect what I wanted them to, but I wasn’t sure what the repercussions would be - not that the solution is ideal, just that it would let me know what is possible.

Thanks!

-Dustin

I had to table these efforts, as I have been unable to successfully clone and deploy an extended linux image without having the swap drive hiccup during the cloning/imaging process. I will return to this as soon as time permits, but I have a few tentative workarounds for this milestone.

-Dustin

@Tom-Elliott : What is the best way for me to learn what I can do in the FOS? I couldn’t locate a primary resource on the FOG wiki regarding it and its available functionality. I wouldn’t mind knowing more about how people use this side of FOG, it is starting to feel like it’s the strongest tool in the whole arsenal.

Also, I was able to capture + deploy the image fine if I used the physical partitions name in lieu of the UUID.

/dev/sda5, none, swap, sw, 0, 0

My primary concern in this solution is the what-if scenario. Should I be concerned about whether this link will change on its own? That would be my primary concern, correct? Someone changing the sym-link between /dev/sda5 and its underlying UUID?

Thanks for going back-and-forth with me on this. I don’t have a lot of people to talk with about topics like this.

-Dustin

@Tom-Elliott :

Oh, that’s awesome! I am still learning how to do more with the system through shell scripts, so this is very cool to read through. I will update my current script to reflect this and give it a whirl. It might not be the best solution, but I can figure out another solution if this one works for this particular milestone.

-Dustin

Setting the image to “Multiple Partition Image - Single Disk (Not Resizable) - (2)” did not work either.

I guess what stumps me is why I am having this issue, or what I need to do to avoid it. There isn’t even anything special about the drive I am imaging, it’s just a fresh installation of Ubuntu 14.04 Desktop. How do you guys generally configure your swap partition? Linux needs this swap partition, so it is awkward to me that I am not seeing more resources on this issue while having received it so easily.

I am trying to avoid the post download scripts solution at the moment, and am looking into other ways of configuring the system before imaging. At the moment, I have tried just using the physical name in lieu of the UUID for the swap drive and am testing this as I write this.

I will continue posting my progress.

-Dustin

Testing this today - had to leave work last night. I am hoping this will solve it. It feels promising, heh.

-Dustin

@mrayzies :

Oh. My. Gosh. I have been using Single Disk - Resizable this whole time! I thought this was the correct configuration, one DRIVE, which is resizable for each partition. When did this change, out of curiosity? When I first downloaded the FOG Project, I swear the multiple partition selection did not exist. This has me wicked excited! I was just about to go home too. Time for one more test!

-Dustin

@Tom-Elliott :

Each of our machines look similar to…

# / was on /dev/nvme0n1p2 during installation
UUID=61d640da-5df9-4a71-b6bc-cc28d8a8c9c8 /               ext4    errors=remount-ro 0       1
# /boot/efi was on /dev/nvme0n1p1 during installation
UUID=030B-0954  /boot/efi       vfat    defaults        0       1
# swap was on /dev/nvme0n1p3 during installation
UUID=f0207d3c-a9b2-492e-93ca-fe37a59473d6 none            swap    sw              0       0

Are you saying that I can just change these to…

# / was on /dev/nvme0n1p2 during installation
/dev/nvme0n1p2 /               ext4    errors=remount-ro 0       1
# /boot/efi was on /dev/nvme0n1p1 during installation
/dev/nvme0n1p1  /boot/efi       vfat    defaults        0       1
# swap was on /dev/nvme0n1p3 during installation
/dev/nvme0n1p3 none            swap    sw              0       0

… and be good-to-go? Then image with the drives labeled as such, instead? I have been looking around for more details on doing something like this, but all I can find are people who lost their drives UUID and need to re-assign it. It’s overwhelming the amount of issues people have in simply manually assigning it, it really drowns out any other questions about fstab and what you can do with it and when.

-Dustin