Bug 11820 - Install/Upgrade fails to correctly determine partitions
Summary: Install/Upgrade fails to correctly determine partitions
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: Installer (show other bugs)
Version: Cauldron
Hardware: x86_64 Linux
Priority: Normal critical
Target Milestone: ---
Assignee: Mageia Bug Squad
QA Contact:
URL:
Whiteboard:
Keywords: NEEDINFO
Depends on:
Blocks: 11778
  Show dependency treegraph
 
Reported: 2013-11-29 17:50 CET by Pierre Fortin
Modified: 2014-01-20 02:37 CET (History)
1 user (show)

See Also:
Source RPM:
CVE:
Status comment:


Attachments
photo of screen (console F3) (162.50 KB, image/jpeg)
2013-11-29 18:54 CET, Pierre Fortin
Details

Description Pierre Fortin 2013-11-29 17:50:45 CET
Description of problem:
After destroying my system via what should have been normal updates (see bug 10162), downloaded mga4.  Attempt at upgrading mga2 destroyed remaining mga2 by failing to correctly ascertain partitions configuration.

Version-Release number of selected component (if applicable):
mga4 cauldron as of 11/28/13-01:30 EST.

How reproducible: unknown - system destroyed

System is a Dell studio 1747 i7 8GB & two 500GB HDs
Disk configuration consists of:
   - sda1 Original Windows 7
   - sdb1 /
   - sdb5 swap
   - sdb6 /home
  After using several distros and many disk configurations since 1998, a few years ago, I settled on two partitions:  / and /home

Rather than mess with / and /usr (and /var) separately, I found it much easier to deal with a single, larger root partition big enough to contain /usr and enough spare space for /var.  I've been running my systems this way for nearly 10 years.

[UPDRADE] 
However, when encountering just these two partitions, rather than use /usr on the root partition, the installer mounted /usr to /dev/loop0 (size=52224) which is quite small, fills quickly and the upgrade fails.  Having gone through many releases of Mandriva and Mageia 1 & 2, upgrading/installing with /usr simply a path on the / partition has never been an issue.

[INSTALL] 
After destroying the mga2 system due to the above "upgrade", trying to install gave the option to update mga4 which aborted and never completed -- this option should not be available unless a previous upgrade/install actually succeeded. 

I selected Install and the installer then assumed(?) only one HD(sda); so it started calculating the size of the Windows partition in order to resize it.  Naturally, I aborted this; hopefully in time.

It did complain with:
  An error occured.
  Can't call method "width" on unblessed reference.


Installer should use existing /usr path no matter where it resides; not assume it must be a partition.  
Installer should use existing Linux partitions, no matter where they reside; not assume only one disk if only Windows on sda.

BTW, this laptop contains TWO HDs (sda,sdb) from the factory.



Reproducible: 

Steps to Reproduce:
Comment 1 Pierre Fortin 2013-11-29 18:20:04 CET
PS:  a quick summary of how I my main system is now unusable...
- Running mga2 since its release
- Unable to upgrade to mga3 (bug 10162)
- Didn't have time to keep up with mga2 updates; when time was available, via mcc, found 900+ updates, hit Apply...  Update proceeded to install **mga3** updates after which system would boot into multi-user; but not KDE, and many applications could not even be run remotely in this state.
- Attempted to upgrade to mga4 (see above)

"rpm -qa" reports a mix of mga{1,2,3,4} in 3711 packages...
Comment 2 Pierre Fortin 2013-11-29 18:45:29 CET
Retrying cauldron install...
Before selecting Install on GUI, Ctrl+Alt+F2, then df reports only sdb6 mounted while console F4 reports EXT-4-fs ({sda3,sdb1}): mounted filesystem with ordered data mode. Opts: (null)"
Forgot to mention above: sda = {1:Win7(C),2:swap,3:/home2,4:Win7(D)}

At this point, Installer is stuck in loop:
 - RESIZING
   Computing the size of the Microsoft Windows(r) partition.
 - An error occured.
   Can't call method "width" on unblessed reference.

Hence, my selection of Critical -- can't upgrade and can't install!
Comment 3 Pierre Fortin 2013-11-29 18:54:01 CET
Created attachment 4543 [details]
photo of screen (console F3)

Was about to shutdown and try removing sda drive; found this on console F3...
Comment 4 Pierre Fortin 2013-11-30 02:57:19 CET
Removed sda drive (see also bug 11826), and installation is proceeding.   MBR will be written to sdb (acting as sda), so will have to re-install sda(Win7) and write boot record to it...

However, this is not a solution for average user.
Comment 5 Pierre Fortin 2013-11-30 05:16:52 CET
Scratch the above UPGRADE comments -- the /usr mounted on /dev/loop0 is not the target (/mnt/usr)...   long time since I had to dig this deep.

