Bug#733706: installation-report: installation on a Lenovo Thinkpad E431

2014-01-01 Thread Andreas Cadhalpun 

Hi,

On 31.12.2013 16:23, Luca Capello wrote:

On Tue, 31 Dec 2013 15:50:39 +0100, Antoine Beaupré wrote:

On 2013-12-31 05:45:01, Andreas Cadhalpun wrote:

Installing on UEFI firmware is supported, but is a little bit tricky,
see for example [1]. Particularly you need a GPT partitioned hard disk
with two additional partitions, one EFI partition marked with the
'boot' flag in gparted and a partition for grub marked as 'bios_grub' in
gparted.


Wrong, with UEFI you do not need any 'bios_grub' partition at all:

   


That's correct. The additional 'bios_grub' partition is only needed, if 
one wants to be able to boot with both EFI and legacy BIOS.

This is probably not intended in most cases.


On 31.12.2013 16:37, Antoine Beaupré wrote:

On 2013-12-31 10:23:18, Luca Capello wrote:

On Tue, 31 Dec 2013 15:50:39 +0100, Antoine Beaupré wrote:

On 2013-12-31 05:45:01, Andreas Cadhalpun wrote:
Yeah... I struggled with that before, and I *was* able to make it work,
but since it wasn't obvious this was necessary *during* theinstaller,
I did a normal MBR-based partitionning. When the boot loader failed to
install, I didn't want to go back and redo everything, especially since
this is a dual-boot system and I was happy to have been able to resize
the NTFS partition at all... ;)


Sorry, but there is something strange here.  In the first email you
reported that "when I rebooted, grub was not installed in the MBR and I
was brought back into windows", which means that partman used the
partition table already present.  This can be checked with a simple
`fdisk -l /dev/sda`: if there is no GPT mention, then the partition
table is plain old MBR.

BTW, Windows 7 does not mandate GPT nor UEFI, but can use both.


Oh right - I used the original partitionning I guess. I assumed it was
MBR.


If it is MBR, UEFI installation is not possible without deleting the 
existing files on the disk and creating a new GPT partition table. But 
with MBR one still can use the legacy BIOS mode, as you did.



Shouldn't we create GPT partitions all the time now anyways?


Why?  IMHO if there is no need for it (because BIOS is used) plain old
MBR is easier.


The reason is that it will fail on newer BIOS, from what I can tell.


But GPT is not supported by most old hardware still out there. 
Personally, I haven't yet come across a BIOS that doesn't support MBR.



On 31.12.2013 15:50, Antoine Beaupré wrote:

