-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi all,
Final TC4 images have been uploaded to EC2 and are available at
ami-955476fc : us-east-1 image for i386 ami-c95476a0 : us-east-1 image for x86_64
additionally if your looking to the AMI's they have been added to files in the release tree http://dl.fedoraproject.org/pub/alt/stage/20-TC4/Images/i386/Fedora-Images-i... http://dl.fedoraproject.org/pub/alt/stage/20-TC4/Images/x86_64/Fedora-Images...
when we get to final and the images are uploaded to all regions they will all be listed and the file will be gpg signed in the final tree
Dennis
Dennis Gilmore dennis@ausil.us writes:
Hi all,
Final TC4 images have been uploaded to EC2 and are available at
ami-955476fc : us-east-1 image for i386 ami-c95476a0 : us-east-1 image for x86_64
The only issue compared to TC3 is one more file with wrong selinux context (/var/log/cron).
So, for TC4: # restorecon -R -v -n -e /proc -e /sys -e /dev -e/run -e/tmp / restorecon reset /var/log/cron context system_u:object_r:var_log_t:s0->system_u:object_r:cron_log_t:s0 restorecon reset /var/log/boot.log context system_u:object_r:var_log_t:s0->system_u:object_r:plymouthd_var_log_t:s0 restorecon reset /var/cache/yum context system_u:object_r:file_t:s0->system_u:object_r:rpm_var_cache_t:s0 restorecon reset /boot/extlinux/ldlinux.sys context system_u:object_r:file_t:s0->system_u:object_r:boot_t:s0
for TC3 it was: # restorecon -R -v -n -e /proc -e /sys -e /dev -e/run -e/tmp / restorecon reset /boot/extlinux/ldlinux.sys context system_u:object_r:file_t:s0->system_u:object_r:boot_t:s0 restorecon reset /var/log/boot.log context system_u:object_r:var_log_t:s0->system_u:object_r:plymouthd_var_log_t:s0 restorecon reset /var/cache/yum context system_u:object_r:file_t:s0->system_u:object_r:rpm_var_cache_t:s0
not sure if it deserves BZ and against what if it does. Last time I created https://bugzilla.redhat.com/show_bug.cgi?id=1033274 against anaconda but it seems misplaced.
On Tue, Dec 03, 2013 at 04:42:44PM +0100, Vitaly Kuznetsov wrote:
The only issue compared to TC3 is one more file with wrong selinux context (/var/log/cron). So, for TC4: # restorecon -R -v -n -e /proc -e /sys -e /dev -e/run -e/tmp / restorecon reset /var/log/cron context system_u:object_r:var_log_t:s0->system_u:object_r:cron_log_t:s0 restorecon reset /var/log/boot.log context system_u:object_r:var_log_t:s0->system_u:object_r:plymouthd_var_log_t:s0
These files don't exist initially -- I expect that just creating them before the fixfiles is run in the kickstart should do it.
restorecon reset /var/cache/yum context system_u:object_r:file_t:s0->system_u:object_r:rpm_var_cache_t:s0
This _does_ exist, though, so it's more of a puzzle. Any guesses?
restorecon reset /boot/extlinux/ldlinux.sys context system_u:object_r:file_t:s0->system_u:object_r:boot_t:s0
And this is because it's immutable.
not sure if it deserves BZ and against what if it does. Last time I created https://bugzilla.redhat.com/show_bug.cgi?id=1033274 against anaconda but it seems misplaced.
Since we're building with appliance-creator, anaconda isn't involved. That will change in the future.... In the meantime, we have to hack around it with kickstart kludges. Can you test
http://mattdm.fedorapeople.org/tmp/Fedora20-sda.qcow2
to see if it's any better?
Matthew Miller mattdm@fedoraproject.org writes:
On Tue, Dec 03, 2013 at 04:42:44PM +0100, Vitaly Kuznetsov wrote:
The only issue compared to TC3 is one more file with wrong selinux context (/var/log/cron). So, for TC4: # restorecon -R -v -n -e /proc -e /sys -e /dev -e/run -e/tmp / restorecon reset /var/log/cron context system_u:object_r:var_log_t:s0->system_u:object_r:cron_log_t:s0 restorecon reset /var/log/boot.log context system_u:object_r:var_log_t:s0->system_u:object_r:plymouthd_var_log_t:s0
These files don't exist initially -- I expect that just creating them before the fixfiles is run in the kickstart should do it.
restorecon reset /var/cache/yum context system_u:object_r:file_t:s0->system_u:object_r:rpm_var_cache_t:s0
This _does_ exist, though, so it's more of a puzzle. Any guesses?
restorecon reset /boot/extlinux/ldlinux.sys context system_u:object_r:file_t:s0->system_u:object_r:boot_t:s0
And this is because it's immutable.
not sure if it deserves BZ and against what if it does. Last time I created https://bugzilla.redhat.com/show_bug.cgi?id=1033274 against anaconda but it seems misplaced.
Since we're building with appliance-creator, anaconda isn't involved. That will change in the future.... In the meantime, we have to hack around it with kickstart kludges. Can you test
http://mattdm.fedorapeople.org/tmp/Fedora20-sda.qcow2
to see if it's any better?
It definitely is: restorecon -R -v -n -e /proc -e /sys -e /dev -e/run -e/tmp / restorecon reset /mnt context unconfined_u:object_r:default_t:s0->unconfined_u:object_r:mnt_t:s0 restorecon reset /var/cache/yum context unconfined_u:object_r:file_t:s0->unconfined_u:object_r:rpm_var_cache_t:s0
But that's kvm. Unless cloud-init does some nasty magick in EC2 we're ok)
BTW, our cloud-init is slighly outdated (0.7.4 is out for couple of weeks).