Bug 3640

Hi all.

Strangely enough, my x86-64 laptop can boot this kernel fine. Its specs are:

<<<
Acer Aspire 5738DZG laptop with the following specs:

    Intel Pentium(R) Dual-Core CPU T4300 @ 2.10GHz. (x86-64).
    ATI Mobility Radeon⢠HD 4570 (r700)
    15.6×´ 3D HD LCD Screen.
    3 GB Memory
    320 GB Hard Disk Drive.
    âDVD Super Multi DL driveâ
    Acer Nplify⢠802.11b/g/n.
>>>

Colin, dmorgan, tmb idea ?

CC: (none) => dmorganec, mageia, tmb

Shlomi, check your kernel command line for a resume= argument. If it's there try removing it. Could just be it's referencing an invalid partition/swap name or something deeper... either way, this is the first port of call.

(In reply to comment #3)
> Shlomi, check your kernel command line for a resume= argument. If it's there
> try removing it. Could just be it's referencing an invalid partition/swap name
> or something deeper... either way, this is the first port of call.

After I removed the resume= argument (which also exists in the bootable config) I'm getting an error from e2fsck that it failed, and being inserted into a shell prompt. There, I typed "exit" and the boot continued successfully. I then went to Ctrl+Alt+F1 and was able to start KDE, with sound, networking and 2D/3D graphics.

Maybe this will give you some clues.

Can you attach the /etc/fstab from the affected machine?

Created attachment 1189 [details]
The fstab from the affected machine.

Do you happen to know which version of dracut was installed when you generated your initrd?

You should be able to tell from the create time on the initrd itself and the install date on the dracut package.

If it's not the latest one, it might not be able to do the fsck stuff properly, but (I think) I added appropriate support for this in the latest dracut package.

If you could regenerate the initrd (dracut -f /boot/....) with the latest dracut and see if it's still affected that would be great.

Thomas: Do you know if urpmi somehow has a list of priorities concerning mkinitrd such that if both a kernel and mkinitrd are to be installed as part of the urpmi process that it installs mkinitrd first before the kernel? If so, we should make sure the same is true of dracut.... if not, can this be done do you think?

afaik only rpm, urpmi + deps, curl/wget/aria, glibc are on the priority list to be installed first by urpmi. 

after that there are no guarantees in wich order (unless some package has strict deps) things are installed.

I wonder if it would help if I add Requires(pre) on "bootloader" to convince urpmi to pull it before the kernel (even if one "bootloader" is already installed)

(we currently dont have any generic provides that would pull in either mkinitrd or dracut, so current kernels require mkinitrd)

(In reply to comment #7)
> Do you happen to know which version of dracut was installed when you generated
> your initrd?
> 
> You should be able to tell from the create time on the initrd itself and the
> install date on the dracut package.
> 

From what I recall it was December 6.

> If it's not the latest one, it might not be able to do the fsck stuff properly,
> but (I think) I added appropriate support for this in the latest dracut
> package.
> 
> If you could regenerate the initrd (dracut -f /boot/....) with the latest
> dracut and see if it's still affected that would be great.

I've ran dracut -f when running the 3.1.4-mga2 kernel, and rebooted - still the same problem. I suppose I can take a photograph of the screen as it appears after boot and from which I need to type "exit". I'll try to get to it soon.

I can also try with mkinitrd.

Regards,

-- Shlomi Fish

Yes please a photo or just the relevant error lines if they are clear and short enough to type in.

Also can you do: "cat /etc/fstab" before you type exit.

This fstab should be very small, but I want to double check that all is well in it.

Created attachment 1201 [details]
A photo of the screen at boot.

This is a screenshot of the screen at boot time.

Created attachment 1202 [details]
Photo of /etc/fstab at boot.

Can you also attach the output of the command blkid

CC: (none) => davidwhodgins

(In reply to comment #13)
> Can you also attach the output of the command blkid

[root@telaviv1 ~]# blkid
/dev/sda1: UUID="4a5d4de6-01cb-4f22-9a9e-f36f6a3867d0" TYPE="ext3" 
/dev/sda5: UUID="cd407dc5-f6b9-4e60-ab3b-b9d012f899c6" TYPE="ext4" 
/dev/sda6: UUID="d320c338-58a2-4aa6-9d47-d2c0bc60524b" TYPE="ext4" 
/dev/sda7: UUID="7fd4da70-c609-49b5-a474-f167cfc5efae" TYPE="swap" 
/dev/sda8: UUID="21a21e54-a2e2-4b4b-b764-6c8db176cbec" TYPE="ext4" 
/dev/sda9: UUID="7963d799-5f21-4e34-9687-142a5bc764be" TYPE="ext4" 
[root@telaviv1 ~]# 

Regards,

-- Shlomi Fish

Thanks for the info. It's a bit strange as /usr is pretty straight forward and the UUID has been correctly resolved to a /dev/sda9 name, so e2fsck should quite happily run.

The resume thing is odd, but it's non-fatal so we should ignore that for now.

I've not got time to look right now but will try and trace through the steps later today.

I'm pretty sure this is resolved now... if not feel free to reopen.

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