Javier Palacios wrote: >>> (B) Having a default for the item_distro.py values is a good thing, >>> because if no argument is passed to "distro add" it can assume a >>> reasonable default. At least for now redhat based distros constitute >>> these fields. >>> [...] >>> (C) Can you explain why the get_pxe_arch function, which was there >>> to return the architecture of a specific point in the directory tree >>> where the kernel+initrd is found, now returns a list? Are these >>> architecture guesses? I can't see any ability for sharing of kernels >>> between arches. >>> > > Here is the patch again, with redhat re-enabled as default, so > actually fixing B. > Regarding C, I can work that easily if you believe is better, although I might > prefer not to drop the list yet, until a sensible guess could be done from the > imported tree and to leave open the way for multiarch repositories and media. > > Javier Palacios > > ------------------------------------------------------------------------ > > _______________________________________________ > cobbler mailing list > [email protected] > https://fedorahosted.org/mailman/listinfo/cobbler >
Ok, just tested this... Running on Fedora 9 (and using --available-as to save space, not because it was needed), I am unable to import a F-9 DVD. [EMAIL PROTECTED] cobbler]# mount -o loop /home/Fedora-9-i386-DVD.iso /tmp/loopy [EMAIL PROTECTED] cobbler]# cobbler import --name=loopy --available-as=http://loopy/ --mirror=/tmp/loopy ---------------- (adding distros) - scanning /tmp/loopy/images/pxeboot for architecture info - architectures found : [] - scanning /tmp/loopy/images/xen for architecture info - architectures found : [] ---------------- (associating kickstarts) ---------------- (syncing) [EMAIL PROTECTED] cobbler]# cobbler profile list | grep loopy Import of directory trees off of NFS, including multiple directory trees, seems to work. [EMAIL PROTECTED] cobbler]# cobbler import --name=IMP4 --mirror=/mnt/engarchive2/released/F-9/GOLD/Fedora/i386/os/ --available-as=http://sparky ---------------- (adding distros) - creating new distro: IMP4-i386 - creating new profile: IMP4-i386 - creating new profile: rescue-IMP4-i386 - creating new distro: IMP4-xen-i386 - creating new profile: IMP4-xen-i386 ---------------- (associating kickstarts) /mnt/engarchive2/released/F-9/GOLD/Fedora/i386/os/, /mnt/engarchive2/released/F-9/GOLD/Fedora/i386/os, -1 - warning: possible symlink traversal?: /mnt/engarchive2/released/F-9/GOLD/Fedora/i386/os /mnt/engarchive2/released/F-9/GOLD/Fedora/i386/os/, /mnt/engarchive2/released/F-9/GOLD/Fedora/i386/os, -1 - warning: possible symlink traversal?: /mnt/engarchive2/released/F-9/GOLD/Fedora/i386/os /mnt/engarchive2/released/F-9/GOLD/Fedora/i386/os/, /mnt/engarchive2/released/F-9/GOLD/Fedora/i386/os, -1 - warning: possible symlink traversal?: /mnt/engarchive2/released/F-9/GOLD/Fedora/i386/os ---------------- (syncing) If you can fix the Fedora ISO import case, I'll apply this. It is looking like imports are "complicated" so if you do think we need seperate import code for Fedora/Red Hat/CentOS and Debian we can do that, and require a "--breed" to import. That may eliminate the problems of breaking the RHEL use cases while working on the Debian ones and might make the Debian code simpler. If you want to continue down the current direction that is fine too, but if you can start testing with Fedora ISOs before submitting that would be helpful to me. I was happy with our previous Debian import capability and still think the most important thing we can do to make it truly useful is to template out some good fully automated preseeds, and then look at this later if needed. I'm less interested in whether Debian can import in batch and so forth as I am as to whether it is fully automated out of the box and we ship some good sample preseeds to show people the way to go. Thanks! --Michael _______________________________________________ cobbler mailing list [email protected] https://fedorahosted.org/mailman/listinfo/cobbler
