in-place upgrade fail: The image file and current ESOS disk labels do not match

46 views
Skip to first unread message

coh...@gmail.com

unread,
Mar 17, 2021, 1:34:24 PM3/17/21
to esos-users
I am trying to upgrade several sever from ESOS 2.0.16 to 2.1.5 or 3.0.6 (or anything) but I always get the message "The image file and current ESOS disk labels do not match! An in-place upgrade is not supported, continuing.."

As far as I can tell, the installation script is doing a "fdisk -u -l /dev/sdc" and the result is:
Device  Boot StartCHS    EndCHS        StartLBA     EndLBA    Sectors  Size Id Type
/dev/sdc1 *  0,32,33     51,30,43          2048     821247     819200  400M ef EFI (FAT-12/16/32)
/dev/sdc2    51,30,44    306,21,35       821248    4917247    4096000 2000M 83 Linux
/dev/sdc3    306,21,36   331,148,9      4917248    5326847     409600  200M 83 Linux
/dev/sdc4    1023,63,32  1023,63,32     5326848   30031871   24705024 11.7G 83 Linux

From this, it extracts those data:
0,32,33
51,30,44
306,21,36
1023,63,32

and compare them to the image partition:
0,32,33
51,30,44
306,21,36
331,148,10

It then fail because the 4th partition doesn't have the same geometry.
The script says it's checking the disk labels but it's really comparing the geometry of the paritions. The 4th partition is kinda filling-up the rest of the device so should it always expect to have the same geometry?

Would it be ok if I modify the script to ignore this test in my case so it could continue with the upgrade?


Marc Smith

unread,
Mar 18, 2021, 11:40:50 AM3/18/21
to esos-...@googlegroups.com
Yeah, you can modify, but something looks strange with your geometry: The compare is only against the "StartCHS" column, not the end. So an expanded fourth partition will have the same start geometry, but a different (usually bigger) end geometry.

Why is your start/end geometry the same:
/dev/sdc4    1023,63,32  1023,63,32     5326848   30031871   24705024 11.7G 83 Linux

I looked at other ESOS systems and it is not like what you have above.

--Marc


--
You received this message because you are subscribed to the Google Groups "esos-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to esos-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/esos-users/a5a853f8-39d7-4cee-b70c-bb8643d4794an%40googlegroups.com.

coh...@gmail.com

unread,
Mar 18, 2021, 12:05:56 PM3/18/21
to esos-users

I checked and my 3 servers have the same geometry. But they were all setup from the same installation package...
Anyway, I changed the script to ignore this check (after making sure it was the right device/partitions) and it worked fine.

By the way, I wanted to make a test first and pluged a copy of the USB stick on a PC at home with 8GB of RAM: that's not enough to do the update. It will start doing and fail with memory allocation errors while uncompressing some files. Then the stick wont boot at all anymore... (maybe should check if there is enough memory before trying to do the upgrade :)

Marc Smith

unread,
Mar 18, 2021, 12:07:30 PM3/18/21
to esos-...@googlegroups.com
On Thu, Mar 18, 2021 at 12:05 PM coh...@gmail.com <coh...@gmail.com> wrote:

I checked and my 3 servers have the same geometry. But they were all setup from the same installation package...
Anyway, I changed the script to ignore this check (after making sure it was the right device/partitions) and it worked fine.

By the way, I wanted to make a test first and pluged a copy of the USB stick on a PC at home with 8GB of RAM: that's not enough to do the update. It will start doing and fail with memory allocation errors while uncompressing some files. Then the stick wont boot at all anymore... (maybe should check if there is enough memory before trying to do the upgrade :)

Yeah, it’s on the to-do list. Patches are welcome!


Reply all
Reply to author
Forward
0 new messages