-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to update Flatcar server - /boot full #1461
Comments
Hello, There are two issues here that need to be checked. Firstly, as a baseline, I verified the upgrade path from 3815.2.1 to stable 3815.2.3, and the /boot was about 47% full before update and 89% full after update. This means that either your environment had an already 50% /boot partition used before update or something happened during the update process that consumed more space than it should have. Can you confirm that the used space of /boot before the update was around 47%? Also, if you can provide the output of this tree command to investigate what is consuming that space (more info on flatcar/scripts#1731): tree -sifF /boot | sort -k2 -rn Secondly, the update client should be fixed to error out and present a descriptive error message when this situation is happening, and then revert the update. Can you please provide the url to the image you first used to see if the issue can be properly reproduced? I assume you have Proxmox with KVM as a hypervisor. Thank you. |
@bignay2000 you can install the |
file system consistency check - fsck appears to have ran and left this file behind. https://en.wikipedia.org/wiki/Fsck - per this article, BTRS can trigger an automatic consistency check and then leave this behind. So looks like their needs to be a third fix here to write *.REC files somewhere else on the drive? |
I am trying to leave this server broken so we can figure out root cause.. so don't want to fix the scp issue trying to get tree on the file system... Let me know if I can provide more information |
it is great that you found the file that gobbled up the space, The only thing that I can think of is a data corruption issue that happened from unknown hardware or maybe network transitory issues. Maybe @jepio has more insight on this change and if it could have changed anything if it is a software issue (flatcar/update_engine@53262f6#diff-3f98f459f8b031989459690e30f38f48446d57c3355aaec9badbb98621c4832dR53)?
Thanks. |
Also, note the vmlinuz-a size, which I think it was vmlinuz-b during the upgrade -- it has a trimmed down size of only 16MB, which means that the fsck000 file was already there before the upgrade was tried. |
@ader1990 the btrfs change is for mounting the @bignay2000 can you share the outputs of
Did you machine crash during an update? Check Otherwise I don't think there is any more forensics to do here: remove the |
hiveadmin@jenkinsdockerslave-n1 ~ $ mount |
hiveadmin@jenkinsdockerslave-n1 ~ $ df -h |
Deleted the /boot/FSCK0000.REC 53 MB file
Update found
Disk Free after update
Updated successfully:
|
I found that the /etc/ssh/sshd_config had an invalid line and no longer matched the ignitton settings. Once I updated to match, scp from the MacBook started working. So the SCP not working is out of scope of this ticket. |
zip of all journal logs starting Mar 03 23:13:28 to current date. |
Description
update_engine_client -update incorrectly reports no update available when trying to update from stable 3815.2.1 to stable 3815.2.3.
flatcar-update --to-version 3815.2.3 correctly fails but with a generic "Error: update failed" error.
df -h shows /boot is 100% used. Found /boot/FSCK0000.REC 53 MB extra file as compared to other servers. /boot is only 127 MB total space.
Impact
Server is configured to check for updates on Thursdays and if found apply and reboot. This server missed 2 updates, it should have automatically applied stable 3815.2.2 and then applied 3815.2.3
Unable to manually update to stable 3815.2.3.
Environment and steps to reproduce
Server was built on Sun Sep 3 16:57:33 2023
Flatcar Container Linux by Kinvolk stable 3815.2.1
Flatcar runs in a VM on Proxmox 8.2.2
Note that FSCK can be configured to only run every X number of reboots, so may need to see if Flatcar runs FSCK on every boot or what triggers it.
Expected behavior
Additional information
The text was updated successfully, but these errors were encountered: