PDA

View Full Version : Custom partition setup order annoyance


Fenrin
12th April 2012, 10:39 PM
I'm installing Fedora 17 Beta RC4 on my notebook.

If I choose custom partition layout, the order of devices I create is completely random. I would think it makes sense that the partitions which I create first have a lower device number (example: sda1) than the devices I create later. I think it was like that in earlier releases.

Is this a bug or intentional? Did anyone else notice that?

sillav
12th April 2012, 11:01 PM
Also noticed it. I'm not sure if it is trying to be clever or its a bug. You can get around it by using gparted off a knoppix cd to create your partition layout first, then just mount the partitions and format to your desired filesystem.

It is annoying, but on the other hand, everyone should have a knoppix disc hanging around.

nonamedotc
12th April 2012, 11:06 PM

Did anyone else notice that?

Yup! I have seen that in earlier releases also. I have seen that even in Scientific Linux. So, I presume this "feature" has been there for a while.

Unfortunately, I do not know if there is a solution with respect to anaconda. I have just never spent time looking for it. Sorry, not much help here...

sonoran
12th April 2012, 11:14 PM
You can boot a LiveCD, install gparted via yum, create partitions, then install to them. :dance:

chrismurphy
12th April 2012, 11:26 PM
If you start entirely from scratch with custom, then it follows a non-random sequence. It's just that when you delete one, it renumbers the others, you add a new one and it adds whatever is missing. I doubt it's by design, it's probably the consequence of something else.

Fenrin
13th April 2012, 12:36 AM
I found out that gnome-disk-utility works too, as alternative to gparted or knoppix. And I also found out that a 1 MB "BIOS Boot" partition is needed since Fedora 16 (otherwise it will report "you have not created a bootloader stage1 device").

If you start entirely from scratch with custom, then it follows a non-random sequence. It's just that when you delete one, it renumbers the others, you add a new one and it adds whatever is missing. I doubt it's by design, it's probably the consequence of something else.

I erased my harddisk on my notebook completely. And it really seems to be pretty random. Even if I don't delete any partitions, it will mix them. For example I create partitions in this order: first root, then swap, then home partition and afterwards it's a order like that: home partition, root, swap.

But I can't install Fedora 17 RC4 via Custom partition layout successfully. It reports a unrecoverable error at the end of the installation. I tried it several times. So I wait on a newer release than Beta RC4 or RC4.x

this bug is reported here (https://bugzilla.redhat.com/show_bug.cgi?id=812155)

chrismurphy
13th April 2012, 12:48 AM
You need to include the anaconda logs to that bug report to be sure, but I suspect your bug is a dupe of this bug (https://bugzilla.redhat.com/show_bug.cgi?id=804779) I filed. XFS is not a supported rootfs currently.

---------- Post added at 05:48 PM ---------- Previous post was at 05:42 PM ----------

Or as /home for that matter. Or at all.

Fenrin
13th April 2012, 01:23 PM
ok I attached the logs: anaconda.log, messages, program.log, storage.log

it happens also with encrypted ext4 home partition, without xfs.

I found this thread http://forums.fedoraforum.org/showthread.php?t=274315 where some users had this issue under Fedora 16

chrismurphy
13th April 2012, 06:21 PM
The problem appears to have nothing to do with encryption from what I can tell. It's a problem with sda4 /boot partition. The formatting is failing as the journal is being created. A subsequent e2fsck then fails. When starting over, this partition causes problems with dumpe2fs as well.

I will guess this may get reassigned to e2fsprogs, as it doesn't seem like an anaconda problem at all. But someone more expert than I at looking at anaconda logs needs to confirm this, and they can make the reassignment.

Could you post here, the results of
smartctl -a /dev/sda
And please format with code tags; highlight text and click on # in the toolbar.

Fenrin
13th April 2012, 07:49 PM
ok, the output:

smartctl 5.42 2011-10-20 r3458 [x86_64-linux-3.3.0-1.fc17.x86_64] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF INFORMATION SECTION ===
Model Family: SAMSUNG SpinPoint M5
Device Model: SAMSUNG HM250JI
Serial Number: S0TVJD0Q753902
LU WWN Device Id: 5 0f0000 001753902
Firmware Version: HS100-08
User Capacity: 250,059,350,016 bytes [250 GB]
Sector Size: 512 bytes logical/physical
Device is: In smartctl database [for details use: -P show]
ATA Version is: 7
ATA Standard is: ATA/ATAPI-7 T13 1532D revision 0
Local Time is: Mon Feb 20 09:36:59 2012 EST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status: (0x00) Offline data collection activity
was never started.
Auto Offline Data Collection: Disabled.
Self-test execution status: ( 32) The self-test routine was interrupted
by the host with a hard or soft reset.
Total time to complete Offline
data collection: ( 103) seconds.
Offline data collection
capabilities: (0x5b) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
No Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 2) minutes.
Extended self-test routine
recommended polling time: ( 103) minutes.
SCT capabilities: (0x003f) SCT Status supported.
SCT Error Recovery Control supported.
SCT Feature Control supported.
SCT Data Table supported.

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000f 100 100 051 Pre-fail Always - 0
3 Spin_Up_Time 0x0007 252 252 025 Pre-fail Always - 2562
4 Start_Stop_Count 0x0032 002 002 000 Old_age Always - 99999
5 Reallocated_Sector_Ct 0x0033 252 252 010 Pre-fail Always - 0
7 Seek_Error_Rate 0x000f 252 252 051 Pre-fail Always - 0
8 Seek_Time_Performance 0x0024 252 252 015 Old_age Offline - 0
9 Power_On_Hours 0x0032 098 098 000 Old_age Always - 1314
10 Spin_Retry_Count 0x0032 100 100 051 Old_age Always - 33
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 741
191 G-Sense_Error_Rate 0x0032 100 100 000 Old_age Always - 470
192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 105
194 Temperature_Celsius 0x0022 154 100 000 Old_age Always - 28 (Min/Max 5/46)
195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age Always - 2857
196 Reallocated_Event_Count 0x0032 252 252 000 Old_age Always - 0
197 Current_Pending_Sector 0x0012 252 252 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0030 252 252 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x0036 200 200 000 Old_age Always - 0
200 Multi_Zone_Error_Rate 0x000a 100 100 000 Old_age Always - 0
201 Soft_Read_Error_Rate 0x0032 252 252 000 Old_age Always - 0
223 Load_Retry_Count 0x0032 099 099 000 Old_age Always - 1418
225 Load_Cycle_Count 0x0032 083 083 000 Old_age Always - 178998

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Short offline Completed without error 00% 923 -

Note: selective self-test log revision number (0) not 1 implies that no selective self-test has ever been run
SMART Selective self-test log data structure revision number 0
Note: revision number not 1 implies that no selective self-test has ever been run
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Interrupted [00% left] (0-65535)
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

chrismurphy
13th April 2012, 11:57 PM
If anyone else monitoring this wants to go to the bugzilla and check out the program log, you can find the two critical errors near the end:
mke2fs -t ext4 /dev/sda4 fails with error, so therefore it kinda makes sense that, e2fsck -f -p -C 0 /dev/sda4 fails as well.

Kinda strange. Not sure why formatting this 15G unencrypted rootfs as ext4 is failing.

I'm noticing the ECC recovered errors in the SMART report, but before suggesting the disk be totally zero'd or ATA secure erased, I think a more definitive cause of the file system creation failure should be found. Others may end up encounter this in the wild, so better to catch it, if it's a bug, before it ends up on shipping media. Yeah?

Also I'm seeing e2fsprogs on RC4 as 1.42. But 1.42.2 is current.

Fenrin
14th April 2012, 01:55 AM
[...]

Also I'm seeing e2fsprogs on RC4 as 1.42. But 1.42.2 is current.

yes, but this error happened also with version 1.42, but I updated some packages via yum, because I thought maybe it's solved in an update.

But I found the reason and feel a bit dump now :doh:

the notebook BIOS time was set to February 2012, this was the reason why it didn't work.

Thanks for your help, sorry for the inconvenience.

chrismurphy
14th April 2012, 02:02 AM
Ok well that's still a bug. See the bugzilla, this appears to be an old problem that going back to FC9 that crops up every now and then. The last bug I found on it, included in your bug, even has one person opining that the established fix is probably inadequate.

So I would be really clear about reproducing this and update the bugzilla. In my view, doesn't matter if the time is wrong. The error message provided gives no indication the problem is due to incorrect date/time. And it shouldn't fail catastrophically anyway.