(That resize, btw, was quite scary - I am not sure I did it right. First
off it was very fast, so I suspect only the boundaries of the filesystem
were changed, without telling NTFS. Then when we rebooted into Windows
7, it did a disk check which thankfully worked fine and it seems the
Windows install is okay. But I can't think of doing this on an older
system - it would have probably destroyed data, which is not clearly
stated in partman.


The resize usually is relatively fast, if the part you are removing from 
the filesystem does not contain any data, because then no data has to be 
moved and only the file system has to be updated to the new size. I 
think chkdsk is always scheduled after a resize of NTFS, just to be on 
the safe side.
This should also work perfectly fine on an older system, but there it 
might take considerably longer, since the data is more likely to be 
distributed over the whole partition.

Of course, one should always have backups of important data.


Last but not least, you have to select the UEFI:USB in the firmware
and not BIOS:USB, which every firmware has a different marking scheme
for, but disabling legacy-bios (or equivalent option) in the UEFI
BIOS, should always disable the BIOS:USB option. (It can be enabled
again after installation.)


Right, I guess this is the tricky bit. It seems that in any case, the
user needs to go fiddle in the BIOS, which is annoying. In my case, I
was able to install by *disabling* UEFI in the BIOS, but the reverse
might be the case for others.


Normally, it should not be necessary to change BIOS settings, one just 
has to select the correct boot device, which is not always easy.
Either the BIOS should be in legacy mode, or the hard drive should be 
partitioned as GPT, when it is an UEFI system. Both cases are supported 
out of the box by the Debian installer. But if the disk is partitioned 
as MBR and the BIOS in UEFI mode, this inconsistency has to be solved 
manually.



  > The next missing thing was wifi. I tried installing firmware-linux-
  > nonfree, but that wasn't enough - firmware-iwlwifi was the one that
  > was required.

The installer should install the correct firmware, if you have (on some
partition accessible during installation) a /firmware folder that
contains the unpacked firmware bundle, which can be downloaded from [2].
But this is currently broken, see [3].


Understood. The weird thing is that the live image did find the wifi
card without a problem, but it wasn't found after the install was done

Processing of partman-basicfilesystems_89_i386.changes

2014-01-01 Thread Debian FTP Masters 
partman-basicfilesystems_89_i386.changes uploaded successfully to 
ftp-master.debian.org
along with the files:
  partman-basicfilesystems_89.dsc
  partman-basicfilesystems_89.tar.gz
  partman-basicfilesystems_89_all.udeb

Greetings,

Your Debian queue daemon (running on host ravel.debian.org)


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1vymig-0007dw...@ravel.debian.org

Processing of partman-basicfilesystems_89_i386.changes

2014-01-01 Thread Debian FTP Masters 
partman-basicfilesystems_89_i386.changes uploaded successfully to localhost
along with the files:
  partman-basicfilesystems_89.dsc
  partman-basicfilesystems_89.tar.gz
  partman-basicfilesystems_89_all.udeb

Greetings,

Your Debian queue daemon (running on host franck.debian.org)


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1vymni-0002gg...@franck.debian.org

partman-basicfilesystems_89_i386.changes ACCEPTED into unstable

2014-01-01 Thread Debian FTP Masters 


Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Wed, 01 Jan 2014 09:31:53 +0100
Source: partman-basicfilesystems
Binary: partman-basicfilesystems
Architecture: source all
Version: 89
Distribution: unstable
Urgency: low
Maintainer: Debian Install System Team 
Changed-By: Christian Perrier 
Description: 
 partman-basicfilesystems - Add to partman support for ext2, linux-swap, fat16 
and fat32 (udeb)
Changes: 
 partman-basicfilesystems (89) unstable; urgency=low
 .
   [ Updated translations ]
   * Russian (ru.po) by Yuri Kozlov
Checksums-Sha1: 
 76ad97f44e11955a5fca4e50b9989d1188fd3c3b 1782 partman-basicfilesystems_89.dsc
 aa119cd0ddf354f83d7924094d143382df36cb53 238960 
partman-basicfilesystems_89.tar.gz
 2d452039272bd4521bcbd73f2b382426fdefd884 176582 
partman-basicfilesystems_89_all.udeb
Checksums-Sha256: 
 c9be4fbb69482b35ccde3c118be4a2140a5c139c5cb8d68ae59cadc87a7fb92c 1782 
partman-basicfilesystems_89.dsc
 462215b6ffe7643642f3a272be928225dc6fd87bfad8bac7885434dabce9665c 238960 
partman-basicfilesystems_89.tar.gz
 41d70f820dd3bae213000ff7d4f908037ad79231cfae73709d76eb4b1e0c4e0d 176582 
partman-basicfilesystems_89_all.udeb
Files: 
 1d3f5bebd89b8410e48bc2ceaa24737b 1782 debian-installer standard 
partman-basicfilesystems_89.dsc
 b892d50d49c6e9194f3954a198b0d77b 238960 debian-installer standard 
partman-basicfilesystems_89.tar.gz
 aed58daae9fd54276246321182e1b6c0 176582 debian-installer standard 
partman-basicfilesystems_89_all.udeb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIVAwUBUsQeZIcvcCxNbiWoAQLzZw//YhQrj/Frq9hLjPptDlQ5FNxlM7t38CS5
oKCIrDw1lN9aV71wlaWFQL1X7bHnBLB1VAOFjZwsJJpk9DQMXvrReXQ4vB2CIdbl
cVQsaGp61hgJIjauhxBzFh+t1TbAqpJZ/gu6bZ2RJ1wptMwVe2zOXz5YCXZw2S8c
SDGPNNtxDe7CwK5rjBgQv4unIlGYQ6NgkPQvrw3DpqTzUnH4USGeKJzET1LbUrmj
j8lde/QQbsOgCkodvqYkz393/UahUK1PhxtHJCoMjFyRG/LaZdP9ExNX7AARlDZK
Ls37UU879H5d8uhtTJ9LhuRpRO8TqZtItvrtQrPhpzyXkLWRrJAy42VMpLLf2guR
TVTb9hsizoG8aEmGAqPCNTHrv5GpHyvRCEBowBC0dX/BXfOI+gphkH9n10oE6RpD
JZROUWAX6p5Zjl3m3K4FoXV5W5DehQXRWSci/5K3iVwsuOzoKVoRTwBOBG10FGqv
IBKk9rNqe59ccoUq9EUSInE6L4irk0I7dg4TGqOWood8wAcoMqO0xUx1hyl2nYJi
D7QWdW1tEes6cuXYrgGYUFIRt9Xlr1rxKEPV3i/hq5QfpgvK1ahqTmc9btvDzpjP
4HMKiNQTybbsL4edAn1Q0WciRuOByez4+AN6jd/CxT+asrr9BathJZUyPx+JUnEx
YZP61GLaQCM=
=iJcV
-END PGP SIGNATURE-


Thank you for your contribution to Debian.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1vyndj-0001yt...@franck.debian.org

Bug#733706: installation-report: installation on a Lenovo Thinkpad E431

2014-01-01 Thread Antoine Beaupré 
On 2014-01-01 05:05:18, Andreas Cadhalpun wrote:
> On 31.12.2013 15:50, Antoine Beaupré wrote:
>> (That resize, btw, was quite scary - I am not sure I did it right. First
>> off it was very fast, so I suspect only the boundaries of the filesystem
>> were changed, without telling NTFS. Then when we rebooted into Windows
>> 7, it did a disk check which thankfully worked fine and it seems the
>> Windows install is okay. But I can't think of doing this on an older
>> system - it would have probably destroyed data, which is not clearly
>> stated in partman.
>
> The resize usually is relatively fast, if the part you are removing from 
> the filesystem does not contain any data, because then no data has to be 
> moved and only the file system has to be updated to the new size. I 
> think chkdsk is always scheduled after a resize of NTFS, just to be on 
> the safe side.
> This should also work perfectly fine on an older system, but there it 
> might take considerably longer, since the data is more likely to be 
> distributed over the whole partition.
> Of course, one should always have backups of important data.

Well, that's reassuring - I somehow thought only the partitions were
resized, without telling the filesystem. Good job there! :)

In my days, you had to to move bits
around with a magnet to resize FAT12 partitions and NTFS was satan! You
kids have it t easy. ;)

