Re: NFTables To Replace iptables In the Linux Kernel
On 21/10/2013 4:09 AM, Henrique C. S. Junior wrote: As reported in Slashdot[1] in the near future iptables is going to be replaced by NFTables in the linux kernel. The project[2] is said to be a new and best package filtering framework. Have any of you, guys, tried it already and have some experiences to share? Does it matter? EL6 won't ever have NFTables support. EL7 probably won't either. Don't stress and keep doing what you're doing. -- Steven Haigh Email: net...@crc.id.au Web: https://www.crc.id.au Phone: (03) 9001 6090 - 0412 935 897 Fax: (03) 8338 0299 signature.asc Description: OpenPGP digital signature
issue in CD not ejecting at the end of OS installation
HI, I am porting my application from Redhat to Scientific Linux 6.3 In Scientific Linux the CD is not ejecting at the end of installation though I have added eject at the end of my kick start file. Can someone point how to fix this issue Thanks, Arul
RE: issue in CD not ejecting at the end of OS installation
Hi All, In the kick start file, I have mentioned eject at post section at the end. Still installation DVD is not ejecting . suggestion on what needs to be configured is welcome #platform=x86, AMD64, or Intel EM64T #version=DEVEL # Firewall configuration firewall --disabled install cdrom graphical firstboot --disable keyboard us lang en_US selinux --disabled logging --level=info . %packages %post eject %end -Original Message- From: owner-scientific-linux-us...@listserv.fnal.gov [mailto:owner-scientific-linux-us...@listserv.fnal.gov] On Behalf Of Edison, Arul (GE Healthcare) Sent: Monday, October 21, 2013 3:54 PM To: scientific-linux-users@fnal.gov Subject: issue in CD not ejecting at the end of OS installation HI, I am porting my application from Redhat to Scientific Linux 6.3 In Scientific Linux the CD is not ejecting at the end of installation though I have added eject at the end of my kick start file. Can someone point how to fix this issue Thanks, Arul
Re: issue in CD not ejecting at the end of OS installation
On 10/21/13 8:12 AM, Edison, Arul (GE Healthcare) wrote: Hi All, In the kick start file, I have mentioned eject at post section at the end. Still installation DVD is not ejecting . suggestion on what needs to be configured is welcome I've been forced to use a hammer (figuratively) to make the eject work until I could sort out (not yet) why a smple 'eject' command didn't work in the kickstart file. The commands I've experimented with are at the end of my postinstall section: eject -v cdrom #eject -v -a on cdrom #eject -v -r -a on cdrom #eject -v -r -a on /dev/cdrom As you can see, for the moment the first is working for me as I want, the verbose flag is just because and I've not messed with success since. I'm open to other approaches, I've just been wrapped up in my own efforts. -- MCTMichael C Tiernan xmpp:mtier...@mit.edu +1 (617) 324-9173 MIT - Laboratory for Nuclear Science - http://www.lns.mit.edu High Perf Research Computing Facility at The Bates Linear Accelerator Please avoid sending me MS-Word or MS-PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html smime.p7s Description: S/MIME Cryptographic Signature
Kernel Panic after power failure
After a power failure in my building, my SL 6.4 (x86_64) is experiencing a
kernel panic in the first stages of booting.
Error messages suggests that a serious problem occurred with my Ext4 filesystem
in /dev/mapper/VolGroup-lv_root.
Here are the error messages aftes the kernel panic:
ata3.00: status: { DRDY ERR }
ata3.00: error: { UNC }
ata3.00: exception Emask 0xoSAct 0x0 SErr 0x0 action 0x0
ata3.00: BMDMA stat 0x25
ata3.00: failed command: READ DMA
ata3.00: cmd c8/00:00:c0:86:14/00:00:00:00:00/e3 tag 0 dm 131072 in
res 51/40:cf:e8:86:14/00:00:00:00:00/e3 Emask 0x9 (media error)
ata3.00: status: { DRDY ERR }
ata3.00: error: { UNC }
JBD: Failed to read block at offset 6886
EXT4-fs (dm-0): error
loading journal
mount: wrong fs type, bad option, bad superblock on
/dev/mapper/VolGroup-lv_root,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
Rescue disk says that I don't have any Linux partitions and I need to rescue,
at least, two MySQL databases in this server.
Can someone, please, provide some help with this case?
---
Henrique C. S. Junior
http://about.me/henriquejunior
Química Industrial - UFRRJ
Prefeitura Muncipal de Paracambi
Centro de Processamento de Dados
Re: Kernel Panic after power failure
Is it a SSD? A lot of SSD (especially consumer grade) lie about writes
completing and cause nasty problems when the power goes out...
Try mounting it with ro,noload.
- Original Message -
From: Henrique C. S. Junior henrique...@gmail.com
To: Scientific Linux Users scientific-linux-users@fnal.gov
Sent: Monday, October 21, 2013 8:52:52 AM
Subject: Kernel Panic after power failure
After a power failure in my building, my SL 6.4 (x86_64) is
experiencing a kernel panic in the first stages of booting.
Error messages suggests that a serious problem occurred with my Ext4
filesystem in /dev/mapper/VolGroup-lv_root.
Here are the error messages aftes the kernel panic:
ata3.00: status: { DRDY ERR }
ata3.00: error: { UNC }
ata3.00: exception Emask 0xoSAct 0x0 SErr 0x0 action 0x0
ata3.00: BMDMA stat 0x25
ata3.00: failed command: READ DMA
ata3.00: cmd c8/00:00:c0:86:14/00:00:00:00:00/e3 tag 0 dm 131072 in
res 51/40:cf:e8:86:14/00:00:00:00:00/e3 Emask 0x9 (media error)
ata3.00: status: { DRDY ERR }
ata3.00: error: { UNC }
JBD: Failed to read block at offset 6886
EXT4-fs (dm-0): error loading journal
mount: wrong fs type, bad option, bad superblock on
/dev/mapper/VolGroup-lv_root,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
Rescue disk says that I don't have any Linux partitions and I need
to rescue, at least, two MySQL databases in this server.
Can someone, please, provide some help with this case?
---
Henrique C. S. Junior
http://about.me/henriquejunior
Química Industrial - UFRRJ
Prefeitura Muncipal de Paracambi
Centro de Processamento de Dados
Re: Kernel Panic after power failure
I was able to fix the issue using the steps provided here:
http://pissedoffadmins.com/os/mount-unknown-filesystem-type-lvm2_member.html
Thank you for your help, guys.
2013/10/21 Henrique C. S. Junior henrique...@gmail.com
Hi,
It is an HDD failure. I have already tried e2fsck -b 8193 with no luck...
---
Henrique C. S. Junior
http://about.me/henriquejunior
Química Industrial - UFRRJ
Prefeitura Muncipal de Paracambi
Centro de Processamento de Dados
On Monday, October 21, 2013 11:33 AM, Henrique Castro
henrique...@yahoo.com wrote:
Hi,
It is an HDD failure. I have already tried e2fsck -b 8193 with no luck...
---
Henrique C. S. Junior
http://about.me/henriquejunior
Química Industrial - UFRRJ
Prefeitura Muncipal de Paracambi
Centro de Processamento de Dados
On Monday, October 21, 2013 11:23 AM, Oleg Sadov sa...@linux-ink.ru
wrote:
Seems like HDD failure. Try to read this disk in another computer. If
superblock is damaged -- you may try to recover form backup superblock
(e2fsck -b).
21/10/2013 05:52 -0700, Henrique C. S. Junior wrote:
After a power failure in my building, my SL 6.4 (x86_64) is
experiencing a kernel panic in the first stages of booting.
Error messages suggests that a serious problem occurred with my Ext4
filesystem in /dev/mapper/VolGroup-lv_root.
Here are the error messages aftes the kernel panic:
ata3.00: status: { DRDY ERR }
ata3.00: error: { UNC }
ata3.00: exception Emask 0xoSAct 0x0 SErr 0x0 action 0x0
ata3.00: BMDMA stat 0x25
ata3.00: failed command: READ DMA
ata3.00: cmd c8/00:00:c0:86:14/00:00:00:00:00/e3 tag 0 dm 131072 in
res 51/40:cf:e8:86:14/00:00:00:00:00/e3 Emask 0x9 (media
error)
ata3.00: status: { DRDY ERR }
ata3.00: error: { UNC }
JBD: Failed to read block at offset 6886
EXT4-fs (dm-0): error loading journal
mount: wrong fs type, bad option, bad superblock
on /dev/mapper/VolGroup-lv_root,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
Rescue disk says that I don't have any Linux partitions and I need
to rescue, at least, two MySQL databases in this server.
Can someone, please, provide some help with this case?
---
Henrique C. S. Junior
http://about.me/henriquejunior
Química Industrial - UFRRJ
Prefeitura Muncipal de Paracambi
Centro de Processamento de Dados
--
Henrique LonelySpooky Junior
http://about.me/henriquejunior
Re: NFTables To Replace iptables In the Linux Kernel
On 10/21/2013 01:07 AM, Steven Haigh wrote: On 21/10/2013 4:09 AM, Henrique C. S. Junior wrote: As reported in Slashdot[1] in the near future iptables is going to be replaced by NFTables in the linux kernel. The project[2] is said to be a new and best package filtering framework. Have any of you, guys, tried it already and have some experiences to share? Does it matter? EL6 won't ever have NFTables support. EL7 probably won't either. Don't stress and keep doing what you're doing. Perhaps someone familiar with the choices made by TUV will clarify the above statement: EL7 probably won't either. SL and other TUV re-distributors of EL simply build and re-package the TUV product (removing the logos and non-open copyrighted material, but keeping all of the internal TUV developer statements -- the actual name of TUV, that evidently is taboo on this list, is plastered all over the source code for EL). Thus, the decision as to which family of Linux kernels to use is a TUV decision. However, as fundamental new functionality, or repackaging of existing functionality with a new API, is incorporated into the Linux kernel -- not in an experimental way that may be removed, but in the stable production released version - the high reliability approach requires that the kernel receives extensive field testing (as happens with Fedora) as well as stress testing and internal hardening against threats and compromises that may not be as needed in an enthusiast distribution. Nonetheless, once a major change (e.g., NFTables replacing iptables) is done in the base source, the production enterprise version must reflect the change -- and in less than a decade. Why less than a decade? Unless there is a fully backward compatible set of APIs, new applications and revisions typically use the current not historical APIs. Presumably, there will be NFTables features that application developers will use that have no iptables backport. Thus -- how long is the delay? Typically, are two major releases (e.g., NFTables in EL8) the usual delay? Does anyone have historical data from EL/TUV? Yasha Karant
Re: NFTables To Replace iptables In the Linux Kernel
EL7 is coming, probably, with kernel 3.11 so, the changes in kernel 3.13 and later will (probably) affect EL = 8. --- Henrique C. S. Junior http://about.me/henriquejunior Química Industrial - UFRRJ Prefeitura Muncipal de Paracambi Centro de Processamento de Dados On Monday, October 21, 2013 1:36 PM, Yasha Karant ykar...@csusb.edu wrote: On 10/21/2013 01:07 AM, Steven Haigh wrote: On 21/10/2013 4:09 AM, Henrique C. S. Junior wrote: As reported in Slashdot[1] in the near future iptables is going to be replaced by NFTables in the linux kernel. The project[2] is said to be a new and best package filtering framework. Have any of you, guys, tried it already and have some experiences to share? Does it matter? EL6 won't ever have NFTables support. EL7 probably won't either. Don't stress and keep doing what you're doing. Perhaps someone familiar with the choices made by TUV will clarify the above statement: EL7 probably won't either. SL and other TUV re-distributors of EL simply build and re-package the TUV product (removing the logos and non-open copyrighted material, but keeping all of the internal TUV developer statements -- the actual name of TUV, that evidently is taboo on this list, is plastered all over the source code for EL). Thus, the decision as to which family of Linux kernels to use is a TUV decision. However, as fundamental new functionality, or repackaging of existing functionality with a new API, is incorporated into the Linux kernel -- not in an experimental way that may be removed, but in the stable production released version - the high reliability approach requires that the kernel receives extensive field testing (as happens with Fedora) as well as stress testing and internal hardening against threats and compromises that may not be as needed in an enthusiast distribution. Nonetheless, once a major change (e.g., NFTables replacing iptables) is done in the base source, the production enterprise version must reflect the change -- and in less than a decade. Why less than a decade? Unless there is a fully backward compatible set of APIs, new applications and revisions typically use the current not historical APIs. Presumably, there will be NFTables features that application developers will use that have no iptables backport. Thus -- how long is the delay? Typically, are two major releases (e.g., NFTables in EL8) the usual delay? Does anyone have historical data from EL/TUV? Yasha Karant
RE: issue in CD not ejecting at the end of OS installation
Eject is a valid kickstart directive you don't need to put it in a post. Additionally if you don't include the eject package in your package then in a post statement it won't work because the post by default execute chrooted into the installed OS-- Sent from my HP Pre3On Oct 21, 2013 8:13, Edison, Arul (GE Healthcare) aruljeyananth.jamesedi...@ge.com wrote: Hi All, In the kick start file, I have mentioned eject at post section at the end. Still installation DVD is not ejecting . suggestion on what needs to be configured is welcome #platform=x86, AMD64, or Intel EM64T #version=DEVEL # Firewall configuration firewall --disabled install cdrom graphical firstboot --disable keyboard us lang en_US selinux --disabled logging --level=info . %packages %post eject %end -Original Message- From: owner-scientific-linux-us...@listserv.fnal.gov [mailto:owner-scientific-linux-us...@listserv.fnal.gov] On Behalf Of Edison, Arul (GE Healthcare) Sent: Monday, October 21, 2013 3:54 PM To: scientific-linux-users@fnal.gov Subject: issue in CD not ejecting at the end of OS installation HI, I am porting my application from Redhat to Scientific Linux 6.3 In Scientific Linux the CD is not ejecting at the end of installation though I have added eject at the end of my kick start file. Can someone point how to fix this issue Thanks, Arul
Re: NFTables To Replace iptables In the Linux Kernel
On 10/21/2013 10:34 AM, Yasha Karant wrote: On 10/21/2013 01:07 AM, Steven Haigh wrote: On 21/10/2013 4:09 AM, Henrique C. S. Junior wrote: As reported in Slashdot[1] in the near future iptables is going to be replaced by NFTables in the linux kernel. The project[2] is said to be a new and best package filtering framework. Have any of you, guys, tried it already and have some experiences to share? Does it matter? EL6 won't ever have NFTables support. EL7 probably won't either. Don't stress and keep doing what you're doing. Perhaps someone familiar with the choices made by TUV will clarify the above statement: EL7 probably won't either. SL and other TUV re-distributors of EL simply build and re-package the TUV product (removing the logos and non-open copyrighted material, but keeping all of the internal TUV developer statements -- the actual name of TUV, that evidently is taboo on this list, is plastered all over the source code for EL). Thus, the decision as to which family of Linux kernels to use is a TUV decision. Redhat Enterprise Linux! It isn't taboo, just takes longer to type than TUV. Their trademarks must be removed from documentation and distributed materials. Internet discussions really don't matter. However, as fundamental new functionality, or repackaging of existing functionality with a new API, is incorporated into the Linux kernel -- not in an experimental way that may be removed, but in the stable production released version - the high reliability approach requires that the kernel receives extensive field testing (as happens with Fedora) as well as stress testing and internal hardening against threats and compromises that may not be as needed in an enthusiast distribution. Nonetheless, once a major change (e.g., NFTables replacing iptables) is done in the base source, the production enterprise version must reflect the change -- and in less than a decade. Why less than a decade? Unless there is a fully backward compatible set of APIs, new applications and revisions typically use the current not historical APIs. Presumably, there will be NFTables features that application developers will use that have no iptables backport. If one takes the time to read up on NFTables (e.g. the articles previously linked), they would find that there is an iptables compatibility layer under development alongside this new project. Thus -- how long is the delay? Typically, are two major releases (e.g., NFTables in EL8) the usual delay? Does anyone have historical data from EL/TUV? Like was previously said. I wouldn't get flustered or worked up over this. NFTables has been in the works for 4 years and is just making it into forked development tree (not mainline) and will be some time before it trickles into the enterprise. Look at how far ahead KDE, Gnome, and other technologies are from the current SL6 offering for comparison. -Mark -- Mr. Mark V. Stodola Senior Control Systems Engineer National Electrostatics Corp. P.O. Box 620310 Middleton, WI 53562-0310 USA Phone: (608) 831-7600 Fax: (608) 831-9591
Re: issue in CD not ejecting at the end of OS installation
On 10/21/13 11:43 AM, Paul Robert Marino wrote: Eject is a valid kickstart directive you don't need to put it in a post. Additionally if you don't include the eject package in your package then in a post statement it won't work because the post by default execute chrooted into the installed OS Yes it is valid but, as seems to be the case at times, the system didn't read the book. I put it in post because 'eject' wasn't working and I needed to fix it sooner than later. (And yes, eject was installed on the system when tested.) -- MCTMichael C Tiernan xmpp:mtier...@mit.edu +1 (617) 324-9173 MIT - Laboratory for Nuclear Science - http://www.lns.mit.edu High Perf Research Computing Facility at The Bates Linear Accelerator Please avoid sending me MS-Word or MS-PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html smime.p7s Description: S/MIME Cryptographic Signature
Re: NFTables To Replace iptables In the Linux Kernel
On Mon, Oct 21, 2013 at 08:34:58AM -0700, Yasha Karant wrote: [...] -- the actual name of TUV, that evidently is taboo on this list, [...] Evidently? It's complete nonsense to NOT use the name of TUV here or at whatever place, as long as you don't say things about SL in relation to TUV and/or their products that are illegal. I thought only the CentOS community was (for no good reason) paranoid. In the time I created and released X/OS Linux, being also rebuild of the Red Hat Enterprise Linux 3/4/5 sources, I did mention Red Hat, RHEL, etc., but only as far as appropriate and allowed of course. Nonetheless, once a major change (e.g., NFTables replacing iptables) is done in the base source, the production enterprise version must reflect the change -- and in less than a decade. Why less than a decade? Unless there is a fully backward compatible set of APIs, new applications and revisions typically use the current not historical APIs. Presumably, there will be NFTables features that application developers will use that have no iptables backport. Thus -- how long is the delay? Typically, are two major releases (e.g., NFTables in EL8) the usual delay? Does anyone have historical data from EL/TUV? Fedora 20 seems to use the 3.11 kernel, so it won't have a kernel with NFTables. RHEL 7 is already being developed (and in alpha stage as far as I've heard) and will most likely have a kernel = 3.11, so this makes the statement that EL7 probably won't either very trustworthy. There are no statistics about delays etc. needed to just see that RHEL 7 won't use a kernel that supports NFTables. So, there is no artificial delay created by RH to postpone things in RHEL, it's just common sense when someone says this about NFTables in relattion to RHEL 7. -- --Jos Vos j...@xos.nl --X/OS Experts in Open Systems BV | Phone: +31 20 6938364 --Amsterdam, The Netherlands| Fax: +31 20 6948204
Re: NFTables To Replace iptables In the Linux Kernel
Well I've heard this before Nf-Hipac http://www.hipac.org/ was at one time slated to be the next big thing. I'm not holding my breath on this one and if it does replace all of the existing tools expect it to be a few years before you see it in production any where. On Mon, Oct 21, 2013 at 1:47 PM, Jos Vos j...@xos.nl wrote: On Mon, Oct 21, 2013 at 08:34:58AM -0700, Yasha Karant wrote: [...] -- the actual name of TUV, that evidently is taboo on this list, [...] Evidently? It's complete nonsense to NOT use the name of TUV here or at whatever place, as long as you don't say things about SL in relation to TUV and/or their products that are illegal. I thought only the CentOS community was (for no good reason) paranoid. In the time I created and released X/OS Linux, being also rebuild of the Red Hat Enterprise Linux 3/4/5 sources, I did mention Red Hat, RHEL, etc., but only as far as appropriate and allowed of course. Nonetheless, once a major change (e.g., NFTables replacing iptables) is done in the base source, the production enterprise version must reflect the change -- and in less than a decade. Why less than a decade? Unless there is a fully backward compatible set of APIs, new applications and revisions typically use the current not historical APIs. Presumably, there will be NFTables features that application developers will use that have no iptables backport. Thus -- how long is the delay? Typically, are two major releases (e.g., NFTables in EL8) the usual delay? Does anyone have historical data from EL/TUV? Fedora 20 seems to use the 3.11 kernel, so it won't have a kernel with NFTables. RHEL 7 is already being developed (and in alpha stage as far as I've heard) and will most likely have a kernel = 3.11, so this makes the statement that EL7 probably won't either very trustworthy. There are no statistics about delays etc. needed to just see that RHEL 7 won't use a kernel that supports NFTables. So, there is no artificial delay created by RH to postpone things in RHEL, it's just common sense when someone says this about NFTables in relattion to RHEL 7. -- --Jos Vos j...@xos.nl --X/OS Experts in Open Systems BV | Phone: +31 20 6938364 --Amsterdam, The Netherlands| Fax: +31 20 6948204
Re: NFTables To Replace iptables In the Linux Kernel
Precisely my point. Compatibility modes often are incomplete, unfaithful, and unreliable. I am not singing the praises of any new fundamental change in a basic kernel utility/configuration entity that has been integrated into many application and configuration packages/environments/situations . However, if the change is forced upon the community, then developers either must maintain two (or more) fundamentally incompatible versions (e.g., native STL and the rest for an ANSI open systems environment and MFC for a proprietary monopoly environment), or select one and let those lacking the environment to find another solution (e.g., VirtualBox to run native MS Windows as a guest/application to run a monopoly only application or environment under a Linux host). Admittedly, the change coming to the linux kernel (unless the change is abandoned) is not as drastic as having to use the monopoly MFC, but it certainly could prove to be highly inconvenient. My timeline question was less directed towards application end user environments such as KDE or Gnome, but more towards actual fundamental kernel or Xwindows internals and the APIs required to use these fundamentals. Does anyone have an average time interval from history when a major change was declared stable production in the fundamental internals and then actually appeared in RHEL production (as it appears RHEL is no longer taboo)? It is Red Hat that determines this timeline, not the clone distributions such as SL or CentOS. Yasha Karant On 10/21/2013 03:53 PM, Nico Kadel-Garcia wrote: If one takes the time to read up on NFTables (e.g. the articles previously linked), they would find that there is an iptables compatibility layer under development alongside this new project. I hear there's plans at NASA for a manned return to the moon, too. Don't hold your breath. Under development by the core authors of nftables itself does not mean they know the iptables configuration tools well enough to write such a layer to work across the broad variety of RPM based and configuration tool managed oddities. Even the system-config-security tool is seriously awkward and underpowered for any complex iptables configurations. I'll be pleased, and surprised, if their nftables compatibility toolkit tool can manage even the well documented configurations and layout of system-config-security.
