linux-kernel - Re: NILFS2: double uuid

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150608100835.GA16569@fritha.org>
Date:	Mon, 8 Jun 2015 12:08:35 +0200
From:	Heinz Diehl <htd+ml@...tha.org>
To:	linux-kernel@...r.kernel.org
Cc:	Ryusuke Konishi <konishi.ryusuke@....ntt.co.jp>,
	linux-nilfs@...r.kernel.org
Subject: Re: NILFS2: double uuid

On 08.06.2015, Heinz Diehl wrote: 

To be more precise, here's what works and what don't, in detail
(and after a fresh install of Arch):

The USB memory is xfs formatted and works fine:

[root@...rmpi /]# lsblk -f
NAME        FSTYPE LABEL UUID                                 MOUNTPOINT
sda                                                           
`-sda1      xfs          ff17dda9-fcae-42e7-a438-9087de58902e 
mmcblk0                                                       
|-mmcblk0p1 vfat         EA5B-4477                            /boot
`-mmcblk0p2 ext4         c4ddc925-15ab-4465-ac78-967a845e98d5 /


Now, it's nilfs2 formatted:

[root@...rmpi /]# mkfs.nilfs2 /dev/sda1
WARNING: Device /dev/sda1 appears to contain an existing xfs superblock.
WARNING: All data will be lost after format!

DO YOU REALLY WANT TO FORMAT DEVICE /dev/sda1?

Continue? [y/N] y
mkfs.nilfs2 (nilfs-utils 2.2.3)
Start writing file system initial data to the device
       Blocksize:4096  Device:/dev/sda1  Device Size:32026656768
File system initialization succeeded !! 

After that, all seems to be ok. lsblk shown no double uuid:

[root@...rmpi /]# lsblk -f
NAME        FSTYPE LABEL UUID                                 MOUNTPOINT
sda                                                           
`-sda1      nilfs2       98da384c-392e-4551-98c0-d076524f5d8b 
mmcblk0                                                       
|-mmcblk0p1 vfat         EA5B-4477                            /boot
`-mmcblk0p2 ext4         c4ddc925-15ab-4465-ac78-967a845e98d5 /
[root@...rmpi /]# 


Now the USB drive gets manually mounted, all is ok:

[root@...rmpi /]# mount /dev/sda1 /USBDRIVE
[root@...rmpi /]# lsblk -f
NAME        FSTYPE LABEL UUID                                 MOUNTPOINT
sda                                                           
`-sda1      nilfs2       98da384c-392e-4551-98c0-d076524f5d8b /USBDRIVE
mmcblk0                                                       
|-mmcblk0p1 vfat         EA5B-4477                            /boot
`-mmcblk0p2 ext4         c4ddc925-15ab-4465-ac78-967a845e98d5 /


Now, the newly formatted drive is registered in fstab to be
automatically mounted on boot:

UUID=ff17dda9-fcae-42e7-a438-9087de58902e	/USBDRIVE	nilfs2	defaults	0	0

After rebooting the machine, nothing is mounted, and lsblk shows the
double uuid:

[root@...rmpi /]# lsblk -f
NAME        FSTYPE LABEL UUID                                 MOUNTPOINT
sda                      98da384c-392e-4551-98c0-d076524f5d8b 
`-sda1      nilfs2       98da384c-392e-4551-98c0-d076524f5d8b
mmcblk0                                                       
|-mmcblk0p1 vfat         EA5B-4477                            /boot
`-mmcblk0p2 ext4         c4ddc925-15ab-4465-ac78-967a845e98d5 /

The logs say:

Jun 08 11:23:47 alarmpi mount: mount.nilfs2: Error while mounting /dev/sda on /USBDRIVE: Device or resource busy
Jun 08 11:23:47 alarmpi systemd: Failed to mount /USBDRIVE.

Here it becomes clear what happens: the system wants to mount /dev/sda
rather than /dev/sda1, and thus fails.

Out of curiosity, I tried both xfs, ext4 and btrfs, and all of them
just work.

Thanks,
Heinz.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/