and the multipath delete code is in udev so if you search udev then
the code doing it should be in there. And I would think anyone else's
partition mapping deletes would be in there.
On Wed, Mar 3, 2021 at 11:22 AM Roger Heflin <rogerheflin(a)gmail.com> wrote:
>
> That looks like multipath is blacklisted.
>
> you might to a lsinitrd | grep -i multipath and make sure it is not in
> the initrd with a config file.
>
> multipath is the only service I have seen that actually deletes
> partition mappings, but it is possible that some of the other dm*
> stuff might (dm-raid maybe?)..
>
> On Wed, Mar 3, 2021 at 6:35 AM GianPiero Puccioni
> <gianpiero.puccioni(a)isc.cnr.it> wrote:
> >
> > On 3/3/21 12:39 PM, Roger Heflin wrote:
> > > Blacklist the wwwid in multipath.conf and/or blacklist the disk type
> > > in multipath.
> > >
> > > And/or whitelist the disks you want multipath to manage.
> > >
> > > If all of your disks have 2 paths and are expected to have 2 paths
> > > then you can set file_multipaths to only manage devices with 2 paths,
> > > but to make multipath work right in the one path case the disks need
> > > to be listed in the bindings file.
> > >
> > I am not sure I understand any of this, as shown before I have only 1 disk with
> > sda 8:0 0 931.5G 0 disk
> > ├─sda1 8:1 0 1G 0 part
> > └─sda2 8:2 0 930.5G 0 part
> > ├─fedora_node06-root 253:0 0 50G 0 lvm /
> > ├─fedora_node06-swap 253:1 0 4G 0 lvm [SWAP]
> > └─fedora_node06-home 253:2 0 876.5G 0 lvm /home
> >
> > So I think that sda2 is managed by multipath but sda1 is not.
> > I do not have a multipath.conf and "multipath -t" writes A LOT of
stuff, while
> > "multipath show config" gives:
> > Mar 03 13:29:38 | /etc/multipath.conf does not exist, blacklisting all devices.
> > Mar 03 13:29:38 | You can run "/sbin/mpathconf --enable" to create
> > Mar 03 13:29:38 | /etc/multipath.conf. See man mpathconf(8) for more details
> > Mar 03 13:29:38 | DM multipath kernel driver not loaded
> >
> > Not sure what this means or what is the proper way to do what you said.
> >
> > > The short term is add ,nofail to the options on the mount then it will
> > > always boot up but may not mount /boot. But make sure /boot is
> > > mounted when doing the things mentioned below.
> > >
> > > The bios finds the data on /boot and puts what is needed to boot into
> > > memory, once that is done you really only need /boot on the machine if
> > > you are updating kernels/changing grub options/rebuilding initrds.
> > >
> > Yes that was why I did not things stay the way they are, after all it works.
> > One possibility could be to use an rc.local (the systemd equivalent or a proper
> > service) to run "partprobe" and "mount" at start, would this
work?
> >
> > GiP
> >
> >
> > > On Wed, Mar 3, 2021 at 4:19 AM GianPiero Puccioni
> > > <gianpiero.puccioni(a)isc.cnr.it> wrote:
> > >>
> > >> On 3/2/21 10:24 PM, Jorge Fábregas wrote:
> > >>> On 3/2/21 5:04 PM, GianPiero Puccioni wrote:
> > >>>> so it is there and seen but why the block device is not
created? Copying
> > >>>> the content of (sda1)boot into /boot and reinstalling grub
could probably
> > >>>> work but how?
> > >>>
> > >>> Hi GianPiero,
> > >>>
> > >>> This is strange. I don't know why there's no device file
for the first
> > >>> partition (/dev/sda1). Can you try "partprobe /dev/sda"
to see if it creates
> > >>> the file?
> > >>
> > >> Thanks all for the help
> > >>
> > >> I didn't know this command (never neded it..) but yes, it did
create the file
> > >> now I have
> > >> # ls /dev/sd*
> > >> /dev/sda /dev/sda1 /dev/sda2
> > >>
> > >> and "blkid" has
> > >> /dev/sda1: UUID="f365a320-f3d7-4c07-8bfb-f0164b9ce8c0"
BLOCK_SIZE="4096"
> > >> TYPE="xfs" PARTUUID="6ccdd7fd-01"
> > >> that wasn't there before.
> > >>
> > >>> Are you sure /dev/sda1 was used for /boot ?
> > >> I think so(it was the partion marked as bootable), and now that I can
mount it I
> > >> can see that all the usal /boot stuff is there.
> > >> Can you
> > >>> show the output of "cat /proc/cmdline"?
> > >>>
> > >> # cat /proc/cmdline
> > >> BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.10.19-200.fc33.x86_64
> > >> root=/dev/mapper/fedora_node06-root ro
resume=/dev/mapper/fedora_node06-swap
> > >> rd.lvm.lv=fedora_node06/root rd.lvm.lv=fedora_node06/swap rhgb quiet
> > >>
> > >> As Roger said the problem seems to be multipath but
> > >> if there is no fix to the fact that sda1 disappeared (any idea?)
> > >> I suppose the solution now could be to copy all the stuff from sda1 in
/boot and
> > >> recreate grub in sda ignoring sda1. Unless it needs a separate /boot, I
think
> > >> UEFI is disabled but I am not sure, or for the weird RAID stuff.
> > >>
> > >> As I said I am doing all this remotely so I have to be careful not to
break the
> > >> boot.
> > >>
> > >> Thanks again.
> > >>
> > >> GiP
> > >> _______________________________________________
> > >> users mailing list -- users(a)lists.fedoraproject.org
> > >> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
> > >> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > >> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> > >> List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
> > >> Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
> > > _______________________________________________
> > > users mailing list -- users(a)lists.fedoraproject.org
> > > To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
> > > Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
> > > Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
> > >
> >
> >
> > --
> > GianPiero Puccioni |Istituto dei Sistemi Complessi-CNR
> > gianpiero.puccioni(a)isc.cnr.it |Via Madonna del Piano, 10
> > T:+39 0555226682 |50019 Sesto F. (Firenze) ITALY
> > _______________________________________________
> > users mailing list -- users(a)lists.fedoraproject.org
> > To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
> > Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
> > Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure