Bug 484529

Summary: Fedora 11 Alpha: Error migrating ext3-> 4 via installation DVD on x86_64 with SELinux enforcing
Product: [Fedora] Fedora Reporter: Daniel Bristot <danielbristot>
Component: anacondaAssignee: Anaconda Maintenance Team <anaconda-maint-list>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: rawhideCC: anaconda-maint-list, esandeen, mishu, rjones
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-06-08 17:49:50 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
ls -lZ of /lib64 after migrate to ext4
none
output of ls -lZ /lib64 with SELinux Disabled
none
output of ls -lZ /lib64 after relabel files
none
boot errors after migrate none

Description Daniel Bristot 2009-02-07 23:54:54 UTC 
Description of problem:
Fedora 11 Alpha: Error migrating ext3-> 4 via installation DVD on x86_64 with SELinux enforcing

Version-Release number of selected component (if applicable):
Fedora 11 Alpha

How reproducible:
every time after migrate ext3 -> ext4 on F11Alpha

Steps to Reproduce:
1 Boot the F11 installer
2 install on lv with ext3 fs in /
3 complete installation
4 reboot into post-install system and complete firstboot
5 Boot the F11 installer with the ext4migrate boot option
6 select the / fs to upgrade
7 complete the upgrade
8 reboot the system

Actual results:
When the system boot, after show:
 Enabling /etc/fstab swaps     [ ok ]

I take many errors like:

 /sbin/consoletype: error while loading sharing libraries: libc.so.6: cannot open shared object file: permission denied.

and it appear many time, with another shared libraries, and the system break down.

Expected results:
normal boot

Additional info:

Workaround 1:
1 Boot the DVD on rescue mode, or, boot with init=/bin/bash,  
2 mount the / fs, and edit the /etc/selinux/config,
3 set "SELINUX=permissive"
4 reboot the system

Workaround 2: 
1 Boot the DVD on rescue mode, or, boot with init=/bin/bash,  
2 mount the / fs, and edit the /etc/selinux/config,
3 set "SELINUX=disable"
4 reboot the system
5 after the system boot, edit /etc/selinux/config
6 set "SELINUX=enforcing"
7 reboot the system and wait SELinux relabel the files.
Comment 1 Michal Jaegermann 2009-02-09 02:10:05 UTC 
In such case you should have "Workaround 3".  Boot with 'selinux=0', touch
/.autorelabel, and if "Workaround 2" really works then just reboot without extra options.
Comment 2 Eric Sandeen 2009-02-09 03:02:08 UTC 
If you can reproduce it, it'd be interesting to see if there are any selinux labels on the files in question: ls -Z /some/file when you have the problem (and when you boot with selinux permissive or off)

-Eric
Comment 3 Daniel Bristot 2009-02-12 01:36:37 UTC 
Created attachment 331639 [details]
ls -lZ of /lib64 after migrate to ext4

output of ls -lZ /lib64 after migrate the file system.
Comment 4 Daniel Bristot 2009-02-12 01:38:12 UTC 
Created attachment 331640 [details]
output of ls -lZ /lib64 with SELinux Disabled

output of ls -lZ with SELinux Disabled.
Comment 5 Daniel Bristot 2009-02-12 01:39:16 UTC 
Created attachment 331641 [details]
output of ls -lZ /lib64 after relabel files

output of ls -lZ /lib64 after relabel files
Comment 6 Daniel Bristot 2009-02-12 01:40:27 UTC 
Created attachment 331642 [details]
boot errors after migrate

the console of first boot after migrate de fs.
Comment 7 Eric Sandeen 2009-02-12 05:07:17 UTC 
I just realized - am I reading it right that you installed f11 on ext3 then rebooted the f11 installer (again) and told it to migrate?

FWIW, that won't actually do any migration (today, anyway).  It probably shouldn't make an unbootable system, but it won't actually migrate anything.

The only migration comes from tuning the fs to have extents and then overwriting (most) files during the actual upgrade process.

-Eric
Comment 8 Chris Lumens 2009-02-20 18:42:35 UTC 
From looking at anaconda real quick, it doesn't appear we actually ever perform a filesystem migration, besides just changing what gets written to /etc/fstab.  Extents are certainly never enabled on the filesystem.  Please try this again with F11 Beta (well - hopefully my patch will be in before then, but what precise day you'll see that in rawhide is tough to predict) and let me know if this is still an issue for you.