Chromium Image Issues after Updating Server
-
@rstockham23 Ok, moved posts over. I’ll look into this tomorrow.
-
@rstockham23 I didn’t find the time to set a whole test system up to try and replicate the issue but looking at the videos and pictures you posted I noticed something. Moving an image from 1.3.5 is one thing. But let’s start with what you posted last. An image taken with FOG 1.4.4 and trying to deploy errors out with
No image file(s) found: In that picture I see... image=2018CloudRetype=downat the end of the kernel command line. The image option is cut and there a quite some options missing. As wellmac=is empty. So I am wondering what’s wrong here. Never seen this before.Can you please post a listing of the image directory:
ls -al /images/2018CloudReadyand take a screenshot of the image settings in the web UI. Post both here so we can check. -
@sebastian-roth Thanks Sebastian. I had since deleted the 2018CloudReady image, but later created another one with the exact same results. It is called NewCloudReady. Below is the contents of it’s directory and attached is a picture of the image setup:
total 1872496
32 d1.mbr
4 d1.original.uuids
4 d1p10.img
4 d1p11.img
4 d1p12.img
4 d1p13.img
4 d1p14.img
4 d1p15.img
407092 d1p16.img
6588 d1p17.img
713284 d1p18.img
6588 d1p19.img
4 d1p1.img
713284 d1p20.img
4 d1p21.img
4 d1p22.img
11860 d1p23.img
4 d1p24.img
4 d1p25.img
128 d1p26.img
13552 d1p27.img
4 d1p2.img
4 d1p3.img
4 d1p4.img
4 d1p5.img
4 d1p6.img
4 d1p7.img
4 d1p8.img
4 d1p9.img
8 d1.partitions
0 directory.txtScreenshot: https://photos.app.goo.gl/BM5R39AVgvhvOBg32
-
@rstockham23 Sorry for taking so long to get back to you. I now got a test setup up and will look into it. Hope I find enough time over the weekend.
-
@rstockham23 Are you still seeing the issue
No image file(s) foundwhen trying to deploy a fresh Chromium OS image captured with FOG 1.4.4. I just can’t reproduce the issue. It’s working great for me.Now about the other things. The ACPI messages in your video tell us that the Linux kernel is not happy with your UEFI firmware but that’s not a real issue. You can ignore those.
About the
Partition type/uuid being set to: Since Chromium OS has more than 10 partitions our regular expression match kind of freaked out and found several matches. I will push a fix soon.The
Can not open file '...d1.original.swapuuids'has been another issue that I’ll post a fix. Thanks for bringing those up!@Tom-Elliott @Joe-Schmitt Please check out the proposed fixes and build fresh inits with those when you have time to do so.
-
I’m currently updating the init’s with the requested changes as proposed. Will be a few more minutes or so, sorry.
Hopefully this will fix the partition uuid setting for chromium os (among others).
-
Init’s are now uploaded.
If you aren’t willing to jump to the working branch, please run:
wget --no-check-certificate -O /var/www/fog/service/ipxe/init.xz https://fogproject.org/inits/init.xz wget --no-check-certificate -O /var/www/fog/service/ipxe/init_32.xz https://fogproject.org/inits/init_32.xzThis should get you the latest init’s with the changes @Sebastian-Roth has suggested.
-
Attached is a photo of the error that we’re still getting even after doing a fresh install of the latest version of FOG. I still can’t Capture a Chromium image without getting an error. Same FOG server works just fine with Windows images, etc, but not with Chromium.
-
@rstockham23 Can you post a screenshot of the image settings?
Are there any special settings for this host? (eg kernel arguments and the like)
-
@rstockham23 Sorry but the important information is not on the picture. Usually there is a message in the blue partclone screen which should give is more hints on what’s wrong. When scheduling the task you can set the checkbox for debug and after the error happens you’ll get to a command shell. There you can check the mentioned log file:
cat /var/log/partclone.log
