PXE client hanged after got IP address and downloaded NBP file by UEFI boot
by mkliu28＠gmail.com
Hello. I failed to install CentOS by uefi boot mode. Could you give me
some suggestions? Thanks in advantage. Here are details:
1) Cobbler server :2.6.11 (installed on CentOS 7.2)
2) I am installing CentOS 7.2 on my Thinkpad T430 laptop (PXE client).
3) The variable "filename" in dhcp.template is default value as below:
class "pxeclients" {
match if substring (option vendor-class-identifier, 0, 9) = "PXEClient";
if option pxe-system-type = 00:02 {
filename "ia64/elilo.efi";
} else if option pxe-system-type = 00:06 {
filename "grub/grub-x86.efi";
} else if option pxe-system-type = 00:07 {
filename "grub/grub-x86_64.efi";
} else {
filename "pxelinux.0";
}
}
When PXE client boot in legacy BIOS mode, the cobbler worked correctly
and installed OS successfully. But when I set the boot mode UEFI only,
it hanged after got IP address by DHCP and downloaded NBP file. The
last message is as below:
>>Start PXE over IPv4.
Station IP address is 192.168.1.133
Server IP address is 192.168.1.172
NBP filename is grub/grub-x86_64.efi
NBP filesize is 243679 Bytes
Downloading NBP file...
Succeed to download NBP file.
Thanks very much!
-ldreamke
7 years, 1 month
RHEL7 deplyment using cobbler 2.6.11
by Kapilraj Koroth
Installed cobbler server on RHEL 6.8
Installed the latest version of cobbler from EPEL 2.6.11
Imported RHEL 7.0 and 7.2 distributions from the binary DVD.
Made a kickstart file as follows, slight changes from RHEL6
<code>
auth --useshadow --enablemd5
bootloader --location=mbr
clearpart --all --initlabel
text
firewall --disabled
firstboot --disable
keyboard us
lang en_US
url --url=$tree
reboot --eject
rootpw --plaintext abc123
selinux --disabled
skipx
timezone --utc America/Chicago
install
zerombr
part /boot --fstype ext3 --size=1024 --ondisk=sda
part pv.01 --size=1 --grow --ondisk=sda
volgroup sysvg --pesize=65536 pv.01
logvol swap --fstype swap --name=swap --vgname=sysvg --size=8192
logvol /opt --fstype ext4 --name=opt --vgname=sysvg --size=6144
logvol / --fstype ext4 --name=root --vgname=sysvg --size=2048
logvol /home --fstype ext4 --name=home --vgname=sysvg --size=1024
logvol /tmp --fstype ext4 --name=tmp --vgname=sysvg --size=2048
logvol /usr --fstype ext4 --name=usr --vgname=sysvg --size=5120
logvol /var --fstype ext4 --name=var --vgname=sysvg --size=8192
$yum_repo_stanza
$SNIPPET('network_config')
%pre
$SNIPPET('log_ks_pre')
$SNIPPET('kickstart_start')
$SNIPPET('pre_install_network_config')
$SNIPPET('pre_anamon')
%end
%packages
$SNIPPET('func_install_if_enabled')
$SNIPPET('puppet_install_if_enabled')
%end
%post
$SNIPPET('log_ks_post')
$yum_config_stanza
$SNIPPET('post_install_kernel_options')
$SNIPPET('post_install_network_config')
$SNIPPET('func_register_if_enabled')
$SNIPPET('puppet_register_if_enabled')
$SNIPPET('download_config_files')
$SNIPPET('koan_environment')
$SNIPPET('redhat_register')
$SNIPPET('cobbler_register')
# Enable post-install boot notification
$SNIPPET('post_anamon')
# Start final steps
$SNIPPET('kickstart_done')
# End final steps
%end
</code>
Created a boot ISO, booted from it to perform a RHEL7 install. It fails
with this error message with some python errors
NoSuchGroup: core
Any idea whats wrong here ?. All VMs are on VirtualBox running on Fedora.
7 years, 7 months
import task completed even when issues in json
by Upendra Gandhi
Hi Cobbler Users:
When running cobbler import command the expectation should that it would
fail when the json file has a syntax error, but is successfully completes.
There is lack of error checking even when issuing the command, but again
import is completed successfully.
[root@ca-cobbler-admin links]# cobbler import --name=OVS-3.4.2-1384-x86_64 --arch=x86_64 --path=mnt
task started: 2016-09-26_162146_import
task started (id=Media import, time=Mon Sep 26 16:21:46 2016)
Found a candidate signature: breed=ovs, version=3.4.1
Found a matching signature: breed=ovs, version=3.4.1
Adding distros from path /var/www/cobbler/ks_mirror/OVS-3.4.2-1384-x86_64:
creating new distro: OVS-3.4.2-1384-x86_64
trying symlink: /var/www/cobbler/ks_mirror/OVS-3.4.2-1384-x86_64 -> /var/www/cobbler/links/OVS-3.4.2-1384-x86_64
creating new profile: OVS-3.4.2-1384-x86_64
associating repos
checking for uln repo(s)
skipping unknown/unsupported repo breed: uln
checking for yum repo(s)
starting descent into /var/www/cobbler/ks_mirror/OVS-3.4.2-1384-x86_64 for OVS-3.4.2-1384-x86_64
processing repo at : /var/www/cobbler/ks_mirror/OVS-3.4.2-1384-x86_64
need to process repo/comps: /var/www/cobbler/ks_mirror/OVS-3.4.2-1384-x86_64
looking for /var/www/cobbler/ks_mirror/OVS-3.4.2-1384-x86_64/repodata/*comps*.xml
Keeping repodata as-is :/var/www/cobbler/ks_mirror/OVS-3.4.2-1384-x86_64/repodata
processing repo at : /var/www/cobbler/ks_mirror/OVS-3.4.2-1384-x86_64/Transition
directory /var/www/cobbler/ks_mirror/OVS-3.4.2-1384-x86_64/Transition is missing xml comps file, skipping
processing repo at : /var/www/cobbler/ks_mirror/OVS-3.4.2-1384-x86_64/Server
need to process repo/comps: /var/www/cobbler/ks_mirror/OVS-3.4.2-1384-x86_64/Server
looking for /var/www/cobbler/ks_mirror/OVS-3.4.2-1384-x86_64/Server/repodata/*comps*.xml
Keeping repodata as-is :/var/www/cobbler/ks_mirror/OVS-3.4.2-1384-x86_64/Server/repodata
*** TASK COMPLETE *** <<<<<<<< This should fail if json file is bad
[root@ca-cobbler-admin links]# cobbler distro list
OL-R5-U11-x86_64
OL-R5-U9-x86_64
OL-R6-U7-i386
OL-R6-U7-x86_64
OL-R6-U8-x86_64
OL-R7-U2-x86_64
OVS-3.2.11-778-x86_64
OVS-3.3.2-1077-x86_64
OVS-3.3.3.1085-x86_64
OVS-3.3.4-1094-x86_64
OVS-3.4.1-trunk-1340-x86_64
OVS-3.4.2-1384-x86_64
thanks
[tag <http://ca-sysadmin.us.oracle.com/show_bug.cgi?id=7329#>] [reply
<http://ca-sysadmin.us.oracle.com/show_bug.cgi?id=7329#add_comment>] [−]
<http://ca-sysadmin.us.oracle.com/show_bug.cgi?id=7329#> Comment 3
<http://ca-sysadmin.us.oracle.com/show_bug.cgi?id=7329#c3> Zarko Dudic
<mailto:zarko.dudic@oracle.com> 2016-09-27 11:38:51 PDT
> The error checking in cobbler for json file is not efficient as the import > went successful and completed.
As a team, we are all in the same boat, I've been suggesting it's good idea not only to join a mailing list, but to be active there.
Let's look into details here ...
> [root@ca-cobbler-admin links]# cobbler import --name=OVS-3.4.2-1384-x86_64 > --arch=x86_64 --path=mnt > task started: 2016-09-26_162146_import >
task started (id=Media import, time=Mon Sep 26 16:21:46 2016) > Found a
candidate signature: breed=ovs, version=3.4.1 > Found a matching
signature: breed=ovs, version=3.4.1
Actually import command had missed to find 3.4.2 signature and it used nearest match 3.4.1
I also see --path=mnt instead of using /mnt. It's really interesting that task has been completed.
Add Comment <http://ca-sysadmin.us.oracle.com/show_bug.cgi?id=7329#>
* Collapse All Comments
<http://ca-sysadmin.us.oracle.com/show_bug.cgi?id=7329#>
* Expand All Comments
<http://ca-sysadmin.us.oracle.com/show_bug.cgi?id=7329#>
*
7 years, 7 months
unsubscribe
by Uma Murali
Sent from my iPhone
> On Sep 19, 2016, at 3:25 PM, Kapilraj Koroth <kapilrajk(a)gmail.com> wrote:
>
> Installed cobbler server on RHEL 6.8
> Installed the latest version of cobbler from EPEL 2.6.11
> Imported RHEL 7.0 and 7.2 distributions from the binary DVD.
> Made a kickstart file as follows, slight changes from RHEL6
>
> <code>
> auth --useshadow --enablemd5
> bootloader --location=mbr
> clearpart --all --initlabel
> text
> firewall --disabled
> firstboot --disable
> keyboard us
> lang en_US
> url --url=$tree
> reboot --eject
> rootpw --plaintext abc123
> selinux --disabled
> skipx
> timezone --utc America/Chicago
> install
> zerombr
> part /boot --fstype ext3 --size=1024 --ondisk=sda
> part pv.01 --size=1 --grow --ondisk=sda
> volgroup sysvg --pesize=65536 pv.01
> logvol swap --fstype swap --name=swap --vgname=sysvg --size=8192
> logvol /opt --fstype ext4 --name=opt --vgname=sysvg --size=6144
> logvol / --fstype ext4 --name=root --vgname=sysvg --size=2048
> logvol /home --fstype ext4 --name=home --vgname=sysvg --size=1024
> logvol /tmp --fstype ext4 --name=tmp --vgname=sysvg --size=2048
> logvol /usr --fstype ext4 --name=usr --vgname=sysvg --size=5120
> logvol /var --fstype ext4 --name=var --vgname=sysvg --size=8192
>
> $yum_repo_stanza
>
> $SNIPPET('network_config')
>
> %pre
> $SNIPPET('log_ks_pre')
> $SNIPPET('kickstart_start')
> $SNIPPET('pre_install_network_config')
> $SNIPPET('pre_anamon')
> %end
>
> %packages
> $SNIPPET('func_install_if_enabled')
> $SNIPPET('puppet_install_if_enabled')
> %end
>
> %post
> $SNIPPET('log_ks_post')
> $yum_config_stanza
> $SNIPPET('post_install_kernel_options')
> $SNIPPET('post_install_network_config')
> $SNIPPET('func_register_if_enabled')
> $SNIPPET('puppet_register_if_enabled')
> $SNIPPET('download_config_files')
> $SNIPPET('koan_environment')
> $SNIPPET('redhat_register')
> $SNIPPET('cobbler_register')
> # Enable post-install boot notification
> $SNIPPET('post_anamon')
> # Start final steps
> $SNIPPET('kickstart_done')
> # End final steps
> %end
>
> </code>
>
> Created a boot ISO, booted from it to perform a RHEL7 install. It fails with this error message with some python errors
>
> NoSuchGroup: core
>
> Any idea whats wrong here ?. All VMs are on VirtualBox running on Fedora.
> _______________________________________________
> cobbler mailing list -- cobbler(a)lists.fedorahosted.org
> To unsubscribe send an email to cobbler-leave(a)lists.fedorahosted.org
7 years, 7 months
UEFI PXE Installation
by William Muriithi
Hello,
I have read an attempted various suggestion on getting cobber to do
UEFI PXE Installation and I haven't had a break though. I am wondering
if someone here had success and how they went about diagnosing the
problem.
Here is my setup:
[root@cobbler ~]# rpm -qa | grep cobbler
cobbler-2.6.11-1.el6.x86_64
I have checked at the project site and this seem to be the most recent
release. I have also pulled fresh boot loaders from github, so I am
not sure if there is anything I can do with updating as I am up to
date as far as I am concerned.
I am able to do installation fine with BIOS, but when I flip to UEFI,
the booting fails with very unhelpful error. I have DHCP server
outside of cobbler management but since I am using static IP, I
thought its fine.
I have looked at the ISC DHCP logs, and don't see anything helpful
there. When I look at the logs after "cobbler sync", I do see
splash.xpm.gz being pushed to tftp. I have fixed
/etc/cobbler/pxe/efidefault.template as recommended by this old
article, but no luck yet
https://gist.github.com/cwacek/5910195
Any ideal where I should poke going forward?
Regards,
William
7 years, 7 months
python-simplejson
by Chris Johnson
Hi.
I'm probably going to get yelled by someone but at this point I jut
don't care any more.
Would someone please either show me a file suitable for
/etc/yum.prepos.d/ or point me to one for
python-simplejson? Or of python-simplejson included in something then
what and where is that please? Cobbler needs it.
Thank you.
7 years, 7 months
Second DHCP network?
by David Lee
Cobbler folks,
RHEL6; cobbler 2.6.5 (yes, I know it's old!)
I have a feeling this ought to be a trivial question, but I can't find the answer.
We have been using Cobbler for several years. (Indeed, I've even contributed a little to the documentation a few years ago.) That usage has been over a single "provisioning" interface on a single provisioning network (similar to "10.old.0.0" with the server address "10.old.srv.addr" and that same value being in the "settings" field "next_server:"). Very simple. Works well.
We are adding a second such network over another interface ("10.new.0.0"). When I PXE boot a client (say "new-client") over this new network, the TFTP stuff works fine. But I then get "error downloading kickstart file" which includes the URL of the server's *old* interface (on the original network).
When I do
cobbler cobbler system getks --name=new-client
the output is full of references to the *old* network, instead of the new, such as:
# Use network installation
url --url=http://10.old.srv.addr/cblr/links/rhel67-x86_64
# If any cobbler repo definitions were referenced in the kickstart profile, include them here.
repo --name=el6-x86_64-local --baseurl=http://10.old.srv.addr/local/el6/x86_64
...
That "10.old.srv.addr" should be the "10.new.srv.addr".
There are no references to the old address in the client's "system", or its profile or the Cobbler "foo.ks" kickstart template.
Yet something, somewhere, somehow is clinging tenaciously to the old network.
The "dhcp.template" contains:
subnet 10.old.foo.0 netmask 255.255.252.0 {
...
next-server $next_server; <-- presumably using the "next_server" from "settings"
}
subnet 10.new.0.0 netmask 255.255.0.0 {
...
#next-server $next_server;
next-server 10.new.srv.addr; <-- explicit reference to new network's server address
}
The "/etc/cobbler/settings" file still has:
next_server: 10.old.srv.addr
but we want to keep this for the time being to continue to serve our existing estate.
Any clues, please?
If the answer is "not available in 2.6.5 but is available later", then I'll set about planning an upgrade.
-- David Lee
-- ECMWF
7 years, 7 months
cobbler system add trigger a crash
by William Muriithi
Good afternoon,
[root@cobbler ~]# rpm -qa | grep cobbler
cobbler-2.6.11-1.el6.x86_64
cobbler-web-2.6.11-1.el6.noarch
[root@cobbler ~]#
I am running into an odd issue where I can use a profile interactively
and have a successful install. However, if I use that profile and
create a system specific profile, I am not able to have a successful
install for both RHEL6 and RHEL7. I am getting the following error
from cobbler logs
Tue Sep 13 17:40:59 2016 - INFO | REMOTE save_item(system);
user(<DIRECT>);
object_id(___NEW___system::gOQ9mTSmZVfODQWldpv/MPykzLe6WuH9Ew==)
Tue Sep 13 17:40:59 2016 - DEBUG | REMOTE CLI Authorized; user(?)
Tue Sep 13 17:40:59 2016 - INFO | add_item(system); ['silicon']
Tue Sep 13 17:40:59 2016 - DEBUG | get_items; ['system']
Tue Sep 13 17:40:59 2016 - DEBUG | done with get_items; ['system']
Tue Sep 13 17:40:59 2016 - WARNING | errors were encountered rendering
the template
Tue Sep 13 17:40:59 2016 - WARNING |
[{'code': u'VFFSL(SL,"grub_menu_items",True)',
'exc_val': NotFound("cannot find 'grub_menu_items'",),
'lineCol': (6, 1),
'rawCode': u'$grub_menu_items',
'time': 'Tue Sep 13 17:40:59 2016'}]
Tue Sep 13 17:40:59 2016 - INFO | generating:
/var/lib/tftpboot/pxelinux.cfg/01-d4-ae-52-af-7d-da
Tue Sep 13 17:40:59 2016 - INFO | generating:
/var/lib/tftpboot/grub/01-D4-AE-52-AF-7D-DA
The resulting pxelinux.cfg is incomplete as seen below:
[root@cobbler ~]# cat /var/lib/tftpboot/pxelinux.cfg/01-d4-ae-52-af-7d-da
default=0
timeout=5
splashimage=(nd)/splash.xpm.gz
$grub_menu_items
Have anybody seen this before?
Regards,
William
7 years, 7 months
Networking snippnet with new network style names
by William Muriithi
Hello
I have been struggling attempting to get cobbler to work with RHEL6.
The problem is, RHEL 6.8 is coming up with the interface name as em1,
but somehow, the kickstart snippet below end up assigning the
interface the name eth0. I have temporarily commented the snippet as
show below and was able to have a successful installation after that.
# Network information
#$SNIPPET('network_config')
network --onboot no --device em1 --bootproto dhcp --noipv6
network --onboot no --device em2 --bootproto dhcp --noipv6
Have anybody been able to get cobbler working with interface names
like em1 or p3p1? My problem is, I have different hardware and
therefore don't have flexibility of hard coding the interface name in
the kickstart. Any pointer would be highly appreciated
Regard,
William
7 years, 7 months
