Bug#794466: VIrtualBox future in Debian

2016-12-12 Thread Gordon Farquharson 
On Tue, 25 Oct 2016 17:29:39 +0200 Gianfranco Costamagna <
locutusofb...@debian.org> wrote:

> As per DSA-3699-1, security team thinks virtualbox can't be released with
Stretch.

Thanks for all your work in maintaining VirtuaBox in Debian.

Could you answer the following questions so that I (and others) can make
some decisions about future use of VirtualBox?

1. Will you continue to package VirtualBox for Debian?

2. Do you anticipate making a backports version available for Stretch?

3. Do you recommend migrating existing VirtualBox images to KVM?

Gordon

-- 
Gordon Farquharson
GnuPG Key ID: 32D6D676

Bug#794466: VIrtualBox future in Debian

2016-12-14 Thread Gordon Farquharson 
I did a test migration of a VirtualBox image running Windows 10 to KVM from
virt-manager, and everything worked. However, I don't seem to have the
correct drivers installed (virtio drivers?) to get full resolution support
in my guest Windows system.

I'd still like to know what the plans are for the VirtualBox package in
Debian. I can backport the version in sid to stretch by building it myself,
but at some point, this process may break if maintenance of the package is
dropped.

Gordon

On Tue, Dec 13, 2016 at 12:55 AM, Ritesh Raj Sarraf  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On Mon, 2016-12-12 at 21:59 -0800, Gordon Farquharson wrote:
> > 3. Do you recommend migrating existing VirtualBox images to KVM?
>
> Migration should be doable. I'm not sure if there are any issues in
> migration,
> but you may give it a shot.
>
>
> Should you migrate, it may depend on what your core requirements are.
>
> VirtualBox has a much nicer UI integrating all features, very well, into
> its
> Graphical interface.
>
>
> On the other hand, KVM is the stock in-kernel hypervisor for Linux, which
> has a
> much larger userbase (Oepnstack, RHEV etc) and gets much more testing.
>
>
> In the past, I've migrated my setups from both ways. Initially, from KMV to
> VBox, and then later again from VBox to KVM.
>
> VM disk image conversion was fairly stable. I had no issues during image
> conversion.
>
> For config settings, I just noted down the settings and applied the same
> when
> importing it to the other hypervisor. For a large number of VMs, this may
> not be
> optimal.
>
>
> - --
> Ritesh Raj Sarraf | http://people.debian.org/~rrs
> Debian - The Universal Operating System
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCgAdFiEEQCVDstmIVAB/Yn02pjpYo/LhdWkFAlhPt4QACgkQpjpYo/Lh
> dWlkKhAAiESUsGuNWhMgqet1QlDPdpC9VBysXuZOm/5JqvdDAPf41cy+KDzCWS4w
> xfdaB7XOw2JShsmYAByf7j/W+o/oiaRRN/GgSy07I3tMzbaiFCjKU4Vd5yszhE91
> Zb3eNMQZw7x7J0qCSNO0zzOJBvSX4QQaxXm9NfphAEQ+i22q9hWYwCTkzGdjmXqJ
> uNYF44HYIOA+1DKp0KeXqs7J9CaLqV/t4SVxA/kBvtQ7ET1iVsjomPPz/6bBBZ/s
> 8j5PTrDgt0gXSXRjGFb/Rr7argXIsJMC9BPr/pYgF4buLkKpL9IRuCEzxAEo4r1c
> IBNen1BiVps1qgZmdv967B4jMhyFhJJnJCeHznLchDodMbK2f2Dqnlnz8hwqTmeu
> e+B/oEFh8mrFsV/gqngl4gg8HTiCXI680wdkCs2hLxTABzPaUKFockKaCO4BLZkr
> NkH/fq6gb6UFFoM42e00qQrK6qzO5IaM1AFrFAiQ+RXE8lSTzKiO7Ot2Em00mLSG
> 7cdf6wU0TyfWirvP1P76rCQ/ToQdqdBX9TBtQZ9m+p1iraT8Ybz79ZljqpNp/yEX
> DaE0ugqoaxlhquESXp6QWhdHWKFhAnMlEmGsI106Iqnuqj7ksV1dhyFpsoVOaHUC
> NA2Sl5kHnPHStOciKySM+mIe8J3O+rnEzwsxvkC/eOYL85k7uro=
> =+9mB
> -END PGP SIGNATURE-
>
>


-- 
Gordon Farquharson
GnuPG Key ID: 32D6D676

Bug#464958: too large to fit in flash on the nslu2

2008-02-10 Thread Gordon Farquharson 
Hi Martin

On Feb 10, 2008 1:01 PM, Martin Michlmayr <[EMAIL PROTECTED]> wrote:
> * Joey Hess <[EMAIL PROTECTED]> [2008-02-10 14:55]:
> > mtd3: 0016 0002 "Kernel"
>
> OK, closing bug.  User error: not using a standard MTD partition
> layout.

It looks like we need to update
installer/build/config/arm/ixp4xx/netboot.cfg. Specifically,

# Let's pad the kernel to 131072 * 10 + 1 so it will be rounded up
# by slugimage to 131072 * 11, i.e. 11 blocks.
util/arm/nslu2/pad $(TEMP)/$(KERNELNAME).nslu2 1310724

Shouldn't 1310724 be 1441792 otherwise the script will fail with a
kernel size of 1337692?

Gordon

-- 
Gordon Farquharson
GnuPG Key ID: 32D6D676



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#464958: too large to fit in flash on the nslu2

2008-02-10 Thread Gordon Farquharson 
Hi Martin

On Feb 10, 2008 2:40 PM, Martin Michlmayr <[EMAIL PROTECTED]> wrote:

> BTW, 1310724 seems to be 131072 * 10 + 4 rather than +1 as the comment
> claims.  I wonder why I made that mistake.

I think that you chose 1310724 in the code because it needs to be
divisible by 4 for devio to perform the endian swap in the next line.

devio "<<"$(TEMP)/$(KERNELNAME).nslu2 >
$(TEMP)/$(KERNELNAME).nslu2.swapped \
    'xp $$,4'

Gordon

-- 
Gordon Farquharson
GnuPG Key ID: 32D6D676



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#448325: Incorrect installation order on NSLU2 with main-menu_1.22

2007-10-27 Thread Gordon Farquharson 
Package: main-menu
Version: 1.22
Severity: serious

It appears that main-menu_1.22 causes an incomplete installation on
the Linksys NSLU2.

