@Can-eh-dian11 Where I’ve seen this kernel panic is just after the kernel boots it tries to connect to the initrd file (virtual hard drive VFS: in the error message). This is the init.xz file that gets transferred after bzImage to the target computer. Almost all selections on the iPXE Boot menu calls bzImage and init.xz

Lets see if you manually download the intits from here: https://github.com/FOGProject/fos/releases

Its init.xz and it goes into /var/www/html/fog/service/ipxe directory. Rename the original one first then download this new one. Again its called init.xz

From the linux command prompt you could run these commands.

md5sum /var/www/html/fog/service/ipxe/init.xz
and
md5sum /var/www/html/fog/service/ipxe/init.xz.old

to see if the files are exactly the same.

@pingonicechap

1. What specifically do you have configured on your dhcp server for dhcp options 66 and 67?
2. What device is your dhcp server for the network you want to pxe boot on? (Manufacturer and model)

@terrigan OK now we have something else to check. Once again I’ll say that something strange is going on with this P620.

Now that we know the fog server is on a different subnet, lets run a few more commands.

1. Do you have a device on the target computer’s subnet you can ping?
2. Lets once again go into the shell console of iPXE. Lets run the following command
   dhcp && route
   That should display the message about getting dhcp address again and then it will print the route and gateway info it gets from dhcp. Is the gateway info valid. If your network allows it can you ping the gateway address?

@george1421 said in Lenovo P620:

Is the fog server on the same subnet as the lenovo?

I’m not sure I saw an answer to this. Is the pxe booting computer on the same subnet as the FOG server?

@ITRecords for right now lets execute these two commands.

Pause that for one second: Lets make sure the /images is still mounted on /dev/sdb1. Check the df -h command if /dev/sdb1 is still mounted over /images then continue on.

Rerun the fog installer, that should fix the permissions on the directory. I would rather have the fog installer script fix things than brute force a permission on everything.

IF that doesn’t work then run these commands:

lets make sure the files are owned by fogproject.

chown -R fogproject.fogproject /images
chmod -R 775 /images

That should reset the permissions…

@AxeMeAQuestion22 use this article to resync the fogproject password. Its typically not advised to manually change the fogproject password, but as you see sometimes there is a requirement

https://forums.fogproject.org/topic/11203/resyncing-fog-s-service-account-password?_=1682368252750

@chambie on the fog server linux console key in: file /var/www/html/fog/service/ipxe/bzImage that will tell you what version of the kernel is installed.

@jfenner said in Changing Server IP in VirtualBox?:

I’ll check with our admins, but our environment is fairly rigid.

If you can’t run a second network, then there should be only two places outside of the web ui that you need to update.

1. a hidden file /opt/fog/.fogsettings and /tftpboot/default.ipxe
2. Inside the web ui FOG Configuration->FOG Settings and hit the expand all button. Search for the old IP address and replace it with the new. Press the save button in each section where you find the replaced IP address
3. Then in Storage Nodes -> Default storage node there is an ip address in there.

Once those three have been changed and then rebooted it should work on an isolated network. Its best to rerun the fog installer script but it should work without it as long as if you change the IP address in those locations.

@jfenner It can be a usb ethernet adapter too. It just needs to exist log enough to get FOG installed. When you reinstall FOG it will ask which is the imaging interface, just give it the forever nic card name.

@ITRecords That’s a permission issue.

So in /images/dev do you see a directory name that looks like a mac address?

@terrigan said in Lenovo P620:

First command nets a valid IP address on our network

This is interesting and maddening at the same time. Is the fog server on the same subnet as the lenovo? I can’t quite explain why it gets an IP address but can not ping the fog server. Something is missing here.

@jfenner Can you install a second network adapter for installing fog only? That second network adapter should have internet access where the primary network adapter will not. After fog is installed then you can remove/disable this second network adapter.

@lostitguy We you will need to make up your own fog ipxe menu to specifically call the wipe function.

I am not 100% sure I have the stanza right but it should look like this

Menu Item: fog.wipeit
Description: FOG builtin Disk Eraser Tool
Parameters:
kernel tftp://${fog-ip}/bzImage
initrd tftp://${fog-ip}/init.xz
imagargs bzImage initrd=init.xz root=/dev/ram0 rw ramdisk_size=256000 ip=dhcp web=${fog-ip}/fog/ consoleblank=0 loglevel=4 mode=wipe wipemode=full
imgfetch init.xz
boot ||
goto MENU
Menu Show with: All Hosts

If you ALWAYS want to wipe before a deploy in one step that is also possible but you will need to “hack” the fog deploy script to include the shred command. That is a bit more complicated than creating a fog ipxe menu, but modifying the fog deploy script is not that difficult either. There are just more steps involved.

@lostitguy said in Wiping HD:

Also is there a way to add wipe options to the fog menu to complete the wipe instead of having to register

Yes there is. I looked into dban and it hasn’t been updated since 2015. So it might have issues with nvme drives (I don’t know, just a guess). If its dban or FOG wipe drive we can call it from the FOG iPXE menu. (this is a bit off topic, but I have a tutorial on how to call different OS installers from the FOG iPXE menu here: https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images while the actions will be different its the concept that we will use )

If we want to use FOG Wipe to perform the disk cleaning there are three modes.

nvme = reformat drive
full and normal uses linux shred program, Where full used 3 passes and normal uses 1 pass.
fast wipe uses dd to zero out all of the blocks.

ref: https://github.com/FOGProject/fos/blob/8abc49dfaa17353411698f81115387a3a4f9743e/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog.wipe#L17

