Hi,everyone
http://www.redhat.com/archives/shrike-list/2003-April/msg00069.htmlhttp://fedoraproject.org/wiki/StackTraceshttp://old-en.opensuse.org/Packaging/Debuginfo
This document said:"passing -g to gcc or g++". And "Note that the default CFLAGS and CXXFLAGS of the distro already contain -g, "
My question is :
I build souce code a.c with myself gcc/make configfile.
first time: compile a.c with -O2,then get a1.bin
second time: compile a.c woth -O2 -g,then strip debug symbols.then get a2.bin
But i find a2.bin is slower then a1.bin.The performance of a2.bin is 5% slower.
Should a2.bin run as fast as a1.bin?(performance is same?)//Tomorrow i will provide the complete commands.
Can anyone give some advice?
I find that:rpmbuild run gcc one time with -g -O2,then get a.rpm and a.debuginforpm.
thanks.
I am out of the office until 12/02/2013.
Please contact hss(a)biotronik.com in urgent cases.
Note: This is an automated response to your message "Re: [CentOS-devel]
CentOS-6.4 OpenStack testing cloud images" sent on 25.11.2013 13:24:03.
This is the only notification you will receive while this person is away.
www.biotronik.com
BIOTRONIK - Celebrating 50 years of excellence
Founded in 1963 with the development of the first German pacemaker, BIOTRONIK has brought innovations and the highest quality standards to the cardiac rhythm management and vascular intervention fields in more than 100 countries around the world. We’ve developed advanced technologies such as BIOTRONIK Home Monitoring®, Closed Loop Stimulation (CLS) and Orsiro, the industry's first hybrid drug eluting stent. BIOTRONIK also offers the broadest portfolio of cardiac devices with ProMRI®, an advanced technology that gives patients access to magnetic resonance (MR) scanning.
BIOTRONIK SE & Co. KG
Woermannkehre 1, 12359 Berlin, Germany
Sitz der Gesellschaft: Berlin, Registergericht: Berlin HRA 6501
Vertreten durch ihre Komplementärin:
BIOTRONIK MT SE
Sitz der Gesellschaft: Berlin, Registergericht: Berlin HRB 118866 B
Geschäftsführende Direktoren: Christoph Böhmer, Dr. Lothar Krings
This e-mail and the information it contains including attachments are confidential and meant only for use by the intended recipient(s); disclosure or copying is strictly prohibited. If you are not addressed, but in the possession of this e-mail, please notify the sender immediately and delete the document.
Hi KB,
Sorry for the delayed response, I wasn't subscribed to the devel list.
I'm also replying to some of the comments that other users posted.
Sorry for messing up the thread.
I tested your image in OpenStack Havana with KVM so my comments are
very much OpenStack centric.
> Hi,
> CentOS-6.4 i386 and x86_64 images targetting OpenStack are now available
> for testing at http://dev.centos.org/centos/hvm/ Images are available
> for KVM, Hyper-V, VMware, Xen and any other HVM hypervisor. Although,
> the 6.x kernel has the pv support enabled, so should work fine under
> paravirt Xen as well.
> Images are published as raw, qcow2 qcow2compressed and vpc ( vhd ) for
> both i386 and x86_64 CentOS-6.4 The images represent media versions, and
> have not had an update run against them. Its highly recommended that in
> testing, please check this version *then* do a yum update and repeat
> tests to ensure that there is no test result change in the 6.4+updates
> tree's.
> Keeping in line with the general CentOS Cloud strategy, ie to help
> people migrate or investigate cloud instances, we expect the images to
> represent as close as possible to a real machine CentOS install ( ie. no
> cloud specific user, people use root to login, selinux is enabled ).
I'd prefer a non-root default user to be inline with the other
community images. IMHO it's a convenience to not have to create a
non-root user after spinning up an instance. But cloud-init will take
care of all that for you, if you configure it correctly, which doesn't
seem to be the case in your image. I.e., cloud-init creates a
'cloud-user' and disables root login but for some reason the
cloud-user is not allowed to sudo (should be handled by cloud-init) so
there's no way to gain root permissions.
In general, the cloud environment has no business in mocking with a
guest image. Yes, OpenStack is still injecting keys but that is likely
to change (I believe). It should be up to the instance to configure
itself which is what we have cloud-init for. In terms of users, I vote
for:
- A 'centos' default user without a password (no console login) and
password-less sudo permissions. This follows Fedora and Ubuntu and to
some degree Debian conventions. IIRC Debinan uses 'admin' as the
default user.
- Disabled root login and certainly no standard well-known password
which is simply a security disaster waiting to happen.
I'm not too crazy about SSH password access and cloud-init disables
that as well (unless you tell it not to).
In general, a cloud image should be as locked-down as possible to
reduce the risk of somebody else taking over your instance before you
can get to it. Providing SSH key access is the preferred method.
Everything else can be enabled later or when the instance is launched
(for example by providing a configuration script that cloud-init
executes on first boot). Similarly, selinux should be enabled by
default. The firewall can be discussed. I think it's not required
since the cloud environment already provides that functionality and
you have to specifically open ports to get access to your instance.
As for console logins, why would we want that in the base image? Can
somebody give a use case? I just don't see it as useful. We have SSH
access and as mentioned everything else required/desired should be
enabled/configured once the instance is up. If SSH access doesn't work
after first boot, then there's something fundamentaly broken and
console access will most likely not work either.
LVM: What's the rational for using LVM? It's not like we can just add
another disk to the instance and add it to the volume. IMHO it just
adds unnecessary overhead and breaks the growroot functionality.
dracut-modules-growroot (which I maintain in EPEL) doesn't support
LVM.
swap: Providing a swap device in a cloud image is debatable as well.
Some clouds charge for IOs and you don't want to pay for swap activity
so the cloud images I'm aware of don't have a predefined swap device.
Again, it can always be added later if need be.
console: As mentioned by others, please add 'console=tty1' to the
kernel commandline to get some messages on the virtual console:
'console=tty1 console=ttyS0' (See
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1016695 for
the rational to use tty1 instead of tty0).
If you try to make this image as close to regular CentOS as possible,
you might confuse other cloud users that are used to certain things in
other cloud images. Although those 'things' are not standardized and
we're not required to follow them. It's a balancing act, I guess.
> CentOS-6.4-i386-Minimal-OpenStack.image.qcow2c.bz2
> CentOS-6.4-x86_64-Minimal-OpenStack.image.qcow2.bz2
Why the bzip2 compression on top of qcow compression? It doesn't
create much smaller files and requires and extra step after
downloading the images. No big deal, though.
> Enjoy!
Good work!
...Juerg
Hi Sancho,
I want to re-config networking in the "first boot" stage,
but there are just "welcome", "create user" and so on except "networking",
how to add "networking" configuration in the "first boot" stage ?
Thanks,
- Jojo
hi Guys
One of the key problems we need to solve / resolve and do so with some
level of urgency is the mirror problem : How do we get content 'out
there' fast enough to reduce the time-to-release lag. Typically, from
the time everything is ready to go and the release notes / release email
are done, it takes 3 days to get to a releaseable stage for the mirror
network.
The rsync tree that we are using at this point is clearly not
good-enough ( either because of how we use it, or because of what it is
and how it works ). Also, release time activity and how donors react to
them makes it tricky to rely on specific nodes - something we really
need to get to in order to improve the rsync tree cascading setup we
have in place.
Thoughts, ideas ? Discuss!
- KB
--
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
GnuPG Key : http://www.karan.org/publickey.asc
Hi,
I am a newbie about for building CentOS iso,
i want to build specific image based on CentOS du to stability, clean of the CentOS :)
i find some wiki from homepage of CentOS.org (http://CentOS.org) except nothing about for building image/iso from scratch :(
anyone could give me any hits for building instruction for CentOS image ?
Thanks,
- Jojo
Hi,
I have recently found a problem of randomly being blocked by ssh
connection to a 64 bit CentOS 6.4 virtual machine, the dmesg shown
following error:
..........
INFO: task gnome-settings-:16976 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
gnome-setting D 0000000000000000 0 16976 1 0x00000080
ffff8800dc3e5dd8 0000000000000082 0000000000000000 ffff8800be54faf0
ffff8800dc3e5d98 ffff8800daf07540 ffff8800daf07540 ffff8800daf07540
ffff8800daf07af8 ffff8800dc3e5fd8 000000000000fb88 ffff8800daf07af8
Call Trace:
[<ffffffff811a1bc0>] ? mntput_no_expire+0x30/0x110
[<ffffffff8150efbe>] __mutex_lock_slowpath+0x13e/0x180
[<ffffffff8150ee5b>] mutex_lock+0x2b/0x50
[<ffffffff8118e890>] lookup_create+0x30/0xd0
[<ffffffff81192589>] sys_symlinkat+0x99/0x120
[<ffffffff81186b4e>] ? vfs_lstat+0x1e/0x20
[<ffffffff81186b74>] ? sys_newlstat+0x24/0x50
[<ffffffff810dc8f7>] ? audit_syscall_entry+0x1d7/0x200
[<ffffffff81192626>] sys_symlink+0x16/0x20
[<ffffffff8100b072>] system_call_fastpath+0x16/0x1b
--------
Searched from Internet and found similar bug report for Fedora 19
declared the issue to a blocker. It seems to me that the bug I
encountered is the same in Fedora 19. While Fedora has a workaround
patch, I am not clear if that bug has been reported to CentOS dev and
if you have a patch as well? Please advice and update.
Thank you.
Kind regards,
jupiter
Hello,
I will to build a new iso for myself with custom packages and kickstarts.
Currently which tools do you use to build your centos builds? According to
my research, pungi and revisor are some tools. Do you have any
recommendation?
Regards,