Posts made by c4c

@sebastian-roth
Thanks for this, using the build.sh produced a working init. Part of me still wants to understand what broke but there really isn’t any point if this is working fine.

@george1421 So this gets weirder and weirder.

I just completely deleted our entire buildroot setup and all the fos information, everything. Re-downloaded everything and started again from absolute scratch. Completely fresh, FOG-standard FOS init and it still doesn’t work. BUT, I also found an old init we were using a couple of months ago and that works absolutely fine.

Now, the interesting thing here is that I did a “make clean” before the last init was compiled and it was then that the issue manifested.

This suggests to me that one of the packages that is downloaded during a clean make process has been updated or changed in the last month in such a way as to break things. If this is the case surely I can just manually download a safe version of whatever it is and put it in the buildroot/dl/ directory but first I need to work out what is broken.

Any ideas?

@george1421 Since we are currently building our own init with buildroot (thanks to your advice in https://forums.fogproject.org/topic/16145/unfreeze-drive-from-fog-init-image/8?_=1650556627677), with the latest from https://github.com/FOGProject/fos would that not include the fix? Or is it something server-side that is missing?

We’ve been using FOG 1.5.9 for over a year, we image multiple machines with Windows 10 every day.

Unfortunately, all our images just stopped resizing the core partition.

I’ve checked every image d1.partition/minimum.partitions/fixed_size_partitions and everything is correct (fixed size is 1:2:4, 3 is the core partition, 4 is Windows Recovery which also blocks the main Windows partition from being expanded manually), but these shouldn’t be the issue anyway since the partitions were extending before and now, suddenly, they are not.

We are using a custom kernel and a modified init.xz (just added a few custom scripts, some extra tools and suspend to RAM functionality). I’ve also tried an old init.xz but we get the same issue. The last change I made was to include procps-ng (from buildroot) in the latest init.xz since busybox ps is super limited, I’m concerned that this might have caused the issue but it still didn’t work with the old init.xz so I’m really not sure!

I’m going to keep hammering away at this but any advice would be greatly appreciated.

Final update: Got everything working! The monitor not waking up after sleep was fixed by adding in some extra graphics drivers to the kernel and we’ve found some solutions to wiping difficult machines (like Lenovo’s) which normally force you to use tools built into the UEFI or a special Lenovo wipe program that only works on certain models and asks you to confirm 5 times and gives you a random generated key that you have to enter in after a reboot. As a note, even parted magic fails to wipe Lenovo drives.

Anyway, thank you @george1421 you’ve helped me to learn a great deal and enabled our success in this.

@george1421 We’re half a step ahead here! Already enabled all the CONFIG_ACPI options and CONFIG_SUSPEND etc. and built a new kernel. We also enabled RTC for rtcwake but that still leaves the screen blank. It also turns out that acpitools (something we thought might work) tries to suspend using /proc/acpi/sleep which, from what I have read, is deprecated because it’s an abuse of /proc.

We are running under the assumption that at least some power management tools have scripts built in to reinitialise monitors/displays etc. using methods which are currently unknown to us and that the easiest solution would be to just get one of them to do it all for us. Unfortunately, so far, this hasn’t worked out.

Right now I’m thinking we need to see if we can just tell stuff to turn back on so I might have to figure out enough ASL to turn the screen back on using acpiexec and an AML file. I’ve also added kexec in to our init though so maybe we can just reload the init after sleeping to unfreeze and that will restart everything.

Another option might be (if this is possible) to use ASL/AML/acpiexec to directly remove power from the drive and then power it back up.

hdparm has an unfreeze command (doesn’t always work) but unfortunately nvme-cli has no equivalent, even tried setting the power states to their lowest possible and then setting them back, also tried the reset command (didn’t work) and the reset-subsystem command just made the drive disappear.

In general, in buildroot, I can’t find any power management tools other than the acpi stuff and powertop (which is useless). Another option might be to try and add in uswsusp manually but the last build of that is from 2011!

The amount of stuff we are learning to solve one, small problem is nuts.

@george1421 Just wanted to update and say thanks again! Your guide is excellent, very easy to follow and everything is working. It would be really useful to have something like this up on fog docs.

Unfortunately we still haven’t been able to solve our core issue though. We can suspend to ram and then wake up (and ssh in) but the screens don’t wake up. I’m sure we’ll figure it out sooner or later. We are certainly learning a lot in the process!

@george1421 That’s literally perfect, thanks! Seems fairly straightforward, I’ll update this thread with progress later.

As a note, we are charity refurbishing computers/laptops and donating them on. We have our own external database that we push data to but we use FOG to harvest data (we’ve created our own inventory and registration scripts to record all drives and pci devices and every RAM module separately). We also use FOG to image outgoing devices and to load tools like parted magic. We are now writing our own data erasure and verification script which is why we need to be able to sleep machines (in order to unfreeze drives), this will be used to effectively complete the automation of processing incoming items, currently we have to use external tools to perform data erasure and some of these we have configured to also report into our database but it would be quicker/more convenient to be able to do it all through 1 boot of the machine, hence adding the functionality to our FOS image.

@george1421 Thank you for your response.

We compiled a custom FOS kernel following the instructions https://docs.fogproject.org/en/latest/reference/compile_fos_kernel.html?highlight=FOS but with CONFIG_SUSPEND=y etc.

This technically works, we can suspend and resume now and machines can be accessed via SSH but their screens stay blank. We’re assuming graphics driver issues but all of the information we can find for diagnosing and fixing these issues relies on tools which are not in the init image and are more complicated to add to it.

As such, we are now looking at following your advice and setting up our own buildroot environment but we’d like to keep everything as close to the default FOS setup as possible. I cannot find anything on docs.fogproject.org that would help with this so any guidance you can give would be extremely helpful!

Thank you.

We have been modifying the FOG init image to include some bespoke functions, useful to our organisation. One of these requires us to occasionally unfreeze frozen drives. Normally we would use systemctl suspend but this functionality is not available in the FOG init image.

Any ideas?

Thanks!

EDIT: Might have solved my own problem (imagine that)
https://wiki.archlinux.org/title/Power_management/Suspend_and_hibernate

Will update here if I get it to work.

@sebastian-roth Thanks for the swift response, looking closer at the fog image files this is exactly the file I will need to modify! From our perspective it would be great to have an audit trail for hardware built in to future versions, but I understand if there isn’t much demand for it, though slightly surprised as it seems useful to me for a whole variety of reasons outside of our specific use case (in which it is required!).

Real quick question:

Which files contain the database interaction for host registration process and where do I find them?

Reason for asking:
Rather than ovewriting host data on taking a new hardware inventory I need to keep records of both the old inventory and the new inventory (effectively I need an audit histroy of changes to hardware, upgrades etc.), ultimately this information will be used in an external database and I’m undecided as to how I want to arrange this, I first want to see how FOG handles the interaction and either modify the FOG interaction to also push to a second database or modify the FOG schema and interaction to fit my needs, though I’d rather keep FOG as vanilla as possible to help future-proof things so I will push to a second DB if I can.