Trying for the Nth time to install (no choice as the machine is unusable).  This time, just doing a default KDE install rather than try to specify Custom with package selection which fails and "error recovery" consists of looping back to the beginning of the install with only Power Off as the way out of the loop.
Comment 6 Thierry Vignaud 2013-11-30 11:15:40 CET
About "have been normal updates", I don't call "normal updates" performing an _upgrade_ (not an update) with a _local_ & _partial_ mirror

You should have plug an USB key and run the "bug" command when you saw the "Can't call method "width" on unblessed reference" error.

Please try again and attach the report.bug.xz file found on your USB key (not the /root/Drakx/report.bug.xz from the previous installs)

Keywords: (none) => NEEDINFO
CC: (none) => thierry.vignaud

Comment 7 Pierre Fortin 2013-11-30 18:43:31 CET
Did you grok Comment #1?  more detail added:

- Running mga2 since its release [because mga3 upgrade never worked -- if, in the course of _using_ the system, we (users) require the occasional 32-bit stuff just to use some application, then are you saying that 32-bit packages should be removed in order to be able to upgrade?]
- [redacted]
- [Since I couldn't upgrade to mga3 last spring, all I could do is rely on mga2 updates; but] Didn't have time to keep up with [installing said] mga2 updates [in the latter months]; when time was available [a few days ago], via mcc, found 900+ updates [that should have only been **mga2** (unless mga3 updates were allowed on an mga2 system)], hit Apply...  Update proceeded to install **mga3** updates[1] after which system would boot into multi-user; but not KDE, and many applications could not even be run remotely in this state.
- Attempted to upgrade to mga4 (see above)[2]

[1] these "mga2" updates were being handled remotely, _not_ a local mirror.  Did the remote mirrors and/or mcc assume that I was on mga3 when I was still on mga2?  Actually, it doesn't really matter now since my mga2 system is gone.

[2] at this point, since my root partition has been formatted by mga4 attempt, can we just treat this as a _fresh_ install of mga4?  At the moment, mga4, using _defaults_ "fails to install" after installing almost everything.  

I use a local mirror on which I _always_ re-run the mirroring several times (at least twice) where _no more_ files are downloaded before I assume the local is stable.

As to using <F2> and "bug"...

To be ultra clear, the following is on a _fresh_ install attempt, 
   [where _fresh_ = existing partitions (sda1=/, sda6=/home)]
of mga4, using only _defaults_ to the point where it complains that "34 installation transactions failed", and where <F2> gives:
  INSTALLING
     Screenshots will be available after install in /root/DrakX-screenshots
                                                               [ OK ]

and:
bash-4.2# bug
Too late to run INIT block at /usr/lib/perl5/vendor_perl/5.18.1/x86_64-linux-thread-multi/Glib/Object/Introspection.pm ine 258.
ask_from_list: empty list
interactive::ask_from_listf_raw() called from /usr/lib/libDrakX/interactive.pm:285
interactive::ask_from_listf() called from /usr/lib/libDrakX/install/commands.pm:404
install::commands::bug() called from /usr/bin/bug:16
(eval)() called from /usr/bin/bug:14

with nothing on the USB stick -- I even have 2 sticks installed, one with boot.iso (via unetbootin) and the other empty.  I even tried reformatting the empty stick as EXT4, then FAT32, mounted and unmounted, and all I can get is the above failure when using "bug".

BTW, "Too late to run..." also appears early (somewhere around 10th line of output) when booting boot.iso


============================ OK... above is only useful as background...

this bug is about the fact that my laptop came with TWO HDs:
  sda Original Windows 7 factory installed
      (full disclosure: shrunk to allow using free space as EXT4 partition.
       Besides, I use VBox to run XP & Win7 from virtual disks)
  sdb was 2nd HD; reformatted EXT4 and mga2 installed
and that I had to physically remove sda in order to even be able to get to try installing mga4.  With sda installed, mga4 simply loops trying and failing to resize the W7 partition, while ignoring sdb which is where mga2 was installed.

Once I have something installed that I can run, I will re-install the HD, retry the install, and add "bug" output (if it works :).

OK?   Peace!  :)
Comment 8 Pierre Fortin 2013-12-02 11:38:36 CET
Between bugs 11826 and 11841, I was seriously doubting Mageia4...  but I love a challenge, so here's the results of my testing...

0. "bug" always fails with:
bash-4.2# bug
Too late to run INIT block at /usr/lib/perl5/vendor_perl/5.18.1/x86_64-linux-thread-multi/Glib/Object/Introspection.pm ine 258.
ask_from_list: empty list
interactive::ask_from_listf_raw() called from /usr/lib/libDrakX/interactive.pm:285
interactive::ask_from_listf() called from /usr/lib/libDrakX/install/commands.pm:404
install::commands::bug() called from /usr/bin/bug:16
(eval)() called from /usr/bin/bug:14

1. Upon booting.install creates some symlinks, followed immediately the same "Too late to run INIT..." line that `bug` gives.

