mirrors/systemd
0
0
Fork 0
mirror of https://github.com/systemd/systemd.git synced 2024-11-23 02:03:37 +08:00
Code Issues Packages Projects Releases Wiki Activity

docs/VIRTUALIZED_TESTING: format text

Browse Source
This commit is contained in:
hulkoba 2024-02-26 14:38:11 +01:00
parent d6f9d00723
commit 0dd403d187
No known key found for this signature in database
GPG Key ID: ACB6C4A3A4F2BE2F
1 changed files with 14 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
docs/VIRTUALIZED_TESTING.md
View File

@ -15,7 +15,7 @@ Here's a nice hack if you regularly build and test-boot systemd, are gutsy enoug
Create a shell script like this:
```
```sh
#!/bin/sh
sudo sync
@ -26,16 +26,22 @@ sudo modprobe kvm-intel
exec sudo qemu-kvm -smp 2 -m 512 -snapshot /dev/sda
```
This will boot your local host system as a throw-away VM guest. It will take your main harddisk, boot from it in the VM, allow changes to it, but these changes are all just buffered in memory and never hit the real disk. Any changes made in this VM will be lost when the VM terminates. I have called this script "q", and hence for test booting my own system all I do is type the following command in my systemd source tree and I can see if it worked.
This will boot your local host system as a throw-away VM guest.
It will take your main harddisk, boot from it in the VM, allow changes to it, but these changes are all just buffered in memory and never hit the real disk.
Any changes made in this VM will be lost when the VM terminates.
I have called this script "q", and hence for test booting my own system all I do is type the following command in my systemd source tree and I can see if it worked.
```
$ make -j10 && sudo make install && q
```
The first three lines are necessary to ensure that the kernel's disk caches are all synced to disk before qemu takes the snapshot of it. Yes, invoking "umount /" will sync your file system to disk as a side effect, even though it will actually fail. When the machine boots up the file system will still be marked dirty (and hence you will get an fsck, usually), but it will work fine nonetheless in virtually all cases.
The first three lines are necessary to ensure that the kernel's disk caches are all synced to disk before qemu takes the snapshot of it.
Yes, invoking "umount /" will sync your file system to disk as a side effect, even though it will actually fail.
When the machine boots up the file system will still be marked dirty (and hence you will get an fsck, usually), but it will work fine nonetheless in virtually all cases.
Of course, if the host's hard disk changes while the VM is running this will be visible to the VM, and might confuse it. If you use this little hack you should keep changes on the host at a minimum, hence. Yeah this all is a hack, but a really useful and neat one.
Of course, if the host's hard disk changes while the VM is running this will be visible to the VM, and might confuse it.
If you use this little hack you should keep changes on the host at a minimum, hence.
Yeah this all is a hack, but a really useful and neat one.
YMMV if you use LVM or btrfs.
@ -43,13 +49,14 @@ YMMV if you use LVM or btrfs.
Test-booting systemd in a container has the benefit of being much easier to debug/instrument from the outside.
**Important**: As preparation it is essential to turn off auditing entirely on your system. Auditing is broken with containers, and will trigger all kinds of error in containers if not turned off. Use `audit=0` on the host's kernel command line to turn it off.
**Important**: As preparation it is essential to turn off auditing entirely on your system.
Auditing is broken with containers, and will trigger all kinds of error in containers if not turned off.
Use `audit=0` on the host's kernel command line to turn it off.
Then, as the first step I install Fedora into a container tree:
```
$ sudo yum -y --releasever=20 --installroot=$HOME/fedora-tree --disablerepo='*' --enablerepo=fedora install systemd passwd yum fedora-release vim-minimal
```
You can do something similar with debootstrap on a Debian system. Now, we need to set a root password in order to be able to log in:
@ -65,14 +72,12 @@ As the next step we can already boot the container:
```
$ sudo systemd-nspawn -bD ~/fedora-tree/ 3
```
To test systemd in the container I then run this from my source tree on the host:
```
$ make -j10 && sudo DESTDIR=$HOME/fedora-tree make install && sudo systemd-nspawn -bD ~/fedora-tree/ 3
```
And that's already it.