device name (symlink) stability

[Vincent Lefevre]

After a reboot of a Debian/unstable machine, I got:

  /dev/cdrw -> sr1

while it was

  /dev/cdrw -> sr0

before the reboot. More precisely, the change in the lshw output:

  *-scsi:0
   physical id: 8c
   logical name: scsi2
   capabilities: emulated
 *-cdrom
  description: DVD-RAM writer
  product: DVD+-RW GTA0N
  vendor: HL-DT-ST
  physical id: 0.0.0
  bus info: scsi@2:0.0.0
  logical name: /dev/cdrom
- logical name: /dev/cdrw
  logical name: /dev/dvd
  logical name: /dev/dvdrw
  logical name: /dev/sr0
  version: A1B0
  capabilities: removable audio cd-r cd-rw dvd dvd-r dvd-ram
  configuration: ansiversion=5 status=nodisc
  *-scsi:1
   physical id: 8d
   logical name: scsi3
   capabilities: emulated
 *-cdrom
  description: DVD-RAM writer
  product: DVD+-RW GHB0N
  vendor: HL-DT-ST
  physical id: 0.0.0
  bus info: scsi@3:0.0.0
+ logical name: /dev/cdrw
  logical name: /dev/sr1
  version: A1B1
  capabilities: removable audio cd-r cd-rw dvd dvd-r dvd-ram
  configuration: ansiversion=5 status=nodisc

Is it normal that the device names are not stable?

In particular, it is strange that all the symlinks point to sr0
except cdrw, which now points to sr1.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: device name (symlink) stability

[Michael Biebl]

Hi

Am 25.04.2017 um 10:53 schrieb Vincent Lefevre:
> After a reboot of a Debian/unstable machine, I got:
> 
>   /dev/cdrw -> sr1
> 
> while it was
> 
>   /dev/cdrw -> sr0

[..]

> Is it normal that the device names are not stable?
> 
> In particular, it is strange that all the symlinks point to sr0
> except cdrw, which now points to sr1.

The udev rules responsible for creating those symlinks is
/lib/udev/rules.d/80-debian-compat.rules or

https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/extra/rules/80-debian-compat.rules#n18

See the comment in there:

# These rules will create symlinks for CD/DVD drives, to help old
# programs which are unable to automatically discover the devices.
# The first detected device gets the symlink, but this is not stable across
# reboots.

So, yes, what you see can happen depending on the order devices are
discovered.

Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

multiple drives, 'Gave up waiting for suspend/resume device'

[craigswin]

For a desktop install from a thumbdrive of testing RC3, there were three 
drives plugged in to the motherboard.  One drive was the installation 
target. The other two had old installs, RC3 and Wheezy.


Bizarrely, the resulting fstab has two swap partitions. One from the 
target drive, and a second from one of the accessory drives.  I 
commented the second swap line out of the fstab. The new installation 
boots fine with or without the second swap as long as all three drives 
are attached.


All other references in fstab to the target drive.

If remove one of the drives, the new install has problems booting with 
or without the second swap. Booting takes a very long time, etc...  One 
message is 'Gave up waiting for suspend/resume device'.


Here is a possibly related thread:
https://mail-archive.com/debian-bugs-dist@lists.debian.org/msg1513355.html

When the boot menu appears, grub, there are options to boot the new 
install, but also additional options to boot the old installs on the 
accessory drives, even if those drives are not attached.


What is going on?  How can I fix it?  Or should I just redo the 
installation with only the target drive attached?

Re: Possibly erroneous "device not present" message during boot

[Brian]

On Mon 24 Apr 2017 at 15:10:16 -0500, David Wright wrote:

> On Mon 24 Apr 2017 at 19:37:22 (+0100), Brian wrote:
> > 
> > A modicum of reassurance and help is never wasted, particularly for
> > those users who come to this thread in the future.
> > 
> > My laptop has a single slotted reader on the PCI bus.
> 
> Before booting, can you see the SD card's device in the CMOS screens?

No. Hard disk and CD are the only offerings. That's with the card in the
slot when the machine is started.

> > The installer
> > boots and shows that mmc_core has been loaded. When it gets to the
> > partitioning stage the SD card is not offered as an option. The
> > module mmc_block is absent from 'lsmod' and does not appear when the
> > card is taken out and reinserted. It is not detected.
> 
> If there's no driver, would you expect the kernel to react?

I would not. But your remark caused *me* to react by taking a closer
look at the modules loaded on Jessie.

  brian@laptop:~$ lsmod | grep mmc
  mmc_block  30466  0 
  mmc_core   91803  4 mmc_block,sdhci,tifm_sd,sdhci_pci
  brian@laptop:~$ lsmod | grep tifm
  tifm_sd17060  0 
  tifm_7xx1  12769  0 
  tifm_core  13113  2 tifm_7xx1,tifm_sd
  mmc_core   91803  4 mmc_block,sdhci,tifm_sd,sdhci_pci

'rmmod tifm_7xx1' causes /dev/mmcblk01p to disappear. Booting without it
present leads to no device file. Stating the obvious, the card will not
work without the tifm_7xx1 module.

In the installer tifm_7xx1 should be in /lib/modules/./drivers/misc/.
It is not present.

> Is there an mmc driver in that installation moduoles screen?

No.
 
> It might be hard to spot, but is there a /proc/interrupts file,
> and does the number of interrupts increase on the appropriate line
> when you insert and remove the card?
> 
> How do you find the line. On my laptop with that sort of SD card,
>  18:   2344  0   IO-APIC-fasteoi   mmc0
> the 2344 increases by 1 when I take the card out and by many when
> I reinsert it. I don't know if mmc_core can provide that line in
> the absense of mmc_block. (Obviously my kernel has both loaded now.)

In the installer environment that number does not change when the card
is taken out and pushed back in. In the Jessie environment it changes
all the time, card in or out.
 
> > What is unusual is that the card is detected by a Jessie OS on being
> > inserted. Is this an installer problem with different hardware (my
> > laptop's is described in another post) or with the card? Basically,
> > is an installation to an SD card on a PCI bus a case of hit or miss?

It very much looks like an installer bug. It is present on Stretch and
Jessie.

The hardware:

  brian@laptop:~$ lspci | grep Texas

  00:10.0 CardBus bridge: Texas Instruments PCIxx21/x515 Cardbus Controller 

  00:10.2 FireWire (IEEE 1394): Texas Instruments OHCI Compliant IEEE 1394 Host 
Controller  
  00:10.3 Mass storage controller: Texas Instruments PCIxx21 Integrated 
FlashMedia Controller
  00:10.4 SD Host controller: Texas Instruments 
PCI6411/6421/6611/6621/7411/7421/7611/7621 Secure Digital Controller

-- 
Brian.

Re: Measuring aggregate internet useage?

[Richard Owlett]

On 04/24/2017 04:12 PM, Ben Caradoc-Davies wrote:

On 24/04/17 22:58, Richard Owlett wrote:

If there were user accessible registers with a running total of
uploaded/downloaded data since device power on would be almost ideal
granularity.


Is ifconfig available on a console during installation?


I can not check at the moment.


The full version reports TX and RX data.


The last line when using the -a option is just what I want.
Thank you.

Re: funny times

[Ric Moore]

On 04/23/2017 09:33 PM, songbird wrote:

  when my computer is turned off the clock
runs slow.

  when my computer is turned on the clock
runs fast.

  so any single adjustment in /etc/adjtime
doesn't work (as my number of hours off or
on the computer each day may change).


You may have reached level 7, where time and space no longer are 
relative to your construct of reality. Then you have reached level 7. To 
test this, use a level 6 exercise where you peer at a distant person, 
between a thumb and forefinger, and close those fingers to squash their 
head like a grape. When you open your fingers again, they will be 
miraculously restored. If you can do this, you may truly be a level 7. 
Level 8 awaits next where you will be able to channel Legba, the Lua of 
Digital Highways and Keeper of USB Keys. Keep in mind that Legba likes 
gifts of strong drink and tobacco. Please do no harm, only good, with 
your new Computer Voodoo powers. :) Ti-Jean-Petro (channeled by Ric)


--
My father, Victor Moore (Vic) used to say:
"There are two Great Sins in the world...
..the Sin of Ignorance, and the Sin of Stupidity.
Only the former may be overcome." R.I.P. Dad.
http://linuxcounter.net/user/44256.html

Re: device name (symlink) stability

[Vincent Lefevre]

Hi,

On 2017-04-25 12:14:30 +0200, Michael Biebl wrote:
> Am 25.04.2017 um 10:53 schrieb Vincent Lefevre:
[...]
> > In particular, it is strange that all the symlinks point to sr0
> > except cdrw, which now points to sr1.
> 
> The udev rules responsible for creating those symlinks is
> /lib/udev/rules.d/80-debian-compat.rules or
> 
> https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/extra/rules/80-debian-compat.rules#n18
> 
> See the comment in there:
> 
> # These rules will create symlinks for CD/DVD drives, to help old
> # programs which are unable to automatically discover the devices.
> # The first detected device gets the symlink, but this is not stable across
> # reboots.
> 
> So, yes, what you see can happen depending on the order devices are
> discovered.

