Sorry check more often what, exactly?
I donât see any point in keeping a thread open if the Original Poster canât provide requested information exactly as requested. If you expect people to take time out of their busy day to help you this is not to much to ask.
1 Like
So to end with a bang this false-statements-festival thread, worth to mention that one of our most active devs is one of calamares devs too.
Cannot guess anyone/anything more up2date than OM on this regard 
This is reopened because I just confirmed this is a very real bug with the new ISO # 2535. It will happen in one has existing partitions and uses âManual Partitioningâ and attempts to use an existing /boot/efi partition.
OK a logical question is why did I not see this in my previous testing. Because I was using ISOâs that did not have this bug. The most recent used by me before this was ISO # 2485. Worth noting is that OP did not tell us what ISO he was using. This points out the huge importance of accurate information for such problems. If the ISOâs I was using previously had this problem I would have seen it right away because this is how I do each and every hardware install on my boxes.
Also reported here.
I think there is no functional problem, nothing technically wrong. This looks like an error message that does not belong.
This based on a hardware install of ISO 2535 where other than the error message everything appears to be normal. It did install grub2 menu ect.
From your /dev/sdb:
That, âmsftdataâ, is not an EFI partition. As long as it says âmsftdataâ it will give that error.
This one probably is legitimate EFI partition if âdĂ©marrageâ means boot. It is from you /dev/sda.
Also if you run âsudo fdisk -lâ it should say:
/dev/sdx1 34 1048609 1048576 512M EFI System
If it does not say EFI System then it isnât. And it must have boot and esp flags as listed by parted. So I see 2 options for you to avoid that error:
- If both conditions are not met then you will need to delete the /dev/sdb1 and create a new /boot/efi.
- Or just use the existing /boot/efi on /dev/sda1 with âKeepâ selected (donât format). It will hold entries from many different operating systems. You can switch which it uses in your BIOS or with âefibootmgrâ (example):
$ sudo efibootmgr
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0001,0002,0003,0004,0005
Boot0000* openmandriva
Boot0001* opensuse
Boot0002* grub
Boot0003* UEFI:CD/DVD Drive
Boot0004* Hard Drive
Boot0005* CD/DVD Drive
That would be booting from 0000 or OpenMandriva. To change the boot order you would use -o like:
$ sudo efibootmgr -o 0005,0001,0002,0003,0004,0000
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0005,0001,0002,0003,0004,0000
Boot0000* openmandriva
Boot0001* opensuse
Boot0002* grub
Boot0003* UEFI:CD/DVD Drive
Boot0004* Hard Drive
Boot0005* CD/DVD Drive
Now it will look first to boot from 0005 CD/DVD Drive. So obviously it will boot from the first entry in the list unless you go in to your BIOS and select another.
Post-edit: By now is obvious Iâm learning about this myself. The above is based on what I know at this moment. If I get something wrong a dev will correct me. Count on that.
in fact some calamares version 3.27 introduce regression & issue on that ,
manjaro use calamares since 2016 , bur be careful on that
each distribution report for âsameâ calamares , so you mays have regression
on version 3.27 the team was tested new version libparted with one flag , instaed of 2 ( boot,esp )
version 3.29 is ok
https://forum.manjaro.org/t/manjaro-does-not-boot-after-installation/89729
In fact that is not true.
Manual partitioning problem has nothing to do what so ever with parted but
new kpmcore4.
Manjaro switched back to kpmcore3 so it has nothing to do with the calamares version.
That means if your /boot/efi was create wrong already , eg: not flagged âEFI Systemâ
in Manual partitioning if you want to keep that partition wonât work right now with
either calamares version and kpmcore4.
And is easy to fix if you know you have this problem.
Before you install just do that:
sudo fdisk /dev/sdX
type p ( and notice which is the efi partition )
type t
( select the partition nr of the efi partition )
type 1
type w
type quit
Start installation and Manual partitioning will work just fine
2 Likes
how many users will do this ?
You know that or donât you ?
A user canât know but that is not what Iâve suggested to you ?
1 Like
i have tried with gparted under manjaro to solve the flag on sdb
but it needs boot and esp , not good if twice boot is selected
as i couldnât flag boot&esp for mountpoint under calamares , i cant select /boot/efi on the other disk sdb for install , kpmcore is a part of calamares
next iso will be better
kpmcore is a part of calamares
No is not part of calamares.
as i couldnât flag boot&esp for mountpoint under calamares
Because there is no ESP is merged into bootflag in kpmcore4
i have tried with gparted under manjaro to solve the flag on sdb
I have told you already how to solve that, didnât I ?
This is noted in our Errata for OM Lx 4.0 final release.
And bug report: