| 2023-10-16 12:21:17 |
Thibf |
bug |
|
|
added bug |
| 2023-10-16 14:25:33 |
Robie Basak |
uvtool: status |
New |
Triaged |
|
| 2023-10-16 14:26:17 |
Robie Basak |
summary |
System is booting up prevent ssh at startup |
"System is booting up. Unprivileged users are not permitted to log in yet." causes wait subcommand to fail |
|
| 2023-10-16 16:42:02 |
Robie Basak |
bug task added |
|
cloud-init (Ubuntu) |
|
| 2023-10-16 16:42:14 |
Robie Basak |
tags |
|
regression-update |
|
| 2023-10-17 10:07:51 |
Po-Hsu Lin |
bug |
|
|
added subscriber Po-Hsu Lin |
| 2023-10-17 10:07:54 |
Launchpad Janitor |
cloud-init (Ubuntu): status |
New |
Confirmed |
|
| 2023-10-17 16:26:59 |
Robie Basak |
merge proposal linked |
|
https://code.launchpad.net/~thibf/uvtool/+git/uvtool/+merge/453689 |
|
| 2023-10-31 09:06:24 |
Robie Basak |
uvtool: status |
Triaged |
Fix Committed |
|
| 2023-10-31 09:06:38 |
Robie Basak |
bug task added |
|
uvtool (Ubuntu) |
|
| 2023-10-31 09:06:55 |
Robie Basak |
nominated for series |
|
Ubuntu Mantic |
|
| 2023-10-31 09:06:55 |
Robie Basak |
bug task added |
|
cloud-init (Ubuntu Mantic) |
|
| 2023-10-31 09:06:55 |
Robie Basak |
bug task added |
|
uvtool (Ubuntu Mantic) |
|
| 2023-10-31 09:06:55 |
Robie Basak |
nominated for series |
|
Ubuntu Lunar |
|
| 2023-10-31 09:06:55 |
Robie Basak |
bug task added |
|
cloud-init (Ubuntu Lunar) |
|
| 2023-10-31 09:06:55 |
Robie Basak |
bug task added |
|
uvtool (Ubuntu Lunar) |
|
| 2023-10-31 09:06:55 |
Robie Basak |
nominated for series |
|
Ubuntu Focal |
|
| 2023-10-31 09:06:55 |
Robie Basak |
bug task added |
|
cloud-init (Ubuntu Focal) |
|
| 2023-10-31 09:06:55 |
Robie Basak |
bug task added |
|
uvtool (Ubuntu Focal) |
|
| 2023-10-31 09:06:55 |
Robie Basak |
nominated for series |
|
Ubuntu Jammy |
|
| 2023-10-31 09:06:55 |
Robie Basak |
bug task added |
|
cloud-init (Ubuntu Jammy) |
|
| 2023-10-31 09:06:55 |
Robie Basak |
bug task added |
|
uvtool (Ubuntu Jammy) |
|
| 2023-10-31 09:07:08 |
Robie Basak |
uvtool (Ubuntu): status |
New |
Triaged |
|
| 2023-10-31 09:07:17 |
Robie Basak |
uvtool (Ubuntu Focal): status |
New |
Triaged |
|
| 2023-10-31 09:07:25 |
Robie Basak |
uvtool (Ubuntu Jammy): status |
New |
Triaged |
|
| 2023-10-31 09:07:34 |
Robie Basak |
uvtool (Ubuntu Lunar): status |
New |
Triaged |
|
| 2023-10-31 09:07:42 |
Robie Basak |
uvtool (Ubuntu Mantic): status |
New |
Triaged |
|
| 2023-10-31 13:20:21 |
Robie Basak |
uvtool (Ubuntu): status |
Triaged |
Fix Committed |
|
| 2023-10-31 13:27:38 |
Launchpad Janitor |
uvtool (Ubuntu): status |
Fix Committed |
Fix Released |
|
| 2023-11-02 13:42:38 |
Alberto Contreras |
cloud-init (Ubuntu): status |
Confirmed |
Fix Committed |
|
| 2023-11-02 13:42:56 |
Alberto Contreras |
cloud-init (Ubuntu Focal): status |
New |
Fix Committed |
|
| 2023-11-02 13:43:04 |
Alberto Contreras |
cloud-init (Ubuntu Jammy): status |
New |
Fix Committed |
|
| 2023-11-02 13:43:25 |
Alberto Contreras |
cloud-init (Ubuntu Lunar): status |
New |
Fix Committed |
|
| 2023-11-02 13:43:36 |
Alberto Contreras |
cloud-init (Ubuntu Mantic): status |
New |
Fix Committed |
|
| 2023-11-29 10:11:03 |
James Page |
uvtool (Ubuntu Mantic): assignee |
|
Agathe Porte (gagath) |
|
| 2024-01-17 09:06:44 |
James Page |
uvtool (Ubuntu Lunar): status |
Triaged |
Won't Fix |
|
| 2024-01-31 09:13:35 |
James Page |
description |
After doing `uvt-kvm wait`, we can expect to be able to ssh into the VMs.
That's not always the case as the ssh port can be up before PAM is setup:
`System is booting up. Unprivileged users are not permitted to log in yet. Please come back later. For technical details, see pam_nologin(8).`
This means that subsequent programs can't rely on `uvt-kvm wait` to know if the system is up, which defeats the purpose of this function and drives the complexity up in highly automated environment.
Personally, I see two ways to fix the wait to handle this case:
- Change the behavior of the created VM to avoid this edge case.
- Makes `uvt-kvm wait` smarter by actually establishing a communication to check if we really can login.
The last option seems less intrusive but will make the library more complex.
I'm not convinced that would be a reasonable default or would be better as an option to `uvt-kvm wait`. |
[ Impact ]
* An explanation of the effects of the bug on users and
* justification for backporting the fix to the stable release.
* In addition, it is helpful, but not required, to include an
explanation of how the upload fixes this bug.
[ Test Plan ]
* detailed instructions how to reproduce the bug
* these should allow someone who is not familiar with the affected
package to reproduce the bug and verify that the updated package fixes
the problem.
* if other testing is appropriate to perform before landing this update,
this should also be described here.
[ Where problems could occur ]
* Think about what the upload changes in the software. Imagine the change is
wrong or breaks something else: how would this show up?
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This must '''never''' be "None" or "Low", or entirely an argument as to why
your upload is low risk.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[ Other Info ]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[ Original Bug Report ]
After doing `uvt-kvm wait`, we can expect to be able to ssh into the VMs.
That's not always the case as the ssh port can be up before PAM is setup:
`System is booting up. Unprivileged users are not permitted to log in yet. Please come back later. For technical details, see pam_nologin(8).`
This means that subsequent programs can't rely on `uvt-kvm wait` to know if the system is up, which defeats the purpose of this function and drives the complexity up in highly automated environment.
Personally, I see two ways to fix the wait to handle this case:
- Change the behavior of the created VM to avoid this edge case.
- Makes `uvt-kvm wait` smarter by actually establishing a communication to check if we really can login.
The last option seems less intrusive but will make the library more complex.
I'm not convinced that would be a reasonable default or would be better as an option to `uvt-kvm wait`. |
|
| 2024-02-02 09:39:49 |
Agathe Porte |
description |
[ Impact ]
* An explanation of the effects of the bug on users and
* justification for backporting the fix to the stable release.
* In addition, it is helpful, but not required, to include an
explanation of how the upload fixes this bug.
[ Test Plan ]
* detailed instructions how to reproduce the bug
* these should allow someone who is not familiar with the affected
package to reproduce the bug and verify that the updated package fixes
the problem.
* if other testing is appropriate to perform before landing this update,
this should also be described here.
[ Where problems could occur ]
* Think about what the upload changes in the software. Imagine the change is
wrong or breaks something else: how would this show up?
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This must '''never''' be "None" or "Low", or entirely an argument as to why
your upload is low risk.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[ Other Info ]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[ Original Bug Report ]
After doing `uvt-kvm wait`, we can expect to be able to ssh into the VMs.
That's not always the case as the ssh port can be up before PAM is setup:
`System is booting up. Unprivileged users are not permitted to log in yet. Please come back later. For technical details, see pam_nologin(8).`
This means that subsequent programs can't rely on `uvt-kvm wait` to know if the system is up, which defeats the purpose of this function and drives the complexity up in highly automated environment.
Personally, I see two ways to fix the wait to handle this case:
- Change the behavior of the created VM to avoid this edge case.
- Makes `uvt-kvm wait` smarter by actually establishing a communication to check if we really can login.
The last option seems less intrusive but will make the library more complex.
I'm not convinced that would be a reasonable default or would be better as an option to `uvt-kvm wait`. |
[ Impact ]
The bug breaks `uvt-kvm wait` promise that the virtualized system is up and running. `uvt-kvm` naively waited for the ssh server to be up, but if the
ssh server is up before authentication (pam notably) is ready, the system is still not ready to use.
For that reason, all automation relying on it breaks and report failures blaming the underlying image instead of waiting for it to be really ready.
This fix will make `uvt-kvm wait` retry in case the login fails.
[ Test Plan ]
Use the patched uvt-kvm to start then wait for this image to come up:
http://cloud-images.ubuntu.com/releases/focal/release-20231011/ubuntu-20.04-server-cloudimg-amd64.img
This image was know to trigger this error, so verify ten times we can: start it, wait then ssh without any failure.
Verify also this with a previously working image such as http://cloud-images.ubuntu.com/daily/server/focal/20231003/focal-server-cloudimg-amd64.img
[ Where problems could occur ]
The retry mechanism could be triggered for other reasons than login error and slow down the whole process.
[ Original Bug Report ]
After doing `uvt-kvm wait`, we can expect to be able to ssh into the VMs.
That's not always the case as the ssh port can be up before PAM is setup:
`System is booting up. Unprivileged users are not permitted to log in yet. Please come back later. For technical details, see pam_nologin(8).`
This means that subsequent programs can't rely on `uvt-kvm wait` to know if the system is up, which defeats the purpose of this function and drives the complexity up in highly automated environment.
Personally, I see two ways to fix the wait to handle this case:
- Change the behavior of the created VM to avoid this edge case.
- Makes `uvt-kvm wait` smarter by actually establishing a communication to check if we really can login.
The last option seems less intrusive but will make the library more complex.
I'm not convinced that would be a reasonable default or would be better as an option to `uvt-kvm wait`. |
|
| 2024-02-02 09:40:22 |
Agathe Porte |
uvtool (Ubuntu Jammy): assignee |
|
Agathe Porte (gagath) |
|
| 2024-02-02 09:40:32 |
Agathe Porte |
uvtool (Ubuntu Focal): assignee |
|
Agathe Porte (gagath) |
|
| 2024-02-02 09:41:57 |
Agathe Porte |
attachment added |
|
uvtool_mantic.debdiff https://bugs.launchpad.net/ubuntu/focal/+source/uvtool/+bug/2039441/+attachment/5744301/+files/uvtool_mantic.debdiff |
|
| 2024-02-02 09:45:17 |
Agathe Porte |
attachment added |
|
uvtool_jammy.debdiff https://bugs.launchpad.net/ubuntu/focal/+source/uvtool/+bug/2039441/+attachment/5744302/+files/uvtool_jammy.debdiff |
|
| 2024-02-02 09:56:28 |
Agathe Porte |
attachment added |
|
uvtool_focal.debdiff https://bugs.launchpad.net/ubuntu/focal/+source/uvtool/+bug/2039441/+attachment/5744303/+files/uvtool_focal.debdiff |
|
| 2024-02-02 12:19:48 |
Ubuntu Foundations Team Bug Bot |
tags |
regression-update |
patch regression-update |
|
| 2024-02-02 12:19:53 |
Ubuntu Foundations Team Bug Bot |
bug |
|
|
added subscriber Ubuntu Sponsors |
| 2024-02-06 11:38:47 |
James Page |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2024-02-06 21:46:59 |
Ubuntu Archive Robot |
bug |
|
|
added subscriber James Page |
| 2024-02-07 09:17:57 |
James Page |
removed subscriber Ubuntu Sponsors |
|
|
|
| 2024-02-07 17:13:46 |
Robie Basak |
uvtool (Ubuntu Mantic): status |
Triaged |
Fix Committed |
|
| 2024-02-07 17:13:49 |
Robie Basak |
bug |
|
|
added subscriber SRU Verification |
| 2024-02-07 17:13:53 |
Robie Basak |
tags |
patch regression-update |
patch regression-update verification-needed verification-needed-mantic |
|
| 2024-02-07 17:14:16 |
Robie Basak |
uvtool (Ubuntu Jammy): status |
Triaged |
Fix Committed |
|
| 2024-02-07 17:14:22 |
Robie Basak |
tags |
patch regression-update verification-needed verification-needed-mantic |
patch regression-update verification-needed verification-needed-jammy verification-needed-mantic |
|
| 2024-02-07 17:14:40 |
Robie Basak |
uvtool (Ubuntu Focal): status |
Triaged |
Fix Committed |
|
| 2024-02-07 17:14:45 |
Robie Basak |
tags |
patch regression-update verification-needed verification-needed-jammy verification-needed-mantic |
patch regression-update verification-needed verification-needed-focal verification-needed-jammy verification-needed-mantic |
|
| 2024-03-06 15:33:39 |
Agathe Porte |
tags |
patch regression-update verification-needed verification-needed-focal verification-needed-jammy verification-needed-mantic |
patch regression-update verification-done verification-done-focal verification-done-jammy verification-done-mantic |
|
| 2024-03-07 17:16:10 |
Launchpad Janitor |
uvtool (Ubuntu Mantic): status |
Fix Committed |
Fix Released |
|
| 2024-03-07 17:16:15 |
Andreas Hasenack |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2024-03-07 17:16:31 |
Launchpad Janitor |
uvtool (Ubuntu Jammy): status |
Fix Committed |
Fix Released |
|
| 2024-03-07 17:16:43 |
Launchpad Janitor |
uvtool (Ubuntu Focal): status |
Fix Committed |
Fix Released |
|