OK, but if sr0 is discovered first, then it should have all the
symlinks, and if sr1 is discovered first, then it should have all
the symlinks. But why do I get sr1 for only one of them?

lrwxrwxrwx  1 root root   3 2017-04-24 10:05:16 cdrom -> sr0
lrwxrwxrwx  1 root root   3 2017-04-24 10:05:16 cdrw -> sr1
lrwxrwxrwx  1 root root   3 2017-04-24 10:05:16 dvd -> sr0
lrwxrwxrwx  1 root root   3 2017-04-24 10:05:16 dvdrw -> sr0

And why isn't there the same rule for cdrom?

/lib/udev/rules.d/80-debian-compat.rules contains:

# These rules will create symlinks for CD/DVD drives, to help old
# programs which are unable to automatically discover the devices.
# The first detected device gets the symlink, but this is not stable across
# reboots.
ENV{ID_CDROM_CD_RW}=="?*", \
  PROGRAM="/bin/sh -c 'ln -s %k /run/udev/link.cdrw 2>/dev/null; [ `readlink 
/run/udev/link.cdrw` = %k ]", \
  SYMLINK+="cdrw", OPTIONS+="link_priority=-100"
ENV{ID_CDROM_DVD}=="?*", \
  PROGRAM="/bin/sh -c 'ln -s %k /run/udev/link.dvd 2>/dev/null; [ `readlink 
/run/udev/link.dvd` = %k ]", \
  SYMLINK+="dvd", OPTIONS+="link_priority=-100"
ENV{ID_CDROM_DVD_RW}=="?*", \
  PROGRAM="/bin/sh -c 'ln -s %k /run/udev/link.dvdrw 2>/dev/null; [ `readlink 
