Could not prepare Boot variable: No space left on device grub-install: error: efibootmgr failed to register...
getting below error. But I think available space is enough for this (use% is 9%)
Can you please help us to resolve this ?
lab@lab:~$ sudo -E apt-get install subversion apache2-utils
Reading package lists... Done
Building dependency tree
Reading state information... Done
subversion is already the newest version (1.9.7-4ubuntu1).
apache2-utils is already the newest version (2.4.29-1ubuntu4.3).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] Y
Setting up grub-efi-amd64-signed (1.93.4+2.02-2ubuntu8.3) ...
Installing for x86_64-efi platform.
Could not prepare Boot variable: No space left on device
grub-install: error: efibootmgr failed to register the boot entry: Input/output error.
dpkg: error processing package grub-efi-amd64-signed (--configure):
installed grub-efi-amd64-signed package post-installation script subprocess returned error exit status 1
dpkg: dependency problems prevent processing triggers for shim-signed:
shim-signed depends on grub-efi-amd64-signed; however:
Package grub-efi-amd64-signed is not configured yet.
dpkg: error processing package shim-signed (--configure):
dependency problems - leaving triggers unprocessed
Errors were encountered while processing:
grub-efi-amd64-signed
shim-signed
E: Sub-process /usr/bin/dpkg returned an error code (1)
lab@lab:~$ df -k .
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda2 479152840 37427836 417315612 9% /
apt
|
show 7 more comments
getting below error. But I think available space is enough for this (use% is 9%)
Can you please help us to resolve this ?
lab@lab:~$ sudo -E apt-get install subversion apache2-utils
Reading package lists... Done
Building dependency tree
Reading state information... Done
subversion is already the newest version (1.9.7-4ubuntu1).
apache2-utils is already the newest version (2.4.29-1ubuntu4.3).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] Y
Setting up grub-efi-amd64-signed (1.93.4+2.02-2ubuntu8.3) ...
Installing for x86_64-efi platform.
Could not prepare Boot variable: No space left on device
grub-install: error: efibootmgr failed to register the boot entry: Input/output error.
dpkg: error processing package grub-efi-amd64-signed (--configure):
installed grub-efi-amd64-signed package post-installation script subprocess returned error exit status 1
dpkg: dependency problems prevent processing triggers for shim-signed:
shim-signed depends on grub-efi-amd64-signed; however:
Package grub-efi-amd64-signed is not configured yet.
dpkg: error processing package shim-signed (--configure):
dependency problems - leaving triggers unprocessed
Errors were encountered while processing:
grub-efi-amd64-signed
shim-signed
E: Sub-process /usr/bin/dpkg returned an error code (1)
lab@lab:~$ df -k .
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda2 479152840 37427836 417315612 9% /
apt
Welcome to Ask Ubuntu. It mentions EFI so I'd check to see if you have a separate /boot partition, and it has space first. Next the most common cause; do you have inodes left?df -hi
(the -h isn't needed, I just hate find larger numbers harder to read).
– guiverc
Sep 6 '18 at 5:29
lab@lab:~$ df -h Filesystem Size Used Avail Use% Mounted on udev 935M 0 935M 0% /dev tmpfs 193M 1.5M 192M 1% /run /dev/sda2 457G 36G 399G 9% / /dev/sda1 511M 4.7M 507M 1% /boot/efi
– Shinu Thombikkodan
Sep 6 '18 at 5:51
1
Please edit your question, and add additional info there (it allows far better formatting than comments do, plus better edit capability - even if you forget using the {} for 'code' quotes; others can do it for you)
– guiverc
Sep 6 '18 at 5:59
1
I don't see the inode info in your question? It's unreadable in comments sorry, and it was this info I was after moved to your question. You can reply to me or any user via comments, but additional info (such as thedf -h
suggested in my first comment) should go up in your question, along with subsequent info you've wrongly put in comments.. If new users come and read your question looking to help, they'll see what you add in questions, but often ignore comments :)
– guiverc
Sep 6 '18 at 6:16
1
@guiverc Although I also have a hard time reading the details in the comments, I doubt inodes are exhausted in the OP’s case. I can’t see any 100% used, the numbers are generally very low. There are zero inodes for/dev/sda1
aka/boot/efi
which probably means it’s a FAT partition.
– Melebius
Sep 6 '18 at 10:08
|
show 7 more comments
getting below error. But I think available space is enough for this (use% is 9%)
Can you please help us to resolve this ?
lab@lab:~$ sudo -E apt-get install subversion apache2-utils
Reading package lists... Done
Building dependency tree
Reading state information... Done
subversion is already the newest version (1.9.7-4ubuntu1).
apache2-utils is already the newest version (2.4.29-1ubuntu4.3).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] Y
Setting up grub-efi-amd64-signed (1.93.4+2.02-2ubuntu8.3) ...
Installing for x86_64-efi platform.
Could not prepare Boot variable: No space left on device
grub-install: error: efibootmgr failed to register the boot entry: Input/output error.
dpkg: error processing package grub-efi-amd64-signed (--configure):
installed grub-efi-amd64-signed package post-installation script subprocess returned error exit status 1
dpkg: dependency problems prevent processing triggers for shim-signed:
shim-signed depends on grub-efi-amd64-signed; however:
Package grub-efi-amd64-signed is not configured yet.
dpkg: error processing package shim-signed (--configure):
dependency problems - leaving triggers unprocessed
Errors were encountered while processing:
grub-efi-amd64-signed
shim-signed
E: Sub-process /usr/bin/dpkg returned an error code (1)
lab@lab:~$ df -k .
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda2 479152840 37427836 417315612 9% /
apt
getting below error. But I think available space is enough for this (use% is 9%)
Can you please help us to resolve this ?
lab@lab:~$ sudo -E apt-get install subversion apache2-utils
Reading package lists... Done
Building dependency tree
Reading state information... Done
subversion is already the newest version (1.9.7-4ubuntu1).
apache2-utils is already the newest version (2.4.29-1ubuntu4.3).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] Y
Setting up grub-efi-amd64-signed (1.93.4+2.02-2ubuntu8.3) ...
Installing for x86_64-efi platform.
Could not prepare Boot variable: No space left on device
grub-install: error: efibootmgr failed to register the boot entry: Input/output error.
dpkg: error processing package grub-efi-amd64-signed (--configure):
installed grub-efi-amd64-signed package post-installation script subprocess returned error exit status 1
dpkg: dependency problems prevent processing triggers for shim-signed:
shim-signed depends on grub-efi-amd64-signed; however:
Package grub-efi-amd64-signed is not configured yet.
dpkg: error processing package shim-signed (--configure):
dependency problems - leaving triggers unprocessed
Errors were encountered while processing:
grub-efi-amd64-signed
shim-signed
E: Sub-process /usr/bin/dpkg returned an error code (1)
lab@lab:~$ df -k .
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda2 479152840 37427836 417315612 9% /
apt
apt
edited Sep 6 '18 at 11:12
guiverc
4,09811522
4,09811522
asked Sep 6 '18 at 5:24
Shinu Thombikkodan
212
212
Welcome to Ask Ubuntu. It mentions EFI so I'd check to see if you have a separate /boot partition, and it has space first. Next the most common cause; do you have inodes left?df -hi
(the -h isn't needed, I just hate find larger numbers harder to read).
– guiverc
Sep 6 '18 at 5:29
lab@lab:~$ df -h Filesystem Size Used Avail Use% Mounted on udev 935M 0 935M 0% /dev tmpfs 193M 1.5M 192M 1% /run /dev/sda2 457G 36G 399G 9% / /dev/sda1 511M 4.7M 507M 1% /boot/efi
– Shinu Thombikkodan
Sep 6 '18 at 5:51
1
Please edit your question, and add additional info there (it allows far better formatting than comments do, plus better edit capability - even if you forget using the {} for 'code' quotes; others can do it for you)
– guiverc
Sep 6 '18 at 5:59
1
I don't see the inode info in your question? It's unreadable in comments sorry, and it was this info I was after moved to your question. You can reply to me or any user via comments, but additional info (such as thedf -h
suggested in my first comment) should go up in your question, along with subsequent info you've wrongly put in comments.. If new users come and read your question looking to help, they'll see what you add in questions, but often ignore comments :)
– guiverc
Sep 6 '18 at 6:16
1
@guiverc Although I also have a hard time reading the details in the comments, I doubt inodes are exhausted in the OP’s case. I can’t see any 100% used, the numbers are generally very low. There are zero inodes for/dev/sda1
aka/boot/efi
which probably means it’s a FAT partition.
– Melebius
Sep 6 '18 at 10:08
|
show 7 more comments
Welcome to Ask Ubuntu. It mentions EFI so I'd check to see if you have a separate /boot partition, and it has space first. Next the most common cause; do you have inodes left?df -hi
(the -h isn't needed, I just hate find larger numbers harder to read).
– guiverc
Sep 6 '18 at 5:29
lab@lab:~$ df -h Filesystem Size Used Avail Use% Mounted on udev 935M 0 935M 0% /dev tmpfs 193M 1.5M 192M 1% /run /dev/sda2 457G 36G 399G 9% / /dev/sda1 511M 4.7M 507M 1% /boot/efi
– Shinu Thombikkodan
Sep 6 '18 at 5:51
1
Please edit your question, and add additional info there (it allows far better formatting than comments do, plus better edit capability - even if you forget using the {} for 'code' quotes; others can do it for you)
– guiverc
Sep 6 '18 at 5:59
1
I don't see the inode info in your question? It's unreadable in comments sorry, and it was this info I was after moved to your question. You can reply to me or any user via comments, but additional info (such as thedf -h
suggested in my first comment) should go up in your question, along with subsequent info you've wrongly put in comments.. If new users come and read your question looking to help, they'll see what you add in questions, but often ignore comments :)
– guiverc
Sep 6 '18 at 6:16
1
@guiverc Although I also have a hard time reading the details in the comments, I doubt inodes are exhausted in the OP’s case. I can’t see any 100% used, the numbers are generally very low. There are zero inodes for/dev/sda1
aka/boot/efi
which probably means it’s a FAT partition.
– Melebius
Sep 6 '18 at 10:08
Welcome to Ask Ubuntu. It mentions EFI so I'd check to see if you have a separate /boot partition, and it has space first. Next the most common cause; do you have inodes left?
df -hi
(the -h isn't needed, I just hate find larger numbers harder to read).– guiverc
Sep 6 '18 at 5:29
Welcome to Ask Ubuntu. It mentions EFI so I'd check to see if you have a separate /boot partition, and it has space first. Next the most common cause; do you have inodes left?
df -hi
(the -h isn't needed, I just hate find larger numbers harder to read).– guiverc
Sep 6 '18 at 5:29
lab@lab:~$ df -h Filesystem Size Used Avail Use% Mounted on udev 935M 0 935M 0% /dev tmpfs 193M 1.5M 192M 1% /run /dev/sda2 457G 36G 399G 9% / /dev/sda1 511M 4.7M 507M 1% /boot/efi
– Shinu Thombikkodan
Sep 6 '18 at 5:51
lab@lab:~$ df -h Filesystem Size Used Avail Use% Mounted on udev 935M 0 935M 0% /dev tmpfs 193M 1.5M 192M 1% /run /dev/sda2 457G 36G 399G 9% / /dev/sda1 511M 4.7M 507M 1% /boot/efi
– Shinu Thombikkodan
Sep 6 '18 at 5:51
1
1
Please edit your question, and add additional info there (it allows far better formatting than comments do, plus better edit capability - even if you forget using the {} for 'code' quotes; others can do it for you)
– guiverc
Sep 6 '18 at 5:59
Please edit your question, and add additional info there (it allows far better formatting than comments do, plus better edit capability - even if you forget using the {} for 'code' quotes; others can do it for you)
– guiverc
Sep 6 '18 at 5:59
1
1
I don't see the inode info in your question? It's unreadable in comments sorry, and it was this info I was after moved to your question. You can reply to me or any user via comments, but additional info (such as the
df -h
suggested in my first comment) should go up in your question, along with subsequent info you've wrongly put in comments.. If new users come and read your question looking to help, they'll see what you add in questions, but often ignore comments :)– guiverc
Sep 6 '18 at 6:16
I don't see the inode info in your question? It's unreadable in comments sorry, and it was this info I was after moved to your question. You can reply to me or any user via comments, but additional info (such as the
df -h
suggested in my first comment) should go up in your question, along with subsequent info you've wrongly put in comments.. If new users come and read your question looking to help, they'll see what you add in questions, but often ignore comments :)– guiverc
Sep 6 '18 at 6:16
1
1
@guiverc Although I also have a hard time reading the details in the comments, I doubt inodes are exhausted in the OP’s case. I can’t see any 100% used, the numbers are generally very low. There are zero inodes for
/dev/sda1
aka /boot/efi
which probably means it’s a FAT partition.– Melebius
Sep 6 '18 at 10:08
@guiverc Although I also have a hard time reading the details in the comments, I doubt inodes are exhausted in the OP’s case. I can’t see any 100% used, the numbers are generally very low. There are zero inodes for
/dev/sda1
aka /boot/efi
which probably means it’s a FAT partition.– Melebius
Sep 6 '18 at 10:08
|
show 7 more comments
2 Answers
2
active
oldest
votes
There have been a number of reports that if the NVRAM is more than 50% used, the efibootmgr will fail because there's a concern about being able to garbage collect EFI variables properly, or some such. Unfortunately, I couldn't find a clear way to determine the used/free space in NVRAM, so I'm going on suspicion.
There are a number of potential solutions to this:
1) Clear the dump files
grub stores efi logs in /sys/fs/efi/efivars/dump-*
Try deleting these to see if that's enough to bring the used space down. Then run apt -f install
to see if the error has changed.
2) BIOS upgrade
If your hardware provider has a BIOS/EFI upgrade, then I'd recommend doing that also, then try apt -f install
again.
3) LAST RESORT - DISABLE EFI CHECK
It's a little dangerous, because you could technically fill your NVRAM to a point were it's unbootable. However, I have used this process successfully on a Dell R420.
To override the check, add "efi_no_storage_paranoia" to the kernel option. To do this:
- Append "efi_no_storage_paranoia" to the GRUB_CMDLINE_LINUX_DEFAULT and GRUB_CMDLINE_LINUX variables in
/etc/default/grub
- Update grub by running
sudo update-grub
- Reboot
- Run
apt -f install
For safety, I reverse this process afterward also. Kernel safety override parameters are not something you want to leave lying around!
add a comment |
I was able to fix the error by disabling the Compatibility Support Module (CSM) in my UEFI setup. After rebooting, the package update for 'grub-efi-amd64-signed' went through without issue.
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "89"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1072618%2fcould-not-prepare-boot-variable-no-space-left-on-device-grub-install-error-ef%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
There have been a number of reports that if the NVRAM is more than 50% used, the efibootmgr will fail because there's a concern about being able to garbage collect EFI variables properly, or some such. Unfortunately, I couldn't find a clear way to determine the used/free space in NVRAM, so I'm going on suspicion.
There are a number of potential solutions to this:
1) Clear the dump files
grub stores efi logs in /sys/fs/efi/efivars/dump-*
Try deleting these to see if that's enough to bring the used space down. Then run apt -f install
to see if the error has changed.
2) BIOS upgrade
If your hardware provider has a BIOS/EFI upgrade, then I'd recommend doing that also, then try apt -f install
again.
3) LAST RESORT - DISABLE EFI CHECK
It's a little dangerous, because you could technically fill your NVRAM to a point were it's unbootable. However, I have used this process successfully on a Dell R420.
To override the check, add "efi_no_storage_paranoia" to the kernel option. To do this:
- Append "efi_no_storage_paranoia" to the GRUB_CMDLINE_LINUX_DEFAULT and GRUB_CMDLINE_LINUX variables in
/etc/default/grub
- Update grub by running
sudo update-grub
- Reboot
- Run
apt -f install
For safety, I reverse this process afterward also. Kernel safety override parameters are not something you want to leave lying around!
add a comment |
There have been a number of reports that if the NVRAM is more than 50% used, the efibootmgr will fail because there's a concern about being able to garbage collect EFI variables properly, or some such. Unfortunately, I couldn't find a clear way to determine the used/free space in NVRAM, so I'm going on suspicion.
There are a number of potential solutions to this:
1) Clear the dump files
grub stores efi logs in /sys/fs/efi/efivars/dump-*
Try deleting these to see if that's enough to bring the used space down. Then run apt -f install
to see if the error has changed.
2) BIOS upgrade
If your hardware provider has a BIOS/EFI upgrade, then I'd recommend doing that also, then try apt -f install
again.
3) LAST RESORT - DISABLE EFI CHECK
It's a little dangerous, because you could technically fill your NVRAM to a point were it's unbootable. However, I have used this process successfully on a Dell R420.
To override the check, add "efi_no_storage_paranoia" to the kernel option. To do this:
- Append "efi_no_storage_paranoia" to the GRUB_CMDLINE_LINUX_DEFAULT and GRUB_CMDLINE_LINUX variables in
/etc/default/grub
- Update grub by running
sudo update-grub
- Reboot
- Run
apt -f install
For safety, I reverse this process afterward also. Kernel safety override parameters are not something you want to leave lying around!
add a comment |
There have been a number of reports that if the NVRAM is more than 50% used, the efibootmgr will fail because there's a concern about being able to garbage collect EFI variables properly, or some such. Unfortunately, I couldn't find a clear way to determine the used/free space in NVRAM, so I'm going on suspicion.
There are a number of potential solutions to this:
1) Clear the dump files
grub stores efi logs in /sys/fs/efi/efivars/dump-*
Try deleting these to see if that's enough to bring the used space down. Then run apt -f install
to see if the error has changed.
2) BIOS upgrade
If your hardware provider has a BIOS/EFI upgrade, then I'd recommend doing that also, then try apt -f install
again.
3) LAST RESORT - DISABLE EFI CHECK
It's a little dangerous, because you could technically fill your NVRAM to a point were it's unbootable. However, I have used this process successfully on a Dell R420.
To override the check, add "efi_no_storage_paranoia" to the kernel option. To do this:
- Append "efi_no_storage_paranoia" to the GRUB_CMDLINE_LINUX_DEFAULT and GRUB_CMDLINE_LINUX variables in
/etc/default/grub
- Update grub by running
sudo update-grub
- Reboot
- Run
apt -f install
For safety, I reverse this process afterward also. Kernel safety override parameters are not something you want to leave lying around!
There have been a number of reports that if the NVRAM is more than 50% used, the efibootmgr will fail because there's a concern about being able to garbage collect EFI variables properly, or some such. Unfortunately, I couldn't find a clear way to determine the used/free space in NVRAM, so I'm going on suspicion.
There are a number of potential solutions to this:
1) Clear the dump files
grub stores efi logs in /sys/fs/efi/efivars/dump-*
Try deleting these to see if that's enough to bring the used space down. Then run apt -f install
to see if the error has changed.
2) BIOS upgrade
If your hardware provider has a BIOS/EFI upgrade, then I'd recommend doing that also, then try apt -f install
again.
3) LAST RESORT - DISABLE EFI CHECK
It's a little dangerous, because you could technically fill your NVRAM to a point were it's unbootable. However, I have used this process successfully on a Dell R420.
To override the check, add "efi_no_storage_paranoia" to the kernel option. To do this:
- Append "efi_no_storage_paranoia" to the GRUB_CMDLINE_LINUX_DEFAULT and GRUB_CMDLINE_LINUX variables in
/etc/default/grub
- Update grub by running
sudo update-grub
- Reboot
- Run
apt -f install
For safety, I reverse this process afterward also. Kernel safety override parameters are not something you want to leave lying around!
edited Sep 10 '18 at 23:25
answered Sep 8 '18 at 10:09
tudor
2,46341844
2,46341844
add a comment |
add a comment |
I was able to fix the error by disabling the Compatibility Support Module (CSM) in my UEFI setup. After rebooting, the package update for 'grub-efi-amd64-signed' went through without issue.
add a comment |
I was able to fix the error by disabling the Compatibility Support Module (CSM) in my UEFI setup. After rebooting, the package update for 'grub-efi-amd64-signed' went through without issue.
add a comment |
I was able to fix the error by disabling the Compatibility Support Module (CSM) in my UEFI setup. After rebooting, the package update for 'grub-efi-amd64-signed' went through without issue.
I was able to fix the error by disabling the Compatibility Support Module (CSM) in my UEFI setup. After rebooting, the package update for 'grub-efi-amd64-signed' went through without issue.
answered Dec 22 '18 at 1:16
user906466
1
1
add a comment |
add a comment |
Thanks for contributing an answer to Ask Ubuntu!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1072618%2fcould-not-prepare-boot-variable-no-space-left-on-device-grub-install-error-ef%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Welcome to Ask Ubuntu. It mentions EFI so I'd check to see if you have a separate /boot partition, and it has space first. Next the most common cause; do you have inodes left?
df -hi
(the -h isn't needed, I just hate find larger numbers harder to read).– guiverc
Sep 6 '18 at 5:29
lab@lab:~$ df -h Filesystem Size Used Avail Use% Mounted on udev 935M 0 935M 0% /dev tmpfs 193M 1.5M 192M 1% /run /dev/sda2 457G 36G 399G 9% / /dev/sda1 511M 4.7M 507M 1% /boot/efi
– Shinu Thombikkodan
Sep 6 '18 at 5:51
1
Please edit your question, and add additional info there (it allows far better formatting than comments do, plus better edit capability - even if you forget using the {} for 'code' quotes; others can do it for you)
– guiverc
Sep 6 '18 at 5:59
1
I don't see the inode info in your question? It's unreadable in comments sorry, and it was this info I was after moved to your question. You can reply to me or any user via comments, but additional info (such as the
df -h
suggested in my first comment) should go up in your question, along with subsequent info you've wrongly put in comments.. If new users come and read your question looking to help, they'll see what you add in questions, but often ignore comments :)– guiverc
Sep 6 '18 at 6:16
1
@guiverc Although I also have a hard time reading the details in the comments, I doubt inodes are exhausted in the OP’s case. I can’t see any 100% used, the numbers are generally very low. There are zero inodes for
/dev/sda1
aka/boot/efi
which probably means it’s a FAT partition.– Melebius
Sep 6 '18 at 10:08