Bug#931852: [armel/marvell] cmdline mtd partition map without effect
On Tue, Jul 16, 2019 at 12:25 PM Ben Hutchings wrote: > On Tue, 2019-07-16 at 09:02 +0200, Chris Laif wrote: > > On Tue, Jul 16, 2019 at 1:22 AM Ben Hutchings wrote: > > > > Thanks. Do you know if the acceptance of 'mtdparts' with/without > > prefix is specific to the Debian kernel or if it is a decision by the > > upstream kernel devs? I remember that some months ago one of the beta > > Buster kernels accepted the 'mtdparts' variable, I /think/ the > > incompatible change has been introduced during finalisation of Buster. > > > > Kernel docs > > (https://www.kernel.org/doc/html/v4.19/admin-guide/kernel-parameters.html) > > refer to the 'mtdparts' variable (without prefix). > > The difference in behaviour between the built-in and modular builds of > the driver, is not specific to Debian. > > The change to building this driver as a module was our decision, > however. That change was made in version 4.16-1~exp1, over a year ago. > Thanks. I'm using 'cmdlinepart.mtdparts' now and for me this bug can be closed. I expect other people will run into this problem but I'm not in a position to judge of whether including cmdlinepart as a module or not. Chris
Bug#931852: [armel/marvell] cmdline mtd partition map without effect
On Tue, Jul 16, 2019 at 1:22 AM Ben Hutchings wrote: > On Mon, 2019-07-15 at 09:31 +0200, Chris Laif wrote: > > On Sat, Jul 13, 2019 at 11:37 PM Ben Hutchings wrote: > > > On Thu, 2019-07-11 at 15:11 +0200, Chris Laif wrote: > > This seems to break backwards compatibility for a lot of devices > > (Google shows lots of hits for "mtdparts=" and only a handful for > > "cmdlinepart.mtdparts", so I think nobody is using the latter). > > > > I wonder what's the best way to have a both Stretch and Buster > > compatible cmdline. A quick test shows that "cmdlinepart.mtdparts" > > works with Stretch, too (even Stretch does not have a seperate > > "cmdlinepart" module). Do you have any recommendations? > > I think that "cmdlinepart.mtdparts" will work whether or not the driver > is actually a module. But I accept it would be better if "mtdparts" > also continued to work when the driver is a module. > Thanks. Do you know if the acceptance of 'mtdparts' with/without prefix is specific to the Debian kernel or if it is a decision by the upstream kernel devs? I remember that some months ago one of the beta Buster kernels accepted the 'mtdparts' variable, I /think/ the incompatible change has been introduced during finalisation of Buster. Kernel docs (https://www.kernel.org/doc/html/v4.19/admin-guide/kernel-parameters.html) refer to the 'mtdparts' variable (without prefix). Chris
Bug#931852: [armel/marvell] cmdline mtd partition map without effect
On Sat, Jul 13, 2019 at 11:37 PM Ben Hutchings wrote:
> On Thu, 2019-07-11 at 15:11 +0200, Chris Laif wrote:
> > Package: debian-installer
> > Version: 20190702
> >
> > I'm using the current Buster kernel/initrd on my Seagate Blackarmor NAS.
> >
> > The mtd partition map ('mtdparts' cmdline variable) has no effect
> > (even with 'cmdline' module loaded):
> [...]
>
> What if you replace "mtdparts=" with "cmdlineparts.mtdparts="?
>
With "cmdlineparts.mtdparts" it does not work:
~ # cat /proc/cmdline
console=ttyS0,115200
cmdlineparts.mtdparts=orion_nand:0xa@0x0(uboot),0x01@0xa(env),0x50@0xc(uimage),0x1a4@0x5c(rootfs)
~ # cat /proc/mtd
dev:size erasesize name
mtd0: 0200 4000 "orion_nand"
~ #
With "cmdlinepart.mtdparts" (without trailing "s", equal to the name
of the kernel-module) it works!:
~ # cat /proc/cmdline
console=ttyS0,115200
cmdlinepart.mtdparts=orion_nand:0xa@0x0(uboot),0x01@0xa(env),0x50@0xc(uimage),0x1a4@0x5c(rootfs)
~ # cat /proc/mtd
dev:size erasesize name
mtd0: 000a 4000 "uboot"
mtd1: 0001 4000 "env"
mtd2: 0050 4000 "uimage"
mtd3: 01a4 4000 "rootfs"
~ #
This seems to break backwards compatibility for a lot of devices
(Google shows lots of hits for "mtdparts=" and only a handful for
"cmdlinepart.mtdparts", so I think nobody is using the latter).
I wonder what's the best way to have a both Stretch and Buster
compatible cmdline. A quick test shows that "cmdlinepart.mtdparts"
works with Stretch, too (even Stretch does not have a seperate
"cmdlinepart" module). Do you have any recommendations?
Thanks,
Chris
Bug#931852: [armel/marvell] cmdline mtd partition map without effect
Package: debian-installer
Version: 20190702
Hi,
I'm using the current Buster kernel/initrd on my Seagate Blackarmor NAS.
The mtd partition map ('mtdparts' cmdline variable) has no effect
(even with 'cmdline' module loaded):
[...]
[2.312626] This architecture does not have kernel memory protection.
[2.319057] Run /init as init process
[2.659299] nand: device found, Manufacturer ID: 0xec, Chip ID: 0x75
[2.665704] nand: Samsung NAND 32MiB 3,3V 8-bit
[2.670237] nand: 32 MiB, SLC, erase size: 16 KiB, page size: 512,
OOB size: 16
[2.738418] mv643xx_eth: MV-643xx 10/100/1000 ethernet driver version 1.4
[2.778297] libphy: orion_mdio_bus: probed
[2.798779] mv643xx_eth_port mv643xx_eth_port.0: DMA mask not set
[2.824205] Scanning device for bad blocks
[...]
~ # uname -a
Linux (none) 4.19.0-5-marvell #1 Debian 4.19.37-5 (2019-06-19)
armv5tel GNU/Linux
~ # cat /proc/cmdline
console=ttyS0,115200
mtdparts=orion_nand:0xa@0x0(uboot),0x01@0xa(env),0x50@0xc(uimage),0x1a4@0x5c(rootfs)
~ # cat /proc/mtd
dev:size erasesize name
mtd0: 0200 4000 "orion_nand"
~ # lsmod
Module Size Used by
ofpart 3447 0
cmdlinepart 2775 0
ehci_orion 3765 0
ehci_hcd 53205 1 ehci_orion
usbcore 159269 2 ehci_orion,ehci_hcd
mvmdio 4528 0
mv643xx_eth27872 0
usb_common 3755 1 usbcore
nls_base5869 1 usbcore
orion_nand 1914 0
nand 74301 1 orion_nand
nand_ecc3294 1 nand
nand_bch2470 1 nand
bch 9396 1 nand_bch
mtd44525 6 nand_bch,ofpart,nand,cmdlinepart,orion_nand
sha256_generic 9524 0
~ #
Manually removing/adding cmdline, mtd and nand modules does not help.
The same device started with Debian Stretch has 4 MTD partitions enabled:
[0.851760] nand: Samsung NAND 32MiB 3,3V 8-bit
[0.856313] nand: 32 MiB, SLC, erase size: 16 KiB, page size: 512,
OOB size: 16
[0.863602] Scanning device for bad blocks
[1.095922] 4 cmdlinepart partitions found on MTD device orion_nand
[1.102165] Creating 4 MTD partitions on "orion_nand":
[1.107309] 0x-0x000a : "uboot"
[1.112995] 0x000a-0x000b : "env"
[1.118397] 0x000c-0x005c : "uimage"
[1.124306] 0x005c-0x0200 : "rootfs"
[1.131105] mtd: device 3 (rootfs) set to be root filesystem
Kind regards,
Chris
Bug#827548: bugfix / php5-common: sessionclean does not read ini settings in conf.d directories
Additional information: php-cli still scans the compiled-in conf.d
directory (/etc/php5/cli/conf.d), so the sessionclean script will mix
apache2-sapi and cli-sapi ini settings during execution. So setting
gc_maxlifetime for the cli-sapi helps you to correctly expire apache2
sessions (definitely not the recommended way, but it works):
# echo "session.gc_maxlifetime = 3456" > /etc/php5/cli/conf.d/90-local.ini
# /usr/lib/php5/sessionclean
DEBUG: /var/lib/php5/sessions 57
A possible bug fix is to set PHP_INI_SCAN_DIR before executing php:
-session_config=$(php5 -c /etc/php5/${conf_dir}/php.ini -d
"error_reporting='~E_ALL'" -r 'foreach(ini_get_all("session") as $k =>
$v) echo "$k=".$v["local_value"]."\n";')
+session_config=$(PHP_INI_SCAN_DIR=/etc/php5/${conf_dir}/conf.d
php5 -c /etc/php5/${conf_dir}/php.ini -d "error_reporting='~E_ALL'" -r
'foreach(ini_get_all("session") as $k => $v) echo
"$k=".$v["local_value"]."\n";')
Chris
Bug#827548: php5-common: sessionclean does not read ini settings in conf.d directories
Package: php5-common Version: 5.6.22+dfsg-0+deb8u1 The /usr/lib/php5/sessionclean script does not read ini settings in conf.d directories: I added some debug code to better explain the problem: $ tail -n6 /usr/lib/php5/sessionclean | head -n3 # find all files older then maxlifetime and delete them echo "DEBUG: $save_path $gc_maxlifetime" find -O3 "$save_path" -depth -mindepth 1 -name 'sess_*' -ignore_readdir_race -type f -cmin "+$gc_maxlifetime" -delete # /usr/lib/php5/sessionclean DEBUG: /var/lib/php5/sessions 24 # echo "session.gc_maxlifetime = 3456" > /etc/php5/apache2/conf.d/90-local.ini # /usr/lib/php5/sessionclean DEBUG: /var/lib/php5/sessions 24 We maintain our php settings in separate ini files as this is considerably easier when working with a huge number of installations and/or employees. Patching the main php.ini just for the gc_maxlifetime parameter is not the best option. Chris
Bug#824450: scanbd does not find scanner
Hi Rolf. On Wed, Jun 1, 2016 at 3:22 PM, Rolf Leggewie wrote: >>> Do you know how to compile software on your own? >>> >> Yes, standard procedures shouldn't be a problem. You can even contact >> me via private mail if that helps. > > Please try http://oss.leggewie.org/scanbd/scanbd_1.4.4-1rl1.dsc > Please see below. > There are binary packages in that directory as well, but they are for > i386. I added a bunch of tests for common configuration mistakes into > the latest init script. Unfortunately, those didn't make it in time for > jessie. Before changing the binary packages, try to replace > /etc/init.d/scanbd with the latest version from git > http://anonscm.debian.org/cgit/collab-maint/scanbd.git/plain/debian/scanbd.init > It might be enough to inform you where your configuration is wrong. Do > "/etc/init.d/scanbd status" and "/etc/init.d/scanbd restart" as root to > see you where you stand. I am almost certain your problem is not a true > bug but a configuration mistake. > Changing the init script did not help. The scanner does not get recognized and status/restart do not show any errors or any other useful info. I strongly believe there is no configuration mistake because I did not change the dist config files at all (only debug-level = 7). After that I compiled scanbd_1.4.4-1rl1 and ... voila, it works :) Jun 1 23:36:37 scanbd: /usr/sbin/scanbd: SANE_CONFIG_DIR=/etc/scanbd Jun 1 23:36:37 scanbd: /usr/sbin/scanbd: sane version 1.0 Jun 1 23:36:37 scanbd: /usr/sbin/scanbd: Scanning for local-only devices Jun 1 23:36:41 scanbd: /usr/sbin/scanbd: found device: plustek:libusb:007:027 Canon CanoScan N1240U/LiDE30 flatbed scanner Jun 1 23:36:41 scanbd: /usr/sbin/scanbd: start_sane_threads Jun 1 23:36:41 scanbd: /usr/sbin/scanbd: Starting poll thread for plustek:libusb:007:027 Jun 1 23:36:41 scanbd: /usr/sbin/scanbd: Thread started for device plustek:libusb:007:027 Jun 1 23:36:41 scanbd: /usr/sbin/scanbd: start dbus thread Jun 1 23:36:41 scanbd: /usr/sbin/scanbd: sane_poll Jun 1 23:36:41 scanbd: /usr/sbin/scanbd: Not Primary Owner (-1) Jun 1 23:36:41 scanbd: /usr/sbin/scanbd: Name Error (Connection ":1.71" is not allowed to own the service "de.kmux.scanbd.server" due to securit Jun 1 23:36:41 scanbd: /usr/sbin/scanbd: udev init Jun 1 23:36:41 scanbd: /usr/sbin/scanbd: get udev monitor Jun 1 23:36:41 scanbd: /usr/sbin/scanbd: udev fd is non-blocking, now setting to blocking mode Jun 1 23:36:41 scanbd: /usr/sbin/scanbd: start udev thread Jun 1 23:36:41 scanbd: /usr/sbin/scanbd: udev thread started Jun 1 23:36:41 scanbd: /usr/sbin/scanbd: found 45 options for device plustek:libusb:007:027 Jun 1 23:36:41 scanbd: /usr/sbin/scanbd: sane_find_matching_options Jun 1 23:36:41 scanbd: /usr/sbin/scanbd: found 5 actions in section (null) Jun 1 23:36:41 scanbd: /usr/sbin/scanbd: checking action scan with filter: ^scan.* Jun 1 23:36:41 scanbd: /usr/sbin/scanbd: found active option[2] mode (type: 3) for device plustek:libusb:007:027 Jun 1 23:36:41 scanbd: /usr/sbin/scanbd: found active option[3] depth (type: 1) for device plustek:libusb:007:027 Jun 1 23:36:41 scanbd: /usr/sbin/scanbd: found active option[5] resolution (type: 1) for device plustek:libusb:007:027 [...] Jun 1 23:46:45 scanbd: /usr/sbin/scanbd: checking option preview number 6 (0) for device plustek:libusb:007:027: value: 0 Jun 1 23:46:45 scanbd: /usr/sbin/scanbd: polling thread for plustek:libusb:007:027 cancellation point Jun 1 23:46:45 scanbd: /usr/sbin/scanbd: polling device plustek:libusb:007:027 [...] I did not test any scan functions yet, but I hope everything works well when the scanner shows up in the log file. I also double-checked by re-installing scanbd_jessiedist again: does not work. Re-installing scanbd_1.4.4-1rl1: works. Chris
Bug#821730: Cannot connect to Samba 4.2 server from OS X 10.11
Hi, the Samba team tracks this issue at https://bugzilla.samba.org/show_bug.cgi?id=11847 (and https://bugzilla.samba.org/show_bug.cgi?id=11849, announcing patch https://attachments.samba.org/attachment.cgi?id=12045 for v4-2-test) The patch applies cleanly to Debian's samba-4.2.10+dfsg. After recompiling, connecting from Mac OS X works again :-) Chris
Bug#824450: scanbd does not find scanner
Hi Rolf, thank you for your help, you'll find the answers below: On Tue, May 17, 2016 at 1:10 AM, Rolf Leggewie wrote: > Are you an an i386 or amd64 or some other system? AMD64 > Is your device connected over USB3? No, it's an Asus P6T motherboard and from their website I see that if offers (only) USB2 ports. > Is there a chance you can try Debian unstable for testing purposes on > your hardware? I can try some unstable packages as long it does not mess up the whole system, unfortunately it is not possible to dual-boot. > Do you know how to compile software on your own? > Yes, standard procedures shouldn't be a problem. You can even contact me via private mail if that helps. Chris
Bug#824450: scanbd does not find scanner
Package: scanbd Version: 1.4.0-2 Severity: important I've got a Canon scanner, which perfectly worked with Squeeze's scanbuttond. After upgrading to Jessie (fresh install, all packages up to date) the scanner is not recognized by scanbd. As root, everything works as expected (scanbd.conf unchanged from dist, only loglevel=7): lsusb|grep Cano: Bus 007 Device 025: ID 04a9:220e Canon, Inc. CanoScan N1240U/LiDE 30 # scanimage -L device `plustek:libusb:007:025' is a Canon CanoScan N1240U/LiDE30 flatbed scanner # scanbd -f scanbd: debug on: level: 7 scanbd: dropping privs to uid saned scanbd: dropping privs to gid scanner scanbd: group scanner has member: scanbd: saned scanbd: drop privileges to gid: 113 scanbd: Running as effective gid 113 scanbd: drop privileges to uid: 109 scanbd: Running as effective uid 109 scanbd: dbus_init scanbd: dbus match type='signal',interface='org.freedesktop.Hal.Manager' scanbd: sane version 1.0 scanbd: Scanning for local-only devices scanbd: found device: plustek:libusb:007:025 Canon CanoScan N1240U/LiDE30 flatbed scanner scanbd: start_sane_threads scanbd: Starting poll thread for plustek:libusb:007:025 scanbd: Thread started for device plustek:libusb:007:025 scanbd: sane_poll scanbd: start dbus thread [...] When started with systemd, the scanner is NOT detected: May 16 10:53:54 scanbd: /usr/sbin/scanbd: sane version 1.0 May 16 10:53:54 scanbd: /usr/sbin/scanbd: Scanning for local-only devices May 16 10:53:54 scanbd: /usr/sbin/scanbd: start_sane_threads May 16 10:53:54 scanbd: /usr/sbin/scanbd: start dbus thread (notice the missing "found device" line) scanbd keeps on logging these lines: May 16 11:01:08 scanbd[3485]: /usr/sbin/scanbd: Iteration on dbus call May 16 11:01:08 scanbd[3485]: /usr/sbin/scanbd: Iteration on dbus call May 16 11:01:08 scanbd[3485]: /usr/sbin/scanbd: Iteration on dbus call May 16 11:01:08 scanbd[3485]: /usr/sbin/scanbd: Iteration on dbus call This already has been posted to debian-users, too (https://lists.debian.org/debian-user/2015/03/msg00907.html) Chris
Bug#484022: Fix for bugs #484022 and #479515
Stopping web server: /etc/init.d/thttpd: line 40: kill: SIGUSR1: invalid signal specification Fix: --- /etc/init.d/thttpd.orig 2008-07-08 10:05:21.0 +0200 +++ /etc/init.d/thttpd 2008-07-08 10:03:17.0 +0200 @@ -37,7 +37,7 @@ stop) echo -n "Stopping web server: " if [ -f $PIDFILE ]; then - kill -SIGUSR1 `cat $PIDFILE` > /dev/null 2>&1 + kill -USR1 `cat $PIDFILE` > /dev/null 2>&1 echo "$NAME" rm -f $PIDFILE else Regards, Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
