Posts made by Zerpie

I changed the image to Multiple Partition Image - Single Disk (Not Resizable) and it’s currently capturing it. We’ll have to see if the capture task finishes and if I can then deploy the image without breaking RAID. But it’s at least getting past the part where I’d get the Permission denied error previously.

I’ve been following the thread over here https://forums.fogproject.org/topic/7851/intel-raid0-image-capture in order to figure out how to image some hardware that I have that uses the “fake” Intel RAID. We specifically use RAID 1 on these machines.

Well I found what I needed and I set the image to Single Disk Resizable and set the Host Kernal Arguments to mdraid=true and the Host Primary Disk to /dev/md126. I kick off the capture task, but then I get the error below.

*Mounting partition (/dev/md126p1)...Failed
*Could not mount /dev/md126p1 (removePageFile)
Args Passed: /dev/md126p1
Reason: ntfs-3g-mount: mount failed: Permission denied

Weird that I’m getting permission denied because if I get rid of the mdraid=true and /dev/md126 and just capture the image like a regular non-RAID machine it captures with no issue. Why would these arguments spit out a permissions error?

@Sebastian-Roth I made it to the “Bake The Cake” section and built the simple 32 bit efi binaries. I’m not sure what to do from there.

@Sebastian-Roth said in Tablet PC hangs on bzImage:

Which version of FOG are you running?

1.5.4

@Sebastian-Roth said in Tablet PC hangs on bzImage:

PHP version string showing PHP/5.6.37 - should not be possible to run a recent version of FOG with that PHP version. Please run rpm -qa | grep php and post output here.

# rpm -qa | grep php
php-gd-5.6.37-1.el7.remi.x86_64
php-mcrypt-5.6.37-1.el7.remi.x86_64
php-pecl-jsonc-1.3.10-2.el7.remi.5.6.x86_64
php-5.6.37-1.el7.remi.x86_64
php-ldap-5.6.37-1.el7.remi.x86_64
php-pdo-5.6.37-1.el7.remi.x86_64
php-process-5.6.37-1.el7.remi.x86_64
php-common-5.6.37-1.el7.remi.x86_64
php-cli-5.6.37-1.el7.remi.x86_64
php-bcmath-5.6.37-1.el7.remi.x86_64
php-mbstring-5.6.37-1.el7.remi.x86_64
php-mysqlnd-5.6.37-1.el7.remi.x86_64
php-pecl-zip-1.15.3-1.el7.remi.5.6.x86_64
php-fpm-5.6.37-1.el7.remi.x86_6

Content-Length: 1727680 seems like my kernel image is 4-5 times as big as >yours is. Why? Please run ls -alk /var/www/html/fog/service/ipxe/bzImage*

# ls -alk /var/www/html/fog/service/ipxe/bzImage*
-rwxr-xr-x. 1 fog  fog  8118832 Sep  6 16:21 /var/www/html/fog/service/ipxe/bzImage
-rwxr-xr-x. 1 fog  fog  7562352 Sep  6 16:21 /var/www/html/fog/service/ipxe/bzImage32
-rw-r--r--. 1 root root 1727680 Sep 10 13:23 /var/www/html/fog/service/ipxe/bzImage_debug

I re-added the Host kernel Arguments (debug earlyprintk=efi loglevel=7) and tried the old iPXE binary, but it’s still hanging on BzImage.

@Sebastian-Roth I’m only running one Fog server.

Here’s the hang3.pcap
https://drive.google.com/file/d/1uA54wIeUgPbpduEJZp_RhobKP1Xh4aWq/view?usp=sharing

Here’s the latest file. I made sure it was grabbing i386-efi/snponly.efi this time.

https://drive.google.com/file/d/1Il1L7msBxgOD2ZIPD3oLr4FifenjwT6E/view?usp=sharing

Actually. I just checked the pcap file myself and it looks like it’s still using the ipxe.efi and not snponly.efi. Let me try that again.

@Sebastian-Roth Thank you for that. I went ahead and changed it. It still hangs on BzImage so I went ahead and captured another hang.pcap.

Here’s the link.
https://drive.google.com/file/d/1fX5xdrz0b_SIPogj7eQFtChOyoDhcf-7/view?usp=sharing

@Sebastian-Roth I let it run a little longer this time. Well after it would hang on BzImage_debug…

Here’s the new link.
https://drive.google.com/file/d/154AX_8LHOGKVLBHetWh9-RxihPoj3qFe/view?usp=sharing

I’ll try changing it to use i386-efi/snponly.efi. Where do I change that?

@Sebastian-Roth I’m using CentOS 7. Specifying the network interface worked, though. Here’s a link to the hang.pcap file shared on my Google Drive.

https://drive.google.com/file/d/1SzQGpk4DsDf3yuB2P7AemvxMXzMdcmYf/view?usp=sharing

@Sebastian-Roth When I run the command I get the following

# tcpdump -w hang.pcap host 153.86.19.24
tcpdump: NFLOG link-layer type filtering not implemented

@Sebastian-Roth It’s still hanging on BzImage_debug… and it will usually get to a percentage and stop. Just now it stopped at

BzImage_debug... 15%

No “Hello World” message.

@Sebastian-Roth Now it just hangs on

BzImage_debug...

@Sebastian-Roth Thanks. To be fair, I should have been able to figure that out, myself, but I’m still getting comfortable with Linux.

Alright, I built the kernel. What is the next step?

Thanks again for your help.

@Sebastian-Roth said in Tablet PC hangs on bzImage:

make oldconfig

I got as far as this command but when I run the command I get the following.

# make oldconfig
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/kconfig/conf.o
  YACC    scripts/kconfig/zconf.tab.c
/bin/sh: bison: command not found
make[1]: *** [scripts/kconfig/zconf.tab.c] Error 127
make: *** [oldconfig] Error 2

@Sebastian-Roth Sure! I’m not as familiar with Linux as I’d like to be so bear with me if I have a lot of questions or make some mistakes. But I’m up for doing whatever I can to figure this out. Our office has had a lot of trouble finding a solution to easily image these tablets so that we can quickly get them out to the customers. I’m hoping Fog is going to be the solution that works for us.

Alright I got my equipment to PXE boot again. I had to undo all the changes I made from the BIOS and UEFI Co-Existance wiki at https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence

Apparently my Fog server didn’t like those changes.

I tried imaging the tablet after entering BzImage32 in the Host Kernel on the web interface and it made it past the BzImage portion but then immediately failed with the following.

BzImage32... ok
Could not select: Exec format error (http://ipxe.org/2e008081)
Could not boot: Exec format error (http://ipxe.org/2e008081)
Could not boot: Exec format error (http://ipxe.org/2e008081)

@Sebastian-Roth No, not yet. I’m still having problems PXE booting at all now. I keep thinking I’ve found the issue, but it’s still not PXE booting for any of my equipment. I don’t know what changed. Everything was working fine on Friday. Nobody touched anything over the holiday weekend, and then Tuesday it was no longer PXE booting. I can’t figure out why. Once I’ve got that working again I can test the tablet.

One of the network adapters was disabled. I’ve re-enabled it.