Re: FC12+selinux+dump/restore



On Tue, 2010-03-23 at 13:33 +0000, T. Horsnell wrote:
Sorry people, I've just found a likely reference in Bugzilla.
Please ignore the stuff below for now...
Terry


Hi all,
I'm using the Live version of FC12 to produce a bootable clone of an idle FC12
system to a USB stick. One step involves using 'dump' to dump the contents of the
idle root fiesystem and piping the result to 'restore', to build the stick
copy of root. This all basically works, except that restore moans about a bunch
of files during the restoration process with things like:

/var/cache/fontconfig/xxxxx: EA set.security.selinux.system_u:object_r:fonts_cache_t:s0 failed: Invalid argument

The disk-based system originally had selinux disabled, and when I tried the dump
of that, I got thousands of restore errors. I then booted up the disk-based system,
set selinux to permissive and let it relabel the files. After that, restore only
produced the current bunch of errors. selinux on the live system runs in enforcing/targeted,
but the problem still occurs if I set it to permissive/targeted (by editing /etc/selinux/config
as there is no option for this in the Administration menu on the live system)

Any ideas anyone?

Cheers,
Terry



Hi Terry
Have you seen this one which I think maybe similar but
not the same?

http://sourceforge.net/tracker/?func=detail&aid=2964667&group_id=1306&atid=101306

John

Yes, thank you. It was in an earlier post of yours to this list.
I also got one of the errors referred to in that URL during my
restore attempts, so I added a reference to the link in my
Fedora bugzilla entry.

Cheers,
Terry
--
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines



Relevant Pages

  • FC12+selinux+dump/restore
    ... I'm using the Live version of FC12 to produce a bootable clone of an idle FC12 ... One step involves using 'dump' to dump the contents of the ... except that restore moans about a bunch ... The disk-based system originally had selinux disabled, and when I tried the dump ...
    (Fedora)
  • Re: FC12+selinux+dump/restore
    ... I'm using the Live version of FC12 to produce a bootable clone of an idle FC12 ... One step involves using 'dump' to dump the contents of the ... except that restore moans about a bunch ... The disk-based system originally had selinux disabled, and when I tried the dump ...
    (Fedora)
  • Re: FC12+selinux+dump/restore
    ... I'm using the Live version of FC12 to produce a bootable clone of an idle FC12 ... One step involves using 'dump' to dump the contents of the ... except that restore moans about a bunch ... The disk-based system originally had selinux disabled, and when I tried the dump ...
    (Fedora)
  • Re: DFSMSdss Data Loss Exposure (UPDATE)
    ... PATCH BYTE FOR DS1DSCHA / DS1IND20 ON FULL AND TRACKS RESTORE ... TRACKS RESTORE when DFSMSdss is not invoked via the API. ... This future enhancement would possibly include a change in default RESTORE behavior based on use of "RESET" in DUMP, with a new RESTORE option to allow for overriding default behavior. ... The crux of the problem is that the only practical way to make a physical copy of a volume with DFSMSdss for moving the volume or recovering it elsewhere is with "DUMP FULL" physical dump, and if this is recovered to another device with the obvious counterpart "RESTORE FULL", the result is currently not an identical volume, but a volume with all the VTOC "changed" bits on the volume reset. ...
    (bit.listserv.ibm-main)
  • DFSMSdss Data Loss Exposure (Was Re: DFSMSdss DOC APAR OA20117)
    ... which is the default usage, indicating the dump is not intended as a replacement for individual dataset dumps -- to save the image of a DASD volume and expecting at some point to use this dump with a "RESTORE FULL" to move the volume to another DASD drive, as part of a Data Center move or migration to new equipment, or for Data Center recovery at a remote site, THEN MOST LIKELY YOU ARE CURRENTLY EXPOSED TO SOME FORM OF DATA-LOSS! ... The crux of the problem is that the only practical way to make a physical copy of a volume with DFSMSdss for moving the volume or recovering it elsewhere is with "DUMP FULL" physical dump, and if this is recovered to another device with the obvious counterpart "RESTORE FULL", the result is currently not an identical volume, but a volume with all the VTOC "changed" bits on the volume reset. ...
    (bit.listserv.ibm-main)