[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Connot load Wheezy in a "virgin" desktop -- SOME RESULTS



For previous installation attempts to install Wheezy in my box -- consisting of a Gigabyte GA-Z87N mainboard, an Intel i5-4670K processor with integrated GPU and two Seagate 2gb hard drives -- I used the 7.2 Wheezy netinst disk.  For the most recent attempts I used the 7.3 version.  The results described below were the same regardless of installer version.

I tried the installation successively using the following four partition configurations:

A)  RAID1 + LVM for everything but /boot + encryption for swap and /home,       random key for the former.

B)  RAID1 + LVM for everything but /boot, no encryption.

C)  RAID1; no LVM; standard partitions /boot, swap, / and /home; no encryption.  (I did not try this configuration with encryption; perhaps I should have.)

D)  No RAID1;  LVM for all partitions except /boot, the logical volume comprising that part of sda not used for /boot and all of sdb; and encryption for swap (random key) and for /home.

Of those four only for (C) and (D) did the installer install a working system where I could open in a virtual console both root and my user.  I did not go so far as to install xorg or a desktop environment.

The other two -- (A) and (B), LVM on top of RAID1 -- the installer stopped when it tried to install the kernel and instead displayed the red screen of death.   Virtual console F4 displayed a full screen of messages quoted below.
-----------------------------------------------------------------------
Selecting previously unselected package linux-image-amd64
Unpacking linux-image-amd64 (from .../linux-image-amd64_3.2+46_amd64.deb ...
Processing triggerrs for man-db ...
Setting up libuuid-perl (0.02-5) ...
Setting up linux-base (3.5) ...
Setting up linux-image-3.2.0-4-amd64 (3.2.51-1) ...
Running depmod.
Examining /etc/kernel/postinst.d.
Run-parts: executing /etc/kernel/postinst.d/initramfs-tools-3.2.0-4-amd64/boot/vmlinux-3.2.0-4-amd64
update-initramfs: Generating /boot/initrd.img-3.2.0-4-amd64
mkinitramfs: for root/dev/mapper/TH-root missing /sys/block entry
mkinitramfs: workaround is MODULES=most
mkinitramfs: Error please report the bug
update-initramfs: failed for /boot/initrd.img-3.2.0-4-amd64 with 1
runparts:
/etc/kernel/postinst.d/initramfs-tools exited with return of 1
Failed to process /etc/kernel/postinst.d at /var/dpkg/info/linux-image-3.2.0-4-amd64.postinst line 696.
dpkg: error processing linux-image-3.2.0-4-amd64 (--configure) subprocess installed post-installation script returned error exit status 1
dpkg: dependency problems prevent configuration of linus-image-3.2.0-4-amd64: linux-image-amd64 depends on linux-image_3.2.0-4-amd64; however: Package linux-image-3.2.0-4-amd64 is not configured yet
dpkg: error processing linux-image-amd64 (-- configure): dependency problems -- leaving unconfigured
Errors were encountered while processing:
linux-image-3.2.0-4-amd64
Linux-image-amd64
E
:subprocess /usr/bin/dpkg returned an error code (1)
[at the beginning of all the lines above was the mention "in-target:"]
base installer: error: exiting on error base-installer/kernek/failed-install
kernel:
------------------------------------------------------------------------
I hope the above makes sense to somebody; it certainly does not to me.  All I know is that it is what is returned when the installer tries to install the kernel when in the partition RAID1 is combined with LVM.  Has anybody else encountered the same phenomenon?

If I can only have one or the other but not both, I would rather have RAID1.  In that case I would have to use standard partitions primary up to four, then logical.  If so would there be any point in reserving some unused space in the RAID1?     Put another way, is it possible to to resize partitions other than by LVM?

Regards, Ken


Reply to: