[Lubuntu-qa] Prepping for the last upgrade test

Nio Wiklund nio.wiklund at gmail.com
Thu Jul 25 06:03:39 UTC 2013


This is getting really interesting :-)

I would like to argue like Jonathan about the testing environment, but I
think Phill has very good intuition or knows something we don't know, or
maybe it is a simple boot option issue.

I used the alternate iso to install the Lubuntu Saucy alpha 2 32-bit
alternate iso into a USB HDD using manual partitioning. (I did not want
to mess with the installed systems on the internal drive.)

I did it in this Dell Pentium 4 computer

http://support.dell.com/support/edocs/systems/dim4600/en/4600i/sm/specs.htm

I got the red screen about no network, but could continue (with files
from the iso file). When rebooting the Dell, I had this error

error: file '/boot/grub/i386-pc/normal.mod' not found
grub rescue>

I powered off and cold booted, but the same error.

I moved the USB HDD to the 64-bit laptop

http://www.toshiba.se/laptops/satellite-pro/c850/satellite-pro-c850-19w/

and found the file, which was reported not found by the Dell. Then I
booted from the USB HDD, and it boots and run beautifully :-) except
that there is no zRAM, but it was expected since I had to upgrade the
kernel when running in VBox to get zRAM. The following terminal output
was transferred via ssh to my main computer

guru at alt-saucy:~$ uname -a
Linux alt-saucy 3.10.0-4-generic #13-Ubuntu SMP Thu Jul 18 19:25:05 UTC
2013 i686 i686 i686 GNU/Linux
guru at alt-saucy:~$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu Saucy Salamander (development branch)
Release:	13.10
Codename:	saucy
guru at alt-saucy:~$ swapon -s
Filename                Type		Size	Used	Priority
/dev/sdb5               partition	4073468	0	-1
guru at alt-saucy:~$

So there is something fishy. The installer can make a working Lubuntu
32-bit system, but it does not work in the computer where it was made,
but in another one, that happens to be a 64-bit computer. I think this
needs more investigation. I hope *you* will find it interesting enough
to test in your computer :-)

I'll check if a boot option or some other simple trick can make the Dell
boot, but I have not needed boot options before in this computer.

Best regards
Nio

On 2013-07-25 04:31, Jonathan Marsden wrote:> On 07/24/2013 06:07 PM,
Phill Whiteside wrote:
>
>> I think that everyone missed what I mentioned. That is the
>> virtualisation of a 32 bit processor from a VM running on a 64 bit
>> host. In kvm, i can choose from various pentium models, basic kvm32
>> etc. etc. And whilst VM's can never take the place of actual
>> hardware, when we need some i386 iso's testing to get them released,
>> getting a VM to as near as to a 32 bit system to try them on is far
>> better than just 'ticking' the box and saying it works.
>
> So you want the virtualization environment to not show CPU flags
> indicating the CPU is 64-bit capable?  Or to trap on all 64bit
> instructions?  Both?
>
> At first thought, all this really tests is that the compiler used for
> the i386 code generation did not accidentally generate 64bit
> instructions... is that what you are wanting to test?
>
> Can't you run just file on all binaries installed and verify they are
> 32bit i386 binaries, and be done with it?  Something like:
>
>   file /bin/* /usr/bin/* |grep executable |grep -v 'script\|32-bit'
>
> would list any 64-bit executables in those directories, for example.
>
> Can you point to a Launchpad bug report which this kind of "don't test
> i386 on a 64bit capable CPU, you MUST test on an i386-only capable CPU"
> testing approach would have found, which testing an i386 image on a
> 64-bit capable CPU (real or virtual) would have missed?  I need a real
> example to better understand what you are expecting to gain.
>
> We don't force i386 image testers to test on 32bit-only CPU hardware, do
> we?  So why would we need to require testers using VMs to use
> 32-bit-only VMs?  We should be consistent about this, if indeed it is an
> issue, as you seem to be suggesting it is.
>
> Jonathan
>
>
On 2013-07-25 06:00, Nio Wiklund wrote:
> Hi Phill,
> 
> I ran the Lubuntu Saucy alpha 2 32-bit alternate iso in a VirtualBox
> within a 32-bit Ubuntu Precise system. But I can try to run it in a real
> computer now.
> 
> Best regards
> Nio
> 
> On 2013-07-25 03:07, Phill Whiteside wrote:
>> Hi Jonathan,
>>
>> I think that everyone missed what I mentioned. That is the
>> virtualisation of a 32 bit processor from a VM running on a 64 bit host.
>> In kvm, i can choose from various pentium models, basic kvm32 etc. etc.
>> And whilst VM's can never take the place of actual hardware, when we
>> need some i386 iso's testing to get them released, getting a VM to as
>> near as to a 32 bit system to try them on is far better than just
>> 'ticking' the box and saying it works.
>>
>> Regards,
>>
>> Phill.
>>
>> On 24 July 2013 23:22, Jonathan Marsden <jmarsden at fastmail.fm
>> <mailto:jmarsden at fastmail.fm>> wrote:
>>
>>     Phill and Nio,
>>
>>     >> You can run 32-bit code in a 64-bit environment (also in Virtualbox).
>>
>>     Correct.
>>
>>     >> But I think there is a switch for it somewhere in the settings.
>>
>>     If there is, I have not needed to use it.  I run a mix of 32bit x86 and
>>     64bit amd64 VMs all the time.  A couple of them run 24x7.
>>
>>     On Wed, Jul 24, 2013, at 02:45 PM, Phill Whiteside wrote:
>>
>>     > I couldn't find the emulation under VBox, it may be in the 'extras'
>>     > package that I do not have installed.
>>
>>     No, that's definitely not needed for running 32bit x86 code in
>>     VirtualBox.   You don't need to do anything special to install and run a
>>     32bit x86 OS under 64bit amd64 VirtualBox.  It just works.
>>
>>     Jonathan
>>     --
>>       Jonathan Marsden
>>       jmarsden at fastmail.fm <mailto:jmarsden at fastmail.fm>
>>
>>
>>
>>
>> -- 
>> https://wiki.ubuntu.com/phillw
> 




More information about the Lubuntu-users mailing list