@fractal13 Hey, long time no hear, hope all is well.
Wondering if you (being the original writer and all) wouldn’t mind reviewing my latest procsfdisk.awk script? Had a few issues in 1.3.x days that kind of required a rewrite of it all, which went fairly well. Last night (early this morning) I hope to have solved the mystery of extended partitions though I’m sure it’s not perfect. I can’t see the “flow” nicely. So a good review could be very very useful. (Others are welcome to it as well.)
I might suggest trying to ensure whatever node this is on is updated to the same as your “main” server? I say this becuase I made that error a warning. I’ll double check just to be sure, but warning will show the same message, but won’t halt the completion when the message presents. I cannot, for the life of me, remember if this was pushed in for an RC of 1.5.0 or if it made it into 1.4.4 though, so you might want to update to the RC’s. (Not that you have to).
To answer the question more directly, as long as the system can boot without any issues you should be fine.
@matthieu-jacquart I take it that makes it sufficient enough to say case closed?
@xipher I believe the swap mount is unrelated to where the partition actually sits, rather Linux Mint seems to set the swap by uuid. While we do try to reset the UUID, this isn’t working and I’m not overly worried about fixing the UUID for SWAP partitions anyway. (Why you ask?) Because you can edit the /etc/fstab, change the swap partition from the UUID to the actual location. In my case /dev/sda5 is the drive, so replace the UUID bit with /dev/sda5 and all works properly on reboots.
I don’t understand. So it was your layout of how it applied the partitions to disk that caused the resizing to not happen properly? So expanding does work when laid out in a specific fashion?
I was able to replicate the results through 3 vms, one capture at 50GB, one for deploying to at 30GB, and one for deploying to at 100GB (to mimic what you described as closely as possible.)
I DID find some issues, and worked very diligently to try to fix those issues. I don’t think it has anything to do with placement of LVM, directly, rather because the extended partition was moving the LVM around and it was unable to find itself based on what was presented originally.
(See Here for more information, though not directly describing it might make sense).
https://github.com/FOGProject/fogproject/commit/635c5050904c3e29edd26151d96b7217318acf6c
I was able to fix and deploy to all devices and the devices were able to boot without an issue and all showed the “expansion” had worked as well. (Well the capture system didn’t expand, but it was using the correct layout as to how it was originally configured. – Meaning it applied back exactly what should have been since it was the exact same disk. Prior to this it was expanding a tiny bit even to the same machine.)
I’ve updated the init’s. Would you be willing to give them a shot and see if the “originals” will now start working?
wget -O /var/www/fog/service/ipxe/init.xz https://fogproject.org/inits/init.xz
wget -O /var/www/fog/service/ipxe/init_32.xz https://fogproject.org/inits/init_32.xz
I’m sorry it took so long to get anything, but hope you understand that we are very busy with our own things too.
So if I’m to gather things correctly, you’re attempting to go down in size from 50gb (capture system) disk to a 30gb (deploy system) disk?, What was the sizes when you said you deployed to a “larger” disk?
I’m not changing the whole field but I added the “protected/unprotected” to snapins as well as added “enabled/disabled” for both snapins and images.
Snapins:
Images:
can we see a picture of the problem please?
Can you also include the Information as it’s stored on the GUI? Proxy is not used to get storage node information.
Fixed the Reboot/Shutdown/None item. Sorry, it was just a missed code logic. I was always setting shutdown or reboot, forgot about the “none” availability. This is now addressed in working.
In chat requested @lmioperations edit /opt/fog/.fogsettings and remove the packages line. Then re-run the installer. All things seemed to point that mcrypt packages weren’t installed or enabled.
After rerunning the installer @lmioperations is able to login to the GUI using the password as set.
@ariederer26 The installer does not lose anything. I’d also highly recommend updating, personally I’d say the RC’s but I understand if you can only go to the latest stable. We’re now up to 1.4.4 for stable, and the RC’s are working towards 1.5.0. This you can find in https://wiki.fogproject.org/wiki/index.php?title=Upgrade_to_trunk
Rerun the installer and it should fix the problem.
I can’t remember the link at the moment, but this is almost certainly related to the unattended upgrades. More info can be found in the Announcements under “Ubuntu is FOG’s enemy”
Are you sure caps-lock isn’t set and all. I know it seems stupid, but this doesn’t make sense.
What if you copy the word password and use the copy paste to the password field.
@lmioperations You’re not changing the fog user password for mysql. You’re changing the user that sits in fog.users
No, copy my command exactly. Not changing 'password' at all. Of course using the MD5 you could use any plain text.
Right now, your password is set literally to:
$2y$11$g0Hu8OaOStuPk7WWYGh6Wu4PLlZDZGOkzMwEEAk.rZMrI9IdDwno.
Can you try:
UPDATE `users` SET `uPass` = MD5('password') WHERE `uName` = 'fog';
I know you’re using 1.3 or higher, but the MD5 mechanism should work as well.
@lmioperations THen is it possible there’s two databases? One that’s the “fog” database as expected, but another fog database with a different name? (So your server is looking at database fog_new where you’re resetting the gui password for database fog)?
Just trying to think of everything. I know the update statement works, I just tested it. So either the change simply isn’t taking.
Do you have more than one FOG Server hosting a DB? Maybe the one you’re changing it for is not the same as the one the GUI is trying to work from?
@lmioperations The test was just to ensure that when you ‘reset’ to the password you could actually see a “change”