>>>   > The next missing thing was wifi. I tried installing firmware-linux-
>>>   > nonfree, but that wasn't enough - firmware-iwlwifi was the one that
>>>   > was required.
>>>
>>> The installer should install the correct firmware, if you have (on some
>>> partition accessible during installation) a /firmware folder that
>>> contains the unpacked firmware bundle, which can be downloaded from [2].
>>> But this is currently broken, see [3].
>>
>> Understood. The weird thing is that the live image did find the wifi
>> card without a problem, but it wasn't found after the install was done.
>
> Did you have a /firmware folder around? As you installed wheezy, this 
> should have worked, because it is only broken in jessie/sid.

Yes, there was a firmware folder, it only contained a .deb of
linux-firmware.

>> Oh, and I forgot to mention that I had to remove this block for
>> Network-Manager to properly pickup the wired interface:
>>
>> auto eth0
>> iface eth0 inet dhcp
>>
>> Otherwise it would say wired: not managed, which is strange to me...
>
> This is bug #724928 [1], which was fixed in the Wheezy 7.2 installer.

That sounds familiar! I guess I need to update my image. ;)

>> My user was expecting the "touch to click" to work out of the box, and
>> we were worried this wasn't supported, and in fact it wasn't until gnome
>> was installed (XFCE failed to configure it properly).
>>
>> This is especially annoying on this laptop because the buttons are
>> completely part of the touchpad construction, so it's actually difficult
>> to "click" without moving the mouse slightly.
>
> These seem to be bugs in xfce4 and gnome respectively. You should report 
> them there. It seems more users prefer this (see [2]) and I also do.

Well, #2 is about a serious bug that makes unrelated things just not
work when you enable "disable touchpad while typing". It seems to me
this bug should be fixed, but it is not related to enabling the touch
functionality on the... touch pad. ;) Probably not related to gnome only
either...

But I understand this is another serious bikeshed material and fold. :)

>>> That being said, I think it really might be a good idea to install
>>> plymouth by default, as 'novices' generally prefer it, and anyone who
>>> wants to see the boot messages should have sufficient knowledge to
>>> remove it.
>>
>> I totally agree with that. One thing I noticed with plymouth is that
>> even when you install it, it doesn't properly configure grub, you still
>> have to go around the grub config and (*gasp*) edit a weird
>> configuration file! ;)
>>
>> I would have expected the plymouth postinst to configure grub
>> automagically. :) But then that's more an issue with plymouth itself
>> than the installer.
>
> You could report this as a bug in plymouth, but it is probably not 
> trivial to fix, because which configuration file has to be changed, 
> depends on which boot loader is used. Actually I'm not even sure it is 
> possible, because the boot loader may be installed after plymouth (as 
> the installer does), or it might be changed after plymouth is installed.

Yeah, this seems to be a problem larger than plymouth actually. On the
top of my head, fixing this would probably involve:

 * triggers
 * a way to hook into /etc/grub.d/10_linux to add boot parameters from
   outside
 * lots more bikeshedding

Unless we make plymouth a hard dependency, which would probably involve
around 1500 emails on -devel, so let's pretend I didn't say anything. ;)

>> And anyways, those are probably things to keep in mind for Jessie more
>> than Wheezy...
>
> Except for

Bug#733706: installation-report: installation on a Lenovo Thinkpad E431

2014-01-01 Thread Andreas Cadhalpun 

On 01.01.2014 18:56, Antoine Beaupré wrote:

In my days, you had to to move bits
around with a magnet to resize FAT12 partitions and NTFS was satan! You
kids have it t easy. ;)


Oh yeah, the good old days... ;)


Yes, there was a firmware folder, it only contained a .deb of
linux-firmware.


You can safely have all the firmware .deb's in the /firmware folder. The 
installer installs only the needed ones.



Well, #2 is about a serious bug that makes unrelated things just not
work when you enable "disable touchpad while typing". It seems to me
this bug should be fixed, but it is not related to enabling the touch
functionality on the... touch pad. ;) Probably not related to gnome only
either...


Sorry if I didn't make myself clear. I just meant that in this bug 
report, also your expected settings were chosen:

-
Then I set:
- enable clicks with touchpad
- two-finger scrolling
-
So your user is not the only one to want those enabled.


Yeah, this seems to be a problem larger than plymouth actually. On the
top of my head, fixing this would probably involve:

  * triggers
  * a way to hook into /etc/grub.d/10_linux to add boot parameters from
outside
  * lots more bikeshedding

Unless we make plymouth a hard dependency, which would probably involve
around 1500 emails on -devel, so let's pretend I didn't say anything. ;)


OK, let's just pretend that. ;)

Do you agree that this bug can be closed now?

Best regards and a happy new year,
Andreas


--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52c469fd.5040...@googlemail.com

Bug#733706: installation-report: installation on a Lenovo Thinkpad E431

2014-01-01 Thread Antoine Beaupré 
On 2014-01-01 14:18:21, Andreas Cadhalpun wrote:
> Do you agree that this bug can be closed now?

Sure yes. I was hoping to improve the process a little, but the
challenge seems to be beyond my patience in dealing with multiple
packages...

Besides, there are significant problems related to the way I built the
installer which will not happen again in a more recent one.

I mostly wanted to document that Debian works on the E431 anyways. :)

Thanks for the feedback!

A.

-- 
Advertisers, not governments, are the primary censors of media content 
in the United States today.
- C. Edwin Baker
http://www.ad-mad.co.uk/quotes/freespeech.htm


pgpaNS1dyubYS.pgp
Description: PGP signature