search for: cpios

Hi there, I'm following the security advisory to patch the cpio vulnerability (update to 6_0_0 RELENG p2, make obj, make depend), yet when it comes to make, it shows some error message as follows: /usr/src/gnu/usr.bin/cpio/../../../contrib/cpio/copyin.c:536: error: redefinition of 'safer_name_suffix' /usr/src/gnu/usr.bin/cpio/../../../contrib/cpio/copyin.c:488: error: previous

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-06:03.cpio Security Advisory The FreeBSD Project Topic: Multiple vulnerabilities cpio Category: contrib Module: contrib_cpio Announced:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-06:03.cpio Security Advisory The FreeBSD Project Topic: Multiple vulnerabilities cpio Category: contrib Module: contrib_cpio Announced:

make -r -C /mlsyslinux -f /mlsyslinux/Makefile SRC="/mlsyslinux" \ OBJ=/mlsyslinux objdir=/mlsyslinux bios make[1]: Entering directory `/mlsyslinux' make -r -C /mlsyslinux/bios -f /mlsyslinux/Makefile SRC="/mlsyslinux" \ objdir=/mlsyslinux/bios OBJ=/mlsyslinux/bios HAVE_FIRMWARE=1 \ ARCH=i386 LDLINUX=ldlinux.c32 all make[2]:

Unlink files, symlinks, FIFOs, devices etc. (except directories) before writing them when extracting CPIOs. This stops weird behaviour like: 1) writing through symlinks created in earlier CPIOs. eg foo->bar in the first CPIO. Having foo as a non-link in a subsequent CPIO, results in bar being written and foo remaining as a symlink. 2) if the first version of file foo is larger than foo...

It's x86 arch.The reason of compiling pxelinux only is that i want to add tcp support, not http and ftp. ? 2014-05-08 18:09:15?"Gene Cumm" <gene.cumm at gmail.com> ??? On May 7, 2014 11:54 PM, "??" <muliu92 at 163.com> wrote: > make[4]: Entering directory `/mlsyslinux/bios/com32/libupload' > gcc -Wp,-MT,cpio.o,-MD,./.cpio.o.d -std=gnu99 -m32

On May 7, 2014 11:54 PM, "??" <muliu92 at 163.com> wrote: > make[4]: Entering directory `/mlsyslinux/bios/com32/libupload' > gcc -Wp,-MT,cpio.o,-MD,./.cpio.o.d -std=gnu99 -m32 -march=i386 -mpreferred-stack-boundary=2 -fno-stack-protector -fwrapv -freg-struct-return -Os -fPIC -fno-exceptions -fno-asynchronous-unwind-tables -fno-strict-aliasing -falign-functions=0

Fix usr/Kbuild so it utilise the new gen_initramfs.sh script which will rebuild initramfs when the content has changed. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> --- usr/Kbuild | 74 +++++++++++++++++++---------------------------------------------- 1 file changed, 22 insertions(+), 52 deletions(-) This patch shall not be applied until my kbuild.git tree is merged upstream. Or it

hello, On Mon, 16 Jun 2008, Joey Hess wrote: > klibc cpio segfaults extracting various cpio files. It seems to work for > small files, but fail for larger ones, including the d-i root floppy > image. > > For example: > > joey at kodama:/tmp/empty>wget http://people.debian.org/~joeyh/d-i/images/20080401-09:01/floppy/root.img > joey at kodama:/tmp/empty>zcat

Generate dependencies almost like done by fixdep in the kernel. This teaches make to rebuild cpio image when content has changed. Also restructured usr/Kbuild a little so we better utilise parallel makes (dash, gzip, utils and kinit are now build in parallel). Signed-off-by: Sam Ravnborg <sam@ravnborg.org> --- patch is on top of hpa's linux tree, so path differ if applied to the klibc

> > according to the documentation the option ucode=scan should tell XEN to > > look for a microcode update in an uncompressed initrd. > > > > While I don?t use the Debian kernel the tools to generate the initrd are > > part of Debian. The command ?cpio -i < /boot/initrd.img-4.0.2-Dom0? > > creates the directory structure

On Thu, 2015-05-14 at 22:45 +0200, Stephan Seitz wrote: > On Wed, May 13, 2015 at 11:57:55AM -0400, Konrad Rzeszutek Wilk wrote: > >> > according to the documentation the option ucode=scan should tell XEN to > >> > look for a microcode update in an uncompressed initrd. > >> > > >> > While I don?t use the Debian kernel the tools to generate the

This fix has been implemented in preparation for the upcoming klibc merge in -mm. But as it fixes a real (but rare I hope) bug in vanilla kernel it will be added to my pending 2.6.17 kbuild queue. I've done quite some changes to the gen_initramfs script and being shell programming newbie review by more experienced shell hackers would be appreciated. I did a git mv

The following patch unlinks (deletes) files, symlinks, FIFOs, devices etc before writing them when extracting CPIOs. It doesn't delete directories. This stops weird behaviour like: 1) writing through symlinks created in earlier CPIOs. eg foo->bar in the first CPIO. Having foo as a non link in a subsequent CPIO, results in bar being written and foo remaining as a symlink. 2) if the first ver...

Can someone explain why this: find . -depth -print0 | cpio --null -pmd /tmp/test will copy all files in and below the current directory -and- this: find . -depth -print | grep -v .iso$ | wc -l will count all the non-iso files -and- this: find . -depth -print | grep .iso$ | wc -l will count *only* the iso files -but- this: find . -depth -print0 | grep -v .iso$ | cpio --null -pmd /tmp/test

Send CentOS-announce mailing list submissions to centos-announce at centos.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.centos.org/mailman/listinfo/centos-announce or, via email, send a message with subject or body 'help' to centos-announce-request at centos.org You can reach the person managing the list at centos-announce-owner at centos.org When

> -----Original Messages----- > From: "Steven Tardy" <sjt5atra at gmail.com> > Sent Time: 2018-02-26 10:48:48 (Monday) > To: "CentOS mailing list" <centos at centos.org> > Cc: > Subject: Re: [CentOS] How to update modules in iniramfs fastly > > On Sun, Feb 25, 2018 at 8:29 PM wuzhouhui <wuzhouhui14 at mails.ucas.ac.cn> > wrote:

One of the things I want to do besides mirror a hard drive is maintain an incremental backup on tape. The way for me to do this ( of course ) is to take the output of rsync and use it to generate a list of files for cpio. The basic ideal is something like this declare -i head tail # gets the first line with total: at the begining head=$(grep -n ^total: $log_rsync|awk -F: '{print $1}')

I've googled to try and find discussion of this topic but didn't see any results particularly interesting... Is there any particular reason the kernel has gen_init_cpio instead of just using cpio itself? I'm working on some changes that would involve just cpio-ing the entire usr/root subtree as the initramfs image (instead of gen_init_cpio having to know ahead of time what files to

Hello, There seems to be problem in the cpio unpack in the kernel in initramfs. I have an empty "/sys" directory in my cpio archive, but it never shows up in my extracted initramfs. I've confirmed that extracting the archive again with cpio results in a correct tree, but it doesn't appear on boot when extracted by the kernel. Any ideas? I poked a bit, but I haven't