I agree with falcojr and dbungert's analysis (#6 and #8, respectively)
on cloud-init's role in this issue; this looks like a symptom that gets
reported via cloud-init not an issue caused by it.
** Changed in: cloud-init (Ubuntu)
Status: Incomplete => Invalid
--
You received this bug
to Jeff:
after received you email(2022/04/28), we used the ISO you provided
> Latency is a problem, for sure. I tried doing this the other day by mounting
> that ISO on my local desktop and booting
> the machine from few hundred miles away on a 1.5Mb/s uplink and it was... not
> pleasant. I suspect Zhou Ling is doing
> this from a windows laptop over wifi through
> Latency is a problem, for sure. I tried doing this the other day by mounting
> that ISO on my local desktop and booting
> the machine from few hundred miles away on a 1.5Mb/s uplink and it was... not
> pleasant. I suspect Zhou Ling is doing
> this from a windows laptop over wifi through
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1946773
Title:
"An error occurred. Press enter to start a shell"
To manage notifications about this bug go to:
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1946773
Title:
"An error occurred. Press enter to start a shell"
To manage notifications about this bug go to:
> OK, so it works via remote media if you mount it locally using NFS.
> And can you install a desktop environment on a server next to the SR650 and
> on the same switch, rather than your >laptop, and see if you can do this from
> one server to the next?
Not only did we test using NFS, but using
On Wed, Apr 27, 2022 at 2:25 PM Jeff Lane <1946...@bugs.launchpad.net> wrote:
> Given that, I'm now curious about how this was set up on the Ampere
> server too, and if anyone tried what I did by putting Desktop on a local
> machine and mounting the ISO from there, rather than from a remote
>
>Having lower latency media does seem like a valid workaround but, IMO,
high-latency media is a significant enough use case that we should try
and support it. I don't know that we can expect users to all have
systems "next door" to their install targets to use for media hosting.
Fair enough. All
One more comment, I cannot reproduce this. To test, I installed Ubuntu
Desktop 20.04 LTS onto a SR645 in a rack in my DC. I then accessed that
desktop, opened Firefox, and accessed the XCC on a SR670 V2. I mounted
the ISO image using local media, and was able to boot the SR670 V2 using
an ISO
> Point is, I don't think the issue you're seeing is actually related to
this bug at this point.
The error appears to be the same in the screenshot @zhouling12 provided
- so it seems like we are still seeing this issue w/ high-latency media.
Or do you have reason to believe the cause is different
OK, so it works via remote media if you mount it locally using NFS.
And does the same hold true for the 20.04.4 LTS Server Live ISO, and the
21.10 Server Live ISO?
And can you install a desktop environment on a server next to the SR650
and on the same switch, rather than your laptop, and see if
to Comment 20:
1) yes, ISO was mounted for sure, this issue can be reproducible 100%
2) NFS mount via the XCC be OK, as we tested.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1946773
Title:
"An
to Comment 19: please see the pic just attached, the issue we encountered using
jammy-live-server20220328-amd64 ISO has almost the same symptom:
-
Ubuntu Jammy Jellyfish (development branch) ubuntu-server tty1
connecting...
Given it took so long, are you sure you're not hitting some timeout
that's unmounting the ISO?
And can you put the ISO somewhere closer to the server? I've had success
sharing it on an NFS share local to the server and mounting that via the
XCC.
--
You received this bug notification because you
I wonder if there is some scope creep in this bug. The bug I filed has
this symptom:
-
Ubuntu 21.10 ubuntu-server ttyAMA0
connecting...
waiting for cloud-init...
An error occurred. Press enter to start a shell
some addition to the #17: the ISO was through XCC(BMC)'s remote
mount(XCC(BMC) -> Remote Console -> Media -> Mount Local Media File)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1946773
Title:
"An
I booted jammy-live-server20220405-amd64 ISO on one Lenovo ThinkSystem SD630 V2
product, it failed with the pic attached in #16. Adding boot option to the
kernel command line:
1) toram works, but it took about 50~60 minutes from boot to load the ISO over
this interface;
2) fsck.mode=skip, could
** Attachment added: "the pic when installation failed"
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1946773/+attachment/5580871/+files/IMG_20220415_083023-4.jpg
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Just tested w/ a jammy image, and yeah - toram works, though it looks
like it took about 50 minutes from boot to load the ISO over this
interface.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1946773
For the record, we fell onto the same issue with the RISC-V live
installer on the SiFive Unmatched board whose logs are attached. In
those logs you'll see a kernel bug that I'm currently investigating
which is likely caused by the md5check job.
Adding fsck.mode=skip to the command line fixed the
The crash on timeout is fixed in main fwiw and I'm just doing the
necessary stuff to make sure it's fixed in jammy. Did anyone try adding
toram to the kernel command line?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
var log collected with impish rc image (211013) with mt. jade (howzit).
** Attachment added: "var-log-impish-rc-20211013-bmc-vmedia.tar.gz"
https://bugs.launchpad.net/subiquity/+bug/1946773/+attachment/5532831/+files/var-log-impish-rc-20211013-bmc-vmedia.tar.gz
--
You received this bug
Does adding toram to the kernel command line help? It'll probably make
boot very slow as it copies everything from the ISO to memory but things
should go much faster once that's done (and hey, maybe sequential read
performance isn't totally awful for the bmc-emulated media)
--
You received this
** Changed in: cloud-init (Ubuntu)
Status: New => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1946773
Title:
"An error occurred. Press enter to start a shell"
To manage
I think BMC-emulated media is a strong enough use-case for servers that
we should do something to address it in a future release. While I don't
think many server users would be using this method for mass installs, it
seems like a reasonable way to "give Ubuntu a try" on a single piece of
kit. It'd
"20211012 arm64 ISO" could reproduce the same issue with Mt. Jade
(howzit)
var/log/installer/subiquity-server-debug.log shows subiquity timeout:
2021-10-13 12:47:18,086 ERROR subiquity.server.server:391 top level error
Traceback (most recent call last):
File
My theory is that it is the file checksumming, which is slow when using
BMC-emulated media.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1946773
Title:
"An error occurred. Press enter to start a
log analysis:
The last output from cloud-init was at 15:17:15
Subiquity started a 10 minute wait on cloud-init status at 15:19:31, finish at
15:29:30
casper-md5check was ongoing as of 15:31:42
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
Re cloud-init, in the log I see a 3 minute gap between when cloud-init's
init stage ends and the modules stage starts, and then I see modules-
final stage never starting. Something else in boot is preventing the
modules-final stage from starting, so cloud-init will never finish.
--
You received
Ah, I need to put the fsck.mode param before the "---" apparently. That
still feels like a difficult to discover workaround though. In the past
I believe there were message on the console that at least made it clear
that a verification process was happening w/ a message about using ^c to
cancel
I tried disabling the ISO verification check (as described in bug
1870337), but it didn't seem to help:
root@ubuntu-server:/var/log# cat /proc/cmdline
BOOT_IMAGE=/casper/vmlinuz quiet --- fsck.mode=skip
In fact, it seems like this method does not disable verification:
@cloud-init - any thoughts on why `cloud-init status --wait` might
exceed 10 minutes?
** Also affects: cloud-init (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
33 matches
Mail list logo