Martin Michlmayr reported an unusual installation order on the NSLU2
[1]. The installer image used for that test used main-menu_1.21. Based
on the discussion in the thread, main-menu_1.22 was uploaded, but now
the installer fails to run flash-kernel-installer. As a result, the
system fails to boot, because the kernel and initrd are not written to
the system flash. Also, clock-setup is not run during the installation
and localechooser is out of order and left unconfigured. The order of
the installation was extracted from the installer /var/log/syslog and
is shown below.

$ grep 'Menu item' syslog
Oct 27 05:18:53 main-menu[1161]: INFO: Menu item 'kbd-chooser' selected
Oct 27 05:18:54 main-menu[1161]: INFO: Menu item 'ethdetect' selected
Oct 27 05:19:10 main-menu[1161]: INFO: Menu item 'netcfg' selected
Oct 27 05:19:12 main-menu[1161]: INFO: Menu item 'network-console' selected
Oct 27 05:20:54 main-menu[2481]: INFO: Menu item 'choose-mirror' selected
Oct 27 05:21:23 main-menu[2481]: INFO: Menu item 'download-installer' selected
Oct 27 05:22:59 main-menu[2481]: INFO: Menu item 'bootstrap-base' selected
Oct 27 06:19:07 main-menu[2481]: INFO: Menu item 'user-setup-udeb' selected
Oct 27 06:19:32 main-menu[2481]: INFO: Menu item 'apt-setup-udeb' selected
Oct 27 06:20:36 main-menu[2481]: INFO: Menu item 'pkgsel' selected
Oct 27 06:56:31 main-menu[2481]: INFO: Menu item 'nobootloader' selected
Oct 27 06:56:46 main-menu[2481]: INFO: Menu item 'finish-install' selected
Oct 27 06:58:58 main-menu[25048]: INFO: Menu item 'localechooser' selected
Oct 27 06:58:59 main-menu[25048]: INFO: Menu item 'localechooser'
succeeded but requested to be left unconfigured.
Oct 27 06:59:01 main-menu[25048]: INFO: Menu item 'localechooser' selected
Oct 27 06:59:01 main-menu[25048]: INFO: Menu item 'localechooser'
succeeded but requested to be left unconfigured.
Oct 27 06:59:06 main-menu[25048]: INFO: Menu item 'save-logs' selected

The installer image was built from
svn://svn.debian.org/d-i/trunk/installer, SVN revision 49892.

Gordon

[1] http://lists.debian.org/debian-boot/2007/10/msg00563.html

-- 
Gordon Farquharson
GnuPG Key ID: 32D6D676



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#448325: marked as done (Incorrect installation order on NSLU2 with main-menu_1.22)

2007-10-31 Thread Gordon Farquharson 
Hi Joey

On 10/29/07, Martin Michlmayr <[EMAIL PROTECTED]> wrote:
> * Joey Hess <[EMAIL PROTECTED]> [2007-10-29 16:12]:
> > Debian Bug Tracking System wrote:
> > > Thanks, Joey.  Installations now work properly on NSLU2.
> >
> > FWIW, I can't see how flash-kernel ordering would influence
> > localechooser/clock-setup ordering at all. Also, main-menu is still at
> > version 1.22 for arm, 1.22 has not built yet. It's not clear to me which
> > versions Gordon is testing with. In my test with 1.21, localechooser and
> > clock-setup ran at the right times.

Thanks for resolving this bug, Joey.

Not that it matters much anymore, but in my testing, I had used a
locally built copy of main-menu_1.22 for arm when I built the
installer. The flash-kernel-installer version was 1.4.

Gordon

-- 
Gordon Farquharson
GnuPG Key ID: 32D6D676



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#517339: wireshark hangs if I try to choose interface

2009-04-01 Thread Gordon Farquharson 
Are you going to backport the fix to lenny?

Thanks.

Gordon

-- 
Gordon Farquharson
GnuPG Key ID: 32D6D676



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#403426: kernel corrupts LUKS partition header on arm

2007-01-05 Thread Gordon Farquharson 

On 1/4/07, Martin Michlmayr <[EMAIL PROTECTED]> wrote:


* Clemens Fruhwirth <[EMAIL PROTECTED]> [2007-01-04 12:56]:
> So, can we close the bug against cryptsetup in this case?

#403426 is really about the header corruption which you have fixed in
SVN.  It should be closed when the Debian maintainers make a new
upload with that fix.

> Maybe someone else can verify that?

CCing Gordon. :)


Ok, so here are some interesting results...

I am able to access the LUKS partition on the NSLU2 running 2.6.18
from subversion (which includes flush_anon_page-generic.patch and
flush_anon_page-arm.patch) with both cryptsetup-1.0.4-8 (the latest
version in testing) and cryptsetup-1.0.4-8 plus 02_fix_arm.dpatch and
03_no_header_conv.dpatch that were posted to this thread.

$ sudo cryptsetup luksOpen /dev/sdb3 testfs
Enter LUKS passphrase:
key slot 0 unlocked.
Command successful.
[EMAIL PROTECTED]:~$ sudo mount /dev/mapper/testfs /mnt/tmp
[EMAIL PROTECTED]:~$ sudo umount /mnt/tmp
[EMAIL PROTECTED]:~$ sudo cryptsetup luksClose testfs

However, I have found that I am unable to access the LUKS partition
when the system is under heavy load and swapping.

$ sudo cryptsetup luksOpen /dev/sdb3 testfs
Enter LUKS passphrase:
Enter LUKS passphrase:
Enter LUKS passphrase:
Command failed: No key available with this passphrase.

[EMAIL PROTECTED]:~$ uptime
00:22:23 up 16 min,  2 users,  load average: 3.01, 1.85, 0.93
[EMAIL PROTECTED]:~$ free
total   used   free sharedbuffers cached
Mem: 29988  28908   1080  0172   3028
-/+ buffers/cache:  25708   4280
Swap:88316  67508  20808

Once the system load decreases and the swapping stops, I am able to
access the LUKS partition again. This behaviour is very repeatable.

Martin, I wonder if this has anything to do with the virtual memory
bug in the kernel that we experienced with apt. It could be that this
bug existed before 2.6.19 but was much harder to trigger (e.g. see
http://lkml.org/lkml/2007/1/3/285). It would be interesting to try
accessing a LUKS partition under heavy load while running 2.6.20-git,
but that will have to wait until the weekend for me to test it.

Gordon

--
Gordon Farquharson


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#403426: kernel corrupts LUKS partition header on arm

2007-01-05 Thread Gordon Farquharson 

On 1/5/07, Martin Michlmayr <[EMAIL PROTECTED]> wrote:

* Gordon Farquharson <[EMAIL PROTECTED]> [2007-01-05 01:36]:
> However, I have found that I am unable to access the LUKS partition
> when the system is under heavy load and swapping.

Interesting.  Can you check whether you see the same problems with
FUSE (see #402876)?


FUSE works with 2.6.18-9 (checked out from subversion on 2007.01.04)
under heavy load and swapping.

[EMAIL PROTECTED]:~$ encfs /home/gordon/.encrypted /home/gordon/encrypted
EncFS Password:
[EMAIL PROTECTED]:~$ ls -l encrypted/
total 4
-rw-r--r-- 1 gordon gordon 13 2007-01-05 22:40 example.txt
[EMAIL PROTECTED]:~$ cat encrypted/example.txt
Some text...
[EMAIL PROTECTED]:~$ fusermount -u /home/gordon/encrypted
[EMAIL PROTECTED]:~$ uptime
23:33:58 up 22:37,  2 users,  load average: 3.38, 2.27, 1.08
[EMAIL PROTECTED]:~$ free
total   used   free sharedbuffers cached
Mem: 29988  28876   1112  0172   1840
-/+ buffers/cache:  26864   3124
Swap:88316  63124  25192

Gordon

--
Gordon Farquharson


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#403426: kernel corrupts LUKS partition header on arm

2007-01-06 Thread Gordon Farquharson 

On 1/5/07, Gordon Farquharson <[EMAIL PROTECTED]> wrote:


However, I have found that I am unable to access the LUKS partition
when the system is under heavy load and swapping.

Martin, I wonder if this has anything to do with the virtual memory
bug in the kernel that we experienced with apt. It could be that this
bug existed before 2.6.19 but was much harder to trigger (e.g. see
http://lkml.org/lkml/2007/1/3/285). It would be interesting to try
accessing a LUKS partition under heavy load while running 2.6.20-git,
but that will have to wait until the weekend for me to test it.


Ok, I tested 2.6.19-1~experimental.1 +

  vm-fix-nasty-and-subtle-race-in-shared-mmap-ed-page-writeback.patch
  flush_anon_page-generic.patch
  flush_anon_page-arm.patch

and I am still unable to access the LUKS paritition under heavy load
and swapping, so it appears that there is someting else causing this
problem.

Gordon

--
Gordon Farquharson


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#407460: USB ethernet interface renamed after installation on NSLU2 which causes the system to be inaccessible

2007-01-18 Thread Gordon Farquharson 

Package: debian-installer
Version: 20061102
Severity: serious

I'm not sure which package to assign this bug to, but since it causes
the system to be inaccessible after an install, debian-installer seems
like a good place to start.

Summary of the problem:

After an installation of Debian on the Linksys NSLU2, the system is
inaccessible because the USB ethernet interface is renamed
eth1_rename.

Background:

The NSLU2 is an ARM based network available storage device. Support
for installing Debian on this system has been added to etch. The NSLU2
has a single built-in ethernet adapter for which a driver has been
written and included in the Debian 2.6.18 kernel. However, Debian
installer images cannot use this driver, because the network processor
engine (NPE) in the IXP4xx CPU requires non-free microcode. Therefore,
a USB to ethernet adapter is required to install Debian.

Problem description:

Debian installs without problems using the USB to ethernet adapter.
During the installation, a udev rule is written which names the USB to
ethernet adapter to eth0:

# cat /etc/udev/rules.d/z25_persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, probably run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single line.
# MAC addresses must be written in lowercase.

# USB device 13b1:0018 (asix)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:14:bf:fe:2a:4e",
NAME="eth0"

However, when booting after the installation, the NPE driver seems to
assume control of the interface name eth0, which causes something to
rename the interface of the USB to ethernet adapter to eth1_rename.


From the boot log:


IXP4XX NPE driver Version 0.2.0 initialized
input: ixp4xx beeper as /class/input/input0
IXP4XX Q Manager 0.2.0 initialized.
ixp4xx_mac driver 0.2.1: eth0 on NPE-B with PHY[1] initialized
eth1: register 'asix' at usb-:00:01.2-2, ASIX AX88772 USB 2.0
Ethernet, 00:14:bf:fe:2a:4e
usbcore: registered new driver asix

the output of ifconfig -a:

# ifconfig -a
eth0  Link encap:Ethernet  HWaddr 00:00:00:00:00:00
 inet addr:192.168.1.67  Bcast:192.168.1.255  Mask:255.255.255.0
 BROADCAST MULTICAST  MTU:1500  Metric:1
 RX packets:0 errors:0 dropped:0 overruns:0 frame:0
 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:1000
 RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

eth1_rena Link encap:Ethernet  HWaddr 00:14:BF:FE:2A:4E
 BROADCAST MULTICAST  MTU:1500  Metric:1
 RX packets:0 errors:0 dropped:0 overruns:0 frame:0
 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:1000
 RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

and the /etc/network/interfaces created by the installer

# The primary network interface
allow-hotplug eth0
iface eth0 inet static
   address 192.168.1.67
   netmask 255.255.255.0
   network 192.168.1.0
   broadcast 192.168.1.255
   gateway 192.168.1.1
   # dns-* options are implemented by the resolvconf package, if installed
   dns-nameservers 205.171.3.65 205.171.2.65
   dns-search example.org

This configuration causes the system to be inaccessible unless the
user has added a connector for a serial port to the NSLU2. This
procedure requires soldering; something most users are not going to
do.

Here is the relevant output from /dev/hotplug.log with hotplug logging enabled:

HOTPLUG_TIME='Thu Jan 18 08:08:22 MST 2007'
PHYSDEVPATH=/devices/platform/ixp4xx_mac.0
SUBSYSTEM=net
OLDPWD=/
DEVPATH=/class/net/eth0
ACTION=add
UDEV_LOG=3
COMMENT=Unknown net device (/class/net/eth0) (ixp4xx_mac)
UDEVD_EVENT=1
PHYSDEVDRIVER=ixp4xx_mac
INTERFACE=eth0
PHYSDEVBUS=platform
SEQNUM=684

Note that eth1 or eth1_rename does not appear in the log.

I have tried the latest version of the NPE driver (0.3.1) that has
been checked into the Debian kernel repository, but there is no change
in the behaviour.

IXP4XX NPE driver Version 0.3.0 initialized
IXP4XX Q Manager 0.2.1 initialized.
ixp4xx_mac driver 0.3.1: eth0 on NPE-B with PHY[1] initialized
eth1: register 'asix' at usb-:00:01.2-2, ASIX AX88772 USB 2.0
Ethernet, 00:14:bf:fe:2a:4e

I am using the version of debian-installer in trunk, and linux-2.6
2.6.18.dfsg.1-9 (linux-image-2.6.18-4-ixp4xx).

I'm still looking for a solution to the problem. Any suggestions would
be helpful.

Other bugs that may be related: #405845, #406948, and #389250

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=389250
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=405845
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=406948

Gordon

--
Gordon Farquharson


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#409747: apex-nslu2 1.4.14 breaks current debian-installer build

2007-02-06 Thread Gordon Farquharson 

Hi Marc

On 2/6/07, Marc Singer <[EMAIL PROTECTED]> wrote:


I already posted the change.  I suppose you could make D-I accept
either?


It's a bit of a hack, but it does now.

Gordon

--
Gordon Farquharson


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#407460: USB ethernet interface renamed after installation on NSLU2 which causes the system to be inaccessible

2007-02-10 Thread Gordon Farquharson 

On 1/18/07, Martin Michlmayr <[EMAIL PROTECTED]> wrote:


Well, I still believe this is a problem with udev.  CCing Marco.


Marco, a while ago, you suggested that the problem could be due to

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=389250

but I still see the problem with 2.6.20 which includes the patch that
apparently fixes 389250. Do you any further ideas ?

Martin, in the meantime, what do you think about adding a script to
the installer to add the following rule to
/etc/udev/rules.d/z25_persistent-net.rules:

# Built-in Ethernet Adapter (NPE-B microcode not present)
SUBSYSTEM=="net", DRIVERS=="ixp4xx_mac", NAME="eth1"

It is a hack, but adding this rule causes the USB Ethernet adapter to
be named eth0 as opposed to eth1_rename. The system would therefore be
accessible after an installation without the NPE-B microcode, which
means that we could downgrade the severity of the bug. I'm not sure
where to put such a script in the installer though.

Gordon

--
Gordon Farquharson


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#407460: USB ethernet interface renamed after installation on NSLU2 which causes the system to be inaccessible

2007-02-11 Thread Gordon Farquharson 

Hi Marco

On 2/10/07, Gordon Farquharson <[EMAIL PROTECTED]> wrote:


On 1/18/07, Martin Michlmayr <[EMAIL PROTECTED]> wrote:

> Well, I still believe this is a problem with udev.  CCing Marco.


I just tested a patch [1,2] that was applied to udev to fix the
network interface renaming code to see if it would solve this bug, but
no luck. The USB ethernet adapter is still (most often) renamed
eth1_rename despite the rule to name it eth0 in
/etc/udev/rules.d/z25_persistent-net.rules.

Gordon

[1] 
http://git.kernel.org/git/?p=linux/hotplug/udev.git;a=commitdiff;h=ca714ef70e549aad486a62f4d6ef849572e3a7f1
[2] http://marc.theaimsgroup.com/?l=linux-hotplug-devel&m=116956926523008&w=2

--
Gordon Farquharson


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#407460: USB ethernet interface renamed after installation on NSLU2 which causes the system to be inaccessible

2007-02-12 Thread Gordon Farquharson 

Hi Steve

On 2/12/07, Steve Langasek <[EMAIL PROTECTED]> wrote:


The problem seems as simple as that the ipx4xx driver is *not* included in
d-i, but is included in the installed kernel; so in the installer, the
module is never loaded resulting in the USB adapter getting the eth0 name,
but after a reboot the ipx4xx driver is found first, breaking the handling
of persistent device names.


Yup. The original reason it wasn't included in the installer is
because including it without the NPE-B microcode causes the NLSU2
built-in ethernet adapter to be named eth0, and the installer, by
default, uses eth0 to provide the installation interface. This
situation makes the installer inaccessible to users without a serial
console attached to the NSLU2.


Which means in turn that a simple fix would be to make ixp4xx available in
the installer so that it can be detected; it certainly makes sense to me
that the onboard ethernet ought to be "eth0", even if it needs extra firmare
to be usable.


Currently, if we include the ixp4xx NPE driver, and tell the installer
to use eth1 (the USB to ethernet adapter) by default, we would prevent
people that do not have a USB to ethernet adapter from using the
unofficial Debian installer image that includes the NPE-B microcode
and which is made available through http://www.slug-firmware.net/. We
would have to change the installer default interface based on whether
or not we had the NPE-B microcode present in the image. This solution
will only work if interfaces are always detected in the same order,
which may not be reliable.

Adding an extra naming rule should never fail, so, although I dislike
this solution, it seems more reliable. It does mean that the interface
name for the built-in ethernet will depend how you installed Debian on
the NSLU2, and this could cause headaches down the line in terms of
support (maybe).


Finally, as popular as NSLU2 is, this is still a hardware-specific bug, and
as such I'm inclined to downgrade this bug report.  I'm happy for us to have
a well-supported NSLU2 installer in etch, but I don't see that this should
be a blocker for the release if it's not addressed in a timely manner.


I was hesitant with deciding on the severity of the bug, because 99%
will use the unofficial installer image which works great. This bug
only affect the probably less than 1% that use a DFSG installation.
However, it looks like we should be able to find a solution that works
for etch.

Gordon

--
Gordon Farquharson


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#407460: USB ethernet interface renamed after installation on NSLU2 which causes the system to be inaccessible

2007-02-12 Thread Gordon Farquharson 

Hi Marco

On 2/12/07, Marco d'Itri <[EMAIL PROTECTED]> wrote:


On Feb 12, Steve Langasek <[EMAIL PROTECTED]> wrote:



> > No, wait... When a new network interface is added it will get the next
> > available name, this is a supported configuration.
> Ok, so this is true when the built-in device is loaded first at boot time
> and is initially assigned eth0, there is no rule saying to rename it, and
> there is a rule saying to rename another interface to eth0?
If there is already a rule to rename some other device to eth0 then the
current eth0 will be renamed to the first free name and a new rule will
be created for it.


Will udev add this new rule to
/etc/udev/rules.d/z25_persistent-net.rules ? Since no new rules are
being added on my test system, does this tells whether something like
DRIVERS=="?*" is matching or not ?

It seems that the real question is what sequence of events causes an
interface to be named eth1_rename, as opposed to the next available
interface name (e.g. eth1). I'll see if I can figure this out from the
code.

Gordon

--
Gordon Farquharson


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#407460: USB ethernet interface renamed after installation on NSLU2 which causes the system to be inaccessible

2007-02-12 Thread Gordon Farquharson 

Hi Marco

On 2/12/07, Marco d'Itri <[EMAIL PROTECTED]> wrote:


> being added on my test system, does this tells whether something like
> DRIVERS=="?*" is matching or not ?
Apparently not. I see that I already suggested this in my first
reply on december 14.


Yeah, your comment in your previous email is what prompted me to ask
the question :-)


> It seems that the real question is what sequence of events causes an
> interface to be named eth1_rename, as opposed to the next available
> interface name (e.g. eth1). I'll see if I can figure this out from the
I explained this today.


Ok, I thought that you meant that the interface would be renamed to
the next available interface name e.g. 'eth0' would become 'eth1', not
'eth1_rename'. Sorry for the misunderstanding.


I do not think I can help you further if you ignore what I write.


Ok.

Gordon

--
Gordon Farquharson


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#401263: apt-get segfaults when building dependency tree

2006-12-02 Thread Gordon Farquharson 

There is a similar issue with apt-get that occurs during an
installation of Debian on the NSLU2 which is an arm based device.
During the installation process, apt fails, and the following log
messages are written to /var/log/syslog:

Dec  2 00:18:18 base-installer: info: Available initramfs
generator(s): 'initramfs-tools'
Dec  2 00:18:19 apt-install: Reading package lists...
Dec  2 00:18:19 apt-install:
Dec  2 00:18:19 apt-install: Building dependency tree...
Dec  2 00:18:24 apt-install:
Dec  2 00:18:24 apt-install: You might want to run `apt-get -f
install' to correct these:
Dec  2 00:18:24 apt-install: The following packages have unmet dependencies:
Dec  2 00:18:24 apt-install:   initramfs-tools: Depends: klibc-utils
(>= 1.4.19-2) but it is not going to be installed
Dec  2 00:18:24 apt-install:Depends: busybox (>=
1:1.01-3) but it is not going to be installed or
Dec  2 00:18:24 apt-install:
busybox-cvs-static (>= 20040623-1) but it is not installable
Dec  2 00:18:24 apt-install:Depends: udev (>=
0.086-1) but it is not going to be installed
Dec  2 00:18:24 apt-install:   libtext-charwidth-perl: Depends:
perlapi-5.8.8 but it is not installable
Dec  2 00:18:24 apt-install:   libtext-iconv-perl: Depends:
perlapi-5.8.8 but it is not installable
Dec  2 00:18:24 apt-install:   netbase: Depends: openbsd-inetd but it
is not installable or
Dec  2 00:18:24 apt-install: inet-superserver
Dec  2 00:18:24 base-installer: error: exiting on error
base-installer/kernel/failed-package-install

At this point, the problem looks like an issue with the repository,
but running 'apt-get -f install' manually shows that apt-get segfaults
while building the dependency tree.

~ # chroot /target/
sh-3.1# mount -t proc none /proc
sh-3.1# apt-get -f install
Reading package lists... Done
Segmentation faulty tree... 50%

Martin Michlmayr has found that after manually installing a deb,
apt-get works again [1].

Below is a backtrace of apt-get before the segfault. I rebuilt apt
with debugging information.

sh-3.1# gdb apt-get
GNU gdb 6.5-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "arm-linux-gnu"...Using host libthread_db
library "/lib/libthread_db.so.1".

(gdb) run -f install
Starting program: /usr/bin/apt-get -f install
Reading package lists... Done
Building dependency tree... 50%
Program received signal SIGSEGV, Segmentation fault.
0x4008b864 in pkgDepCache::CheckDep (this=0x3f020, Dep=
 {Dep = 0x407f0a68, Type = pkgCache::DepIterator::DepVer, Owner =
0x3ec38}, Type=1, [EMAIL PROTECTED]) at depcache.cc:157
157 depcache.cc: No such file or directory.
   in depcache.cc
(gdb) backtrace
#0  0x4008b864 in pkgDepCache::CheckDep (this=0x3f020, Dep=
 {Dep = 0x407f0a68, Type = pkgCache::DepIterator::DepVer, Owner =
0x3ec38}, Type=1, [EMAIL PROTECTED]) at depcache.cc:157
#1  0x40090fb0 in pkgDepCache::CheckDep (this=0x3f020, Dep=
 {Dep = 0x407f0a68, Type = pkgCache::DepIterator::DepVer, Owner =
0x3ec38}, Type=1) at ../build/include/apt-pkg/depcache.h:142
#2  0x4008be58 in pkgDepCache::DependencyState (this=0x3f020, [EMAIL PROTECTED])
   at depcache.cc:360
#3  0x4008f74c in pkgDepCache::Update (this=0x3f020, Prog=0xbeb37340)
   at depcache.cc:431
#4  0x400902b8 in pkgDepCache::Init (this=0x3f020, Prog=0xbeb37340)
   at depcache.cc:91
#5  0x400c9284 in pkgCacheFile::Open (this=0xbeb378c8, [EMAIL PROTECTED],
   WithLock=true) at cachefile.cc:101
#6  0x0002e39c in CacheFile::Open (this=0xbeb378c8, WithLock=true)
   at apt-get.cc:96
#7  0x0002e4e4 in CacheFile::OpenForInstall (this=0xbeb378c8) at apt-get.cc:107
#8  0x00023114 in DoInstall ([EMAIL PROTECTED]) at apt-get.cc:1415
#9  0x40072e80 in CommandLine::DispatchArg (this=0xbeb37df4, Map=0xbeb37d84,
   NoMatch=true) at contrib/cmndline.cc:337
#10 0x00011050 in main (argc=3, argv=0xbeb37e74) at apt-get.cc:2606
(gdb)

I am only too happy to help debug this problem, so please let me know
what else you need in terms of output, etc.

sh-3.1# cat /etc/apt/sources.list
deb http://debian.osuosl.org/debian/ etch main

sh-3.1# uname -a
Linux LKG7CD8B5 2.6.18-3-ixp4xx #2 Tue Nov 21 13:23:11 UTC 2006
armv5tel GNU/Linux

sh-3.1# dpkg -s libc6 | grep ^Version
Version: 2.3.6.ds1-8

sh-3.1# apt-get -V
apt 0.6.46.3 for linux arm compiled on Nov 30 2006 23:11:20

Gordon

[1] http://lists.debian.org/debian-boot/2006/11/msg01207.html

--
Gordon Farquharson


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#401263: Problem is not solved

2006-12-03 Thread Gordon Farquharson 

This problem is not solved because it causes the Debian Installer to
fail on a NSLU2. In practice, one can manually delete the *.bin files
in /var/cache/apt/ during an install (I haven't tried to see if it
fixes the problem), but I expect that this procedure is not the user
friendly installation experience that the Debian Installer team is
looking for :-)

The problem does seem to lie either with the cache files or with files
in /var/lib/dpkg, although I suspect that it is the former.  Attached
is a diff of /var/lib/dpkg before and after I manually install a deb
using dpkg (gdb in this case). Everything in the diff looks ok to me.

The only other changes in /var/lib/apt and /var/cache/apt occurs in
the package cache files. Specifically, before I manually install a deb
with dpkg:

-rw-r--r-- 1 gordon gordon 6422636 2006-12-01 17:17 pkgcache.bin
-rw-r--r-- 1 gordon gordon 6422586 2006-12-01 17:17 srcpkgcache.bin

and after I manually install a deb with dpkg:

-rw-r--r-- 1 gordon gordon 6422686 2006-12-03 14:49 pkgcache.bin
-rw-r--r-- 1 gordon gordon 6422586 2006-12-01 17:17 srcpkgcache.bin

The size of pkgcache.bin changes. So it looks like there is a
corruption of some sort in the package cache files. I can send these
files if somebody wants to have a look at them.

For now, I'm going to try the installation again, and when the problem
occurs, I'm going to save the pkgcache.bin file, fix it by manually
installing a deb, and then replace the new pkgcache.bin file with the
old one to see if the problem returns.

Gordon

--
Gordon Farquharson


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#401263: Problem is not solved (attachment)

2006-12-03 Thread Gordon Farquharson 

Woops ! Forgot the attachment of the diff between /var/lib/dpkg before
and after manually installing a deb.

--
Gordon Farquharson
diff -Naur apt-files-broken/var/lib/dpkg/available 
apt-files-fixed/var/lib/dpkg/available
--- apt-files-broken/var/lib/dpkg/available 2006-12-01 17:17:15.0 
-0700
+++ apt-files-fixed/var/lib/dpkg/available  2006-12-03 14:49:14.0 
-0700
@@ -118,6 +118,25 @@
  savelog sensible-browser sensible-editor sensible-pager tempfile
  which.
 
+Package: gdb
+Priority: standard
+Section: devel
+Installed-Size: 5288
+Maintainer: Daniel Jacobowitz <[EMAIL PROTECTED]>
+Architecture: arm
+Version: 6.5.dfsg-2
+Replaces: gdb-arm, insight (<< 6.1+cvs.2004.04.07-1)
+Depends: libc6 (>= 2.3.5-1), libncurses5 (>= 5.4-5), libreadline5 (>= 5.2)
+Suggests: gdb-doc
+Conflicts: gdb-arm
+Size: 2541184
+Description: The GNU Debugger
+ GDB is a source-level debugger, capable of breaking programs at
+ any specific line, displaying variable values, and determining
+ where errors occurred. Currently, it works for C, C++, Fortran,
+ Modula 2 and Java programs. A must-have for any serious
+ programmer.
+
 Package: makedev
 Priority: required
 Section: admin
diff -Naur apt-files-broken/var/lib/dpkg/info/gdb.list 
apt-files-fixed/var/lib/dpkg/info/gdb.list
--- apt-files-broken/var/lib/dpkg/info/gdb.list 1969-12-31 17:00:00.0 
-0700
+++ apt-files-fixed/var/lib/dpkg/info/gdb.list  2006-12-03 14:49:12.0 
-0700
@@ -0,0 +1,29 @@
+/.
+/usr
+/usr/share
+/usr/share/man
+/usr/share/man/man1
+/usr/share/man/man1/gdb.1.gz
+/usr/share/man/man1/gdbserver.1.gz
+/usr/share/man/man1/gdbtui.1.gz
+/usr/share/man/man1/arm-linux-gnu-run.1.gz
+/usr/share/doc
+/usr/share/doc/gdb
+/usr/share/doc/gdb/NEWS.gz
+/usr/share/doc/gdb/refcard.dvi.gz
+/usr/share/doc/gdb/refcard.ps.gz
+/usr/share/doc/gdb/changelog.gz
+/usr/share/doc/gdb/README.Debian
+/usr/share/doc/gdb/copyright
+/usr/share/doc/gdb/README.gz
+/usr/share/doc/gdb/refcard.tex.gz
+/usr/share/doc/gdb/changelog.Debian.gz
+/usr/share/menu
+/usr/share/menu/gdb
+/usr/lib
+/usr/bin
+/usr/bin/gdbtui
+/usr/bin/gdb
+/usr/bin/gdbserver
+/usr/bin/arm-linux-gnu-run
+/usr/bin/gcore
diff -Naur apt-files-broken/var/lib/dpkg/info/gdb.md5sums 
apt-files-fixed/var/lib/dpkg/info/gdb.md5sums
--- apt-files-broken/var/lib/dpkg/info/gdb.md5sums  1969-12-31 
17:00:00.0 -0700
+++ apt-files-fixed/var/lib/dpkg/info/gdb.md5sums   2006-11-18 
18:06:42.0 -0700
@@ -0,0 +1,19 @@
+a920fd7d3d84bba50532dfac914301b3  usr/share/man/man1/gdb.1.gz
+9ff3af27c9ff7357fdeb1341f233c857  usr/share/man/man1/gdbserver.1.gz
+1f58e9e82dc4f8426bde46bb3ab0d4d3  usr/share/man/man1/gdbtui.1.gz
+565cc55b9d17440935371ebec09503fc  usr/share/man/man1/arm-linux-gnu-run.1.gz
+6f9faf5eae1877d53775f656cc1dc6c0  usr/share/doc/gdb/NEWS.gz
+e5f0fe33e9b537bbf7e0134233295002  usr/share/doc/gdb/refcard.dvi.gz
+d23b474ee994ef78c5b697e441fca7c6  usr/share/doc/gdb/refcard.ps.gz
+da5307182f93d2bb67e43a0dd7f59806  usr/share/doc/gdb/changelog.gz
+448047b6c71a7e443b65eb82d5ec294c  usr/share/doc/gdb/README.Debian
+e16da30b34b027a7ea7a25bc73c94468  usr/share/doc/gdb/copyright
+6d6ad9df191da93d062d930465590b5f  usr/share/doc/gdb/README.gz
+46815d9354edce7295f7b821403fdede  usr/share/doc/gdb/refcard.tex.gz
+e5d8c1752e0583dcdbda84df401a8b04  usr/share/doc/gdb/changelog.Debian.gz
+7cc8b373541b9e5c805b70a3801b347a  usr/share/menu/gdb
+9bb70b752964dedd2d6318e13fe8ebc4  usr/bin/gdbtui
+a7a9b090817dbf73a2b5d48969a02c09  usr/bin/gdb
+6bea7049da692672d71c5cafd491f67e  usr/bin/gdbserver
+d900c3fa6c42680bdc9e3df9cebf5396  usr/bin/arm-linux-gnu-run
+c140eead79acd9be0788491373b6fb32  usr/bin/gcore
diff -Naur apt-files-broken/var/lib/dpkg/info/gdb.postinst 
apt-files-fixed/var/lib/dpkg/info/gdb.postinst
--- apt-files-broken/var/lib/dpkg/info/gdb.postinst 1969-12-31 
17:00:00.0 -0700
+++ apt-files-fixed/var/lib/dpkg/info/gdb.postinst  2006-11-18 
18:06:02.0 -0700
@@ -0,0 +1,7 @@
+#!/bin/sh
+set -e
+# Automatically added by dh_installmenu
+if [ "$1" = "configure" ] && [ -x "`which update-menus 2>/dev/null`" ]; then
+   update-menus
+fi
+# End automatically added section
diff -Naur apt-files-broken/var/lib/dpkg/info/gdb.postrm 
apt-files-fixed/var/lib/dpkg/info/gdb.postrm
--- apt-files-broken/var/lib/dpkg/info/gdb.postrm   1969-12-31 
17:00:00.0 -0700
+++ apt-files-fixed/var/lib/dpkg/info/gdb.postrm2006-11-18 
18:06:03.0 -0700
@@ -0,0 +1,5 @@
+#!/bin/sh
+set -e
+# Automatically added by dh_installmenu
+if [ -x "`which update-menus 2>/dev/null`" ]; then update-menus ; fi
+# End automatically added section
diff -Naur apt-files-broken/var/lib/dpkg/status 
apt-files-fixed/var/lib/dpkg/status
--- apt-files-broken/var/lib/dpkg/status2006-12-01 17:17:14.0 
-0700
+++ apt-files-fixed/var/lib/dpkg/status 2006-12-03 14:49:14.0 -0700
@@ -122,6 +122,25 @@
  savelog s

Bug#401263: Looks like this problem is he same as 81829

2006-12-03 Thread Gordon Farquharson 

It looks like the problem I am seeing on the NSLU2 is similar to
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=81829 and all of its
reincarnations. Historically, problem has been blamed on faulty lower
level functionality (kernel, filesystem, hardware), but two different
people started seeing it at around the the same time in Debian
Installer daily build images, so I doubt that it can be hardware. This
leaves kernel and filesystem issues, which if correct, would be bad.

I'm still going to try recreating the problem with the corrupted
pkgcache.bin file after I've "fixed" it by manually installing a deb.
However, I'm not sure that this will help resolve the cause of the
problem. Let's see what happens.

Gordon

--
Gordon Farquharson


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#401263: Possible solution

2006-12-05 Thread Gordon Farquharson 

Jan

It has been suggested that this *may* be a networking problem [1, 2,
3]. This is a wild suggestion that could be totally wrong, but I think
that it is worth a shot.

Delete the *.bin files and have apt recreate them as before, and then
set the TCP window scaling to 0 with

echo 0 > /proc/sys/net/ipv4/tcp_window_scaling

and try apt-get again.

I haven't had a chance to try this with the Debian Installer on the
NSLU2 yet, but I will this evening (UTC-7).

Gordon

[1] http://lwn.net/Articles/92727/
[2] http://www.gatago.com/linux/kernel/9440712.html
[3] http://lists.debian.org/debian-boot/2006/12/msg00213.html

--
Gordon Farquharson


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#401263: apt-get segfaults when building dependency tree

2006-12-05 Thread Gordon Farquharson 
 details.
This GDB was configured as "arm-linux-gnu"...Using host libthread_db
library "/lib/libthread_db.so.1".

(gdb) run -f install
Starting program: /usr/bin/apt-get -f install
Reading package lists... Done
Building dependency tree... 50%
Program received signal SIGSEGV, Segmentation fault.
0x4008b2dc in pkgDepCache::CheckDep (this=0x3fc60, Dep=
 {Dep = 0x409efa4c, Type = pkgCache::DepIterator::DepVer, Owner =
0x3ecb0}, Type=1, [EMAIL PROTECTED]) at depcache.cc:123
123 depcache.cc: No such file or directory.
   in depcache.cc
(gdb) backtrace
#0  0x4008b2dc in pkgDepCache::CheckDep (this=0x3fc60, Dep=
 {Dep = 0x409efa4c, Type = pkgCache::DepIterator::DepVer, Owner =
0x3ecb0}, Type=1, [EMAIL PROTECTED]) at depcache.cc:123
#1  0x40090fb0 in pkgDepCache::CheckDep (this=0x3fc60, Dep=
 {Dep = 0x409efa4c, Type = pkgCache::DepIterator::DepVer, Owner =
0x3ecb0}, Type=1) at ../build/include/apt-pkg/depcache.h:142
#2  0x4008be58 in pkgDepCache::DependencyState (this=0x3fc60, [EMAIL PROTECTED])
   at depcache.cc:360
#3  0x4008f74c in pkgDepCache::Update (this=0x3fc60, Prog=0xbef25350)
   at depcache.cc:431
#4  0x400902b8 in pkgDepCache::Init (this=0x3fc60, Prog=0xbef25350)
   at depcache.cc:91
#5  0x400c9284 in pkgCacheFile::Open (this=0xbef258d8, [EMAIL PROTECTED],
   WithLock=true) at cachefile.cc:101
#6  0x0002e39c in CacheFile::Open (this=0xbef258d8, WithLock=true)
   at apt-get.cc:96
#7  0x0002e4e4 in CacheFile::OpenForInstall (this=0xbef258d8) at apt-get.cc:107
#8  0x00023114 in DoInstall ([EMAIL PROTECTED]) at apt-get.cc:1415
#9  0x40072e80 in CommandLine::DispatchArg (this=0xbef25e04, Map=0xbef25d94,
   NoMatch=true) at contrib/cmndline.cc:337
#10 0x00011050 in main (argc=3, argv=0xbef25e84) at apt-get.cc:2606
(gdb)

The offending lines in depcache.cc is

   if (Type == InstallVersion && PkgState[Pkg->ID].InstallVer != 0)

This is in apt version

sh-3.1# apt-get -V
apt 0.6.46.3 for linux arm compiled on Nov 30 2006 23:11:20

which, as I mentioned before, I recompiled with debugging information.
The debugging information does not make a difference to the behaviour
of apt-get.

Now, why does apt-get create corrupt cache files the first time it is
run ? This seems to be the heart of the problem. I have copies of both
the corrupt and recreated cache files that I can send to somebody for
analysis.

For reference, there is a thread about this problem in debian-boot [1]
since it causes the installer to fail on the Linksys NSLU2.

Gordon

[1] http://lists.debian.org/debian-boot/2006/11/msg01207.html

--
Gordon Farquharson


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#401980: apt-get segfaults during Debian installation

2006-12-06 Thread Gordon Farquharson 
pe = pkgCache::DepIterator::DepVer, Owner =
0x3ecb0}, Type=1, [EMAIL PROTECTED]) at depcache.cc:123
123  Dep.TargetVer()) == true)
(gdb) list 123
118{
119   PkgIterator Pkg = Dep.TargetPkg();
120   // Check the base package
121   if (Type == NowVersion && Pkg->CurrentVer != 0)
122  if (VS().CheckDep(Pkg.CurrentVer().VerStr(),Dep->CompareOp,
123  Dep.TargetVer()) == true)
124 return true;
125
126   if (Type == InstallVersion && PkgState[Pkg->ID].InstallVer != 0)
127  if
(VS().CheckDep(PkgState[Pkg->ID].InstVerIter(*this).VerStr(),
(gdb) print Pkg.CurrentVer().VerStr()
$1 = 0xd5323001 

Any suggestions for things to try ?

Other information:

I am using Debian GNU/Linux 4.0, kernel 2.6.18-3-ixp4xx.

There is a thread about this problem in debian-boot [1] since it
causes the installer to fail on the Linksys NSLU2.

Gordon

[1] http://lists.debian.org/debian-boot/2006/11/msg01207.html

--
Gordon Farquharson


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#401980: apt-get segfaults during Debian installation

2006-12-07 Thread Gordon Farquharson 

Why has this bug been merged with #401263 ? I specifically separated
it out from #401263, because I became apparent to me that the problem
was different to the one detailed there. The patch posted to #401263
does not fix the problem I am seeing in the installer.

Gordon

--
Gordon Farquharson


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#403426: kernel corrupts LUKS partition header on arm

2007-04-26 Thread Gordon Farquharson 

Hi Martin

On 4/26/07, Martin Michlmayr <[EMAIL PROTECTED]> wrote:


Gordon, can you check if LUKS still doesn't work under heavy load with
2.6.21 (I can give you .debs if you want)?


I should be able to build the debs (I need to set up my machine to do
that anyway). I'll let you know if I have problems, but I'll probably
only get to it this weekend.

Gordon

--
Gordon Farquharson


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#403426: kernel corrupts LUKS partition header on arm

2007-04-28 Thread Gordon Farquharson 

Hi Martin

On 4/26/07, Martin Michlmayr <[EMAIL PROTECTED]> wrote:

Gordon, can you check if LUKS still doesn't work under heavy load with
2.6.21 (I can give you .debs if you want)?


Unfortunately, I can still trigger the problem, although instead of
cryptsetup asking me for the passphrase three times and then returning
"Command failed: No key available with this passphrase", it now just
fails with "Command failed". The problem is intermittent though. Below
are some examples of trying to access the LUKS partition under heavy
load. In the first case, the access works, but then a little while
later, it fails. In the third case, it works again. I sure that the
second case was not a case of typing in the passphrase incorrectly
because the problem is repeatable as shown in the forth case.

[EMAIL PROTECTED]:~$ uname -a
Linux LKG7102D7 2.6.21-1-ixp4xx #1 Thu Apr 26 20:40:53 MDT 2007
armv5tel GNU/Linux

[EMAIL PROTECTED]:~$ uptime
08:57:11 up  9:19,  3 users,  load average: 3.94, 1.54, 0.81
[EMAIL PROTECTED]:~$ sudo cryptsetup luksOpen /dev/sda2 x
Enter LUKS passphrase:
key slot 0 unlocked.
Command successful.
[EMAIL PROTECTED]:~$ sudo cryptsetup luksClose x
[EMAIL PROTECTED]:~$ uptime
08:57:49 up  9:20,  3 users,  load average: 4.79, 2.05, 1.01

[EMAIL PROTECTED]:~$ uptime
09:04:02 up  9:26,  3 users,  load average: 3.93, 3.46, 1.98
[EMAIL PROTECTED]:~$ sudo cryptsetup luksOpen /dev/sda2 x
Enter LUKS passphrase:
Command failed.
[EMAIL PROTECTED]:~$ uptime
09:04:29 up  9:27,  3 users,  load average: 4.29, 3.57, 2.06

[EMAIL PROTECTED]:~$ uptime
09:06:35 up  9:29,  3 users,  load average: 2.27, 3.01, 2.03
[EMAIL PROTECTED]:~$ sudo cryptsetup luksOpen /dev/sda2 x
Enter LUKS passphrase:
key slot 0 unlocked.
Command successful.
[EMAIL PROTECTED]:~$ uptime
09:07:14 up  9:29,  3 users,  load average: 2.61, 2.99, 2.07

[EMAIL PROTECTED]:~$ uptime
09:18:58 up  9:41,  3 users,  load average: 2.52, 2.47, 2.17
[EMAIL PROTECTED]:~$ sudo cryptsetup luksOpen /dev/sda2 x
Enter LUKS passphrase:
Command failed.
[EMAIL PROTECTED]:~$ uptime
09:19:31 up  9:42,  3 users,  load average: 3.18, 2.63, 2.23

To trigger the heavy load conditions, I am compiling apt on the NSLU2.
Occasionally, to up the load on the NSLU2, I run Linus's test program
that he used to track down the mmap problem, but the problem does
trigger if I am just compiling apt. Also, the load does not need to be
that high to trigger the problem:

[EMAIL PROTECTED]:~$ uptime
09:24:12 up  9:46,  3 users,  load average: 1.93, 2.26, 2.17
[EMAIL PROTECTED]:~$ sudo cryptsetup luksOpen /dev/sda2 x
Enter LUKS passphrase:
Command failed.
[EMAIL PROTECTED]:~$ uptime
09:25:35 up  9:48,  3 users,  load average: 1.69, 2.13, 2.13
[EMAIL PROTECTED]:~$ free
total   used   free sharedbuffers cached
Mem: 29912  28800   1112  0104   4640
-/+ buffers/cache:  24056   5856
Swap:88316  18640  69676

I have not been able to get the problem to occur under light load conditions.

This problem looks like it is going to be a tricky one to track down.

Gordon

--
Gordon Farquharson


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#592005: Debian installer fails because the initial ramdisk does not include unusual USB storage drivers

2010-08-06 Thread Gordon Farquharson 
Package: kernel-wedge
Version: 2.64
Severity: serious

The daily squeeze installer builds aren't working on my NSLU2 (armel).
I think that the problem is related to bug 534324 [1]. The USB disk
enclosure I am using uses a Cypress chipset, and the installer image
doesn't include ums-cypress.ko, which seems to be required with 2.6.32
for this chipset. Therefore, the installer does not find any disks
onto which the operating system can be installed.

Gordon

-- 
Gordon Farquharson
GnuPG Key ID: 32D6D676



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org