Bug #14074
closed
Cannot edit or delete ZFS Boot Environment with a name containing only numbers
100%
Description
i just created a new boot environment, but it apparently didnt like the name i gave it and set it to '0'
It cannot be edited. If you attempt to do so, it just creates another boot environment entry to the list.
if i try to delete, it says Unable to delete boot environment "0". Error 3
TrueNAS had a similar issue a couple years ago, and the work around was deleting any other boot environments post that broken one - that does not help in this case.
running 23.01 on a netgate 7100
Files
Related issues
Updated by Marcos M about 1 year ago
Are you able to replicate this reliably? If so, please detail the steps to do so.
Updated by Mark Grant about 1 year ago
now that it has this new boot environment '0' if i try to edit it, it makes a new boot environment. Each time.
however, the new ones with proper names CAN be deleted. its just the one labeled '0' that cannot be deleted and gives that error message.
Updated by Jim Pingle about 1 year ago
- Subject changed from Boot Environment - cant delete to Cannot edit or delete ZFS Boot Environment named ``0``
- Status changed from New to Feedback
There must be some additional steps needed to replicate the problem. I tried a 23.01 system here and I could create a BE named 0 and then delete it successfully. I created it again, then edited it successfully, then deleted it successfully. All without errors.
Updated by Mark Grant about 1 year ago
to get the initial issue;
what i did; i didnt read the limitation of what characters could be used, and used a "-" instead of the "_" as part of the name
i dont remember the name i used exactly, but it tossed the name i used, gave me the error i posted above, and just created it with "0" anyway
just tried it again with a couple combinations but i didnt duplicate it. would the config file help debug it or ?
Updated by Mark Grant about 1 year ago
did some more trials, and found if i just use the date as 20230306 it does it.
named it 20230306, the other day i named it that date of 20230304
clone from default
description was "Everything works, dmz zone". the other day it was "Everything works after update"
this time it created an environment labeled "1". so i guess it is just going to increment for these rogue named environments.
it also cannot be erased, getting the same error 3
Updated by Mark Grant about 1 year ago
more experimentation
if i create a new environment with the same name as the old damaged ones (now 0 or 1) it creates a new one with the next sequential number, in my case "2". so i have three environments that cannot be deleted via the gui.
Updated by Chris W about 1 year ago
- File Screenshot from 2023-03-18 11-51-00.png Screenshot from 2023-03-18 11-51-00.png added
- File Screenshot from 2023-03-18 11-56-56.png Screenshot from 2023-03-18 11-56-56.png added
- File Screenshot from 2023-03-18 11-50-50.png Screenshot from 2023-03-18 11-50-50.png added
- Status changed from Feedback to Confirmed
I was able to reproduce this by cloning the default environment, naming it 20230318 (today's date), no description. Click Save. It gets renamed to just 0. Then trying to delete or activate it results in Unable to activate boot environment "0" . Error: 3. However if I click the play icon on that cloned entry, the dated name I gave it is available in the dropdown menu and it appears to boot normally, but then the GUI reports it's still on the default boot environment after logging back in.
It appears that using all numbers in the name is a problem. This results in the incremented 0, 1, 2, etc. names and these environments are unusable and cannot be deleted. It also appears that those names cannot be edited, and trying to do so just results in an additional environment entry with the new name, but the incremented number of the bootloader you try to edit is still there.
Adding even one letter to the name when cloning or creating bypasses all this and works as expected. I didn't see any issues when adding - or _ to the name when also using a letter.
Updated by Christopher Cope about 1 year ago
Updated by Chris W about 1 year ago
The patch works well. I'm not hitting any of the problems I encountered previously. It only applies to the currently active boot environment so if you like to keep multiple available, you will need to boot each environment (including the auto_ created environments made before a pfSense upgrade) and apply the patch from within each one.
Updated by Mark Grant about 1 year ago
i installed the patch.
it renamed the two broken boot environments with the name i originally gave them, swapping it for the '0' or '1' name it was giving me
.
but when i go to erase them, it wont. now i get an error 'unable to delete boot environment '20230305', Error 21"
so progress since the names are now correct, but not quite fixed yet. and a different error number
more testing; i found that although the name is now correct, if i create a new clone off one of the 'broken' environments, it wont let me erase the original.
but if i erase the new/cloned one first, then i can erase the original/faulty environment. This is exactly what truenas had a couple years ago.
so im not sure yet if its entirely fixed. i will poke around with it tomorrow for a bit. for now i do have the faulty/now renamed ones deleted, and everything else works, so perhaps it was just a remnant from the broken names?
Updated by Jim Pingle about 1 year ago
- Subject changed from Cannot edit or delete ZFS Boot Environment named ``0`` to Cannot edit or delete ZFS Boot Environment with a name containing only numbers
- Status changed from Pull Request Review to New
The current patch was merged into dev builds last week, but since there is still an issue with the patch applied, moving this back to New.
Updated by Jim Pingle about 1 year ago
- Has duplicate Bug #14158: Unable to delete boot environment "X". Error 3 added
Updated by Mark Grant about 1 year ago
just want to be precise so you dont spend time on this if you dont have to;
the patch fixed the issue regarding naming, BUT i had boot environments that were created after those damaged(?) environments and it wasnt allowing me to erase the original issue boot environments (the ones the patch renamed properly).
but when i deleted those boot environments that were created after the damaged two, it allowed me to delete those original ones as well.
now it works ok. and i havent seen any issues post those deletions
so it may be done, since the patch fixed the improper naming issue etc.
fyi.
Updated by Jim Pingle about 1 year ago
OK, it may still be worth a quick look to see if we can make that smoother in case users are stuck with the problem environments created before the patch. But if what we have is good enough then we can close this out.
Updated by Christopher Cope about 1 year ago
- Status changed from New to Resolved
Did some more testing. The other error seems to be unrelated to this issue. I created another redmine to track it. https://redmine.pfsense.org/issues/14224