| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
This has been requested for a while. Some people have
wanted the ability to do an 'ethtool -p' from stage 1 so
they can figure out what NIC port to use. I can understand
arguments for this feature, but I have still tried to make
it more or less non-invasive. A new button is on the dev
selection screen called Identify. Self-explanatory from
there.
|
| |\ |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
This may not be the best final resting place for this code, but I don't
expect there to be any users outside of anaconda for now so it's not worth
the extra complication of findig a source control home and new package for
a single source file. This could all change in the future, of course.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Different products and distributions could support completely different
bug filing system (or none at all, for that matter) so support an
abstraction that allows us to use multiple kinds of bug files. We still
need to commit that abstraction somewhere and also make sure we allow full
customization through the product.img.
|
| | |
| |
| |
| |
| | |
This decreases the widget load we were seeing from having so much crammed
into one single page.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This patch adds support for save to bugzilla, using the python-bugzilla module.
We get the bugzilla URL from product.bugUrl and require the user to already
have a valid account with that bugzilla instance. That should cut down on
potential abuse.
To cut down on the number of possible duplicates, we hash the file name,
function name, and line of each frame in the traceback and store that hash in
the bug itself. Before filing a new bug, we query for any bugs containing that
hash value. If found, we simply add the traceback as a new attachment and put
the user on the CC list. If not found, we create a new bug. Either way, the
user is encouraged to visit their bug and make a more meaningful comment.
|
| | |
| |
| |
| |
| |
| |
| | |
The purpose of this class is to package up the Python representation of a
traceback along with some methods for doing all the dumping and mangling
that we need to do. In particular, now there's fewer values to pass around
to the various functions in the exn saving dialogs.
|
| | | |
|
| |/
|
|
|
|
|
|
|
| |
To help speed up the boot time of VM and LPAR s390x
instances, set a default cio_ignore parameter to ignore all
devices except the system console. The CMS conf file is
used anyway to specify all devices to use, so setting the
cio_ignore parameter to a reasonable default speeds things
up.
|
| | |
|
| |
|
|
| |
* po/he.po: Yet some more Hebrew.
|
| | |
|
| |
|
|
| |
question (#455612)
|
| |
|
|
|
|
| |
igor@fedoraproject.org)
* po/pt_BR.po: Minor fix
|
| |
|
|
|
|
| |
tajikfedora@fedoraproject.org)
* po/tg.po: Updated Tajik Translation
|
| |
|
|
|
|
| |
tajikfedora@fedoraproject.org)
* po/tg.po: NEW: Tajik Language added by Victor Ibragimov
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The s390 can boot El Torito CD or DVD images iff they are attached
by zFCP, used as the IPL device, and contain a specially formatted
boot image on the disc. IBM provided the tool to combobulate the
boot image together and a description of the desired execution
path.
When you boot on s390, the linuxrc.s390 will look to see if you
IPL'ed from a CD or DVD. If you did, it will ask if you also
want to install from that device. If you answer yes (y, Y, or
any case spelling of 'yes'), the script will bring the IPL device
online so the kernel assigns it a device name. Then it skips over
the network configuration and starts you in to loader. If you
tell it no or did not IPL from a CD or DVD, it'll launch the
missiles--wait, no, I mean you get the normal network installation
questions before loader starts.
I have no way to test this as it requires the following changes:
(1) Rel-eng needs to build s390x media with -no-emul-boot and
specify the new cdboot.img file on that platform. I have
already contacted rel-eng about making this change.
(2) I don't have a CD-ROM drive in my mainframe. IBM does and
testing is all falling on them. IBM knows this...maybe.
I explain all of this like anyone else on the team will ever get a
chance to experience it.
So there you have it. A letter opener.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
For now, we need to be able to support xdriver= as sometimes, drivers are
broken and people want vesa instead. This is kind of lame and it'd be
nice if we didn't have to carry such hacks.
So take the argument and write out a minimal xorg.conf if it's given.
This is all hidden away in the anaconda class, although arguably it could
belong in instdata instead. But if it's in instdata, more things might
actually try to depend or care about it. And we don't want that.
|
| |
|
|
|
|
|
|
|
|
|
| |
when running anaconda (kickstart) over a serial linedisplay (two line
output device) loadkeys does not function. The output of anaconda is
writing to /dev/console, which is achieved by kernel parameter
"console=ttyS1". If user input is needed (ks.cfg-%pre) the layout of the
keyboard does not match the settings in ks.cfg. Obviously the loadkeys
of anaconda does not function correctly if the output is a serial port.
This patch fixes this by not using /dev/console, but /dev/tty0 (the
master-tty).
|
| |
|
|
|
|
|
| |
this one-liner should make installation in cmdline possible for systems
with little RAM. Currently if little RAM is detected, anaconda changes
to textmode. Running in cmdmode should also be possible. This patch is
completely untested for now, but please verify.
|
| |
|
|
| |
VNC server (#455612)
|
| |
|
|
|
| |
If the user passed mtu=X as a boot parameter, set the interface
MTU to that value before configuring the network.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
yum wants to look in installroot+/etc/yum.repos.d for config files, which
means it ends up looking under /mnt/sysimage. On fresh installs this is
no problem because that path does not exist, but on upgrades it does. We
end up with the wrong repo config objects in the upgrade case. The least
hacky fix is to change where we store repo config files to a path that
likely won't exist on installed systems.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
live.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
