12:36 a.m.
Hi Kairui,
I have a question about testing kdump-anaconda-addon. I used virt-install
to start the installation,
$ virt-install --ram 2048 --location
https://mirrors.ustc.edu.cn/fedora/releases/35/Server/x86_64/os/ \
--disk=kdump_b.img,format=qcow2,bus=virtio
--extra-args="inst.updates=http://172.31.9.95:8000/updates.img"
The problem is it somehow takes several minutes for the installation GUI
window to appear. If I use --cdrom RHEL9-xxx.iso, the GUI window would
appear very fast but --cdrom it doesn't support --extra-args and I have
to manually edit the boot menu to add inst.updates=. I remember you
use kickstart to test the kdump addon. Could you share you kickstart
.cfg file so I may find out what's wrong with my way? Thanks!
--
Best regards,
Coiby
9:34 a.m.
Hi Coiby,
Coiby Xu <coxu(a)redhat.com> 于2021年11月23日周二 下午2:41写道：
Hi Kairui,
I have a question about testing kdump-anaconda-addon. I used virt-install
to start the installation,
$ virt-install --ram 2048 --location
https://mirrors.ustc.edu.cn/fedora/releases/35/Server/x86_64/os/ \
--disk=kdump_b.img,format=qcow2,bus=virtio
--extra-args="inst.updates=http://172.31.9.95:8000/updates.img"
The problem is it somehow takes several minutes for the installation GUI
window to appear. If I use --cdrom RHEL9-xxx.iso, the GUI window would
appear very fast.
Could this be just a network issue? I never tried virt-install before,
not sure how it works.
but --cdrom it doesn't support --extra-args and I have
to manually edit the boot menu to add inst.updates=.
Actually you can attach a serial console to the qemu machine, and just
copy-paste the inst.updates= to the grubby interface, I think that's
not troublesome at all, and that's how I test the
kdump-anaconda-addon.
I remember you use kickstart to test the kdump addon. Could you share
you kickstart
.cfg file so I may find out what's wrong with my way? Thanks!
Sorry I tried to find my old kickstart file but it seems I lost it :(
However I didn't keep a backup of it just because it's very short and
easy to rewrite one, on anaconda installed machine (eg. every beaker
machine you provisioned) you can see a /root/anaconda-ks.cfg, which is
the kickstart file to reproduce that installation, you can drop the
unneeded part and reuse that.
My test setup is easy, just spin a EFI qemu machine with a Fedora iso
image, a disk image, a serial console, and network. (Virt manager can
help you setup all these very easily). With EFI qemu machine GRUB can
talk to the serial console, so you can then just paste your
inst.updates=http://172.31.9.95:8000/updates.img and
inst.kickstart=... cmdline to the GRUB boot entry easily.
>
> --
> Best regards,
> Coiby
>
12:20 a.m.
Hi Kairui,
On Tue, Nov 23, 2021 at 11:34:11PM +0800, Kairui Song wrote:
Hi Coiby,
Coiby Xu <coxu(a)redhat.com> 于2021年11月23日周二 下午2:41写道：
>
> Hi Kairui,
>
> I have a question about testing kdump-anaconda-addon. I used virt-install
> to start the installation,
> $ virt-install --ram 2048 --location
https://mirrors.ustc.edu.cn/fedora/releases/35/Server/x86_64/os/ \
> --disk=kdump_b.img,format=qcow2,bus=virtio
--extra-args="inst.updates=http://172.31.9.95:8000/updates.img"
>
> The problem is it somehow takes several minutes for the installation GUI
> window to appear. If I use --cdrom RHEL9-xxx.iso, the GUI window would
> appear very fast.
Could this be just a network issue? I never tried virt-install before,
not sure how it works.
Thanks for the hint. I think it's a network issue because,
1. after using cdrom as installation source,
$ qemu-system-x86-64 -append "inst.repo=cdrom" -cdrom RHEL9-xxx.iso -boot c ...
the installation window would appear very soon.
2. if manually launching qemu using the same vmlinuz and initrd.img
as virt-install,
$ qemu-system-x86_64 -kernel vmlinuz -initrd initrd.img -hda ~kdump_b.img -m 4G \
--enable-kvm -smp 4 -append
"inst.repo=https://mirrors.ustc.edu.cn/fedora/releases/35/Server/x86_64/os/ \
inst.updates=http://172.31.9.95:8000/updates.img"
The result is the same to virt-install.
> but --cdrom it doesn't support --extra-args and I have
> to manually edit the boot menu to add inst.updates=.
Actually you can attach a serial console to the qemu machine, and just
copy-paste the inst.updates= to the grubby interface, I think that's
not troublesome at all, and that's how I test the
kdump-anaconda-addon.
I added the following options to start qemu,
$ qemu-system-x86-64 -append "console=tty0 console=ttyS0,115200n81" -serial
mon:stdio ..
but somehow I was presented with a TUI interface instead of the GUI
interface.
> I remember you use kickstart to test the kdump addon. Could you share you kickstart
> .cfg file so I may find out what's wrong with my way? Thanks!
Sorry I tried to find my old kickstart file but it seems I lost it :(
However I didn't keep a backup of it just because it's very short and
easy to rewrite one, on anaconda installed machine (eg. every beaker
machine you provisioned) you can see a /root/anaconda-ks.cfg, which is
the kickstart file to reproduce that installation, you can drop the
unneeded part and reuse that.
My test setup is easy, just spin a EFI qemu machine with a Fedora iso
image, a disk image, a serial console, and network. (Virt manager can
help you setup all these very easily). With EFI qemu machine GRUB can
talk to the serial console, so you can then just paste your
inst.updates=http://172.31.9.95:8000/updates.img and
inst.kickstart=... cmdline to the GRUB boot entry easily.
Thanks for sharing your way of testing.
>
> --
> Best regards,
> Coiby
>
--
Best regards,
Coiby
8:26 a.m.
Coiby Xu <coxu(a)redhat.com> 于2021年11月24日周三 下午2:25写道：
Hi Kairui,
On Tue, Nov 23, 2021 at 11:34:11PM +0800, Kairui Song wrote:
>Hi Coiby,
>
>Coiby Xu <coxu(a)redhat.com> 于2021年11月23日周二 下午2:41写道：
>>
>> Hi Kairui,
>>
>> I have a question about testing kdump-anaconda-addon. I used virt-install
>> to start the installation,
>> $ virt-install --ram 2048 --location
https://mirrors.ustc.edu.cn/fedora/releases/35/Server/x86_64/os/ \
>> --disk=kdump_b.img,format=qcow2,bus=virtio
--extra-args="inst.updates=http://172.31.9.95:8000/updates.img"
>>
>> The problem is it somehow takes several minutes for the installation GUI
>> window to appear. If I use --cdrom RHEL9-xxx.iso, the GUI window would
>> appear very fast.
>
>Could this be just a network issue? I never tried virt-install before,
>not sure how it works.
Thanks for the hint. I think it's a network issue because,
1. after using cdrom as installation source,
$ qemu-system-x86-64 -append "inst.repo=cdrom" -cdrom RHEL9-xxx.iso -boot c
...
the installation window would appear very soon.
2. if manually launching qemu using the same vmlinuz and initrd.img
as virt-install,
$ qemu-system-x86_64 -kernel vmlinuz -initrd initrd.img -hda ~kdump_b.img -m 4G \
--enable-kvm -smp 4 -append
"inst.repo=https://mirrors.ustc.edu.cn/fedora/releases/35/Server/x86_64/os/ \
inst.updates=http://172.31.9.95:8000/updates.img"
The result is the same to virt-install.
Yes, I think you are right.
>
>> but --cdrom it doesn't support --extra-args and I have
>> to manually edit the boot menu to add inst.updates=.
>
>Actually you can attach a serial console to the qemu machine, and just
>copy-paste the inst.updates= to the grubby interface, I think that's
>not troublesome at all, and that's how I test the
>kdump-anaconda-addon.
I added the following options to start qemu,
$ qemu-system-x86-64 -append "console=tty0 console=ttyS0,115200n81" -serial
mon:stdio ..
but somehow I was presented with a TUI interface instead of the GUI
interface.
Maybe because your VM is a headless machine so anaconda decide to run
in text mode? Actually you can keep both the VGA and serial console,
anaconda prefer to use the graphical interface if available. The
console can be used as fallback and talk with GRUB during early boot.
(When both VGA and console are available, GRUB will use both, just the
test console is easier to use since you can copy and paste).
>
> >
> >> I remember you use kickstart to test the kdump addon. Could you share you
kickstart
> >> .cfg file so I may find out what's wrong with my way? Thanks!
> >
> >Sorry I tried to find my old kickstart file but it seems I lost it :(
> >However I didn't keep a backup of it just because it's very short and
> >easy to rewrite one, on anaconda installed machine (eg. every beaker
> >machine you provisioned) you can see a /root/anaconda-ks.cfg, which is
> >the kickstart file to reproduce that installation, you can drop the
> >unneeded part and reuse that.
> >
> >My test setup is easy, just spin a EFI qemu machine with a Fedora iso
> >image, a disk image, a serial console, and network. (Virt manager can
> >help you setup all these very easily). With EFI qemu machine GRUB can
> >talk to the serial console, so you can then just paste your
> >inst.updates=http://172.31.9.95:8000/updates.img and
> >inst.kickstart=... cmdline to the GRUB boot entry easily.
>
> Thanks for sharing your way of testing.
>
> >
> >>
> >> --
> >> Best regards,
> >> Coiby
> >>
> >
>
> --
> Best regards,
> Coiby
> _______________________________________________
> kexec mailing list -- kexec(a)lists.fedoraproject.org
> To unsubscribe send an email to kexec-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/kexec@lists.fedoraproject.org
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
9:26 p.m.
On Wed, Nov 24, 2021 at 10:26:15PM +0800, Kairui Song wrote:
Coiby Xu <coxu(a)redhat.com> 于2021年11月24日周三 下午2:25写道：
[..]
> >> but --cdrom it doesn't support --extra-args and I
have
> >> to manually edit the boot menu to add inst.updates=.
> >
> >Actually you can attach a serial console to the qemu machine, and just
> >copy-paste the inst.updates= to the grubby interface, I think that's
> >not troublesome at all, and that's how I test the
> >kdump-anaconda-addon.
>
> I added the following options to start qemu,
> $ qemu-system-x86-64 -append "console=tty0 console=ttyS0,115200n81" -serial
mon:stdio ..
> but somehow I was presented with a TUI interface instead of the GUI
> interface.
Maybe because your VM is a headless machine so anaconda decide to run
in text mode? Actually you can keep both the VGA and serial console,
anaconda prefer to use the graphical interface if available. The
console can be used as fallback and talk with GRUB during early boot.
(When both VGA and console are available, GRUB will use both, just the
test console is easier to use since you can copy and paste).
I don't think my VM is a headless machine because if I remove
'"console=tty0 console=ttyS0,115200n81" -serial mon:stdio', the
graphical
interface would appear. It seems there is something wrong with RHEL9. If
I add "inst.graphical" to the kernel cmdline, the graphical interface would
appear. And for Fedora, without "inst.graphical", the graphical interface
would be chosen by default. I'll create a bug for anaconda team.
--
Best regards,
Coiby
876
days inactive
878
days old
4 comments
2 participants
participants (2)
-
Coiby Xu -
Kairui Song