Skip to content
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

Run eos-firstboot a second time on existing installs #410

Merged
merged 1 commit into from
Jun 5, 2024

Conversation

wjt
Copy link
Member

@wjt wjt commented Jun 4, 2024

An alternative approach to #408.


In new dual-boot installs of 6.0.0, eos-firstboot did not correctly grow the filesystem due to the bug fixed in commit
56aea35.

We now want to run it a second time. Ideally we would only trigger it on affected dual-boot systems; but it is harder to detect that case than to run eos-firstboot again and have resize2fs gracefully do nothing.

While we could easily run a unit only on dual-boot systems with:

ConditionKernelCommandLine=endless.image.device
ConditionKernelCommandLine=!endless.live_boot

to do this only once requires a second unit with its own new flag file. So rather than introducing a second flag file, let's harmlessly re-run this unit once on all systems, and take the opportunity to move the flag file out of the top-level of /var to /var/lib/eos-firstboot.

https://phabricator.endlessm.com/T35432

In new dual-boot installs of 6.0.0, eos-firstboot did not correctly grow
the filesystem due to the bug fixed in commit
56aea35.

We now want to run it a second time. Ideally we would only trigger it on
affected dual-boot systems; but it is harder to detect that case than to
run eos-firstboot again and have resize2fs gracefully do nothing.

While we could easily run a unit only on dual-boot systems with:

    ConditionKernelCommandLine=endless.image.device
    ConditionKernelCommandLine=!endless.live_boot

to do this only once requires a second unit with its own new flag file.
So rather than introducing a second flag file, let's harmlessly re-run
this unit once on all systems, and take the opportunity to move the flag
file out of the top-level of /var to /var/lib/eos-firstboot.

https://phabricator.endlessm.com/T35432
@wjt
Copy link
Member Author

wjt commented Jun 4, 2024

Draft because untested.

I also have a mild concern that there may exist other devices out there where the filesystem and partition don't match, and so unexpectedly running resize2fs may not in fact be harmful. But I'm struggling to think of a non-contrived situation where this would happen & be a problem.

@wjt wjt marked this pull request as ready for review June 5, 2024 09:32
@wjt
Copy link
Member Author

wjt commented Jun 5, 2024

I tested this on a dual-boot system in the state where the partition had been resized but not the filesystem; as expected, the job re-ran once and grew the filesystem.

@wjt wjt requested a review from dbnicholson June 5, 2024 21:08
@dbnicholson
Copy link
Member

I also have a mild concern that there may exist other devices out there where the filesystem and partition don't match, and so unexpectedly running resize2fs may not in fact be harmful. But I'm struggling to think of a non-contrived situation where this would happen & be a problem.

I paused a bit on this. If we do run into a situation where old systems can't run the resize2fs sequence again, we can change the script like:

need_resize=false
[ -f /var/lib/eos-firstboot ] || need_resize=true
[ -f /var/eos-booted ]] && relevant_dual_boot_setup && need_resize=true
if "$need_resize"; then
    resize2fs "${root_part}"
fi

> /var/lib/eos-firstboot

@dbnicholson dbnicholson merged commit d73f66e into master Jun 5, 2024
2 checks passed
@dbnicholson dbnicholson deleted the T35432-rerun-eos-firstboot-once branch June 5, 2024 22:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants