Posts made by glucas

New tests:

1. I deploy myImageV1 on my test workstation with FOG 1.5.9 + init.xz from 2020 (see my previous post)
2. Boot my test workstation on a Ubuntu LiveUSB to change logical partition (sda2) into primary one with fixparts + resize partition with gparted + fsck + grub-install
3. Modify what I want on the system (do system updates, modify the content of a configuration file)
4. Capture from my test workstation to myImageV2 (with FOG 1.5.9 + init.xz from 2020)
5. Deploy my new myImageV2 to my test workstation (with FOG 1.5.9 + init.xz from 2020)
6. The partition is properly expanded

.
AMO, the logical partition (sda2) confuses / puzzles partclone (or an another piece of software).

My new myImageV2structure:

$ ls -lh /images/myImageV2
total 53G
-rwxrwxrwx 1 root root    2 Apr  7 12:58 d1.fixed_size_partitions
-rwxrwxrwx 1 root root    0 Apr  7 12:59 d1.has_grub
-rwxrwxrwx 1 root root 1.0M Apr  7 12:59 d1.mbr
-rwxrwxrwx 1 root root  208 Apr  7 12:59 d1.minimum.partitions
-rwxrwxrwx 1 root root   16 Apr  7 12:58 d1.original.fstypes
-rwxrwxrwx 1 root root    0 Apr  7 12:58 d1.original.swapuuids
-rwxrwxrwx 1 root root 1.7K Apr  7 12:59 d1p1.img
-rwxrwxrwx 1 root root  53G Apr  7 13:31 d1p2.img
-rwxrwxrwx 1 root root  208 Apr  7 12:58 d1.partitions

$ cat /images/myImageV2/d1.fixed_size_partitions 
1

$ cat /images/myImageV2/d1.minimum.partitions
label: dos
label-id: 0x78c7d5cb
device: /dev/sda
unit: sectors
sector-size: 512

/dev/sda1 : start=        2048, size=     1048576, type=b, bootable
/dev/sda2 : start=     1050624, size=   278817898, type=83

$ cat /images/myImageV2/d1.original.fstypes
/dev/sda2 extfs

$ cat /images/myImageV2/d1.partitions
label: dos
label-id: 0x78c7d5cb
device: /dev/sda
unit: sectors
sector-size: 512

/dev/sda1 : start=        2048, size=     1048576, type=b, bootable
/dev/sda2 : start=     1050624, size=   499067392, type=83

After the deployment of my new myImageV2 (all is fine):

root@testwks:~# fdisk -lu /dev/sda
Disk /dev/sda: 238,49 GiB, 256060514304 bytes, 500118192 sectors
Disk model: SK hynix SC311 S
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x78c7d5cb

Device     Boot   Start       End   Sectors  Size Id Type
/dev/sda1  *       2048   1050623   1048576  512M  b W95 FAT32
/dev/sda2       1050624 500118015 499067392  238G 83 Linux

root@testwks:~$ parted /dev/sda print
Model: ATA SK hynix SC311 S (scsi)
Disk /dev/sda: 256GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags: 

Number  Start   End    Size   Type     File system  Flags
 1      1049kB  538MB  537MB  primary  fat32        boot
 2      538MB   256GB  256GB  primary  ext4

root@testwks:~# df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2       234G  123G 100G  56%  

@sebastian-roth

I did a few more tests.

It seems that the version of init.xz is important. So, I tried to get its version number. To do that, I use: 7z x init.xz 1>/dev/null && /sbin/dumpe2fs init 2>/dev/null | grep -E '(UUID|created)'

On my FOG 1.5.7:

Filesystem UUID:          4bf29812-3f33-4d94-9787-76f18704df76
Filesystem created:       Mon Jul 15 19:13:43 2019

On my FOG 1.5.9:

Filesystem UUID:          1c9acfae-b3e6-4506-8ccc-4ffbff7bdfce
Filesystem created:       Sun Sep  6 10:12:57 2020

