← Back to team overview

lubuntu-qa team mailing list archive

Re: Prepping for the last upgrade test

 

[Since we started top posting in this thread I'll continue]

Update: I upgraded the kernel to 3.10.0-5 and zRAM started to work in
the 64-bit Toshiba laptop.

Then I tried again in the Dell. This time it was dead (after the kernel
upgrade). It stayed at the boot menu, where I selected to boot from USB,
so not even grub rescue.

I tested the Dell with a persistent live USB drive made yesterday from
the Lubuntu Saucy alpha 2 32-bit desktop iso. It booted and ran nicely
(even had zRAM), and I needed no boot option.

So I think there is something wrong with the Lubuntu Saucy alpha 2
32-bit alternate iso, something more than the lack of network and lack
of zRAM. Maybe this is related to what was stopping Lance, when he tried
to install into his VIA computer.

I hope *you* will find it interesting enough to test in your computer :-)

Best regards
Nio

On 2013-07-25 08:03, Nio Wiklund wrote:
> 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@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@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@alt-saucy:~$ swapon -s
> Filename                Type		Size	Used	Priority
> /dev/sdb5               partition	4073468	0	-1
> guru@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@xxxxxxxxxxx
>>> <mailto:jmarsden@xxxxxxxxxxx>> 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@xxxxxxxxxxx <mailto:jmarsden@xxxxxxxxxxx>
>>>
>>>
>>>
>>>
>>> -- 
>>> https://wiki.ubuntu.com/phillw
>>
> 



Follow ups

References