Host Startup; Booting into LVM Disk Fails
-
@dholtz-docbox said in Host Startup; Booting into LVM Disk Fails:
That said, when do you project there being an official release?
I can’t give any date, there isn’t one. That said, I feel like it’s close. We’re in Release Candidate mode, which means no new features, the focus is on bug fixes. The more bugs people report for the devs to fix, the sooner the devs will feel good about releasing.
RC-14 is pretty solid, but it still has some minor issues. And still, people are finding minor issues in it. And they will continue to find minor issues. I would imagine when there’s nothing but crickets for a future RC, that would be when the countdown starts for a release.
-
@Wayne-Workman : Awesome! Yeah, I didn’t expect a date; I was just curious given, as you said, being in RC mode, but wasn’t sure how far into the candidate process the team was given the frequency of candidate releases. Which is always; did they go into candidate mode too soon, or is their DEV team really cranking that hard. I guess it’s the latter though; that’s very exciting to hear! You guys have a solid DEV team over there
-
@dholtz-docbox lol we have a Tom and Joe. Both are superstars.
-
@Wayne-Workman : I would love either/both of them as consultants for even a day, haha. Teach me the ways of your land. This is like… the region of software engineering no one ever wants to touch, and you guys seem to have a great handle on it - which is extremely exciting to see. It’s so hard to resist not just opening a chat and asking a million questions in an effort to absorb their brains, heh.
Alright, updated the FOG Server to RC-14. Rebooting the system and seeing if there is any change by chance.
-Dustin
-
@dholtz-docbox said in Host Startup; Booting into LVM Disk Fails:
I have mixed input on whether or not LVM is supported as of 1.3.0-RC-13, so that would be first question - whether capturing and booting into LVM is supported, at all, currently?
No version of FOG currently supports resizable LVM. FOG does support resizable Ext4. The last time I tried capturing a Linux LVM disk, FOG tried to capture it in RAW mode and I wasn’t having that, I canceled and rebuilt from scratch using Ext4 for every partition.
You’re step 4 and issue with the machine not exiting to disk properly - another person had a similar issue not too long ago. His solution was swapping around the drives so that the OS drive was /dev/sda
Here are related threads:
https://forums.fogproject.org/topic/8708/image-second-disk-on-host-w-multiple-disks
https://forums.fogproject.org/topic/8487/dual-boot-windows-7-opensuse-boot-problemThe Bios Exit Type only applies to machines operating in BIOS mode, as the EFI exit type only applies to machines operating in UEFI mode. That said, sanboot is already the default. You’re free to try other kinds, that’s why they are there. Because no single type works with all systems. Try Grub, then the others. Do a full reboot on the problematic system between each try.
What is /dev/sda being used for? What’s on it? Why can’t the OS disk be /dev/sda ?
-
What is the target hardware? What version is it’s firmware? Make and Model please. What boot file are you using for DHCP options 066/067 next-server and filename.
-
@Wayne-Workman : Haha, that’s funny. Reading that, I am like… I think that person was me!
That resolved the issue when I deployed the captured LVM image to the machine. Unfortunately, when LVM installs, I get these wonky boot options in my BIOS and then it’s like the system has no idea how to boot anymore from SAN. I have discussed it with my team, and we are going to nix LVM next release. It’s just not something we can do this release, as it was something I discovered going through FOG and becoming more intimate with the system at this level.
As far as what /dev/sda is, it’s the data drive. I guess the way this machine was setup - hardware wise - its first drive is the data drive and the second drive is the system drive. Upon discovering this, I asked why, since it only seems to complicate matters. The answer I received was that they tried mounting them different, but Linux always wanted to install them as such - mounting the smaller drive to /dev/sdb instead of /dev/sda. This is kind of where I stepped in and said that doesn’t seem right, can’t we just swap the SATA cables or define it differently when we setup the partitions? It hit an expertise-wall after that, as no one has the domain knowledge for any of this - which is a part of why I am so eager to ask so many questions. Knowing what I know now, I am sure we can handle this ourselves, but we know so little surrounding this that I am cobbling it together while building an insane amount of other tools and tech in parallel.
I had issues copying the drive as EXT4 in the past too. The swap drive would always be mis-aligned I believe, and the system would create a new one and then I’d have fstab issues always. I guess at the end of the day, I don’t feel I have successfully captured and deployed an image, given all the little things. Now I just wonder what I am doing right and doing wrong, given all the successes and failures I have had.
Let me dig up the information you requested. It might be a tomorrow-thing as I am going on 12-hours already and need to get home for misc. life things.
-Dustin
-
PS> I think what trips me up is, I am just trying to find one happy path, and I don’t think that has been revealed yet to me (with our hardware, at least). It’s mind boggling to me the things that do work, when they work, and the things that do not work, and for reasons I am not equipped-enough to handle yet. Even now, understanding as much as I do, I circle back and ask simple questions, such as, why does the swap partition fail to image when deploying an EXT formatted drive. Or, why can I set the system up for LVM, capture and deploy the disk, and only then am I able to boot into ‘/dev/sdb’ with the settings I provided; however, fails to do a simple SANBOOT.
Also, here’s an image of the boot drives post-installation of Ubuntu…
-
Yeah, I have to head home for now. I will get this information ASAP tomorrow or tonight if I can.
-Dustin
-
@dholtz-docbox said in Host Startup; Booting into LVM Disk Fails:
I had issues copying the drive as EXT4 in the past too. The swap drive would always be mis-aligned I believe, and the system would create a new one and then I’d have fstab issues always.
This is known about. Here’s lots of info on that, and options too:
https://forums.fogproject.org/topic/8549/fog-1-3-rc8-fails-to-apply-swap-uuid-on-image-deploy -
@dholtz-docbox San boot releases to the first found HDD, or sda in your case. Exit should release to bios which then finds the disk with the right boot active flag. I’d recommend trying exit first. If this doesn’t work then try grub, though it defaults to first HDD. The best grub would be first found windows but these systems aren’t windows systems.
-
@Tom-Elliott : That’s what I started to think last night, so that makes sense. I wanted EXIT to work as you described, but it throws a chainloading error each time. I am actually going to… just install the drive as EXT4. I mean… /dev/sdb is just /dev/sdb, one way or the other, right? I am hoping the system works fine, and then I can just do single disk targeting the second drive, hoping that it is more reliable.
-
@dholtz-docbox said in Host Startup; Booting into LVM Disk Fails:
I wanted EXIT to work as you described, but it throws a chainloading error each time.
A chainloading error is better than the other stuff you were describing. Let’s focus on that, please provide a photo of the error, and the MAC address of the computer you tried on, and the FOG Server’s IP address.
-
No problem. Let me re-install the system with LVM - I was trying other things in the interim. I will provide an image as soon as that is complete.
-
@dholtz-docbox said in Host Startup; Booting into LVM Disk Fails:
Let me re-install the system with LVM
Nah, please go with Ext4. We will explore the EXIT option with that setup.
-
Unfortunately, I have to move forward with the LVM installation for now. Given the time until our next release, it is too risky to greenlight the change to EXT. That said, I had the same issue with both SANBOOT and EXIT w/ the EXT install, so the problem is similar I feel - wild guess.
I was also hopeful that installing EXT would eliminate the extra boot options in my BIOS. It seems that was not the case, so maybe they are related to Server Edition instead? I just find it odd that, when installing Ubuntu to the disk, that I can no longer boot from the disk and must boot from one of those Ubuntu options. Which one also has relevance, as the other one appears to have no operating system on it. Perhaps it’s the swap?
As far as the other information…
- host mac => 08:60:6e:fa:05:af
- server ip => 10.1.10.42
and here’s an image of the boot output…
-
@dholtz-docbox Ok, in your browser click on this link and give us a copy of the output:
10.1.10.42/fog/service/ipxe/boot.php?mac=08:60:6e:fa:05:af
It appears you have your DHCP server setup for FOG, and you also have dnsmasq setup for FOG? This isn’t necessary. Choose one or the other, I’d suggest using the full DHCP server.
And what boot file are you using again? I don’t think you listed that earlier. You can quickly find this just by looking at what you have set in DHCP option 067.
-
#!ipxe set fog-ip 10.1.10.42 set fog-webroot fog set boot-url http://${fog-ip}/${fog-webroot} exit
-
As far as whether I have DHCP setup for FOG and DNSMasq, I should only have DNSMasq? Is there a way to validate this? The .fogsettings for the server are as follows…
## Start of FOG Settings ## Created by the FOG Installer ## Version: 1.3.0-RC-11 ## Install time: Fri 30 Sep 2016 05:26:11 PM EDT ipaddress='10.1.10.42' interface='eth0' submask='255.255.255.0' routeraddress='10.1.10.1' plainrouter='10.1.10.1' dnsaddress='# No dns added' username='fog' password='{password}' osid='2' osname='Debian' dodhcp='N' bldhcp='0' dhcpd='' blexports='1' installtype='N' snmysqluser='root' snmysqlpass='' snmysqlhost='localhost' installlang='0' donate='0' storageLocation='/images' fogupdateloaded=1 docroot='/var/www/' webroot='/fog/' caCreated='yes' startrange='' endrange='' bootfilename='undionly.kpxe' packages='apache2 bc build-essential cpp curl g++ gawk gcc gzip htmldoc lftp libapache2-mod-php5 libc6 libcurl3 m4 mysql-client mysql-server net-tools nfs-kernel-server openssh-server php5 php5-cli php5-curl php5-fpm php5-gd php5-json php5-ldap php5-mcrypt php5-mysqlnd php-gettext sysv-rc-conf tar tftpd-hpa tftp-hpa vsftpd wget xinetd zlib1g ' noTftpBuild='' notpxedefaultfile='' sslpath='/opt/fog/snapins/ssl/' backupPath='/home/' php_ver='5' php_verAdds='-5.6' sslprivkey='/opt/fog/snapins/ssl//.srvprivate.key' ## End of FOG Settings
Then I have the following dnsmasq.conf…
# Don't function as a DNS server: port=0 # Log lots of extra information about DHCP transactions. log-dhcp # Set the root directory for files available via FTP. tftp-root=/tftpboot # The boot filename, Server name, Server Ip Address dhcp-boot=undionly.kpxe,,10.1.10.42 # Disable re-use of the DHCP servername and filename fields as extra # option space. That's to avoid confusing some old or broken DHCP clients. dhcp-no-override # PXE menu. The first part is the text displayed to the user. The second is the timeout, in seconds. pxe-prompt="Booting FOG Client", 0 # The known types are x86PC, PC98, IA64_EFI, Alpha, Arc_x86, # Intel_Lean_Client, IA32_EFI, BC_EFI, Xscale_EFI and X86-64_EFI # This option is first and will be the default if there is no input from the user. pxe-service=X86PC, "Boot to FOG", undionly pxe-service=X86-64_EFI, "Boot to FOG UEFI", ipxe dhcp-range=10.1.10.1,proxy
Edit> I would be led to believe that only DNSMasq should be handled because of…
dodhcp='N' bldhcp='0'
… no?
-
You had me thinking…
One of the other VM’s on the network I used, at one point, to do an installation, where it setup using FOG’s DHCP. Is it possible something is still lingering on this machine? I am going to shut it off and give it a whack, in the mean time…
Edit> Nope. No difference.