added the maintainer since I see nothing related to btrfs in the dracut changelog

Assignee: bugsquad => mageia
Source RPM: (none) => dracut

I just did a network install with:
 sda1 /boot on ext4
 sda5 swap
 sda6 / on btrfs

Worked fine and rebooted without issue.

Not sure if it's something fixed with installer updates after beta3 but it's certainly all OK for me.

Can you reproduce with latest everything?

I could still reproduce after M2b2 install + update during install, but with network install (M2RC), issue is resolved.

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

*** Bug 6692 has been marked as a duplicate of this bug. ***

CC: (none) => tavvva

reoping as it's valid again see duplicate

Whiteboard: (none) => MGA2TOO

really

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

If you hit this bug, please tell whether Colin's workaround from the link below solves it for you

https://bugs.mageia.org/show_bug.cgi?id=6692#c11
> I can also confirm that simply switching to tty2 while at the user password
> screen and doing: "rm -f /mnt/boot/initrd-3*.img" will allow for the bootloader
> to be regenerated properly as part of the installer process.

@ Jaromír

It seems you missed that Colin asked you to confirm this works in 
https://bugs.mageia.org/show_bug.cgi?id=6692#c14

CC: (none) => marja11

I shall try and confirm this with a DVD install. However, in the meantime I have a very related issue which is that given a new install on a fresh disk the DVD installer is unable to mount btrfs (or XFS) partitions because the relevant kernel modules have not been loaded.

Switching to tty2 and running modprobe btrfs (and modprobe xfs) fixes this problem when you retry the disk partitioning and formatting.

So it looks like we have a problem with MGA3B2 not loading modules and creating initrd properly.

If you want me to file this as an additional bug I can but they are VERY related.

The system hasn't finished installing so I can't confirm if it boots or not yet!

CC: (none) => uberscubajim

The issues in mga2 (reported here) are quite different from those in mga3.

That said I think the issue of initrd generation for xfs in mga3 should be solved when we push dracut 025, So please do check then (or do a net install when dracut 025 is available in cauldron)

OK, I've just been running some more tests.

The M2B2 problem has recurred in M3B2. It's identical as far as I can tell. There is no btrfs module available when the system boots so it can't boot. The same almost certainly applies to XFS.

Similarly, you have to take extra steps to create a system with a btrfs and/or XFS filesystem during install. Specifically manually modprobeing btrfs and xfs.

So, it would appear that M3B2 has the same problems as M2B2.

The issue in mga2 (which I'm not sure is resolved) is that of a buggy theme package which was updated with certain %post scripts that resulted in the initrd being generated too early in the install process (i.e. when the theme is installed, not at the end when all package installation is complete).

If this same problem is happening in mga3 I'd be surprised, but it's easy to check.

Simply do the install, but after the package installation, flip over to a text terminal when the "Add user" screen is visible and check to see if any files are present in the /mnt/boot/ folder matching the *.img glob. If so, rm them (the actual files, ignore any symlinks that may be present), and flip back to the install and then complete it as usual. If this solves your problem then please let me know and I'll look into what is triggering the initrd generation early.

Ok, sorry for the delay but I've double checked.

It is indeed the same as in M2B2 with the files initrd-desktop.img and initrd-server.img in /mnt/boot.

I've deleted the .img files and it seems to rebuild them OK.

So far I've only checked with reiserfs (which I think failed before) but that works. I'm just starting a check with btrfs and will report back.

Hmm, those files you mention should just be symlinks, not real files. Did they point to real files which you deleted? If so, then that's fine, but if not then something is still amiss elsewhere...

No, they were real files.

I'm currently reinstalling again (1 minute to go!). Manually modprobing btrfs during installation meant that I could not only format but use a btrfs / (I have an ext2 /boot).

Hang on. I'm back at setting the root password and can confirm stuff.

I was wrong, the files are symbolic links. initrd-desktop.img points to initrd-3.8.0-desktop-0.rc4.1.mga3.img (which doesn't exist) and initrd-server.img which points to initrd-3.8.0-server-0.rc4.1.mga3.img.

I deleted the symlinks then completed setting the root password and creating users.

I then rebooted the system and it *didn't* work! No btrfs module was installed!

Added note: the root file system was btrfs and installed over a LUKS partition.

Dang! Should have added: do you want me to try without LUKS and/or without deleting the symlinks in /boot?

No it's OK, I think I'll need to go through and try and debug in a VM myself to see what's happening.

The symlinks existing (but dangling) is expected. The files they point to should be created at the end. It is, however, odd that you have both desktop and server kernels apparently installed. Is that something you've manually chosen? Also did the initrd-3.8.0-server-0.rc4.1.mga3.img file (point to by initrd-server.img) exist when you looked? If so, then this shines some light on the situation. If you could confirm how you got both -desktop and -server installs that would be most useful for reproducing.

You also shouldn't need to modprobe btrfs manually during install to be able to see existing and format new btrfs partitions... it should all "just work"(tm), so that likely needs some investigation also.

I didn't manually choose both kernels. It was a pretty vanilla install of a LXDE system (so it would install quicker).

Good luck with the VMing. I use virtualbox myself.

I am confirming this bug with a fresh new install with mga3 RC1 on a dell xps 13 laptop (brand new and still shinning!)

Amazingly, I would have never done that by myself, but the installer proposed me btrfs as a default choice instead of ext4, and I accepted. I think that triggers a critical bug, because it is going to happen to many too curious soon :)

The install goes fine, but at boot time, "operating system not found". Mounting my partition with boot.iso and trying to reinstall the bootloader also fails with a error like "invalid device".

I tried a second install, putting everything as before *but* creating only a /boot with ext4 (/ /home/ /usr still on btrfs). In that case, the bootloader got installed.

So, the problem is only having /boot with btrfs now.

Cheers,
Chris

Priority: Normal => High
CC: (none) => dirteat

Installer of M2 or M3 cannot be fixed. If this is valid for 5beta1 please change the whiteboard. Alternatively, it should be closed.

Keywords: (none) => NEEDINFO

I have just tested with 5beta1 installer; that bug is fixed.

/dev/sda6 on / type btrfs (rw,relatime,ssd,space_cache)
/dev/sda1 on /boot type ext2 (rw,relatime,errors=continue,user_xattr,acl)

Cheers,
Chris.

(In reply to Chris Denice from comment #20)
> I have just tested with 5beta1 installer; that bug is fixed.


Thanks :-)

Closing

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