Hi,
F21, fully updated, no longer boots cleanly. After to tries, I found the culprit:
suddenly, the physical device (/dev/sda) has got a UUID, and it's the same as the one /home has. So no wonder that /home can't be mounted. I have not the slightest clue what could have given /dev/sda a UUID.
So how to remove it?
Thanks, Heinz.
I don't know about removing a UUID, but you can assign a new one with GParted.
Sent from my iPhone
On Mar 20, 2015, at 10:49 AM, Heinz Diehl htd+ml@fritha.org wrote:
Hi,
F21, fully updated, no longer boots cleanly. After to tries, I found the culprit:
suddenly, the physical device (/dev/sda) has got a UUID, and it's the same as the one /home has. So no wonder that /home can't be mounted. I have not the slightest clue what could have given /dev/sda a UUID.
So how to remove it?
Thanks, Heinz.
-- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
On 03/20/2015 10:49 AM, Heinz Diehl wrote:
Hi,
F21, fully updated, no longer boots cleanly. After to tries, I found the culprit:
suddenly, the physical device (/dev/sda) has got a UUID, and it's the same as the one /home has. So no wonder that /home can't be mounted. I have not the slightest clue what could have given /dev/sda a UUID.
So how to remove it?
Thanks, Heinz.
uuid is the way to go!!! It assures that the drive may be connected to any of the ports of a computer and it will still get mounted on the same mountpoint listed in /etc/fstab.
On 03/20/2015 12:49 PM, Heinz Diehl wrote:
Hi,
F21, fully updated, no longer boots cleanly. After to tries, I found the culprit:
suddenly, the physical device (/dev/sda) has got a UUID, and it's the same as the one /home has. So no wonder that /home can't be mounted. I have not the slightest clue what could have given /dev/sda a UUID.
So how to remove it?
Thanks, Heinz.
vi /etc/fstab probably.. ls -l /dev/disk/by-uuid |grep UUID to see what UUID's are there, not sure which one you have for /home.
ls -l /dev/disk/by-uuid|grep sdb4 lrwxrwxrwx 1 root root 10 Mar 18 15:37 0514b132-c06e-4b52-8c15-82a5ff272e40 -> ../../sdb4
mine looks like this: grep /home /etc/fstab UUID=0514b132-c06e-4b52-8c15-82a5ff272e40 /home ext4 defaults 1 2
On 20.03.2015, Ron Morse wrote:
I don't know about removing a UUID, but you can assign a new one with GParted.
Yes. But I was curious what could have assigned a UUID to /dev/sda. And I found it. Making a nilfs2 partition on /home the evening before, lsblk -f reported the same UUID for /dev/sda and /dev/sda4!
After reformatting /home with good ol' XFS and a reboot, /dev/sda no longer has any UUID, and all is good.
Now that was REALLY weird. WTF??
Looks like a serious problem with nilfs-tools.
On Fri, Mar 20, 2015 at 10:49 AM, Heinz Diehl htd+ml@fritha.org wrote:
Hi,
F21, fully updated, no longer boots cleanly. After to tries, I found the culprit:
suddenly, the physical device (/dev/sda) has got a UUID, and it's the same as the one /home has. So no wonder that /home can't be mounted. I have not the slightest clue what could have given /dev/sda a UUID.
So how to remove it?
If /dev/sda uses MBR, it doesn't really have a UUID, it might have a serial number. If /dev/sda uses GPT, it has a UUID and it should have a UUID and it shouldn't be removed. A UUID doesn't just somehow accidentally transfer from one fs volume to another, or from an fs to a partition table. I think think needs more troubleshooting, rather than bringing out the hammer before the problem is identified.
Feel free to post the results from fstab, and blkid.
It might also be useful to see the output from journalctl -b -l -o short monotonic, from a boot that fails, that also has kernel parameter rd.debug set.
On 20.03.2015, Chris Murphy wrote:
If /dev/sda uses MBR, it doesn't really have a UUID, it might have a serial number.
It's MBR, and it didn't have a UUID before.
I think think needs more troubleshooting, rather than bringing out the hammer before the problem is identified. Feel free to post the results from fstab, and blkid.
I'm nearly done with debugging, and are 99% sure it's a systemd problem. What happens is that when /home is nilfs2 formatted, systemd sees the identical UUID assigned to /dev/sda, and the systemd service fails to mount /home because it tries to mount /dev/sda rather than the correct partition /dev/sdaX.
Reformatting with either ext4 or xfs solves the problem immediately. Btw: lsblk -f shows the faulty UUID assigned to /dev/sda, while blkid does not.
On Fri, Mar 20, 2015 at 11:59 PM, Heinz Diehl htd+ml@fritha.org wrote:
On 20.03.2015, Chris Murphy wrote:
If /dev/sda uses MBR, it doesn't really have a UUID, it might have a serial number.
It's MBR, and it didn't have a UUID before.
I think think needs more troubleshooting, rather than bringing out the hammer before the problem is identified. Feel free to post the results from fstab, and blkid.
I'm nearly done with debugging, and are 99% sure it's a systemd problem. What happens is that when /home is nilfs2 formatted, systemd sees the identical UUID assigned to /dev/sda, and the systemd service fails to mount /home because it tries to mount /dev/sda rather than the correct partition /dev/sdaX.
Reformatting with either ext4 or xfs solves the problem immediately. Btw: lsblk -f shows the faulty UUID assigned to /dev/sda, while blkid does not.
I don't think systemd has any concept of filesystems (volume formats). It gets all of this from libblkid, udev, and the kernel. So I'd say one of those three things is confused, and then confuses everything else.
The fact you get a difference in output between lsblk and blkid is itself a bug. I'd file it against libblkid and then include the bug URL here.
OK I think I found the problem. The Fedora kernel doesn't come with nilfs2 kernel module. At least, a default Fedora 22 installation doesn't include it.
Chris Murphy
On 21.03.2015, Chris Murphy wrote:
I don't think systemd has any concept of filesystems (volume formats). It gets all of this from libblkid, udev, and the kernel. So I'd say one of those three things is confused, and then confuses everything else.
Didn't have much time today to further debug this thing, but I can confirm that "something" is getting confused when rebooting for the first time with the new partition.
Precisely: when I reformat /home with nilfs2 and check the assigned UUID afterward, all is good. No /dev/sda with an erroneous UUID. Then I reboot, and systemd claims it can't mount /home because "/dev/sda is busy". After dropping into runlevel 1, lsblk shows why: now /dev/sda has the same UUID as /home, and of course can't /dev/sda not be mounted.
So whatever it is in the system that can't handle a nilfs2 mount wrecks it here. Will dig further into it, but it seems like it's systemd itself. I took a look into the systemd source, and it uses common /bin/mount to mount the filesystems. Manually mounting /home and going to runlevel 5 works flawlessly. Something in the boot process is wrong.
The fact you get a difference in output between lsblk and blkid is itself a bug.
I'm afraid it isn't, because blkid doesn't show the toplevel physical device, while lsblk -f does. Anyway, that's obviously not the problem here. Something claims /dev/sda has the same UUID as /home, and then systemd looks up the UUID, grabs the first assigned device and tries to mount it. And I don't get why the f*ck /dev/sda should have a UUID or what wrecks it..
On 21.03.2015, Chris Murphy wrote:
OK I think I found the problem. The Fedora kernel doesn't come with nilfs2 kernel module. At least, a default Fedora 22 installation doesn't include it.
I don't use any distribution kernel. My kernel has nilfs2 - definitely. A manual mount works perfectly, just on boot /home doesn't get mounted and the system boots into emergency shell.
On Sat, Mar 21, 2015 at 11:52 AM, Heinz Diehl htd+ml@fritha.org wrote:
I don't use any distribution kernel. My kernel has nilfs2 - definitely. A manual mount works perfectly, just on boot /home doesn't get mounted and the system boots into emergency shell.
OK it's a little annoying when you provide so little information from the very start about what you're trying to do, and what the setup is, and now you're not even using a Fedora kernel. It's sorta important information to say upfront when you're having a problem. I don't really know what state your system is in now to even have a chance of reproducing the problem.
When I install kernel-modules-extras, nilfs2 on /home works for me, I don't have duplicate UUIDs, and boot doesn't fail when trying to mount home. *shrug*
/dev/sda2 on / type xfs (rw,relatime,seclabel,attr2,inode64,noquota) /dev/sda3 on /home type nilfs2 (rw,relatime) /dev/sda1 on /boot type xfs (rw,relatime,seclabel,attr2,inode64,noquota)
# df -h Filesystem Size Used Avail Use% Mounted on /dev/sda2 50G 4.0G 47G 8% / /dev/sda3 28G 16M 27G 1% /home /dev/sda1 497M 153M 344M 31% /boot
# lsblk -f NAME FSTYPE LABEL UUID MOUNTPOINT sda ├─sda1 xfs 9f5d6b34-7c6f-4e6c-996e-122f5b68e1f8 /boot ├─sda2 xfs f1da5867-6fd3-4e36-9c1c-76baac13dd1d / ├─sda3 nilfs2 2e2ef4de-13df-41d2-9e2e-593dfd42fb64 /home ├─sda4 └─sda5 swap 94516b4e-5b60-436a-8783-d168210d1bf2 [SWAP] sr0
# blkid /dev/sda1: UUID="9f5d6b34-7c6f-4e6c-996e-122f5b68e1f8" TYPE="xfs" PARTUUID="a00446cc-01" /dev/sda2: UUID="f1da5867-6fd3-4e36-9c1c-76baac13dd1d" TYPE="xfs" PARTUUID="a00446cc-02" /dev/sda3: UUID="2e2ef4de-13df-41d2-9e2e-593dfd42fb64" TYPE="nilfs2" PARTUUID="a00446cc-03" /dev/sda5: UUID="94516b4e-5b60-436a-8783-d168210d1bf2" TYPE="swap" PARTUUID="a00446cc-05"
# cat /etc/fstab UUID=f1da5867-6fd3-4e36-9c1c-76baac13dd1d / xfs defaults 0 0 UUID=9f5d6b34-7c6f-4e6c-996e-122f5b68e1f8 /boot xfs defaults 0 0 UUID=2e2ef4de-13df-41d2-9e2e-593dfd42fb64 /home nilfs2 defaults 0 0 #UUID=0bc7066a-b8f1-4949-b480-3775dd5efec4 /home xfs defaults 0 0 UUID=94516b4e-5b60-436a-8783-d168210d1bf2 swap swap defaults 0 0
On Sat, Mar 21, 2015 at 12:11 PM, jd1008 jd1008@gmail.com wrote:
On 03/21/2015 11:51 AM, Chris Murphy wrote:
OK I think I found the problem. The Fedora kernel doesn't come with nilfs2 kernel module. At least, a default Fedora 22 installation doesn't include it.
Chris Murphy
Did it ever?? Which was the last release that had it?
I found it in kernel-modules-extra (not extras as I wrote earlier) for both 3.19.2 and 4.0.0; I have no idea what the history is, whether that module has been in some other package before the kernel packaging changes for F21.
On 21.03.2015, Chris Murphy wrote:
OK it's a little annoying when you provide so little information from the very start about what you're trying to do, and what the setup is, and now you're not even using a Fedora kernel.
My original posting was kinda sort of "does this ring a bell?". Otherwise I would have filed a bug report. It's not that important to me. Was just curious why it failed. Btw: tried it on my Arch machine, and it works.
What I did was:
1. Booting into rl 1 2. Backup /home (with rsync) 3. mkfs -t nilfs2 /dev/sdaX 4. Restoring /home 5. Fixing fstab with the correct UUID for /home 6. Reboot
It's sorta important information to say upfront when you're having a problem. I don't really know what state your system is in now to even have a chance of reproducing the problem.
My system is fine, and the phenomenon is 100% replicable. And the behaviour is the same with the latest Fedora kernel from the Fedora update repo.
When I install kernel-modules-extras, nilfs2 on /home works for me, I don't have duplicate UUIDs, and boot doesn't fail when trying to mount home. *shrug*
Just curious: does cleanerd get invoked when /home is mounted at boot time?
On 03/21/2015 02:04 PM, Heinz Diehl wrote:
My system is fine, and the phenomenon is 100% replicable. And the behaviour is the same with the latest Fedora kernel from the Fedora update repo.
One other thing you can do is give the partition a label, and list the label in fstab instead. That way, you don't have to care what the system thinks the UUID is.
On 03/21/2015 02:25 PM, Chris Murphy wrote:
I found it in kernel-modules-extra (not extras as I wrote earlier) for both 3.19.2 and 4.0.0; I have no idea what the history is, whether that module has been in some other package before the kernel packaging changes for F21.
My F19 system has it in kernel-modules-extra as well, so its been in there for a while....
On 21.03.2015, Chris Murphy wrote:
OK it's a little annoying when you provide so little information from the very start about what you're trying to do, and what the setup is,
Here's what lsblk says before formatting:
AME FSTYPE LABEL UUID MOUNTPOINT sda ├─sda1 ext4 6cb0a099-3037-4b82-87ad-e4058dc8944c /boot ├─sda2 xfs 5a16b831-b896-437c-8b8c-95d600ce90e0 / ├─sda3 swap 3f579e51-577f-4f8b-975c-d58aa3063f7e [SWAP] └─sda4 xfs 1dc70566-e597-4c1a-baa8-c652b79c2010 /home sr0
And here afterwards:
AME FSTYPE LABEL UUID MOUNTPOINT sda nilfs2 190d8a5e-81c3-461a-8602-1d67a01b59f3 ├─sda1 ext4 6cb0a099-3037-4b82-87ad-e4058dc8944c /boot ├─sda2 xfs 5a16b831-b896-437c-8b8c-95d600ce90e0 / ├─sda3 swap 3f579e51-577f-4f8b-975c-d58aa3063f7e [SWAP] └─sda4 nilfs2 190d8a5e-81c3-461a-8602-1d67a01b59f3 /home sr0
And this is systemd complaining that it can't mount /dev/sda:
[....] Mar 20 17:11:27 ayna systemd: Mounting /home... Mar 20 17:11:27 ayna kernel: Bluetooth: SCO socket layer initialized Mar 20 17:11:28 ayna kernel: usbcore: registered new interface driver btusb Mar 20 17:11:28 ayna kernel: NILFS version 2 loaded Mar 20 17:11:28 ayna systemd: home.mount mount process exited, code=exited status=32 Mar 20 17:11:28 ayna mount: mount.nilfs2: Error while mounting /dev/sda on /home: Device or resource busy Mar 20 17:11:28 ayna systemd: Failed to mount /home. Mar 20 17:11:28 ayna systemd: Dependency failed for Local File Systems. Mar 20 17:11:28 ayna systemd: Mar 20 17:11:28 ayna systemd: Triggering OnFailure= dependencies of local-fs.target. Mar 20 17:11:28 ayna systemd: Unit home.mount entered failed state. [....]
I do nothing more than booting into rl 1, formatting /home with nilfs2, set up the correct UUID in fstab, and so reboot. Formatting /home with ext4 or xfs works as expected, the UUID assigned to /dev/sda vanishes.
-
Chris Murphy -
Heinz Diehl -
JD -
Joe Zeff -
Kevin Cummings -
Paul Cartwright -
Ronal B Morse