Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #230829 > unrolled thread

Too many levels of symbolic links

Back to article view | Back to linux.debian.user

Contents

  Too many levels of symbolic links steve <dlist@bluewin.ch> - 2021-01-19 10:10 +0100
    Re: Too many levels of symbolic links Greg Wooledge <wooledg@eeg.ccf.org> - 2021-01-19 13:50 +0100
      Re: Too many levels of symbolic links <tomas@tuxteam.de> - 2021-01-19 14:50 +0100
        Re: Too many levels of symbolic links steve <dlist@bluewin.ch> - 2021-01-19 15:50 +0100
          Re: Too many levels of symbolic links <tomas@tuxteam.de> - 2021-01-19 16:00 +0100
            Re: Too many levels of symbolic links steve <dlist@bluewin.ch> - 2021-01-19 16:10 +0100
              Re: Too many levels of symbolic links Greg Wooledge <wooledg@eeg.ccf.org> - 2021-01-19 17:20 +0100
                Re: Too many levels of symbolic links David Wright <deblis@lionunicorn.co.uk> - 2021-01-19 18:10 +0100
                  Re: Too many levels of symbolic links steve <dlist@bluewin.ch> - 2021-01-20 08:50 +0100
                  [SOLVED] Re: Too many levels of symbolic links steve <dlist@bluewin.ch> - 2021-01-20 08:50 +0100
                  Re: Too many levels of symbolic links steve <dlist@bluewin.ch> - 2021-01-20 09:50 +0100
                    Re: Too many levels of symbolic links <tomas@tuxteam.de> - 2021-01-20 10:20 +0100
                      Re: Too many levels of symbolic links steve <dlist@bluewin.ch> - 2021-01-20 10:50 +0100
                        Re: Too many levels of symbolic links <tomas@tuxteam.de> - 2021-01-20 11:00 +0100
                          Re: Too many levels of symbolic links steve <dlist@bluewin.ch> - 2021-01-20 11:20 +0100
                            Re: Too many levels of symbolic links steve <dlist@bluewin.ch> - 2021-01-20 11:30 +0100
                            Bluewin bouncing my mails [was: Too many levels of symbolic links] tomas@tuxteam.de - 2021-01-20 11:30 +0100
                              Re: Bluewin bouncing my mails tomas@tuxteam.de - 2021-01-20 12:50 +0100
                            Re: Too many levels of symbolic links <tomas@tuxteam.de> - 2021-01-20 11:30 +0100
                        Re: Too many levels of symbolic links Erwan David <erwan@rail.eu.org> - 2021-01-20 11:40 +0100
                          Re: Too many levels of symbolic links <tomas@tuxteam.de> - 2021-01-20 11:40 +0100
                          Re: Too many levels of symbolic links steve <dlist@bluewin.ch> - 2021-01-20 12:10 +0100
                    Re: Too many levels of symbolic links Stefan Monnier <monnier@iro.umontreal.ca> - 2021-01-20 16:20 +0100
                      Re: Too many levels of symbolic links steve <dlist@bluewin.ch> - 2021-01-20 16:40 +0100
                        Re: Too many levels of symbolic links Stefan Monnier <monnier@iro.umontreal.ca> - 2021-01-20 22:10 +0100
                          Re: Too many levels of symbolic links steve <dlist@bluewin.ch> - 2021-01-21 08:10 +0100
                          Re: Too many levels of symbolic links steve <dlist@bluewin.ch> - 2021-01-21 08:40 +0100
                            Re: Too many levels of symbolic links Andrei POPESCU <andreimpopescu@gmail.com> - 2021-01-21 08:50 +0100
                              Re: Too many levels of symbolic links steve <dlist@bluewin.ch> - 2021-01-22 08:10 +0100
                                Re: Too many levels of symbolic links Vincent Lefevre <vincent@vinc17.net> - 2021-01-22 13:50 +0100
                                  Re: Too many levels of symbolic links steve <dlist@bluewin.ch> - 2021-01-23 09:40 +0100
                                    Re: Too many levels of symbolic links Vincent Lefevre <vincent@vinc17.net> - 2021-01-23 16:20 +0100
                                Re: Too many levels of symbolic links Andrei POPESCU <andreimpopescu@gmail.com> - 2021-01-22 14:00 +0100
                                  remove me from this list J B Martin <bryant@ab-domain.com> - 2021-01-22 14:10 +0100
                                    Re: remove me from this list Charles Curley <charlescurley@charlescurley.com> - 2021-01-22 18:50 +0100
                                    Re: remove me from this list "Andrew M.A. Cater" <amacater@einval.com> - 2021-01-23 11:00 +0100
                                  Re: Too many levels of symbolic links steve <dlist@bluewin.ch> - 2021-01-23 09:40 +0100
                            Re: Too many levels of symbolic links David Wright <deblis@lionunicorn.co.uk> - 2021-01-22 03:50 +0100
                              Re: Too many levels of symbolic links steve <dlist@bluewin.ch> - 2021-01-22 08:10 +0100
                                Re: Too many levels of symbolic links David Wright <deblis@lionunicorn.co.uk> - 2021-01-22 20:30 +0100
                                  Re: Too many levels of symbolic links Dan Ritter <dsr@randomstring.org> - 2021-01-22 21:10 +0100
                                  Re: Too many levels of symbolic links steve <dlist@bluewin.ch> - 2021-01-23 15:40 +0100
              Re: Too many levels of symbolic links <tomas@tuxteam.de> - 2021-01-19 17:20 +0100
                Re: Too many levels of symbolic links steve <dlist@bluewin.ch> - 2021-01-19 18:00 +0100

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#230883

[Multipart message — attachments visible in raw view] — view raw

On Wed, Jan 20, 2021 at 11:30:50AM +0100, Erwan David wrote:

[...]

> it is not missing : it disapears. And /dev/fd/4 is a link to a file
> opend by find itself, it is sufficient that find closes it and the
> name does not exist anymore.

Thanks for putting this in a less roundabout way than I did :-D

Cheers
 - t

[toc] | [prev] | [next] | [standalone]

#230884

Le 20-01-2021, à 11:30:50 +0100, Erwan David a écrit :

>>What is strange is that it is always /dev/fd/4 that is missing, even
>>after a reboot.
>>
>>
>
>it is not missing : it disapears. And /dev/fd/4 is a link to a file 
>opend by find itself, it is sufficient that find closes it and the 
>name does not exist anymore.

Got it now :)

Thanks.

[toc] | [prev] | [next] | [standalone]

#230888

> # find /dev -follow -printf ""

You want `-mount` in there so you don't enter things like `/dev/fd` or
`/dev/shm`.


        Stefan

[toc] | [prev] | [next] | [standalone]

#230889

Le 20-01-2021, à 10:15:47 -0500, Stefan Monnier a écrit :

>> # find /dev -follow -printf ""
>
>You want `-mount` in there so you don't enter things like `/dev/fd` or
>`/dev/shm`.

I tried that on / and got no output at all.

But still have the same messages in syslog at boot time.

Thanks.

[toc] | [prev] | [next] | [standalone]

#230896

> Le 20-01-2021, à 10:15:47 -0500, Stefan Monnier a écrit :
>>> # find /dev -follow -printf ""
>>You want `-mount` in there so you don't enter things like `/dev/fd` or
>>`/dev/shm`.
> I tried that on /

Not a good idea: the `-mount` will then preventing it from entering
`/dev` since `/dev` is usually another mount point (using a sort of
tmpfs).

> and got no output at all.

Since the problem is expected to be in /dev, I'd do:

    find /dev -mount -follow -printf ""

Of course, I don't actually know if that'll catch the source of
your problem.


        Stefan

[toc] | [prev] | [next] | [standalone]

#230918

Le 20-01-2021, à 16:06:53 -0500, Stefan Monnier a écrit :

>> Le 20-01-2021, à 10:15:47 -0500, Stefan Monnier a écrit :
>>>> # find /dev -follow -printf ""
>>>You want `-mount` in there so you don't enter things like `/dev/fd` or
>>>`/dev/shm`.
>> I tried that on /
>
>Not a good idea: the `-mount` will then preventing it from entering
>`/dev` since `/dev` is usually another mount point (using a sort of
>tmpfs).

Understood.

>> and got no output at all.
>
>Since the problem is expected to be in /dev, I'd do:
>
>    find /dev -mount -follow -printf ""

No output.

>Of course, I don't actually know if that'll catch the source of
>your problem.

Seems not.

Thanks for the help.

[toc] | [prev] | [next] | [standalone]

#230921

I have rebooted with udev_log=debug in /etc/udev/udev.conf. I see

Jan 21 08:15:28 box systemd-udevd[607]: sdc6: Failed to update device symlinks: Too many levels of symbolic links
Jan 21 08:15:28 box systemd-udevd[607]: sdc6: Preserve already existing symlink '/dev/disk/by-path/pci-0000:00:17.0-ata-2.0-part6' to '../../sdc6'
Jan 21 08:15:28 box systemd-udevd[607]: sdc6: Preserve already existing symlink '/dev/disk/by-partuuid/7acd2c90-b372-4bfb-a517-e14d2a17e342' to '../../sdc6'
Jan 21 08:15:28 box systemd-udevd[607]: sdc6: Preserve already existing symlink '/dev/disk/by-path/pci-0000:00:17.0-ata-2-part6' to '../../sdc6'

And the same for other partitions which are all part of a Raid1 array.
Other partitions are not impacted. So I guess this is related.

But I'm blocked now.

Help please.

Thanks 

Steve

[toc] | [prev] | [next] | [standalone]

#230922

[Multipart message — attachments visible in raw view] — view raw

On Jo, 21 ian 21, 08:34:34, steve wrote:
> I have rebooted with udev_log=debug in /etc/udev/udev.conf. I see
> 
> Jan 21 08:15:28 box systemd-udevd[607]: sdc6: Failed to update device symlinks: Too many levels of symbolic links
> Jan 21 08:15:28 box systemd-udevd[607]: sdc6: Preserve already existing symlink '/dev/disk/by-path/pci-0000:00:17.0-ata-2.0-part6' to '../../sdc6'
> Jan 21 08:15:28 box systemd-udevd[607]: sdc6: Preserve already existing symlink '/dev/disk/by-partuuid/7acd2c90-b372-4bfb-a517-e14d2a17e342' to '../../sdc6'
> Jan 21 08:15:28 box systemd-udevd[607]: sdc6: Preserve already existing symlink '/dev/disk/by-path/pci-0000:00:17.0-ata-2-part6' to '../../sdc6'
> 
> And the same for other partitions which are all part of a Raid1 array.
> Other partitions are not impacted. So I guess this is related.

Could you inspect the /dev directory from a live image or similar (i.e. 
with the affected system not running)?

Do you have any custom udev rules or any other custom scripts, services, 
etc. plugged into the early startup?

How is the RAID assembled?

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#230962

Le 21-01-2021, à 09:45:18 +0200, Andrei POPESCU a écrit :

>On Jo, 21 ian 21, 08:34:34, steve wrote:
>> I have rebooted with udev_log=debug in /etc/udev/udev.conf. I see
>>
>> Jan 21 08:15:28 box systemd-udevd[607]: sdc6: Failed to update device symlinks: Too many levels of symbolic links
>> Jan 21 08:15:28 box systemd-udevd[607]: sdc6: Preserve already existing symlink '/dev/disk/by-path/pci-0000:00:17.0-ata-2.0-part6' to '../../sdc6'
>> Jan 21 08:15:28 box systemd-udevd[607]: sdc6: Preserve already existing symlink '/dev/disk/by-partuuid/7acd2c90-b372-4bfb-a517-e14d2a17e342' to '../../sdc6'
>> Jan 21 08:15:28 box systemd-udevd[607]: sdc6: Preserve already existing symlink '/dev/disk/by-path/pci-0000:00:17.0-ata-2-part6' to '../../sdc6'
>>
>> And the same for other partitions which are all part of a Raid1 array.
>> Other partitions are not impacted. So I guess this is related.
>
>Could you inspect the /dev directory from a live image or similar (i.e.
>with the affected system not running)?

Yes I can do that. What should I look for?


>Do you have any custom udev rules or any other custom scripts, services,
>etc. plugged into the early startup?

Don't know:

tree /etc/udev
/etc/udev
├── hwdb.d
├── rules.d
│   ├── 51-android.rules
│   ├── 55-Argyll.rules
│   ├── 69-libmtp.rules
│   ├── 70-persistent-cd.rules
│   └── 70-persistent-net.rules.old
└── udev.conf

>How is the RAID assembled?


See my other's morning mail.

Thanks for your help.

Steve

[toc] | [prev] | [next] | [standalone]

#230969

On 2021-01-22 08:08:57 +0100, steve wrote:
> Le 21-01-2021, à 09:45:18 +0200, Andrei POPESCU a écrit :
> 
> > On Jo, 21 ian 21, 08:34:34, steve wrote:
> > > I have rebooted with udev_log=debug in /etc/udev/udev.conf. I see
> > > 
> > > Jan 21 08:15:28 box systemd-udevd[607]: sdc6: Failed to update device symlinks: Too many levels of symbolic links
> > > Jan 21 08:15:28 box systemd-udevd[607]: sdc6: Preserve already existing symlink '/dev/disk/by-path/pci-0000:00:17.0-ata-2.0-part6' to '../../sdc6'
> > > Jan 21 08:15:28 box systemd-udevd[607]: sdc6: Preserve already existing symlink '/dev/disk/by-partuuid/7acd2c90-b372-4bfb-a517-e14d2a17e342' to '../../sdc6'
> > > Jan 21 08:15:28 box systemd-udevd[607]: sdc6: Preserve already existing symlink '/dev/disk/by-path/pci-0000:00:17.0-ata-2-part6' to '../../sdc6'
> > > 
> > > And the same for other partitions which are all part of a Raid1 array.
> > > Other partitions are not impacted. So I guess this is related.
> > 
> > Could you inspect the /dev directory from a live image or similar (i.e.
> > with the affected system not running)?
> 
> Yes I can do that. What should I look for?

As usual, the error message gives the name of the symlink: sdc6,
so that should be /dev/sdc6. If it is not a symlink, I suggest that
you check the ctime with /usr/bin/stat in case it has changed after
the error message.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[toc] | [prev] | [next] | [standalone]

#231014

Le 22-01-2021, à 13:40:20 +0100, Vincent Lefevre a écrit :

>> > Could you inspect the /dev directory from a live image or similar (i.e.
>> > with the affected system not running)?
>>
>> Yes I can do that. What should I look for?
>
>As usual, the error message gives the name of the symlink: sdc6,
>so that should be /dev/sdc6. If it is not a symlink, I suggest that
>you check the ctime with /usr/bin/stat in case it has changed after
>the error message.


❯ ls -l /dev/sdc6
brw-rw---- 1 root disk 8, 38 23 jan 09:31 /dev/sdc6

❯ stat /dev/sdc6
   Fichier : /dev/sdc6
    Taille : 0           Blocs : 0          Blocs d'E/S : 4096   fichier spécial de blocs
Périphérique : 5h/5d    Inœud : 266         Liens : 1     Type de périph. : 8,26
Accès : (0660/brw-rw----)  UID : (    0/    root)   GID : (    6/    disk)
  Accès : 2021-01-23 09:31:05.525009350 +0100
Modif. : 2021-01-23 09:31:05.525009350 +0100
Changt : 2021-01-23 09:31:05.525009350 +0100
   Créé : -


Looks good?

[toc] | [prev] | [next] | [standalone]

#231024

On 2021-01-23 09:38:52 +0100, steve wrote:
> ❯ stat /dev/sdc6
>   Fichier : /dev/sdc6
>    Taille : 0           Blocs : 0          Blocs d'E/S : 4096   fichier spécial de blocs
> Périphérique : 5h/5d    Inœud : 266         Liens : 1     Type de périph. : 8,26
> Accès : (0660/brw-rw----)  UID : (    0/    root)   GID : (    6/    disk)
>  Accès : 2021-01-23 09:31:05.525009350 +0100
> Modif. : 2021-01-23 09:31:05.525009350 +0100
> Changt : 2021-01-23 09:31:05.525009350 +0100
>   Créé : -
> 
> Looks good?

I don't know. You need to compare this date with the date of the
error message: if the error message is older, this means that the
file has changed and inspecting the filesystem now is useless.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[toc] | [prev] | [next] | [standalone]

#230971

[Multipart message — attachments visible in raw view] — view raw

On Vi, 22 ian 21, 08:08:57, steve wrote:
> Le 21-01-2021, à 09:45:18 +0200, Andrei POPESCU a écrit :
> 
> > On Jo, 21 ian 21, 08:34:34, steve wrote:
> > > I have rebooted with udev_log=debug in /etc/udev/udev.conf. I see
> > > 
> > > Jan 21 08:15:28 box systemd-udevd[607]: sdc6: Failed to update device symlinks: Too many levels of symbolic links
> > > Jan 21 08:15:28 box systemd-udevd[607]: sdc6: Preserve already existing symlink '/dev/disk/by-path/pci-0000:00:17.0-ata-2.0-part6' to '../../sdc6'
> > > Jan 21 08:15:28 box systemd-udevd[607]: sdc6: Preserve already existing symlink '/dev/disk/by-partuuid/7acd2c90-b372-4bfb-a517-e14d2a17e342' to '../../sdc6'
> > > Jan 21 08:15:28 box systemd-udevd[607]: sdc6: Preserve already existing symlink '/dev/disk/by-path/pci-0000:00:17.0-ata-2-part6' to '../../sdc6'
> > > 
> > > And the same for other partitions which are all part of a Raid1 array.
> > > Other partitions are not impacted. So I guess this is related.
> > 
> > Could you inspect the /dev directory from a live image or similar (i.e.
> > with the affected system not running)?
> 
> Yes I can do that. What should I look for?
 
I'm guessing it should be empty ;)

At least in buster /dev is a 'devtmpfs' mounted over /dev (is this the 
same for you?).
 
> > Do you have any custom udev rules or any other custom scripts, services,
> > etc. plugged into the early startup?
> 
> Don't know:
> 
> tree /etc/udev
> /etc/udev
> ├── hwdb.d
> ├── rules.d
> │   ├── 51-android.rules
> │   ├── 55-Argyll.rules
> │   ├── 69-libmtp.rules
> │   ├── 70-persistent-cd.rules
> │   └── 70-persistent-net.rules.old
> └── udev.conf

Maybe the output of 'udevadm test /sys/block/sdc/sdc6' can provide some 
interesting information, as well as 'ls -l /dev/disk/by-*', otherwise 
I'm out of ideas.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#230972 — remove me from this list

[Multipart message — attachments visible in raw view] — view raw

I do not use this product.

Please remove my name.

Thank you.

Bryant Martin

On 1/22/2021 7:59 AM, Andrei POPESCU wrote:
> On Vi, 22 ian 21, 08:08:57, steve wrote:
>> Le 21-01-2021, à 09:45:18 +0200, Andrei POPESCU a écrit :
>>
>>> On Jo, 21 ian 21, 08:34:34, steve wrote:
>>>> I have rebooted with udev_log=debug in /etc/udev/udev.conf. I see
>>>>
>>>> Jan 21 08:15:28 box systemd-udevd[607]: sdc6: Failed to update device symlinks: Too many levels of symbolic links
>>>> Jan 21 08:15:28 box systemd-udevd[607]: sdc6: Preserve already existing symlink '/dev/disk/by-path/pci-0000:00:17.0-ata-2.0-part6' to '../../sdc6'
>>>> Jan 21 08:15:28 box systemd-udevd[607]: sdc6: Preserve already existing symlink '/dev/disk/by-partuuid/7acd2c90-b372-4bfb-a517-e14d2a17e342' to '../../sdc6'
>>>> Jan 21 08:15:28 box systemd-udevd[607]: sdc6: Preserve already existing symlink '/dev/disk/by-path/pci-0000:00:17.0-ata-2-part6' to '../../sdc6'
>>>>
>>>> And the same for other partitions which are all part of a Raid1 array.
>>>> Other partitions are not impacted. So I guess this is related.
>>> Could you inspect the /dev directory from a live image or similar (i.e.
>>> with the affected system not running)?
>> Yes I can do that. What should I look for?
>   
> I'm guessing it should be empty ;)
>
> At least in buster /dev is a 'devtmpfs' mounted over /dev (is this the
> same for you?).
>   
>>> Do you have any custom udev rules or any other custom scripts, services,
>>> etc. plugged into the early startup?
>> Don't know:
>>
>> tree /etc/udev
>> /etc/udev
>> ├── hwdb.d
>> ├── rules.d
>> │   ├── 51-android.rules
>> │   ├── 55-Argyll.rules
>> │   ├── 69-libmtp.rules
>> │   ├── 70-persistent-cd.rules
>> │   └── 70-persistent-net.rules.old
>> └── udev.conf
> Maybe the output of 'udevadm test /sys/block/sdc/sdc6' can provide some
> interesting information, as well as 'ls -l /dev/disk/by-*', otherwise
> I'm out of ideas.
>
> Kind regards,
> Andrei

-- 
Joseph Bryant Martin
USA 804 223-0325
Info Voice
804 334-4309

[toc] | [prev] | [next] | [standalone]

#230978 — Re: remove me from this list

On Fri, 22 Jan 2021 08:02:29 -0500
J B Martin <bryant@ab-domain.com> wrote:

> I do not use this product.
> 
> Please remove my name.
> 
> Thank you.

You can remove yourself. Many mail lists add headers on how to manage
the list to every email, as this list does. Get your mail reader to
display headers (often CTL-h). Then find "List-Unsubscribe:", and send
an email to that email address. Or go to "List-URL:" and do it there.

Also, please don't hijack existing threads. Please start a new thread.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[toc] | [prev] | [next] | [standalone]

#231019 — Re: remove me from this list

Dear Bryant,

If you have subscribed to this list in error (or somebody else has subscribed
you as a prank or whatever) -
You need to send a mail to 

debian-user-REQUEST@lists.debian.org

with the subject

unsubscribe

Note the -REQUEST part of the list address is crucial: the mailing list software will then picl this up. 
This needs to be from the same account that's getting mail from the list.

Note: We will not normally be able to remove all trace of you from the list: 
the lists are archived in various locations around the 'Net so "please remove my name" 
will be ineffective and may be counter-productive.

With every good wish,

Andy Cater

On Fri, Jan 22, 2021 at 08:02:29AM -0500, J B Martin wrote:
> I do not use this product.
> 
> Please remove my name.
> 
> Thank you.
> 
> Bryant Martin
> 
> On 1/22/2021 7:59 AM, Andrei POPESCU wrote:
> > On Vi, 22 ian 21, 08:08:57, steve wrote:
> > > Le 21-01-2021, à 09:45:18 +0200, Andrei POPESCU a écrit :
> > > 
> > > > On Jo, 21 ian 21, 08:34:34, steve wrote:
> > > > > I have rebooted with udev_log=debug in /etc/udev/udev.conf. I see
> > > > > 
> > > > > Jan 21 08:15:28 box systemd-udevd[607]: sdc6: Failed to update device symlinks: Too many levels of symbolic links
> > > > > Jan 21 08:15:28 box systemd-udevd[607]: sdc6: Preserve already existing symlink '/dev/disk/by-path/pci-0000:00:17.0-ata-2.0-part6' to '../../sdc6'
> > > > > Jan 21 08:15:28 box systemd-udevd[607]: sdc6: Preserve already existing symlink '/dev/disk/by-partuuid/7acd2c90-b372-4bfb-a517-e14d2a17e342' to '../../sdc6'
> > > > > Jan 21 08:15:28 box systemd-udevd[607]: sdc6: Preserve already existing symlink '/dev/disk/by-path/pci-0000:00:17.0-ata-2-part6' to '../../sdc6'
> > > > > 
> > > > > And the same for other partitions which are all part of a Raid1 array.
> > > > > Other partitions are not impacted. So I guess this is related.
> > > > Could you inspect the /dev directory from a live image or similar (i.e.
> > > > with the affected system not running)?
> > > Yes I can do that. What should I look for?
> > I'm guessing it should be empty ;)
> > 
> > At least in buster /dev is a 'devtmpfs' mounted over /dev (is this the
> > same for you?).
> > > > Do you have any custom udev rules or any other custom scripts, services,
> > > > etc. plugged into the early startup?
> > > Don't know:
> > > 
> > > tree /etc/udev
> > > /etc/udev
> > > ├── hwdb.d
> > > ├── rules.d
> > > │   ├── 51-android.rules
> > > │   ├── 55-Argyll.rules
> > > │   ├── 69-libmtp.rules
> > > │   ├── 70-persistent-cd.rules
> > > │   └── 70-persistent-net.rules.old
> > > └── udev.conf
> > Maybe the output of 'udevadm test /sys/block/sdc/sdc6' can provide some
> > interesting information, as well as 'ls -l /dev/disk/by-*', otherwise
> > I'm out of ideas.
> > 
> > Kind regards,
> > Andrei
> 
> -- 
> Joseph Bryant Martin
> USA 804 223-0325
> Info Voice
> 804 334-4309
> 

[toc] | [prev] | [next] | [standalone]

#231015

Le 22-01-2021, à 14:59:27 +0200, Andrei POPESCU a écrit :

>On Vi, 22 ian 21, 08:08:57, steve wrote:
>> Le 21-01-2021, à 09:45:18 +0200, Andrei POPESCU a écrit :
>>
>> > On Jo, 21 ian 21, 08:34:34, steve wrote:
>> > > I have rebooted with udev_log=debug in /etc/udev/udev.conf. I see
>> > >
>> > > Jan 21 08:15:28 box systemd-udevd[607]: sdc6: Failed to update device symlinks: Too many levels of symbolic links
>> > > Jan 21 08:15:28 box systemd-udevd[607]: sdc6: Preserve already existing symlink '/dev/disk/by-path/pci-0000:00:17.0-ata-2.0-part6' to '../../sdc6'
>> > > Jan 21 08:15:28 box systemd-udevd[607]: sdc6: Preserve already existing symlink '/dev/disk/by-partuuid/7acd2c90-b372-4bfb-a517-e14d2a17e342' to '../../sdc6'
>> > > Jan 21 08:15:28 box systemd-udevd[607]: sdc6: Preserve already existing symlink '/dev/disk/by-path/pci-0000:00:17.0-ata-2-part6' to '../../sdc6'
>> > >
>> > > And the same for other partitions which are all part of a Raid1 array.
>> > > Other partitions are not impacted. So I guess this is related.
>> >
>> > Could you inspect the /dev directory from a live image or similar (i.e.
>> > with the affected system not running)?
>>
>> Yes I can do that. What should I look for?
>
>I'm guessing it should be empty ;)

…

>At least in buster /dev is a 'devtmpfs' mounted over /dev (is this the
>same for you?).

I have 

mount | grep devtmp
udev on /dev type devtmpfs (rw,nosuid,noexec,relatime,size=16243620k,nr_inodes=4060905,mode=755)


>> > Do you have any custom udev rules or any other custom scripts, services,
>> > etc. plugged into the early startup?
>>
>> Don't know:
>>
>> tree /etc/udev
>> /etc/udev
>> ├── hwdb.d
>> ├── rules.d
>> │   ├── 51-android.rules
>> │   ├── 55-Argyll.rules
>> │   ├── 69-libmtp.rules
>> │   ├── 70-persistent-cd.rules
>> │   └── 70-persistent-net.rules.old
>> └── udev.conf
>
>Maybe the output of 'udevadm test /sys/block/sdc/sdc6' can provide some
>interesting information

Sure, a lot of output. Here is what seems worrying (error or failed
word):

sdc6: /lib/udev/rules.d/64-md-raid-assembly.rules:33 Importing properties from results of '/sbin/mdadm --incremental --export /dev/sdc6 --offroot /dev/disk/by-id/ata-Samsung_SSD_860_EVO_250GB_S3YJNX1K619373P-part6 /dev/disk/by-id/wwn-0x5002538e4051327c-part6 /dev/disk/by-path/pci-0000:00:17.0-ata-2.0-part6 /dev/disk/by-path/pci-0000:00:17.0-ata-2-part6 /dev/disk/by-partlabel/Linux\x20RAID /dev/disk/by-partuuid/7acd2c90-b372-4bfb-a517-e14d2a17e342'
sdc6: Starting '/sbin/mdadm --incremental --export /dev/sdc6 --offroot /dev/disk/by-id/ata-Samsung_SSD_860_EVO_250GB_S3YJNX1K619373P-part6 /dev/disk/by-id/wwn-0x5002538e4051327c-part6 /dev/disk/by-path/pci-0000:00:17.0-ata-2.0-part6 /dev/disk/by-path/pci-0000:00:17.0-ata-2-part6 /dev/disk/by-partlabel/Linux\x20RAID /dev/disk/by-partuuid/7acd2c90-b372-4bfb-a517-e14d2a17e342'
Successfully forked off '(spawn)' as PID 16720.

