Chromium Image Issues after Updating Server
-
New thread spawned from my previous post about upgrade issues. I’m not able to use my old Chromium issues after upgrade and also not able to successfully create and restore Chromium images after upgrade. Windows images seem to be working fine.
-
@Wayne-Workman Here is a link to a couple of videos with the Fog errors. One of them is before the imaging process and the other is after the imaging process. I never got these messages before and I assume that maybe they are related to why my Chromium images are not working. Please check it out:
-
@rstockham23 The most notable thing I saw in the second video was this error message
Can not open file '/images/CloudRead61/d1.original.swapuuids".
So what I would like to see is the output of this command.
ls -la /images/CloudReady61
also
cat /images/CloudRead61/d1.partitions
-
@george1421 Here is the output of the ls command. Also note, that these images are stored on a Node server, so this command is being run on the Node server:
total 1661360 drwxrwxrwx 2 root root 4096 Jan 31 13:00 . drwxrwxrwx 53 fog root 4096 Jan 31 13:01 .. -rwxrwxrwx 1 root root 32768 Jan 31 12:56 d1.mbr -rwxrwxrwx 1 root root 1267 Jan 31 12:56 d1.original.uuids -rwxrwxrwx 1 root root 100 Jan 31 12:57 d1p10.img -rwxrwxrwx 1 root root 100 Jan 31 12:57 d1p11.img -rwxrwxrwx 1 root root 100 Jan 31 12:57 d1p12.img -rwxrwxrwx 1 root root 100 Jan 31 12:57 d1p13.img -rwxrwxrwx 1 root root 100 Jan 31 12:57 d1p14.img -rwxrwxrwx 1 root root 100 Jan 31 12:57 d1p15.img -rwxrwxrwx 1 root root 212540978 Jan 31 12:58 d1p16.img -rwxrwxrwx 1 root root 6742981 Jan 31 12:58 d1p17.img -rwxrwxrwx 1 root root 730396661 Jan 31 12:59 d1p18.img -rwxrwxrwx 1 root root 6742981 Jan 31 12:59 d1p19.img -rwxrwxrwx 1 root root 100 Jan 31 12:56 d1p1.img -rwxrwxrwx 1 root root 730396691 Jan 31 12:59 d1p20.img -rwxrwxrwx 1 root root 276 Jan 31 12:59 d1p21.img -rwxrwxrwx 1 root root 261 Jan 31 13:00 d1p22.img -rwxrwxrwx 1 root root 245987 Jan 31 13:00 d1p23.img -rwxrwxrwx 1 root root 272 Jan 31 13:00 d1p24.img -rwxrwxrwx 1 root root 351 Jan 31 13:00 d1p25.img -rwxrwxrwx 1 root root 127142 Jan 31 13:00 d1p26.img -rwxrwxrwx 1 root root 13873585 Jan 31 13:00 d1p27.img -rwxrwxrwx 1 root root 100 Jan 31 12:56 d1p2.img -rwxrwxrwx 1 root root 100 Jan 31 12:56 d1p3.img -rwxrwxrwx 1 root root 100 Jan 31 12:56 d1p4.img -rwxrwxrwx 1 root root 100 Jan 31 12:57 d1p5.img -rwxrwxrwx 1 root root 100 Jan 31 12:57 d1p6.img -rwxrwxrwx 1 root root 100 Jan 31 12:57 d1p7.img -rwxrwxrwx 1 root root 100 Jan 31 12:57 d1p8.img -rwxrwxrwx 1 root root 100 Jan 31 12:57 d1p9.img -rwxrwxrwx 1 root root 4357 Jan 31 12:56 d1.partitions
-
@george1421 Here is the output of the cat command:
label: gpt label-id: 0EAC06B1-8867-D143-A213-146CF0F7B6CA device: /dev/sda unit: sectors first-lba: 34 last-lba: 117231374 /dev/sda1 : start= 64, size= 1, type=2E0A753D-9E48-43B0-8337-B15192CB1B5E, uuid=1F6B7189-FBFE-4D49-83FC-8C50EF9001AA, name="CRDYSTUB" /dev/sda2 : start= 65, size= 1, type=2E0A753D-9E48-43B0-8337-B15192CB1B5E, uuid=150A93BE-3C90-0F47-9D33-A8C9F7E6E3B7, name="CRDYSTUB" /dev/sda3 : start= 66, size= 1, type=2E0A753D-9E48-43B0-8337-B15192CB1B5E, uuid=96D4A3A5-298A-E54D-94FD-665A6D227172, name="CRDYSTUB" /dev/sda4 : start= 67, size= 1, type=2E0A753D-9E48-43B0-8337-B15192CB1B5E, uuid=46338198-7637-6D46-82AF-667EE26B327E, name="CRDYSTUB" /dev/sda5 : start= 68, size= 1, type=2E0A753D-9E48-43B0-8337-B15192CB1B5E, uuid=550E0544-B3CE-BD49-A8F8-18B4138F2CDF, name="CRDYSTUB" /dev/sda6 : start= 69, size= 1, type=2E0A753D-9E48-43B0-8337-B15192CB1B5E, uuid=17631450-4B4C-C945-9B0D-052DACE7D343, name="CRDYSTUB" /dev/sda7 : start= 70, size= 1, type=2E0A753D-9E48-43B0-8337-B15192CB1B5E, uuid=E32BFEB9-959F-424B-9209-97FECDCC54FF, name="CRDYSTUB" /dev/sda8 : start= 71, size= 1, type=2E0A753D-9E48-43B0-8337-B15192CB1B5E, uuid=E7D02AC5-3818-1A4A-B243-C90DB73D2A95, name="CRDYSTUB" /dev/sda9 : start= 72, size= 1, type=2E0A753D-9E48-43B0-8337-B15192CB1B5E, uuid=7A788CE4-39E2-F549-9218-FC5D692CE30C, name="CRDYSTUB" /dev/sda10 : start= 73, size= 1, type=2E0A753D-9E48-43B0-8337-B15192CB1B5E, uuid=C8F219B3-BB32-E143-A690-98B9B30A8129, name="CRDYSTUB" /dev/sda11 : start= 74, size= 1, type=2E0A753D-9E48-43B0-8337-B15192CB1B5E, uuid=38BE338C-94EA-0C49-A404-2B7C10807D94, name="CRDYSTUB" /dev/sda12 : start= 75, size= 1, type=2E0A753D-9E48-43B0-8337-B15192CB1B5E, uuid=51F906E6-4287-A445-86D9-4D79BDF0EC59, name="CRDYSTUB" /dev/sda13 : start= 76, size= 1, type=2E0A753D-9E48-43B0-8337-B15192CB1B5E, uuid=22F188EE-3584-9C47-8FEB-C285673827DE, name="CRDYSTUB" /dev/sda14 : start= 77, size= 1, type=2E0A753D-9E48-43B0-8337-B15192CB1B5E, uuid=5C35E129-7808-2B41-8355-7CAAE0D5EB0E, name="CRDYSTUB" /dev/sda15 : start= 78, size= 1, type=2E0A753D-9E48-43B0-8337-B15192CB1B5E, uuid=5083A3C4-5FAF-3A4E-A986-54A3F369E053, name="CRDYSTUB" /dev/sda16 : start= 14831682, size= 102399692, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=04CD822C-013D-F443-8104-D6C5E5FD6862, name="STATE" /dev/sda17 : start= 20546, size= 32768, type=FE3A2A5D-4F32-41A7-B725-ACCC3285A309, uuid=849AD749-9EA9-D940-9ABE-04415E7D7A3D, name="KERN-A", attrs="GUID:48,53,54,56" /dev/sda18 : start= 8589378, size= 6242304, type=3CB8E202-3B7E-47DD-8A3C-7FF2A13CFCEC, uuid=726616F9-9587-D14C-9ACF-3410B0945046, name="ROOT-A" /dev/sda19 : start= 53314, size= 32768, type=FE3A2A5D-4F32-41A7-B725-ACCC3285A309, uuid=B31444EF-4417-234B-A848-8382C0340C2F, name="KERN-B", attrs="GUID:52,53,54,55" /dev/sda20 : start= 2347074, size= 6242304, type=3CB8E202-3B7E-47DD-8A3C-7FF2A13CFCEC, uuid=126A9BC8-C55D-2C4A-9632-CCF8B883A294, name="ROOT-B" /dev/sda21 : start= 16514, size= 1, type=FE3A2A5D-4F32-41A7-B725-ACCC3285A309, uuid=B9A205EE-743B-604D-9B42-A763FB667219, name="KERN-C", attrs="GUID:52,53,54,55" /dev/sda22 : start= 16515, size= 1, type=3CB8E202-3B7E-47DD-8A3C-7FF2A13CFCEC, uuid=F9EE26D3-5A6F-F94E-9071-3F333D0486B3, name="ROOT-C" /dev/sda23 : start= 86082, size= 2097152, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=C5A29595-FB6A-0F40-B693-852D6F73B502, name="OEM" /dev/sda24 : start= 16516, size= 1, type=2E0A753D-9E48-43B0-8337-B15192CB1B5E, uuid=4A50ED90-1D40-2245-B441-D7F0D8361FA1, name="reserved" /dev/sda25 : start= 16517, size= 1, type=2E0A753D-9E48-43B0-8337-B15192CB1B5E, uuid=A8D9CE8B-EA02-C942-A2E4-75F04FB2B62E, name="reserved" /dev/sda26 : start= 130, size= 16384, type=CAB6E88E-ABF3-4102-A07A-D4BB9BE3C1D3, uuid=ED6C6E28-ACF7-E04B-91FE-23DCC222A05A, name="RWFW" /dev/sda27 : start= 2314306, size= 32768, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=71053A51-16C1-2B46-A5D6-25116CF1CB8F, name="EFI-SYSTEM", attrs="LegacyBIOSBootable"
-
@rstockham23 Color me shocked, but Chromium has 20 partitions?? That does explain what is visible in the video a bit more.
can we also get a cat of the d1.original.uuids file
-
@george1421 Yes sir…it’s an OS of many partitions. Here is the other output you requested:
/dev/sda 0eac06b1-8867-d143-a213-146cf0f7b6ca 1:1f6b7189-fbfe-4d49-83fc-8c50ef9001aa 2:150a93be-3c90-0f47-9d33-a8c9f7e6e3b7 3:96d4a3a5-298a-e54d-94fd-665a6d227172 4:46338198-7637-6d46-82af-667ee26b327e 5:550e0544-b3ce-bd49-a8f8-18b4138f2cdf 6:17631450-4b4c-c945-9b0d-052dace7d343 7:e32bfeb9-959f-424b-9209-97fecdcc54ff 8:e7d02ac5-3818-1a4a-b243-c90db73d2a95 9:7a788ce4-39e2-f549-9218-fc5d692ce30c 10:c8f219b3-bb32-e143-a690-98b9b30a8129 11:38be338c-94ea-0c49-a404-2b7c10807d94 12:51f906e6-4287-a445-86d9-4d79bdf0ec59 13:22f188ee-3584-9c47-8feb-c285673827de 14:5c35e129-7808-2b41-8355-7caae0d5eb0e 15:5083a3c4-5faf-3a4e-a986-54a3f369e053 /dev/sda16 16:066670c1-582e-457c-8023-bf0d8de662fc 16:04cd822c-013d-f443-8104-d6c5e5fd6862 17:849ad749-9ea9-d940-9abe-04415e7d7a3d 18:726616f9-9587-d14c-9acf-3410b0945046 19:b31444ef-4417-234b-a848-8382c0340c2f 20:126a9bc8-c55d-2c4a-9632-ccf8b883a294 21:b9a205ee-743b-604d-9b42-a763fb667219 22:f9ee26d3-5a6f-f94e-9071-3f333d0486b3 /dev/sda23 23:ebc2c96f-7b00-404f-9eeb-e567ea639dbb 23:c5a29595-fb6a-0f40-b693-852d6f73b502 24:4a50ed90-1d40-2245-b441-d7f0d8361fa1 25:a8d9ce8b-ea02-c942-a2e4-75f04fb2b62e 26:ed6c6e28-acf7-e04b-91fe-23dcc222a05a /dev/sda27 27:BA20-3347 27:71053a51-16c1-2b46-a5d6-25116cf1cb8f
-
@george1421 said in Upgraded an Existing Server to 1.4.4 and Now Interface is Very Slow and Chromium Images are not working:
Color me shocked, but Chromium has 20 partitions??
Yes. I can confirm from experience.
-
@rstockham23 Well I don’t 100% understand what I’m looking at, but I do see an anomaly in the data in the uuid file. Why is /dev/sda16 different than 15 and 17? Same with sda17 and sda23
That’s just an open question. I need to see now if your video gives me any more detail knowing now what we know.
-
Posting the link to the Chromium OS project in case future readers are interested:
https://www.chromium.org/chromium-osI went through the documentation myself years ago and back then, it was really difficult to understand - I had to jump around in the instructions to get things going on the hardware I was working with (elite books).
Old thread about the HP Elite Books with Chromium OS on them:
https://forums.fogproject.org/topic/6214/chromiumos-r48-elitebook-8730w@george1421 I provided a ton of disk related output in that thread.
-
@george1421 @Wayne-Workman I appreciate you guys looking at this. Like I said in my original message, this has never been a problem in the past. It just worked, but since updating it just won’t boot correctly. If you’re wanting to try and duplicate on your end. The easiest to download installer for Chromium and the particular version that I’m using in this case can be found here: https://www.neverware.com/freedownload
@Wayne-Workman you had mentioned going back through different versions of Fog…I have never tried to Back-Rev Fog before. Can that be done gracefully by simply installing an old version over top of a newer version or is that a recipe for disaster?
-
@rstockham23 reverting to a previous build is not usually supported. Moving from 1.4.x to 1.3.0 wouldn’t be advised. What I’m speculating is that 1.4.4 is expecting something to be in that uuid file that is not currently there. The developers spent many hours improving disk imaging and resizing between 1.4.1 and 1.4.4. I think the fix is pretty easy we just need to identify what is missing. With 1.5.0 (stable) nearing release I don’t think moving backwards is the best choice right now.
-
@george1421 Thank you. I will take that advice to heart!
-
@george1421 Your comments gave me an idea that I hadn’t tried yet. The images I’ve been using so far are all ones that were originally created in fog 1.3.5. So I went ahead and created an entirely new image file from scratch and uploaded from a working Chromium laptop like I normally would. All messages showed successful for the upload, etc. I then went to download the image to another laptop and got this error message before it started the download:
https://photos.app.goo.gl/I75ORDRoDZqf24OU2So it would seem now that with my current server it’s not successfully creating new Chromium images from scratch either.
-
@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=down
at 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/2018CloudReady
and 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) found
when 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).