| Summary: | initrd missing ext4 support on fresh install | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Frank Griffin <ftg> |
| Component: | Installer | Assignee: | Colin Guthrie <mageia> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | critical | ||
| Priority: | Normal | CC: | ennael1, marc.lattemann, marja11 |
| Version: | Cauldron | ||
| Target Milestone: | Mageia 3 | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | 3alpha1 | ||
| Source RPM: | CVE: | ||
| Status comment: | |||
| Attachments: |
report.bug.gz
unknown fs type 'ext4' |
||
>I can't get a report.bug.gz easily
then maybe can try:
"switch to console 2 (by pressing 'Ctrl-Alt-F2') during installation, put a floppy in floppy drive or plug a USB key/stick and type: 'bug' then press Enter. It will put report.bug on the floppy/key."
(In reply to comment #1) > >I can't get a report.bug.gz easily > > then maybe can try: > "switch to console 2 (by pressing 'Ctrl-Alt-F2') during installation, put a > floppy in floppy drive or plug a USB key/stick and type: 'bug' then press > Enter. It will put report.bug on the floppy/key." Well, that would mean redoing the install. If it's really needed, I could pull the drive from the laptop and access it from another system with a SATA-USB connector. Col, is it worth that, or do you have a pretty good idea what this is about ? Not really any clue yet. Perhaps try booting with sysresccd.org image or an MGA2 Live image and extract the initrd itself, and the logs from /root/drakx. Also if you could make a note of the timestamp on the initrd that might be useful as if it's an issue of it being generated at the wrong time, then it might be important (although not including ext4 module just seems almost impossible :s, so I'm not sure it's a timing thing). Created attachment 2750 [details]
report.bug.gz
Here's the report.bug.gz. The ddebug.log and install.log are also available, if needed.
Frank Griffin
2012-09-04 16:38:14 CEST
Attachment 2750 mime type:
text/plain =>
application/octet-stream It's ok, the ddebug is in the report.bug file. Well it certainly appears that the ext4 module is simply not included (as the kernel/fs folder does not exist in the folder listing of the initrd - so no filesystem modules are included). Can't immediately see why this is broken. My initial guess would be some missing udev rules needed by the installer but I don't think that would really be it. The "kernel modules" module in dracut is selected which should, in theory include any loaded modules and ext4 is clearly listed as loaded. The only suggestions I've got at the moment are: 1. Repeat the install 2. Have the dracut rpm from mga2 available somewhere. 3. At the end of the install, but before reboot, flip to tty2. 4. chroot into /mnt 5. download and install with rpm --oldpackage the mga2 dracut. 6. Regenerate the initrd (or a separate initrd) for the kernel installed (which is different to the running one it seems). and see if that generates a better image. This is the kind of debug I did a lot during mga2 cycle - doing lots of installs and flipping over to tty2 near the end and doing stuff manually. It's a pain, but such is the process. If it's a reproducible problem in a VM, then I could work it out here, but it seems like it's related in some way to the h/w... or is that just a red herring do you think? I'll try it in a VM and see what happens. Works in a VM, but then again the install has been reloaded to the mirrors twice since the original try. I'll retry the real one. Now it works for real. FM. Status:
NEW =>
RESOLVED Created attachment 2754 [details]
unknown fs type 'ext4'
Leumanu got this error today, after installing pre-alpha 1 dual boot.
So reopening
(In reply to comment #9) > Created attachment 2754 [details] > unknown fs type 'ext4' > > Leumanu got this error today, after installing pre-alpha 1 dual boot. > > So reopening Again reopening Status:
RESOLVED =>
REOPENED Marja, between the time I wrote comment#7 and comment#8, the install was uploaded for the third time. Do you know where in this timeline (starting Sep03) the pre-alpha 1 dual boot ISO was cut ? It's possible that this bug occurs randomly, and just happened to work for me after the first time, but it's more likely that it got fixed in one of the three newer versions (counting today's, four). It may just have been a build error in the version where I encountered it, especially since Col can't see any reason for it. (In reply to comment #11) > Marja, between the time I wrote comment#7 and comment#8, the install was > uploaded for the third time. Do you know where in this timeline (starting > Sep03) the pre-alpha 1 dual boot ISO was cut ? > MrsB (QA leader) told me it was rebuilt this morning Latte, another QA tester, hit this bug today in the dual CD, too Has anyone been able to reproduce on a VM or is it all on bare metal? My only failure was on bare metal, but so was a subsequent success. (In reply to comment #13) > Has anyone been able to reproduce on a VM or is it all on bare metal? I tried it on Virtualbox as well as on real HW, with the same result as seen in the attachment CC:
(none) =>
marc.lattemann Tried dual CD in kvm. It's working properly here CC:
(none) =>
ennael1 I get the feeling this will be one of those nasty problems that will take a while to track down the exact cause :s I can't reproduce this bug anymore, OK for everyone ? (Marc especially) Sorry for the late reply: yes, it's also OK here: I tried it yesterday again on VB and real HW and on both machines the reboot worked without any issue. (In reply to comment #18) > I can't reproduce this bug anymore, OK for everyone ? (Marc especially) (In reply to comment #19) > Sorry for the late reply: yes, it's also OK here: I tried it yesterday again on > VB and real HW and on both machines the reboot worked without any issue. Thx, so it is fixed :) Status:
REOPENED =>
RESOLVED |
A fresh install of today's cauldron boots to a repair shell with the message: mount : Unknown filesystem type 'ext4' I can't get a report.bug.gz easily, because this is a new HD with no other bootable partitions, and whatever this is seems to affect "rescue" as well, since even after "drvinst" the rescue system "sees" no /dev/sdX disks. Assigning to you, Col, as Thierry seems to think you know all about it (or at the very least that you are deserving of having to figure it out) :-)