2. mga4 will NOT install on my x896_64 laptop with TWO HDs (both 500GB) installed:
   sda1 Windows 7 C: (factory installed)
   sda2 Linux swap  (after resizing sda1 a year ago)
   sda3 Linux (/home2)  (after resizing sda1 a year ago)
   sda4 Windows 7 D: (factory installed)
   sdb1 Linux (/)
   sdb5 Linux swap
   sdb6 Linux (/home)
Included all the partition details in case I have a combination that confuses the install.  mga4 seems to assume that the only drive available for installation is one of the Windows partitions (not sure which one yet -- sda{1|4}).  The installation goes into a tight loop trying to:
 a) resize one of the Windows partitions, 
    - RESIZING
      Computing the size of the Microsoft Windows(r) partition.
 b) failing with:
    - An error occurred.
      Can't call method "width" on unblessed reference.
then, back to a) with only the power button as an escape from this sequence.

3. Removed sda, and I was able to Install mga4 and run it.

4. Shutdown, re-installed sda, and the system will not boot into the freshly installed & runnable mga4.  I know... this is an MBR issue...   So I went through the Upgrade procedure which, as expected, skips the install since nothing is new, and proceeds to the MBR creation...  except that it doesn't behave...

I've tried all these attempts at getting a bootable system:

 - removed boot flag on sdb1 (fdisk) to force system to see only sda as bootable.

 - removed extraneous grub 'windows' entry (via installer gui) which comes from leaving USB stick plugged in -- FAT32 formatted boot.iso created with unetbootin (details below).  However, the system still offers the extra Windows option on next boot attempt -- this seems to indicate that the boot records may not be written to disk on Upgrade (?).

 - selected grub2. Appears to install (with the extra Windows option removed); but the system still boots with grub 0.97 and the extra Windows options -- again casting doubt on boot records being written...
In fact, grub2 initially offers:
   Mageia (/boot/vmlinuz-desktop)
   Mageia, with Linux desktop (/boot/vmlinuz-desktop)
   windows (/dev/sda1)
   windows1 (/dev/sdd1)
The last one is puzzling because it has no Windows *at all* on it:
# ll
total 3836
drwxr-xr-x 4 root root    4096 2013-11-29 01:15 isolinux/
-r-xr-xr-x 1 root root   32256 2013-11-29 01:15 ldlinux.sys*
drwxr-xr-x 3 root root    4096 2013-05-19 21:46 Mageia3/
-rwxr-xr-x 1 root root   56292 2013-11-29 01:15 menu.c32*
-rwxr-xr-x 1 root root    1087 2013-11-29 01:15 syslinux.cfg*
-rwxr-xr-x 1 root root     299 2013-11-29 01:15 ubnfilel.txt*
-rwxr-xr-x 1 root root 3813360 2013-11-21 15:00 ubnkern*
-rwxr-xr-x 1 root root      16 2013-11-29 01:15 ubnpathl.txt*
-rwxr-xr-x 1 root root      65 2013-11-21 15:00 VERSION*
Only the partition type resembles a Windows system:
   Device Boot      Start         End      Blocks   Id  System
/dev/sdd1   *          98      744448     7815680    b  W95 FAT32

 - on one boot attempt, manually edited the presented grub boot statements from hd(1,0) to hd(0,0); but could still not boot normally. It appears to boot; but ends up in emergency mode...


Nothing I've tried gives me an installable or bootable system with sda installed -- leaving it removed is _not_ an option.  

Hope this is sufficient info to begin tracking down this problem...  :)
Comment 9 Thierry Vignaud 2013-12-03 17:22:43 CET
The "Can't call method "width" on unblessed reference" error should be fixed with drakx-installer-stage2-16.5 which should land on your favourite mirror by tonight
Comment 10 Pierre Fortin 2013-12-04 04:19:12 CET
Thanks Thierry!  There a lot in this report, much inter-related; but I should open separate bugs for "bug" and F2. 

Removed sda HD, re-ran Upgrade to restore MBR...  Bootup goes through decompressing kernel, then drops me into emergency mode...  Looks like I may have to re-install...  :(   I'm trying to track down why mga4 ran once, and won't anymore............   Got it...   see bug 11869
Comment 11 Thierry Vignaud 2013-12-06 14:48:17 CET
So we can close this one?

Status: NEW => RESOLVED
Resolution: (none) => FIXED

Comment 12 Pierre Fortin 2013-12-06 15:24:03 CET
I've been short on time -- will try to get to this today...  

Q: your fix comments seem to address only the "width" problem; is the issue where the installer assumes the only install option is to resize the Windows partition also fixed?

I still haven't been able to re-install the sda drive and miss not having partition 4...  I could temporarily work around this part by installing the drive in an external case; but that's undesirable/awkward as my USB ports are already sucking enough power...  Testing such a fix should only require starting the installer without actually installing anything. Of course, that still leaves the MBR to be checked/fixed...
Thierry Vignaud 2014-01-20 02:37:01 CET

Blocks: (none) => 11778


Note You need to log in before you can comment on or make changes to this bug.