sdc6: '/sbin/mdadm --incremental --export /dev/sdc6 --offroot /dev/disk/by-id/ata-Samsung_SSD_860_EVO_250GB_S3YJNX1K619373P-part6 /dev/disk/by-id/wwn-0x5002538e4051327c-part6 /dev/disk/by-path/pci-0000:00:17.0-ata-2.0-part6 /dev/disk/by-path/pci-0000:00:17.0-ata-2-part6 /dev/disk/by-partlabel/Linux\x20RAID /dev/disk/by-partuuid/7acd2c90-b372-4bfb-a517-e14d2a17e342'(err) 'mdadm: cannot reopen /dev/sdc6: Device or resource busy.'

sdc6: Process '/sbin/mdadm --incremental --export /dev/sdc6 --offroot /dev/disk/by-id/ata-Samsung_SSD_860_EVO_250GB_S3YJNX1K619373P-part6 /dev/disk/by-id/wwn-0x5002538e4051327c-part6 /dev/disk/by-path/pci-0000:00:17.0-ata-2.0-part6 /dev/disk/by-path/pci-0000:00:17.0-ata-2-part6 /dev/disk/by-partlabel/Linux\x20RAID /dev/disk/by-partuuid/7acd2c90-b372-4bfb-a517-e14d2a17e342' failed with exit code 1.

sdc6: /lib/udev/rules.d/64-md-raid-assembly.rules:33 Command "/sbin/mdadm --incremental --export /dev/sdc6 --offroot /dev/disk/by-id/ata-Samsung_SSD_860_EVO_250GB_S3YJNX1K619373P-part6 /dev/disk/by-id/wwn-0x5002538e4051327c-part6 /dev/disk/by-path/pci-0000:00:17.0-ata-2.0-part6 /dev/disk/by-path/pci-0000:00:17.0-ata-2-part6 /dev/disk/by-partlabel/Linux\x20RAID /dev/disk/by-partuuid/7acd2c90-b372-4bfb-a517-e14d2a17e342" returned 1 (error), ignoring




> as well as 'ls -l /dev/disk/by-*', otherwise I'm out of ideas.

There's a lot there and nothing looking bad at first sight.

[toc] | [prev] | [next] | [standalone]

#230959

On Thu 21 Jan 2021 at 08:34:34 (+0100), steve wrote:
> I have rebooted with udev_log=debug in /etc/udev/udev.conf. I see
> 
> Jan 21 08:15:28 box systemd-udevd[607]: sdc6: Failed to update device symlinks: Too many levels of symbolic links
> Jan 21 08:15:28 box systemd-udevd[607]: sdc6: Preserve already existing symlink '/dev/disk/by-path/pci-0000:00:17.0-ata-2.0-part6' to '../../sdc6'
> Jan 21 08:15:28 box systemd-udevd[607]: sdc6: Preserve already existing symlink '/dev/disk/by-partuuid/7acd2c90-b372-4bfb-a517-e14d2a17e342' to '../../sdc6'
> Jan 21 08:15:28 box systemd-udevd[607]: sdc6: Preserve already existing symlink '/dev/disk/by-path/pci-0000:00:17.0-ata-2-part6' to '../../sdc6'
> 
> And the same for other partitions which are all part of a Raid1 array.
> Other partitions are not impacted. So I guess this is related.
> 
> But I'm blocked now.

You said it's working, so that's a good thing. But I can't help
wondering whether there's some mistake in the way your raid is
configured—a part that perhaps aids monitoring it rather than
being essential to its assembly.

