Created attachment 2234 [details]
diskdrake fail finding /dev/mapper mounts /home and /

If this situation appears, this is how to fix it (tested now):
(of course first a full backup/disk image is always good, and copy of fstab)

In diskdrake set the mount points for partitions that seem to miss it.
Diskdrake will tell the mount point already have content and ask if to copy or overwrite (mount over).  Select the latter (not copy!)
Let it write fstab.  Check fstab manually.
Partitions in LVM are identified in the /dev/vg-mga/logicalname style.
After reboot all is OK, diskdrake shows mount points and resize etc works.

Did you select install or upgrade?

If you select install, it will ignore the existing fstab, and overwrite it
using the partitions and mount points you select.

Using uuid instead of /dev entry shouldn't matter.

CC: (none) => davidwhodgins

I chosed install, custom partitioning, and pointed at the mount points for existing /home and / in the LVM.

Now i have checked that in the original system that i cloned
(cauldron installed a few months ago)
the / and /home mount points contain /mapper/
and currently diskdrake on that system too fail to find and show them.

Possibly the installer make /mapper/ mount points?

I now have fount that the same difference in mount points cause
Bug 5793 - "Oops no root partition" upgrading system using LVM

Hi,

This bug was filed against cauldron, but we do not have cauldron at the moment.

Please report whether this bug is still valid for Mageia 2.

Thanks :)

Cheers,
marja

Keywords: (none) => NEEDINFO

@ Morgan

This bug was filed agains old cauldron, from before Mageia 2 release

It is very important for us to know whether this bug is valid for Mageia 2 and/or for *current* cauldron.

Please tell us within two weeks from now. If you don't reply again, we'll have to close this bug as old.

CC: (none) => marja11

Too late i think.. but i someone really wants to look into this i can see if i can dig up the disk image and redo the test.
Same goes for Bug 5793
Probably it is faster for the programmer to see how diskdrake differ in recognizing existing dev/mapper and just /mapper partitions.

(In reply to comment #9)
> Too late i think.. but i someone really wants to look into this i can see if i
> can dig up the disk image and redo the test.

> Probably it is faster for the programmer to see how diskdrake differ in
> recognizing existing dev/mapper and just /mapper partitions.

@ pterjan

assigning to you so you can decide whether you want to do that, or want Morgan to redo the test

Please set status to assigned or put OK on the whiteboard if you agree with the assignment (and reassign if not)

Keywords: NEEDINFO => (none)
Assignee: bugsquad => pterjan
Source RPM: (none) => drakxtools

"Test" redone ( cough... actually i forgot about this bug...)
on two fully updated mga2 machines:
A) below i think is the same as i wrote about here, mga2-32
B) is fresh install mga2-64

____Procedure:

1) Both machines are working great, including sucessfully using NFS shares i have added manually to fstab.

2) I added a NFS share using mcc->Network sharing->Connect to NFS shares (translated)

3) Boot fail with a lengthy text message graphic mode could not be started.
Closer investigation shows /home is not mounted and / is readonly
If i press escape when the cauldron shows up, i can see that boot starts normally, but then there are so many FAILED passing fast that neither me nor my camera can catch, but i think i read in the beginning like it failed to load NFS module or something. But i believe it is because the real / is not mounted correctly.


____Machines:

A: Laptop T40, Fully updated mga2-32 that have been in use a while, Using LVM fo /, /home, swap.

B: Laptop T61, fresh install mga 32-64 a couple week ago, configured like above but LVM is encrypted making it harder to work with... 


____Remedies:

I have now used a live system (sysresccd.org) to on machine A restore the old fstab containing hte / and /home mounts, plus copyining in the new NFS share manually and it boots and works OK.

But i do not understand how it managed to boot so far as it did wihout / in fstab?

Now I am reading up on how to mount encrypted LVM for machine B...

Created attachment 3349 [details]
fstab before breaking, machine A

Created attachment 3350 [details]
fstab after mcc wrecked it, machine A

CC Colin as i see he is on other recent NFS issue.

CC: (none) => mageia

Created attachment 3351 [details]
fstab working before breaking, machine B

Created attachment 3352 [details]
fstab broken by mcc, machine B

To replicate the problem:
Machine B is a fresh network install made late in december.
To repeat the problem you can probably do like I did, but it seems from machine A that you can skip encryption.  I think it is enough to set up to use LVM during install for /, and later use mcc to add NFS share.

For machine B, I used the installer to in expert mode clear partitioning, make /boot, then a large LVM and ticked the encrypt checkbox, then made the logical partitions in LVM.



Interesting 1:
The installer specifies the partitions differently using /mapper/ folder for / and /home but not for swap.  See attachment 3351 [details]
/dev/vg-mga/swap
/dev/mapper/vg--mga-home


Interesting 2:
Only the fstab lines containing /dev/mapper/ are deleted.
The line containing /dev/vg-mga/ is preserved.


...And I really think there should be one little sanity check in the tool to warn if there is no fstab line specifying / .

I let it stay set as Cauldron as it probably is not fixed there either, and added MGA2TOO in whiteboard.

I think both LVM and NFS are very nice to use, so I am surprised noone else seem to find this problem... I think it is critical.

Can someone else please test to see if it is not just me having bad karma...?

Whiteboard: (none) => MGA2TOO

If someone need help to fix a wrecked fstab in an encrypted LVM, i wrote this: https://forums.mageia.org/en/viewtopic.php?t=4204

Strangely, on this third machine fstab did not loose any mount points, but fstab got rewritten so one line contain /mapper/ which was not there before - works either way.

Created attachment 3362 [details]
Machine C, fstab before having mcc add one NFS share

Created attachment 3363 [details]
Machine C, fstab after having mcc add one NFS share

Hit again!  Diskdrake removed / from fstab !!

And here I have no NFS configured.

On an up to date i586 KDE mga3 b3 + updates right now.
This is a testing portable system installed on a fast large USB stick.
Original partitoning:
/boot ext4 200MB
then several partitions for a LVM vg
  (so i can later delete and make room for non LVM)
and a 1GB fat32 which i do not mount in fstab

In the LVM: /, swap, /var/www

I set up most of it in installation (booted on mga3 b2 live DVD) Earlier when I used diskdrake to add partitions for LVM, and created the /var/www in it, it worked.  (it also moved contents of /var/www correctly :) )


What i did now was unmounting existing swap, expanding /var/www without unmounting it, created another swap,
(first i intended to delete the swap i had and making a larger but changed my mind to have two swap partitions instead - more flexible in future changes)
An i think i clicked to mount the new swap, 
Then mounted the old swap
noticed the new sap as not mounted, but no there as a format button so i Clicked it, then mounted, and exited.

Then i remembered this bug and compared fstab and fstab.old:

Old:
/dev/mapper/vg--Extreme-root / ext4 acl,noatime 1 1
# Entry for /dev/sdb5 :
UUID=74d4c613-dd3a-4e5c-a2c6-1d7b9e906903 /boot ext4 acl,noatime 1 2
none /proc proc defaults 0 0
/dev/vg-Extreme/var_www /var/www ext4 acl,noatime 1 2
/dev/vg-Extreme/swap swap swap defaults 0 0


New:  Without / !!
# Entry for /dev/sdb5 :
UUID=74d4c613-dd3a-4e5c-a2c6-1d7b9e906903 /boot ext4 acl,noatime 1 2
none /proc proc defaults 0 0
/dev/mapper/vg--Extreme-var_www /var/www ext4 acl,noatime 1 2
/dev/vg-Extreme/swap swap swap defaults 0 0
/dev/vg-Extreme/1 swap swap defaults 0 0

( If it is of any importance i had at this occasion also the internal PATA drive in the system, but not use din any way except it need to be there else i have a minute delay for pata timeout during boot :( That drive also have mga3 with LVM and is displayed in diskdrake. )

Sadly I think we really need to get a good method of reproducing this with clear steps on both setup and how to trigger it. Ideally in a VM where we can take snapshots, trigger the bug, roll back, retrigger it etc. Thus we'd also be able to test the fix reliably. 

@Dave, perhaps you're nicely LVM'ed VM can reproduce this issue?

Diskdrake seem to forget specifically the /dev/mapper/vg- forms.

But it itself write new partitions on that form...

A strange detail is that the installer specified the / partition using /dev/mapper/vg- , but the other partiitons using the /dev/vg- form.   As i understand the two forms mean the same?

I guess that if i had re-run the procedure and first changed root to then /dev/vg form it would not have been deleted.  Unfortunately i have messed up that system completely now and it is now running mga2 intended for production next week.

But an idea to stress this is to manually rewrite the entries to /dev/mapper/vg- forms, then mess with diskdrake and see what it does to fstab.

fixed in SVN.

Status: NEW => RESOLVED
Resolution: (none) => FIXED

Reopening, as it seems fixing mga2 is forgotten?

Status: RESOLVED => REOPENED
Resolution: FIXED => (none)

Closing

Status: REOPENED => RESOLVED
Resolution: (none) => FIXED

Thierry, Can you explain the closure or reference an mga2 bug/update? Thanks.

Ahh nvm, I see a blocks was added: bug #9741 will cover the mga2 update. Sorry for the noise.

Thanks Colin for the pointer.
Thanks Thierry for fixing. Next time please point at it too ;)

Yeah, bugzilla is not quite as clear as it could be on that front. Hey ho :)