Merge ~sil2100/cloud-initramfs-tools:growroot-do-not-waitroot into cloud-initramfs-tools:master
| Status: | Needs review |
|---|---|
| Proposed branch: | ~sil2100/cloud-initramfs-tools:growroot-do-not-waitroot |
| Merge into: | cloud-initramfs-tools:master |
| Diff against target: |
21 lines (+4/-4) 1 file modified
growroot/scripts/local-bottom/growroot (+4/-4) |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| cloud-initramfs-tools | Pending | ||
|
Review via email:
|
|||
Commit message
When performing growroot, we don't need to perform a wait-for-root call as we already waited for the whole of udev to settle before that.
Description of the change
When performing growroot, we don't need to perform a wait-for-root call as we already waited for the whole of udev to settle before that.
The reason I'm proposing this change is actually as a workaround to a weird problem I have encountered with growpart and udev (might be kernel related?). Basically the problem there is that after growpart the rootfs block device loses all the ID_* udev properties, and wait-for-root basically loops until timeout looking for ID_FS_TYPE. Yes, this is a real bug that we need to chase down, but I think that's a separate thing.
I don't think there is *any* merit in doing a `wait-for-root` here as it was. In the regular local initrd setup, wait-for-root is (if I understand correctly) used to wait for the root device to be fully available without having to wait for the whole of udev to settle (per the comment in scripts/local's local_device_
So even though this is a workaround to get growroot working in this weird broken usecase, I think either way this call is redundant and doesn't make any sense to be there. Looks like it got copied over just-in-case anyway. Though, maybe I'm missing context and it's needed? If yes, please comment!
| Scott Moser (smoser) wrote | # |
There was an error fetching revisions from git servers. Please try again in a few minutes. If the problem persists, contact Launchpad support.
well, lots of things have changed since this code was written and it probably did take a safe approach even then. Generally speaking, one 'settle' or (wait-for-root) immediately after another is going to happen "real fast", so its not really wasteful.
In theory, we've worked out all the bugs in growpart at cloud-utils version 0.32, and there is no longer any need for *any* settle as growpart should not return until everything has been done. (see 6b98f49ffb2c7, 957ba4cff0, d99b2d7664d5).
that might be something to consider.
I won't approve or deny this, simply because I don't really have the time to think it all the way through. I'll let someone else do that.