Posts made by Eruthon

Eruthon

Good day,

I would like to ask if it’s possible to change the way progress bar data are shown visually.
I imagine it being centered (and properly contrasted against background colors) within the whole progress bar, not just the green part.

Reason: e.g. if I create a task with WOL on remote PC, I’d like to see the required time for the task as soon as it begins, not 5 minutes after the numbers are more apart and readable.

Can it be somehow edited manually in an easy way by me? Or would it be better to wait for FOG 1.6 (in case it’s being polished in that version)?

Eruthon

@george1421 Great, thank you

Eruthon

Your guidance has been very helpful and spot on. It works exactly as I wanted: the grubx64.efi is now shown in rEFInd menu after “Booting…”

But if I understand correctly, wouldn’t editing only the original refind.conf file by adding Debian option solve the problem, too? Maybe it could be added to the next release of FOG out of the box, because Ubuntu is already there.

Eruthon

Re: IPXE exit not lauching BIOS UEFI next boot option

I have similar problems as the one above.

Is there a way to reconfigure settings for the EXIT method to boot Linux instead of Windows?

I want to boot grub as default, from there have grub configured to start Win10 (Windows Boot manager) as default (as Win10 doesn’t allow booting Linux from its Manager).
My UEFI boot order is:

UEFI IPv4 PXE
Debian grubx64.efi
Windows Boot Manager

If I choose:

REFIND-EFI Exit Type, the PC boots into Win10 automatically
EXIT Exit Type, the PXE boot says “Chainloading failed”

Eruthon

@sebastian-roth, it’s working! Managed to deploy the image from 1TB to 240GB, hopefully it will work for others, too. Thank you verymuch for your time! Should I post some files here for reference?

Eruthon

@sebastian-roth, thank you, files downloaded and ready, will report back with results tommorow!

Eruthon

@sebastian-roth In the heat of the moment I tried to edit the data partition size in that file to try it that way; I didn’t think it would work, but tried it as last resort. The issue persisted, also the log during deploying showed the same amount of blocks that were problematic because of smaller disk size.

Sadly I didn’t back up the original file, but before the change I saw that the d1.partitions had the same values as the d1.minimum.partitions, so I copied the values from d1.partitions back after trying the mentioned experiment.

d1.minimum.partition for the new 21H1 image:

label: gpt
label-id: D7496BEB-B8A7-4BDA-84D1-A924BDEB9789
device: /dev/nvme0n1
unit: sectors
first-lba: 34
last-lba: 1953525134
sector-size: 512

/dev/nvme0n1p1 : start=        2048, size=      204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=25DAF354-4243-415E-9163-8AA61F158BBC, name="EFI system partition", attrs="GUID:63"
/dev/nvme0n1p2 : start=      206848, size=       32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=3C51C90A-87D5-4C14-9D3E-378D17FF0882, name="Microsoft reserved partition", attrs="GUID:63"
/dev/nvme0n1p3 : start=      239616, size=    77211472, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=EE6CC19C-A52C-4909-B57D-E2915E54BB55, name="Basic data partition"
/dev/nvme0n1p4 : start=  1952640000, size=      884224, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=17790088-AF7B-4D4B-B155-8C7E9DAFE516

The starting lba of the partition 4 is the same as in the posts of the 20H2 image you can see in my earlier posts. My point is I don’t see any differences between the working 20H2 image and the new 21H1 image, except for the size of the data partitions which is, ofc, expected.

Also I wonder if the name of the issue here could be changed as it’s not longer a suitable name for the problem here. Could be changed to sth regarding the gpt partitions, so it wouldn’t sound like a problem with the PC model mentioned in the title.

Eruthon

After some time I tried to deploy new Win10 21H1 image with some pre-installed software again with UEFI and GPT… also using the new init… sadly it didn’t capture the partitions correctly again… lost my nerve, so didn’t try the debug mode, but will try next week

Eruthon

@sebastian-roth
Thank you for the appreciation!

Also maybe I just overlooked something, maybe edited wrong host, as I had multiple tabs and didn’t keep track of it. Otherwise I don’t see any other reason for it not working on the first try.

Eruthon

@sebastian-roth
Changed the host properties:

Scheduled as debug task:

iPXE initializing:
IMG20210512150857 (Medium).jpg

Variable dump from FOG:
IMG20210512150930 (Medium).jpg

FOG prep:

Moving of nvme0n1p4; the partition 4 in the “after” table has corrected start address:

Partclone:

Also the d1.minimum.partitions looks correct:

label: gpt
label-id: D7496BEB-B8A7-4BDA-84D1-A924BDEB9789
device: /dev/nvme0n1
unit: sectors
first-lba: 34
last-lba: 1953525134
sector-size: 512

/dev/nvme0n1p1 : start=        2048, size=      204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=25DAF354-4243-415E-9163-8AA61F158BBC, name="EFI system partition", attrs="GUID:63"
/dev/nvme0n1p2 : start=      206848, size=       32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=3C51C90A-87D5-4C14-9D3E-378D17FF0882, name="Microsoft reserved partition", attrs="GUID:63"
/dev/nvme0n1p3 : start=      239616, size=    61985414, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=EE6CC19C-A52C-4909-B57D-E2915E54BB55, name="Basic data partition"
/dev/nvme0n1p4 : start=    62225408, size=      884224, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=17790088-AF7B-4D4B-B155-8C7E9DAFE516

Edit:
Now I’m triying to deploy it to the smaller SSD and it works so far… interesting that I didn’t change anything since when it wasn’t working.

Edit:
It succesfully deployed the image to the SSD and Windows booted without problems.

Eruthon

@sebastian-roth
I tried the new init.xz (named it init-new.xz) and created new image, I used the Host Init option on both the source PC and destination PC; capturing went smoothly, but deploying to the smaller disk didn’t, it’s showing the same error with Partition 4:

Here’s the d1.minimum.partitions file:

label: gpt
label-id: D7496BEB-B8A7-4BDA-84D1-A924BDEB9789
device: /dev/nvme0n1
unit: sectors
first-lba: 34
last-lba: 1953525134
sector-size: 512

/dev/nvme0n1p1 : start=        2048, size=      204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=25DAF354-4243-415E-9163-8AA61F158BBC, name="EFI system partition", attrs="GUID:63"
/dev/nvme0n1p2 : start=      206848, size=       32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=3C51C90A-87D5-4C14-9D3E-378D17FF0882, name="Microsoft reserved partition", attrs="GUID:63"
/dev/nvme0n1p3 : start=      239616, size=    61921776, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=EE6CC19C-A52C-4909-B57D-E2915E54BB55, name="Basic data partition"
/dev/nvme0n1p4 : start=  1952491908, size=      884386, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=17790088-AF7B-4D4B-B155-8C7E9DAFE516

Eruthon

@sebastian-roth
I found out it could be a problem with the new Windows 10 2004 and 20H2, where the Recovery partition causes problems discussed in this thread.

Today we tried to deploy an image with Windows 10 20H2 from 1TB NVMe to 240GB SSD, and it didn’t work until we shrank the Windows data partition to lower volume than ~240GB (we shrank to ~100GB) and moved the Recovery partition right after the data partition with Hiren’s Boot and AOMEI Partition Assistant, uploaded it and deployed it succesfully.

Tommorow I could try the new init file shared in the mentioned thread and post the result here.

Eruthon

Hi,

this week at work we wanted to upgrade 2x Acer Z3-605 AiO from 500GB HDDs to 240GB SSDs. Systems were installed with Win10 with GPT partitioning and UEFI boot.

We tried file ipxe.pxe with IPv4 Network Stack iPXE, which resulted in restart before even downloading bzImage.

We changed UEFI to Legacy (and undionly.kpxe) and used this with Single Disk (resizable); it managed to upload everything into the /images/dev folder, but the PC restarted and the task started again in infinite loop. This issue isn’t happening with other PCs, so I don’t think it’s FTP related.

We changed the Single Disk (resizable) to Single Disk - Multiple Partitions (not-resizable) and it managed to upload the image succesfully. Or at least it shows Image Size on Server now. We then resorted to copy with USB partition utilities, because there was not enough time to tackle with it (wasted 2 days with this).

FOG version 1.5.9 stable

So now just for explanation: what could be the problem here?

Eruthon

Great, it works sorry for the bother

Eruthon

@george1421 Thank you, I’ll look into it.

Eruthon

Hi,

is there a possibility to create a snapin to automatically activate Visual Studio Enterprise in already deployed PCs?

Eruthon

Ok, I found out the problem for the virtual test PC - the default bridge in QEMU386/KVM bridge system in virt-manager didn’t work with multicast, so we used brct-util explicitly adding bridge interface.

addbr brctl br143

In /etc/network/interfaces file:

auto lo
iface lo inet loopback

auto eno1.143
iface eno1.143 inet manual
    vlan-raw-device eno1

auto br143
iface br143 inet static
    bridge_ports eno1.143
    address X.X.143.23
    netmask 255.255.255.0
    gateway X.X.143.254
    bridge_hello 2
    bridge_maxage 12
    bridge_stp off
    bridge_fd 9
    up /sbin/ifconfig $IFACE up || /bin/true

Checking setting by “ip a”:

1: lo: ...
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:22:19:c7:18:8b brd ff:ff:ff:ff:ff:ff
       valid_lft forever preferred_lft forever
3: eno2: ...
4: eno1.143@eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br143 state UP group default qlen 1000
    link/ether 00:22:19:c7:18:8b brd ff:ff:ff:ff:ff:ff
5: br143: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:22:19:c7:18:8b brd ff:ff:ff:ff:ff:ff
    inet X.X.143.23/24 brd X.X.143.255 scope global br143
       valid_lft forever preferred_lft forever

EDIT: it works on every PC in the network! Thanks for all the support, problem solved!

Eruthon

Ok, so I found out why it was showing the “Unable to find image path”… I found out there was an old testing multicast session in the Images->Multicast Image->Current sessions tab, after removing it, it stopped showing the error message.

Nevertheless the testing PC is not getting the image and waits on the PartClone screen.

Eruthon

@Sebastian-Roth Yes, that’s alright…

One thing coming to mind is network settings… on the way from the FOG server to the classrooms we have:

FOG server
DELL blade PC
DELL blade switch
Cisco C3750E L3 switch
Cisco C3560G L3 switch
Linksys switches in every classroom
Classroom PCs

I saw that the Cisco switches should be configured in a way to allow multicast, but we have multicast TV all over the school and we can watch it with VLC player perfectly. Also I could find multicast from FOG in the mroute table of the cisco switch…

Eruthon

@Sebastian-Roth
We have old FOG 1.2.0 server, which was used until this summer, from there I managed to copy the settings and images to the new server.

The new server was firstly version 1.5.8-RC2, now it’s 1.5.9. It’s located on a DELL blade system PC running Debian 10 and there with virt-manager is running main FOG server on Debain 10 on IP X.X.143.101 together with the storage node on IP X.X.143.102.

Also firstly we wanted the main server to not work as a storage, so the main node with all the images would be just the .102 storage node. Then I copied all the images from there to the .101 main server, when I realized that the logs in web interface were coming from the .102 node.
Also until recently I had problems with the interface not coming up without any info, which interface precisely - that was resolved by restarting the virtual machines (all interfaces came up in the logs at startup) and probably by copying those images to the .101 main server (that resolved the problem with 0.00Bi sizes of images on server).

Also this is a vlan environment at school, so almost every PC classroom has its VLAN with maximum of 2 classrooms per VLAN and there are 10-26 PCs per classroom.

On the old 1.2.0 server multicast wasn’t working, but unicast did without any problems. Also the WOL and snapins didn’t work.
On the new server it’s similar, but we’d really like to make the multicast work, because one classroom can take up about 4 hours to download image for all PCs with unicast.

That’s why we made another virtual machine on the PC with main server and storage node with the 143 VLAN to check if the problem would be somewhere in the network, but it’s the same for all PCs around the school for every image.