/run/udev/link.dvdrw` = %k ]", \
  SYMLINK+="dvdrw", OPTIONS+="link_priority=-100"

but /lib/udev/rules.d/60-cdrom_id.rules contains:

KERNEL=="sr0", SYMLINK+="cdrom", OPTIONS+="link_priority=-100"

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

mutt & maillist digests

[Mike McClain]

I'm running Debian Wheeze on a P3 1/2M memory. Mostly CL.
Mutt 1.5.21 is the culprit ( or am I? )
I subscribe to mailing lists in digest form.
Mutt recognizes the fact when I'm viewing a Debian User digest but not
when I'm reading a 'help-bash' digest from gnu.org. The difference
that's got me is that when I open a DebUser digest I can enter 'v' and
mutt separates the messages so I can respond on list to a particular
message. The help-bash digest doesn't get split like that by mutt so
if I want to reply to a particular message mutt will put the whole
digest into the reply for me to delete all that doesn't apply to the
message I want to send.

Is there a configuration I'm missing?
Is there anything I can do to tell mutt that the messages from
help-bash are to be treated as a mailing list digest?
Thanks,
Mike
--
Go to heaven for the climate, hell for the company.
- Mark Twain

Re: mutt & maillist digests

[Vincent Lefevre]

On 2017-04-24 15:57:17 -0700, Mike McClain wrote:
> I'm running Debian Wheeze on a P3 1/2M memory. Mostly CL.
> Mutt 1.5.21 is the culprit ( or am I? )
> I subscribe to mailing lists in digest form.
> Mutt recognizes the fact when I'm viewing a Debian User digest but not
> when I'm reading a 'help-bash' digest from gnu.org. The difference
> that's got me is that when I open a DebUser digest I can enter 'v' and
> mutt separates the messages so I can respond on list to a particular
> message. The help-bash digest doesn't get split like that by mutt so
> if I want to reply to a particular message mutt will put the whole
> digest into the reply for me to delete all that doesn't apply to the
> message I want to send.

Perhaps the 'help-bash' digest does not use MIME.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Mouse pointer _sometimes_ too big

[Ric Moore]

On 04/24/2017 11:19 AM, Cindy-Sue Causey wrote:


Mine will occasionally do something like this. In my case, it gives
the appearance it's switching back and forth between entire cursor
themes. Is there a chance that's actually what's going on here rather
than it "just" being about pixel size?

Mine is occurring on occasional occasion in debootstrap'ed Debian
Stretch and also did so in Sid. AND I'm using Xfce4..


XFCE is FAMOUS for this behavior in that it never gets fixed. I have 
both Debian and Ubuntu installed and both have the exact same flipping 
behavior of mouse themes. Here's a bug report against that from 2007: 
https://bugs.launchpad.net/ubuntu/+source/xfwm4/+bug/157447
Sure would be nice for the mouse cursor to be stable after when first 
set. Ric


--
My father, Victor Moore (Vic) used to say:
"There are two Great Sins in the world...
..the Sin of Ignorance, and the Sin of Stupidity.
Only the former may be overcome." R.I.P. Dad.
http://linuxcounter.net/user/44256.html

Re: device name (symlink) stability

[Michael Biebl]

Am 25.04.2017 um 16:09 schrieb Vincent Lefevre:
> Hi,
> 
> On 2017-04-25 12:14:30 +0200, Michael Biebl wrote:
>> Am 25.04.2017 um 10:53 schrieb Vincent Lefevre:
> [...]
>>> In particular, it is strange that all the symlinks point to sr0
>>> except cdrw, which now points to sr1.
>>
>> The udev rules responsible for creating those symlinks is
>> /lib/udev/rules.d/80-debian-compat.rules or
>>
>> https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/extra/rules/80-debian-compat.rules#n18
>>
>> See the comment in there:
>>
>> # These rules will create symlinks for CD/DVD drives, to help old
>> # programs which are unable to automatically discover the devices.
>> # The first detected device gets the symlink, but this is not stable across
>> # reboots.
>>
>> So, yes, what you see can happen depending on the order devices are
>> discovered.
> 
> OK, but if sr0 is discovered first, then it should have all the
> symlinks, and if sr1 is discovered first, then it should have all
> the symlinks. But why do I get sr1 for only one of them?
> 
> lrwxrwxrwx  1 root root   3 2017-04-24 10:05:16 cdrom -> sr0
> lrwxrwxrwx  1 root root   3 2017-04-24 10:05:16 cdrw -> sr1
> lrwxrwxrwx  1 root root   3 2017-04-24 10:05:16 dvd -> sr0
> lrwxrwxrwx  1 root root   3 2017-04-24 10:05:16 dvdrw -> sr0
> 
> And why isn't there the same rule for cdrom?

I guess every sr0 can be considered a cdrom, but it's not necessarily a
dvd/cd writer.

> /lib/udev/rules.d/80-debian-compat.rules contains:
> 
> # These rules will create symlinks for CD/DVD drives, to help old
> # programs which are unable to automatically discover the devices.
> # The first detected device gets the symlink, but this is not stable across
> # reboots.
> ENV{ID_CDROM_CD_RW}=="?*", \
>   PROGRAM="/bin/sh -c 'ln -s %k /run/udev/link.cdrw 2>/dev/null; [ `readlink 
> /run/udev/link.cdrw` = %k ]", \
>   SYMLINK+="cdrw", OPTIONS+="link_priority=-100"
> ENV{ID_CDROM_DVD}=="?*", \
>   PROGRAM="/bin/sh -c 'ln -s %k /run/udev/link.dvd 2>/dev/null; [ `readlink 
> /run/udev/link.dvd` = %k ]", \
>   SYMLINK+="dvd", OPTIONS+="link_priority=-100"
> ENV{ID_CDROM_DVD_RW}=="?*", \
>   PROGRAM="/bin/sh -c 'ln -s %k /run/udev/link.dvdrw 2>/dev/null; [ `readlink 
> /run/udev/link.dvdrw` = %k ]", \
>   SYMLINK+="dvdrw", OPTIONS+="link_priority=-100"
> 
> but /lib/udev/rules.d/60-cdrom_id.rules contains:
> 
> KERNEL=="sr0", SYMLINK+="cdrom", OPTIONS+="link_priority=-100"


60-cdrom_id.rules is a rules provided by upstream,
80-debian-compat.rules a Debian specific file which we provide for
compat reasons.

I don't remember the details of 80-debian-compat.rules, but it's rather
ugly and it's maybe time to drop that hack early in the buster release
cycle.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: mutt & maillist digests

[David Wright]

On Tue 25 Apr 2017 at 17:22:28 (+0200), Vincent Lefevre wrote:
> On 2017-04-24 15:57:17 -0700, Mike McClain wrote:
> > I'm running Debian Wheeze on a P3 1/2M memory. Mostly CL.
> > Mutt 1.5.21 is the culprit ( or am I? )
> > I subscribe to mailing lists in digest form.
> > Mutt recognizes the fact when I'm viewing a Debian User digest but not
> > when I'm reading a 'help-bash' digest from gnu.org. The difference
> > that's got me is that when I open a DebUser digest I can enter 'v' and
> > mutt separates the messages so I can respond on list to a particular
> > message. The help-bash digest doesn't get split like that by mutt so
> > if I want to reply to a particular message mutt will put the whole
> > digest into the reply for me to delete all that doesn't apply to the
> > message I want to send.
> 
> Perhaps the 'help-bash' digest does not use MIME.

Or perhaps you didn't subscribe to the MIME version if it exists. On
https://lists.gnu.org/mailman/listinfo/help-bash
IIRC the digest "radio button" selects only the non-MIME version.
To get the MIME one you have to go down to the section ridiculously
labelled:

Help-bash Subscribers
(The subscribers list is only available to the list administrator.) 

and press:

Unsubscribe or edit options

Some non-MIME list digests scrub the attachments and give links to
see them, which don't work. BTW I've never received a reply to any
email sent to webmast...@gnu.org about any of their lists/problems.

Cheers,
David.

Re: multiple drives, 'Gave up waiting for suspend/resume device'

[Felix Miata]

craigswin composed on 2017-04-25 04:41 (UTC-0700):

> For a desktop install from a thumbdrive of testing RC3, there were three 
> drives plugged in to the motherboard.  One drive was the installation 
> target. The other two had old installs, RC3 and Wheezy.
> 
> Bizarrely, the resulting fstab has two swap partitions. One from the 
> target drive, and a second from one of the accessory drives.  I 
> commented the second swap line out of the fstab. The new installation 
> boots fine with or without the second swap as long as all three drives 
> are attached.
> 
> All other references in fstab to the target drive.
> 
> If remove one of the drives, the new install has problems booting with 
> or without the second swap. Booting takes a very long time, etc...  One 
> message is 'Gave up waiting for suspend/resume device'.
> 
> Here is a possibly related thread:
> https://mail-archive.com/debian-bugs-dist@lists.debian.org/msg1513355.html
> 
> When the boot menu appears, grub, there are options to boot the new 
> install, but also additional options to boot the old installs on the 
> accessory drives, even if those drives are not attached.
> 
> What is going on?  How can I fix it?  Or should I just redo the 
> installation with only the target drive attached?

Looks to me like this may be a manifestation of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860543
just fixed yesterday. Have you tried including noresume on your kernel cmdline?
Have you updated and rebuilt initrd since that bug fix reached the mirrors?

Do both of the other installations still boot normally (no swap waits) since
completing the new installation?
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Re: Re: funny times

[songbird]

Ric Moore wrote:
> On 04/23/2017 09:33 PM, songbird wrote:
>>   when my computer is turned off the clock
>> runs slow.
>>
>>   when my computer is turned on the clock
>> runs fast.
>>
>>   so any single adjustment in /etc/adjtime
>> doesn't work (as my number of hours off or
>> on the computer each day may change).
>
> You may have reached level 7, where time and space no longer are 
> relative to your construct of reality. Then you have reached level 7. To 
> test this, use a level 6 exercise where you peer at a distant person, 
> between a thumb and forefinger, and close those fingers to squash their 
> head like a grape. When you open your fingers again, they will be 
> miraculously restored. If you can do this, you may truly be a level 7. 

  or a fan of Kids in the Hall...  :)

20 Helens Agree...


> Level 8 awaits next where you will be able to channel Legba, the Lua of 
> Digital Highways and Keeper of USB Keys. Keep in mind that Legba likes 
> gifts of strong drink and tobacco. Please do no harm, only good, with 
> your new Computer Voodoo powers. :) Ti-Jean-Petro (channeled by Ric)

  i could use some.  i have fallen into an
odd state this past week.


  songbird

Old, stale bug reports (bug triage)

[Felix Dietrich]

Looking through bugs in the Mnemosyne package I noticed a couple of
old and stale reports that could have already been closed.  E.g. the
discussion in report #783929 ends with the upstream developer saying that
Mnemosyne is working as intended and in the last message he simply
writes "Done." – yet, the report has no been closed.

What is the etiquette dealing with seemingly forgotten bug reports?
Should I send an email to the maintainer that asks him to have another
look at the report and decide for an appropriate action; may I close the
report myself or set e.g. the "wontfix" tag; something else?

--
Felix Dietrich