Best posts made by Quazz

@Boyan-Biandov said in upgraded to Ubuntu 18.04.1 LTS:

@Wayne-Workman Great link Wayne, I am actually going to do this myself very soon, one point of clarification if I may: section “Arranging Images”. Is it really necessary to copy the images to a folder, other than /images on the new fog server and then once they are copied there “rearrange” them by moving them again into the final destination of /images (assuming fog defaults)?

Imagine scenario A: You are busy capturing a new version of your image and someone attempts to deploy that image. They will get an incomplete and broken image and the install has failed.

Imagine scenario B: You are busy capturing a new version of your image but something goes wrong! The image is now in an incomplete/broken state and you have no way of knowing for how long that will be the case! Not very practical.

So yeah, there are legitimate reasons for using a ‘temporary directory’ if you will.

@mckayj Okay, I think this one should have it enabled

https://drive.google.com/open?id=1ZiRWrrN3dv26bLwW8GAEdLtzGw5xkyQI

Can you take a picture of the error? A picture of someone else’s environment doesn’t really help us since their problem seemed to be related to a specific system.

Double check host settings primary disk field. Possibly the primary disk for the SSD is not the same and thus the disk can’t be found on deployment.

What language do you install Windows 10 in?

Any OEM specific partitions?

@Baessens Please run the following commands to update the kernels and inits to the latest version which should provide better results for Dutch installations

wget https://fogproject.org/kernels/bzImage -O /var/www/html/fog/service/ipxe/bzImage
wget https://fogproject.org/kernels/bzImage32 -O /var/www/html/fog/service/ipxe/bzImage32
wget https://fogproject.org/inits/init.xz -O /var/www/html/fog/service/ipxe/init.xz
wget https://fogproject.org/inits/init_32.xz -O /var/www/html/fog/service/ipxe/init_32.xz

You will have to recapture the image after this so the information is correctly captured for deployment.

@Baessens @Sebastian-Roth Some googling indicates 0x0000225 has to do with the BCD.

Given that the start positions of the partitions seem to be correct, I don’t think the resize process is directly responsible for the error.

Is it possible you’re deploying an MBR (legacy/old BIOS) (assuming, based on your partitions) to a system that’s trying to boot in GPT (new/UEFI) mode?

Does d1.mbr exist in your image folder?

@Sebastian-Roth I recently updated most of my images and it works fine on all MBR images (accross languages (EN, FR, NL) and W7 + W10), but I do notice a problem on the latest W10 GPT images, where the first partition isn’t picked up on certain languages since they decided to change/translate labels. (first partition is “Recovery”). in fact I think this may even fail on English too since it’s FAT32, not NTFS

However, if @maxcarpone is using an MBR installation (looks like he is since the first partition label), then I have no clue why it wouldn’t work. The regex works fine in test cases and in real scenarios on my own images.

His label information on his disk is correct too as we can see in the screenshot, by all accounts it should be processed correctly…

If an English image could be created the same way a French one would and then testing to see if that one works could potentially shed some light on the situation. I realize that’s asking a lot of course. You don’t have to install all the software or anything, just install Windows and then prepare for capture as you usually do.

main reason I want to test this is because I wonder if we’re focusing on the language too much as opposed to other alternative factors that could mess with detecting the partitions correctly

double check image settings, primarily the OS field needs to be correct or it will never even try to check for the labels

After further investigation, using the ‘English’ label ‘System Reserved’ works fine.

I double checked my french images and one dating 25 october capture the label was picked up correctly, but one dating 16 november was not.

I believe the one around 25 october was the one I was using when I originally tested the new label regex and confirmed it working.

Not sure how/why it wouldn’t work now, though.

@Sebastian-Roth Yes, I have tested in FOS, every other variation we tried worked on regular systems already

edit: I may have messed up the test case, I’ll try again in a bit though

I dun goofed, I’m pretty embarassed. I messed up my sed which made the variable empty and of course it matches then…

@maxcarpone Basically, unicode support (required for letters such as é) is broken/missing in current builds, causing the check to fail.

