-
Notifications
You must be signed in to change notification settings - Fork 20
Fix password change required #74
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
Changes from all commits
ffc2c6c
fb3d121
1d32887
e32df6a
e4b9125
5de4a36
76f2c74
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -182,6 +182,76 @@ NB: It's also possible to run qdl from the host while the baord is not connected | |
|
|
||
| Want to join in the development? Changes welcome! See [CONTRIBUTING.md file](CONTRIBUTING.md) for step by step instructions. | ||
|
|
||
| ### Test an image locally with qemu | ||
|
|
||
| You can boot an image locally with qemu as follows: | ||
|
|
||
| 1. Install dependencies. `qemu-system-arm` is required together with | ||
| an aarch64 build of UEFI. On Debian and Ubuntu, this is provided by the | ||
| `qemu-system-arm` package which recommends `qemu-efi-aarch64`: | ||
| ```bash | ||
| sudo apt install qemu-system-arm qemu-efi-aarch64 | ||
| ``` | ||
|
|
||
| 1. As above under "Usage", build the disk image from the root filesystem | ||
| tarball if you haven't done this already: | ||
| ```bash | ||
| debos debos-recipes/qualcomm-linux-debian-image.yaml | ||
| ``` | ||
|
|
||
| 1. Run qemu as follows: | ||
| ```bash | ||
| # SCSI is required to present a device with a matching 4096 sector size | ||
| # inside the VM | ||
| qemu-system-aarch64 -cpu cortex-a57 -m 2048 -M virt -nographic \ | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That made me wonder how we should define the QEMU model. We could pick it to be fast and manage it like a reference device that we maintain, or we could try to follow the most constrained environment we're trying to support. For the latter, the RB1 is probably the oldest board we're trying to enable, so 2GiB of RAM is fitting. I don't think QEMU has support for Kryo CPUs, so not sure what Cortex equivalent we should pick.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Since have dedicated hardware tests, I imagine the qemu tests to be primarily for hardware agnostic matters and mainly for the purposes of testing userspace matters to be correct. Strict constraints like memory and CPU features would still be important though, as we'd want to know if any use case we test is memory constrained in order to make appropriate decisions, or indeed built for a too-high CPU target. We could mark tests differently depending on their requirements (eg. if we want a standard image to have functionality that we know won't work on the oldest supported hardware, but we still want to test it). So then we would want the model to be fast and with the most limited memory, but with the option of marking tests that require more to automatically get more. And we'd keep hardware-specific tests out of this test suite. |
||
| -device virtio-scsi-pci,id=scsi1 \ | ||
| -device scsi-hd,bus=scsi1.0,drive=disk1,physical_block_size=4096,logical_block_size=4096 \ | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Oh that's cool! Makes me think we should (separately) make a test to check the SD card/eMMC images boot too (with the normal 512 bytes sector size)!
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I only did what was necessary to get the image we already had booting :) Would an additional test be valuable here? The risk would be that something later works in qemu but fails on real hardware - in which case - why not just rely on the test against the real hardware? I'm imagining the qemu test to be solely for testing the userspace-specific bits, and the hardware-specific bits (that interact most with qemu) to be a necessary distraction for that purpose that we should minimise. Then we can rely on the hardware tests for the hardware-specific bits. |
||
| -drive if=none,file=disk-ufs.img,format=raw,id=disk1 \ | ||
| -bios /usr/share/AAVMF/AAVMF_CODE.fd | ||
| ``` | ||
|
|
||
| #### Copy on write | ||
|
|
||
| Instead of modifying `file-ufs.img`, you can arrange copy-on-write, for example | ||
| to reproduce the same first boot multiple times: | ||
|
|
||
| 1. Prepare a qcow file to contain the writes, backed by `disk-ufs.img`: | ||
| ```bash | ||
| qemu-img create -b disk-ufs.img -f qcow -F raw disk1.qcow | ||
| ``` | ||
|
|
||
| 1. Run qemu as follows: | ||
| ```bash | ||
| qemu-system-aarch64 -cpu cortex-a57 -m 2048 -M virt -nographic \ | ||
| -device virtio-scsi-pci,id=scsi1 \ | ||
| -device scsi-hd,bus=scsi1.0,drive=disk1,physical_block_size=4096,logical_block_size=4096 \ | ||
| -drive if=none,file=disk1.img,format=qcow,id=disk1 \ | ||
| -bios /usr/share/AAVMF/AAVMF_CODE.fd | ||
| ``` | ||
|
|
||
| #### Direct kernel boot | ||
lool marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| For debugging purposes, it is sometimes useful to boot the kernel directly, for | ||
| example to confirm that an issue in the image lies in the bootloader | ||
| installation. You can do this as follows: | ||
|
|
||
| 1. Extract the rootfs: | ||
| ```bash | ||
| mkdir rootfs | ||
| tar xzC rootfs -f rootfs.tar.gz | ||
| ``` | ||
|
|
||
| 2. Run qemu against the kernel and initrd present inside the rootfs directly: | ||
| ```bash | ||
| qemu-system-aarch64 -cpu cortex-a57 -m 2048 -M virt -nographic \ | ||
| -device virtio-scsi-pci,id=scsi1 \ | ||
| -device scsi-hd,bus=scsi1.0,drive=disk1,physical_block_size=4096,logical_block_size=4096 \ | ||
| -drive if=none,file=disk-ufs.img,format=raw,id=disk1 \ | ||
| -kernel rootfs/boot/vmlinuz-* | ||
| -initrd rootfs/boot/initrd.img-* | ||
| -append root=/dev/sda2 | ||
| ``` | ||
|
|
||
| ## Reporting Issues | ||
|
|
||
| We'd love to hear if you run into issues or have ideas for improvements. [Report an Issue on GitHub](../../issues) to discuss, and try to include as much information as possible on your specific environment. | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,82 @@ | ||
| """Tests that are entirely qemu based, so do not require test hardware""" | ||
|
|
||
| # Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries. | ||
| # SPDX-License-Identifier: BSD-3-Clause | ||
|
|
||
| import os | ||
| import signal | ||
| import subprocess | ||
| import tempfile | ||
|
|
||
| import pexpect | ||
| import pytest | ||
|
|
||
|
|
||
| @pytest.fixture | ||
| def vm(): | ||
| """A pexpect.spawn object attached to the serial console of a VM freshly | ||
| booting with a CoW base of disk-ufs.img""" | ||
| with tempfile.TemporaryDirectory() as tmpdir: | ||
| qcow_path = os.path.join(tmpdir, "disk1.qcow") | ||
| subprocess.run( | ||
| [ | ||
| "qemu-img", | ||
| "create", | ||
| "-b", | ||
| os.path.join(os.getcwd(), "disk-ufs.img"), | ||
| "-f", | ||
| "qcow", | ||
| "-F", | ||
| "raw", | ||
| qcow_path, | ||
| ], | ||
| check=True, | ||
| ) | ||
| child = pexpect.spawn( | ||
| "qemu-system-aarch64", | ||
| [ | ||
| "-cpu", | ||
| "cortex-a57", | ||
| "-m", | ||
| "2048", | ||
| "-M", | ||
| "virt", | ||
| "-drive", | ||
| f"if=none,file={qcow_path},format=qcow,id=disk1", | ||
| "-device", | ||
| "virtio-scsi-pci,id=scsi1", | ||
| "-device", | ||
| "scsi-hd,bus=scsi1.0,drive=disk1,physical_block_size=4096,logical_block_size=4096", | ||
| "-nographic", | ||
| "-bios", | ||
| "/usr/share/AAVMF/AAVMF_CODE.fd", | ||
| ], | ||
| ) | ||
| yield child | ||
|
|
||
| # No need to be nice; that would take time | ||
| child.kill(signal.SIGKILL) | ||
|
|
||
| # If this blocks then we have a problem. Better to hang than build up | ||
| # excess qemu processes that won't die. | ||
| child.wait() | ||
|
|
||
|
|
||
| def test_password_reset_required(vm): | ||
| """On first login, there should be a mandatory reset password flow""" | ||
| # https://github.com/qualcomm-linux/qcom-deb-images/issues/69 | ||
|
|
||
| # This takes a minute or two on a ThinkPad T14s Gen 6 Snapdragon | ||
| vm.expect_exact("debian login:", timeout=240) | ||
|
|
||
| vm.send("debian\r\n") | ||
| vm.expect_exact("Password:") | ||
| vm.send("debian\r\n") | ||
| vm.expect_exact("You are required to change your password immediately") | ||
| vm.expect_exact("Current password:") | ||
| vm.send("debian\r\n") | ||
| vm.expect_exact("New password:") | ||
| vm.send("new password\r\n") | ||
| vm.expect_exact("Retype new password:") | ||
| vm.send("new password\r\n") | ||
| vm.expect_exact("debian@debian:~$") |
Uh oh!
There was an error while loading. Please reload this page.