Re: Problem installing debian ARM on nslu2

[Martin Michlmayr]

* Marcos Lazarini <[EMAIL PROTECTED]> [2008-02-17 23:22]:
> I'm following the instructions from
> . It all goes pretty
> fine until the point I have to choose the installer modules, that is:
> partman-auto, partman-ext3 and usb-storage-modules-2.6.18-5-ixp4xx-di.
> Unfortunately, I have no usb-storage-modules-2.6.18-5-ixp4xx-di module
> in the list. Without this module, the installer cannot see my USB
> stick nor USB HDD, and the partman sees only the internal memory
> blocks.

This is because the stable version of Debian was updated a few days
ago with a new, incompatible kernel.  I will have to rebuild the
unofficial installer images.  Give me a day or two.
-- 
Martin Michlmayr
http://www.cyrius.com/


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

Problem installing debian ARM on nslu2

[Marcos Lazarini]

Hi,

I'm following the instructions from
. It all goes pretty
fine until the point I have to choose the installer modules, that is:
partman-auto, partman-ext3 and usb-storage-modules-2.6.18-5-ixp4xx-di.
Unfortunately, I have no usb-storage-modules-2.6.18-5-ixp4xx-di module
in the list. Without this module, the installer cannot see my USB
stick nor USB HDD, and the partman sees only the internal memory
blocks.

Just in case, I checked
/lib/modules/2.6.18-5-ixp4xx/kernel/drivers/usb/ and some other places
and I could not find any usb-storage.ko like kernel module, so I'm
stuck at this point.

I use the unofficial binary file from http://www.slug-firmware.net/
with I flashed successfully onto the nslu2. (the debian-4.0r2.zip
release)


A few info from the terminal:
~ # uname -a
Linux NSLU2 2.6.18-5-ixp4xx #1 Sat Jun 2 12:56:45 UTC 2007 armv5tel unknown
~ # lsmod
Module  Size  Used by
ixp4xx_mac 19316  0
evdev  10208  0
ixp4xx_qmgr 8396  5 ixp4xx_mac
ixp4xx_npe 14080  2 ixp4xx_mac
firmware_class 10400  1 ixp4xx_npe
ehci_hcd   31016  0
ohci_hcd   16932  0
ixp4xx_beeper   3392  0
usbcore   126248  3 ehci_hcd,ohci_hcd
~ # tail -f /var/log/syslog
...
Feb 18 00:33:53 kernel: usb 3-2: new high speed USB device using
ehci_hcd and address 4
Feb 18 00:33:53 kernel: usb 3-2: configuration #1 chosen from 1 choice
~ #


Any suggestion will be greatly appreciated.


Thank you very much.


-- 
Marcos


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

Re: leisner: rm assertion on arm

[Riku Voipio]

On Fri, Feb 15, 2008 at 09:59:50PM -0600, Bill Gatliff wrote:
> Peter Palfrader wrote:
> >in the sid chroot on leisner this can be observed:

> >rm: rm.c:371: main: Assertion `((status) == RM_OK || (status) == 
> >RM_USER_DECLINED || (status) == RM_ERROR)' failed.

> >Do we have a guess whether this is hardware, kernel, or coreutils
> >related?  (anybody else seeing this?)

New version of coreutils uses unlinkat instead of unlink as previously.

-unlink("tests") = -1 EISDIR (Is a directory)
-open(".", O_RDONLY|O_LARGEFILE) = 3
-lstat64("tests", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
-chdir("tests")  = 0
-lstat64(".", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
-open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x8) = 4
-fstat64(4, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
-fcntl64(4, F_GETFD) = 0x1 (flags FD_CLOEXEC)
-getdents64(4, /* 2 entries */, 4096)= 48
-getdents64(4, /* 0 entries */, 4096)= 0
-close(4)= 0
-fchdir(3)   = 0
-rmdir("tests")  = 0
+lstat64("/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
+SYS_327(0xff9c, 0xbeed8f06, 0xbeed8c50, 0x100, 0xbeed8f06) = 0
+SYS_328(0xff9c, 0xbeed8f06, 0, 0, 0x40148000) = -1 EISDIR (Is a directory)
+SYS_322(0xff9c, 0xbeed8f06, 0x28900, 0, 0x40148000) = 3
+fstat64(3, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
+fstat64(3, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
+fcntl64(3, F_GETFL) = 0x28800 (flags 
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_NOFOLLOW)
+fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
+getdents64(3, /* 2 entries */, 4096)= 48
+getdents64(3, /* 0 entries */, 4096)= 0
+fcntl64(3, F_GETFD) = 0x1 (flags FD_CLOEXEC)
 close(3)= 0
+SYS_328(0xff9c, 0x1d1a8, 0x200, 0, 0x40148000) = 0
+write(2, "rm: rm.c:371: main: Assertion `("..., 116) = 116

SYS_328 = unlinkat

rm seems works as expected, after unlinkat fails, unlinkat is called with
AT_REMOVEDIR, and directory gets removed and RM_OK is returned. Why rm
decides to assert anyway is complete mystery to me. Reassign to
coreutils?




-- 
"rm -rf" only sounds scary if you don't have backups


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