On my FOG 1.5.9 after upgrading init.xz to version 20220204 (see my previous post): not a filesystem, but the more recent files in the archive are dated Feb 4 2022.
`

With FOG 1.5.7 this exact same image was properly expanded to a larger disk?

About myImageV1 (version 1) created in 2020 on my FOG 1.5.7 with init.xz from 2019:
Deployment with FOG 1.5.7: properly expanded ;
Deployment with FOG 1.5.9 + init.xz from 2020: properly expanded ;
deployment with FOG 1.5.9 + init.xz from 2022-02-04: NOT expanded.

For all my tests (between 2020 and today), I always used the same test workstation (with 256G SSD).

So, yes, the exact same image was (and is) properly expanded to a larger disk (unless the version of init.xz is 2022-02-04).

About myImageV2 (version 2) created in Feb 2022 on my FOG 1.5.9 with init.xz from 2020:
Deployment with FOG 1.5.9 + init.xz from 2020: NOT expanded ;
Deployment with FOG 1.5.9 + init.xz from 2022-02-04: NOT expanded.

Reminder: my steps to create myImageV2:

1. I deploy myImageV1 on my test workstation ;
2. I modify the content of a configuration file and I do system updates (security updates, no change of the Ubuntu version) ;
3. I capture in myImageV2.

.

From what I see so far the extended partition is still expanded but not sda5 on deployment. Right?

Right, except with init.xz 2022-02-04.

MyImageV2 deployed with FOG 1.5.9 + init.xz 2020:

# parted /dev/sda print
Modèle : ATA SK hynix SC311 S (scsi)
Disque /dev/sda : 256GB
Taille des secteurs (logiques/physiques) : 512B/4096B
Table de partitions : msdos
Drapeaux de disque :

Numéro  Début   Fin    Taille  Type      Système de fichiers  Drapeaux
 1      1049kB  538MB  537MB   primary   fat32                démarrage
 2      539MB   256GB  256GB   extended
 5      539MB   143GB  143GB   logical   ext4

MyImageV2 deployed with FOG 1.5.9 + init.xz 2022-02-04:

# parted /dev/sda print
Modèle : ATA SK hynix SC311 S (scsi)
Disque /dev/sda : 256GB
Taille des secteurs (logiques/physiques) : 512B/4096B
Table de partitions : msdos
Drapeaux de disque :

Numéro  Début   Fin    Taille  Type      Système de fichiers  Drapeaux
 1      1049kB  538MB  537MB   primary   fat32                démarrage
 2      539MB   256GB  256GB   extended
 5      539MB   143GB  143GB   logical   ext4

MyImageV1 (yes, version 1) with FOG 1.5.9 + init.xz 2022-02-04:

# parted /dev/sda print
Erreur: Impossible d’avoir une partition en dehors du disque !
Ignorer/Ignore/Annuler/Cancel? Ignore
Erreur: Impossible d’avoir une partition en dehors du disque !
Ignorer/Ignore/Annuler/Cancel? Ignore
Modèle : ATA SK hynix SC311 S (scsi)
Disque /dev/sda : 256GB
Taille des secteurs (logiques/physiques) : 512B/4096B
Table de partitions : msdos
Drapeaux de disque :

Numéro  Début   Fin    Taille  Type      Système de fichiers  Drapeaux
 1      1049kB  538MB  537MB   primary   fat32                démarrage
 2      539MB   500GB  500GB   extended
 5      539MB   144GB  143GB   logical   ext4

MyImageV2 with FOG 1.5.9 + init.xz 2020 (all is fine):

# parted /dev/sda print
Modèle : ATA SK hynix SC311 S (scsi)
Disque /dev/sda : 256GB
Taille des secteurs (logiques/physiques) : 512B/4096B
Table de partitions : msdos
Drapeaux de disque : 

Numéro  Début   Fin    Taille  Type      Système de fichiers  Drapeaux
 1      1049kB  538MB  537MB   primary   fat32                démarrage
 2      539MB   256GB  256GB   extended
 5      539MB   256GB  256GB   logical   ext4

Hello,

In 2020, with my FOG 1.5.7 / Debian 8, I’ve captured an Ubuntu 20.04 workstation (single disk resizable).

In June 2021, I upgraded my FOG to 1.5.9 / Debian 10. Since, my image is still working when I deploy it.

Today, in this image, I need to modify the content of a configuration file and do system updates (security updates, no change of the Ubuntu version).
So I deploy my image on my test workstation, I do my changes, I create a new single disk resizable image on my FOG (because I want to keep my working image), I capture my image “in this new slot”, I deploy it on my test workstation.

At the end of the deployment, FOG prints Resizing extfs volume (/dev/sda5)…………Done but the system partition isn’t expanded (its size is 130 Go on a 256 Go SSD).

I ran fsck -fv from a live CD before retrying a new capture and deployment: fsck sees no errors, but the expand still fails.

I upgraded init.xz and init_32.xz to 20220204 (https://fogproject.org/inits/init.xz) before retrying a new capture and deployment: expand still fails.
I use 5.10.71 bzImage.

I tried zerofree before a new capture and deployment: still fails.

I have read a few threads in this forum, no help.

Reinstall my test workstation from scratch to capture a fresh image would be too expensive in time (several bullshit business softwares, tricky configuration,…).

$ ls -lh /images/myImageV2
total 53G
 -rwxrwxrwx 1 root root    2 Mar  4 19:01 d1.fixed_size_partitions
 -rwxrwxrwx 1 root root    0 Mar  4 18:01 d1.has_grub
 -rwxrwxrwx 1 root root 1.0M Mar  4 18:01 d1.mbr
 -rwxrwxrwx 1 root root  266 Mar  4 18:01 d1.minimum.partitions
 -rwxrwxrwx 1 root root   16 Mar  4 18:01 d1.original.fstypes
 -rwxrwxrwx 1 root root    0 Mar  4 18:01 d1.original.swapuuids
 -rwxrwxrwx 1 root root 1.7K Mar  4 18:01 d1p1.img
 -rwxrwxrwx 1 root root  512 Mar  4 18:01 d1p2.ebr
 -rwxrwxrwx 1 root root  118 Mar  4 18:01 d1p2.img
 -rwxrwxrwx 1 root root  512 Mar  4 18:01 d1p5.ebr
 -rwxrwxrwx 1 root root  53G Mar  4 18:32 d1p5.img
 -rwxrwxrwx 1 root root  266 Mar  4 18:01 d1.partitions

$ cat /images/myImageV2/d1.fixed_size_partitions
1:2

$ cat /images/myImageV2/d1.minimum.partitions
label: dos
label-id: 0x78c7d5cb
device: /dev/sda
unit: sectors
sector-size: 512

/dev/sda1 : start=        2048, size=     1048576, type=b, bootable
/dev/sda2 : start=     1052670, size=   499065522, type=5
/dev/sda5 : start=     1052672, size=   278443872, type=83

$ cat /images/myImageV2/d1.original.fstypes
/dev/sda5 extfs

$ cat /images/myImageV2/d1.partitions
label: dos
label-id: 0x78c7d5cb
device: /dev/sda
unit: sectors
sector-size: 512

/dev/sda1 : start=        2048, size=     1048576, type=b, bootable
/dev/sda2 : start=     1052670, size=   499065522, type=5
/dev/sda5 : start=     1052672, size=   499065520, type=83

After deployment:

root@testwks:~# fdisk -lu /dev/sda
Disk /dev/sda: 238,49 GiB, 256060514304 bytes, 500118192 sectors
Disk model: SK hynix SC311 S
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x78c7d5cb

Device     Boot   Start       End   Sectors   Size Id Type
/dev/sda1  *       2048   1050623   1048576   512M  b W95 FAT32
/dev/sda2       1052670 500118015 499065346   238G  5 Extended
/dev/sda5       1052672 279496543 278443872 132,8G 83 Linux

Partition 2 does not start on physical sector boundary.

root@testwks:~# df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda5       130G  124G     0 100% /

My 2020 / V1 image:

$ ls -lh /images/myImageV1
total 53G
 -rwxrwxrwx 1 fogproject  fogproject    9 Jun 11  2020 d1.fixed_size_partitions
 -rwxrwxrwx 1 fogproject  fogproject    0 Jun 11  2020 d1.has_grub
 -rwxrwxrwx 1 fogproject  fogproject 1.0M Jun 11  2020 d1.mbr
 -rwxrwxrwx 1 fogproject  fogproject  249 Jun 11  2020 d1.minimum.partitions
 -rwxrwxrwx 1 fogproject  fogproject   16 Jun 11  2020 d1.original.fstypes
 -rwxrwxrwx 1 fogproject  fogproject    0 Jun 11  2020 d1.original.swapuuids
 -rwxrwxrwx 1 fogproject  fogproject  18K Jun 11  2020 d1p1.img
 -rwxrwxrwx 1 fogproject  fogproject  512 Jun 11  2020 d1p2.ebr
 -rwxrwxrwx 1 fogproject  fogproject  512 Jun 11  2020 d1p5.ebr
 -rwxrwxrwx 1 fogproject  fogproject  53G Jun 11  2020 d1p5.img
 -rwxrwxrwx 1 fogproject  fogproject  249 Jun 11  2020 d1.partitions

$ cat /images/myImageV1/d1.fixed_size_partitions
:1:2:1:2

$ cat /images/myImageV1/d1.minimum.partitions
label: dos
label-id: 0x78c7d5cb
device: /dev/sda
unit: sectors

/dev/sda1 : start=        2048, size=     1048576, type=b, bootable
/dev/sda2 : start=     1052670, size=   975718402, type=5
/dev/sda5 : start=     1052672, size=   279441926, type=83

$ cat /images/myImageV1/d1.original.fstypes
/dev/sda5 extfs

$ cat /images/myImageV1/d1.partitions
label: dos
label-id: 0x78c7d5cb
device: /dev/sda
unit: sectors

/dev/sda1 : start=        2048, size=     1048576, type=b, bootable
/dev/sda2 : start=     1052670, size=   975718402, type=5
/dev/sda5 : start=     1052672, size=   975718400, type=83

Differences:

• d1p2.img (the extended partition) is absent in V1.
• fixed_size_partitions content is different.
• in minimum.partitions, the extended partition is smaller in V2
• in partitions, the extended and ext4 partitions are smaller

I tried to copy all files except “d1p5.ebr” and “d1p5.img” from myImageV1 to myImageV2 before retrying deployment of myImageV2: the expand still fails.

I have no idea how to solve my problem.

Any idea?

Hello,

This thread is very well referenced by search engines so I complete it with my experience.

I installed a new storage node on my FOG (Debian 8 + 1.5.7) setup (before : web server / central node + two storage nodes, after : web server / central node) + three storage nodes).

During the installation, I failed on question “What is the IP address or hostname of the FOG server running the fog database?”. The default value is the storage node itself. The mysql command given by Wayne Workman worked from my new storage node, the problem was on FOG side.

I understood my mistake. So, I modified “snmysqlhost” in /opt/fog/.fogsettings with the address of the FOG web server / central node.
I restarted the FOG services (systemctl restart FOGSnapinHash FOGImageReplicator FOGImageReplicator FOGImageSize FOGTaskScheduler FOGSnapinReplicator FOGPingHosts FOGMulticastManager).
The problem was still here.
I rebooted the server.
The problem was still here.

I executed installfog.sh a second time on my new storage node. It detected the existing installation. It did some stuff and… the new storage node works fine.

Regards.

@sebastian-roth One of my colleagues suggested me to use echo / var_dump / die() instead of exec(‘touch’).

So, yes, fogbase.class.php:wakeUp(…) is used when I schedule a wake task and when I deploy an image.

I compared the value of the following variables in the wakeUp function:

• $macs = array(1) { [0]=> string(17) “00:00:5E:00:53:00” }
• $gHost = string(1) “1”
• $nodeURL = array(3) { [0]=> string(69) “https://10.107.0.24/fog/management/index.php?node=client&sub=wakeEmUp” [1]=> string(69) “https://10.108.0.79/fog/management/index.php?node=client&sub=wakeEmUp” [2]=> string(1) “1” }
• $ret = array(3) { [0]=> string(0) “” [1]=> string(0) “” [2]=> string(0) “” }

These variables have these values in both cases: schedule a wake task or deploy an image. So, I was wrong in my first message: my problem isn’t in the wake() function and I’m not stuck on the getSubObjectIDs() function.

I have tried to echo/var_dump/die() the functions called by the wakeup() function but I didn’t understand. I’m still stuck.

Hello,

I use FOG 1.5.4 on Debian 8.

In the web interface, if I do “Hosts” -> I select my device -> “Basic Tasks” -> “Deploy”, my device boot (thanks to wake on lan) and deployement begin then finish. All is fine.

If I do “Hosts” -> I select the same device -> “Basic Tasks” -> “Advanced” -> “Wake”, my device doesn’t boot. tcpdump on my fog server see no udp packet port 7|9. I see no errors in the apache errors log.

I read the code (a little bit) and I think my problem is in fogbase.class.php, function “wakeUp(…)”. When I use “wake” feature, I never return from “list($gHost) = self::getSubObjectIDs(…)”. How do I know that? I write “exec(‘touch /tmp/fog.debug’)” after “self::getSubObjectIDs(…)”. When I use “wake” feature, /tmp/fog.debug is not created, when I use “deploy” feature, it is created.

I’m unable to understand the code of the “getSubObjectIDs(…)” function in fogbase.class.php so my investigation stops here.

Somebody have the same problem?