For deban its a little different in that we will use the concepts of the previous link for booting different OS installers. If you download the deban iso we can copy the dban.bzi file from the iso image to the /tftpboot directory on the fog server. Then we would create a custom iPXE FOG menu that would look like this:
Menu Item: app.dban
Description: DBAN Disk Eraser Tool
Parameters:
kernel tftp://${fog-ip}/dban.bzi
imgargs dban.bzi nuke=“dwipe --autonuke --method dod522022m” silent vga=785
boot || goto MENU
Menu Show with: All Hosts

Again this will be a two step process,

1. Wipe the hard drive
2. Image the computer using the iPXE Image Deploy menu. You will not need to touch the FOG web ui.

@ITRecords OK very good. That gives me enough of a picture to help out.

Are you linux familiar or no?

I thought I had a tutorial on it but I didn’t add the part if FOG was already installed. https://forums.fogproject.org/topic/11048/moving-fog-s-images-files-off-the-root-partition-2017-edition

The workflow here will be (You might want to make a snapshot/backup of your fog server. There is a potential ~5% you could lose your images if these steps are not followed correctly)

1. Add your new VMDK file (you have it already with /dev/sdb1)
2. Now make a temp mount point to connect your /dev/sdb1 to
   mkdir -P /tmp/img2
3. Lets just make a flag file so we can know a future step works
   touch /tmp/img2/fog.txt
   Prove that we can see the flag file ls -la /tmp/img2
4. Create a partition on the disk. You have already done this since you have /dev/sdb1
5. Now you need to format the partition with a linux disk format. (I can’t tell from the screen shot if its done or not)
   mkfs.ext4 /dev/sdb1
6. Mount this new parttion onto the mount point we created before.
   mount /dev/sdb1 /tmp/img2
7. Now that the mount is complete (and because the /dev/sdb1 partition is blank we should not see the flag file when we list that directory.
   ls -la /tmp/img2 (you should not see the flag file since the new disk is mounted over the top of /tmp/img2
8. If everything is good here, again run the df -h command. Note the utilization of /dev/sda1 in GB. When we run that command you should see the value will be lower in /dev/sda1 and appear in /dev/sdb1
9. Lets move your current images to the new drive
   mv -vf /images/* /tmp/img2 (you should see a verbose output as all of your images and associated files are moved over to your new disk.
10. Once the move is done confirm that the files are in the new path /tmp/img2
    ls -la /tmp/img2 (You should now see files in this directory, confirm you can see files that start with a period)
    df -h (this should now show that /dev/sda1 size should have decreased by the size of /dev/sdb1)
    ls -la /images (this directory should now be empty)
11. If everything is good lets unmount /dev/sdb1
    umount /tmp/img2
12. Now of a small monetary ($$) contribution I’ll tell you how to get your images back.
13. Just kidding, The last step is to mount your /dev/sdb1 to the /images directory (just like we did in the beginning). Lets edit /etc/fstab. Add the following line to the fstab file
    /dev/sdb1 /images ext4 defaults 0 1
    Now save and exit the fstab file.
14. Last step is to tell linux to mount /dev/sdb1 onto /images.
    mount -a
15. If everything worked you should be able to list /images and see all of your files again.
    ls -la /images
16. Running df -h will now show that your root directory ( / ) is mounted on /dev/sda1 and ( /images ) is mounted on /dev/sdb1
17. If you took a snapshot of the VM in the beginning go ahead and commit the changes.
18. You are done.

@lostitguy Sorry about the 20 questions here but I’m trying to dive to an actionable answer.

Do you specifically need a dod or mil standard wipe or is something like a 3 pass random write work?

The wipe (dban or fog) and imaging is currently a three step process. Wipe, reboot, Deploy. If you could do that all from the fog ipxe menu would that work?

Is this a requirement for every system you deploy?

Will you use FOG in a system builder role (image with FOG then never see the hardware again)?

@lostitguy You must have the target computer registered with FOG. When you do go into the host management page, select the target host of interest and open its profile. On the basic tab at the top there is a wipe disk option.

When you deploy that task if the target computer has the fog client installed the target will reboot and then once it reboots and connects to the fog iPXE menu it will begin wiping the hard drive.

If you need something else, please explain.

@ITRecords You need to be a bit more descriptive of the problem you have.

Also provide the output of these commands.
lsblk
df -h
cat /etc/exports

Is this a physical server or virtual?

@lostitguy From a data security perspective FOG does not wipe a hard drive before imaging. FOG destroys the partition tables than lays down a new partition table and data onto the disk.

The term to “wipe a hard drive”, is a specific and intentional action. I might be reading more into your question, but you used a specific trigger phrase.

For example, lets say you had 100GB of data on a hard drive and you reimage with FOG, and your image is 25GB in size. FOG will destroy the partition table and then download 25GB of data back to the hard drive. The data beyond 25 GB is still really on the disk media, but its not accessible unless you use forensic tools. So this data is not securely erased before reimaging.

I want to make a point that there is a difference between securely wiping a HD and simply reimaging make it difficult to access the data. If you need to securely wipe a hard drive fog does have tools to do that, or you can use pxe boot to boot into deban if you need a certificate of destruction type wipe.

@Ax_Hades While this is an english site I will tell you to answer in your native language. We can work out the translation, because I only know english well.

The problem is you never get to the FOG iPXE menu. To solve this you need to look at your dhcp server. From the screen shot your target computer is bios based.
You dhcp server must have the IP address of the fog server in dhcp option 66 and undionly.kpxe in dhcp option 67.
If you checked and the values are there, then I will ask do you have a second dhcp server on your network? For example a backup dhcp server and primary dhcp server?
If Yes, check the setting on your backup dhcp server to make sure the values are set.
If No, what device is your dhcp server for the network?