I think we’re on the right track, but each build takes time to compile, so for each idea it takes hours before I can test.

Currently looking into busybox locale support.

@Sebastian-Roth I’ll be glad to escape unicode hell, I do think focus on a language neutral solution is the way to go. I’m still unsure about the best direction to take.

So far, it seems we have two possible paths to explore:

File based detection:
Will check the mounted partition for specific files/folders, if they exist then we know what kind of partition we can expect (eg resizable partition if Windows folder is found)

However, I foresee some funky stuff being able to mess this up. Atypical installations might not be detected properly.

Partition flag based detection:
Will check the mounted partition for specific flags, if they exist then we know what kind of partition we can expect based on the set flags.

However, partition flags seem to have been somewhat inconsistently set as well as have changed between MBR and GPT somewhat. And of course users/software could theoretically alter these (although this will typically lead to issues with the system in question so less likely than with labels and marginally less likely than with files)

Our greatest advantage is that we only really need to think about NTFS partitions if we are simply replacing the old label system. This means we can work a lot more targetted regardless of the path taken.

I created and tested out the partition flag system which seems to work well on the systems I use, but of course I have no idea how it will behave outside of that.

@Sebastian-Roth I was looking into a file based approach but ran into a major speed bump.

It seems that on GPT builds of Windows 10 (at least on the latest official ISO release of Microsoft), the only folder (and there’s no files) on the first partition (which should be non-resizable) is ‘System Volume Information’ which is available on every NTFS partition…

Not sure how to resolve this at this point.

Got a working flag based approach available for now which should work fine for cases such as @maxcarpone has experienced.

edit: Even better news, had an OEM disk come in so I checked it out and it turns out they also use the ‘hidden’ flag which means we can mark them as non-resizable as well with this approach.

Of course as you pointed out, ideally they’d be ‘moveable’, but that’s a different issue I think, just fixing the partitions being resized that shouldn’t should do for now I think!

Yes, there’s a small mistake in the regex for the new password check. The whole password thing is getting a bit of a tune up.

More details here: https://github.com/FOGProject/fogproject/commit/244b239641d8ff602e97441d1d6658e71e9593b0#commitcomment-32148121

Change 0-1 to 0-9 over at https://github.com/FOGProject/fogproject/commit/71844d48ea00581f28ce56c28a8a63fc6166c38b

You can do working branch as well of course.

@jcabuco You can UEFI boot with secure boot disabled.

Secure boot and bitlocker are unrelated. They can be enabled irrespective of the other.

@imt_fog If you boot the machine in question in debug mode, you should be able to run parted -l manually and check the flags.

I don’t think this is caused by such, however, but interested in seeing the results.

Worth noting that partitions that go through the checks but fail to resize get marked as fixed size as well (to prevent issues during deploy)

You can change the password on the Web UI for any account, including fog from the users menu on the Web UI.

As for the MySQL password, it says what to do

Configuring the new FOG mysql root password
Edit the file /opt/fog/.fogsettings and enter the password on line 21:
nano /opt/fog/.fogsettings
snmysqlpass = ‘MdpROOTsql’

Edit the file /var/www/fog/lib/fog/config.class.php and enter the password on line 50:
nano /var/www/fog/lib/fog/config.class.php
define (‘DATABASE_PASSWORD’, “MdpROOTsql”);

@Guillaume-IT You need to edit two files

/opt/fog/.fogsettings (edit snmysqlpass)

and

/var/www/fog/lib/fog/config.class.php (edit define (‘DATABASE_PASSWORD’, “MdpROOTsql”);)

There was a bug in the inits that would cause issues with recording the wrong info about “fixed size partitions”. I believe 1.5.6 (just released!) contains the fix though. You’ll have to recapture the images though.

It was fixed in this PR, no? (the PR isn’t labelled that well, but basically the code hadn’t been updated in that file, but now we just read the info instead of running the same tests twice) https://github.com/FOGProject/fos/pull/24

The other user hasn’t reported back yet, but give 1.5.6 a go and let us know!

@george1421 Worth noting that on 1.5.6 the linux user account was changed from fog to fogproject