Not that it would help me at all (I haven't used raid), but
perhaps you could show how your raid is configured, for others
to cast an eye over. Experienced raiders might spot something.

I always archive the output of udevadm for my disks (actually
I just copy the /run/udev/data/b8\:* files). Does mdadm have a
equivalent manner of displaying its configuration?

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#230961

Hi,

Le 21-01-2021, à 20:41:05 -0600, David Wright a écrit :

>On Thu 21 Jan 2021 at 08:34:34 (+0100), steve wrote:
>> I have rebooted with udev_log=debug in /etc/udev/udev.conf. I see
>>
>> Jan 21 08:15:28 box systemd-udevd[607]: sdc6: Failed to update device symlinks: Too many levels of symbolic links
>> Jan 21 08:15:28 box systemd-udevd[607]: sdc6: Preserve already existing symlink '/dev/disk/by-path/pci-0000:00:17.0-ata-2.0-part6' to '../../sdc6'
>> Jan 21 08:15:28 box systemd-udevd[607]: sdc6: Preserve already existing symlink '/dev/disk/by-partuuid/7acd2c90-b372-4bfb-a517-e14d2a17e342' to '../../sdc6'
>> Jan 21 08:15:28 box systemd-udevd[607]: sdc6: Preserve already existing symlink '/dev/disk/by-path/pci-0000:00:17.0-ata-2-part6' to '../../sdc6'
>>
>> And the same for other partitions which are all part of a Raid1 array.
>> Other partitions are not impacted. So I guess this is related.
>>
>> But I'm blocked now.
>
>You said it's working, so that's a good thing. But I can't help
>wondering whether there's some mistake in the way your raid is
>configured—a part that perhaps aids monitoring it rather than
>being essential to its assembly.
>
>Not that it would help me at all (I haven't used raid), but
>perhaps you could show how your raid is configured, for others
>to cast an eye over. Experienced raiders might spot something.

cat /proc/mdstat
Personalities : [raid1] [linear] [multipath]
md1 : active raid1 sdg5[3] sdc5[5] sdd5[4]
       117120896 blocks super 1.2 [3/3] [UUU]

md0 : active raid1 sdg1[3] sdc1[5] sdd1[4]
       19514240 blocks super 1.2 [3/3] [UUU]

md2 : active raid1 sdg6[3] sdc6[5] sdd6[4]
       97589120 blocks super 1.2 [3/3] [UUU]

unused devices: <none>


and


cat /etc/mdadm/mdadm.conf
# mdadm.conf
#
# Please refer to mdadm.conf(5) for information about this file.
#

# by default (built-in), scan all partitions (/proc/partitions) and all
# containers for MD superblocks. alternatively, specify devices to scan, using
# wildcards if desired.
#DEVICE partitions containers

# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes

# automatically tag new arrays as belonging to the local system
HOMEHOST <system>

# instruct the monitoring daemon where to send mail alerts
MAILADDR root

# definitions of existing MD arrays
ARRAY /dev/md/0 metadata=1.2 name=paros:0 UUID=9bb7d2a7:e96b5e9e:54c12ef1:4e8992fc
ARRAY /dev/md/1 metadata=1.2 name=paros:1 UUID=be24cc5a:5a29d2b8:10385878:4ae00056
ARRAY /dev/md/2 metadata=1.2 name=paros:2 UUID=78920a51:c8858cf6:a6027ee6:a016643e


>I always archive the output of udevadm for my disks (actually
>I just copy the /run/udev/data/b8\:* files).

I don't understand.

Thanks.

[toc] | [prev] | [next] | [standalone]

#230980

On Fri 22 Jan 2021 at 08:06:37 (+0100), steve wrote:
> Le 21-01-2021, à 20:41:05 -0600, David Wright a écrit :
> 
> > I always archive the output of udevadm for my disks (actually
> > I just copy the /run/udev/data/b8\:* files).
> 
> I don't understand.

I keep a log for each of my hard drives, its acquisition, SMART
history, partitioning, filesystems, usage, problems, etc.
At the end of my opinions come the facts, the output of
udevadm info --query=all --name=/dev/sdX    and
udevadm info --query=all --name=/dev/sdXN   for all N.
By that means, I have information available for a drive even
when its host is powered off, or the drive is in storage.

When I edit said log file on the system that it attaches to,
I could update all the udevadm information by removing the
old version and then appending it again by running udevadm
several times. But instead I usually copy in the appropriate
subset of files /run/udev/data/b8\:* that contain almost all
the same information, just for convenience as I'm already in
an editor. Here's a small sample (pruned with grep) of that
information being obtained from each of those sources:

$ for j in '' 1 2 3 4 5 6 ; do udevadm info --query=all --name=/dev/sda$j ; done | grep -e 'ID_FS_UUID='
E: ID_FS_UUID=9a3fa215-a749-47f4-a33e-5708097634b2
E: ID_FS_UUID=10358228-7f4b-49ec-8864-2547e27bccdb
E: ID_FS_UUID=33c3cbeb-ee4b-4a21-9899-49e546f024de
E: ID_FS_UUID=98f15f4c-e3fc-45f3-aa15-3774e012e996
$ 

$ grep -e 'ID_FS_UUID=' /run/udev/data/b8\:?
/run/udev/data/b8:3:E:ID_FS_UUID=9a3fa215-a749-47f4-a33e-5708097634b2
/run/udev/data/b8:4:E:ID_FS_UUID=10358228-7f4b-49ec-8864-2547e27bccdb
/run/udev/data/b8:5:E:ID_FS_UUID=33c3cbeb-ee4b-4a21-9899-49e546f024de
/run/udev/data/b8:6:E:ID_FS_UUID=98f15f4c-e3fc-45f3-aa15-3774e012e996
$ 

> > Does mdadm have a
> > equivalent manner of displaying its configuration?

Not having used it, I wondered whether mdadm could effortlessly
"brain-dump" in a similar manner to either of these methods.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | linux.debian.user

csiph-web