system hang on "starting init crypto disks [OK]"

Bug #485858 reported by Rob Canning
22
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Puredyne Live
Won't Fix
Critical
krgn
puredyne-kernel
Won't Fix
Critical
krgn

Bug Description

this has been duplicated on two T43s and i also observed this in some machines in access space...
i made a fresh install with automatically log in user and an ext4 partition - i was able to log in sometimes but mostly it hangs on
"starting init crypto disks [OK]"
seems erratic - i installed my x41 exactly the same way and have had no problems
i also after install tried a aptitude safe-upgrade but that didn't help

Changed in puredyne-live:
status: New → Confirmed
importance: Undecided → Critical
Changed in puredyne-kernel:
status: New → Confirmed
Changed in puredyne-live:
status: Confirmed → Incomplete
Changed in puredyne-kernel:
importance: Undecided → Critical
Revision history for this message
Rob Canning (rob-goto10) wrote :

so i reinstalled using ext3 this time - rebooted 4 times without problem - then i installed thunderbird, aptitude removed mbr{u}
i rebooted successfully once then on second reboot problem came back

what is this mbr{u} - i wonder is this something to do with it

Revision history for this message
Rob Canning (rob-goto10) wrote :

now it booted fine again, i noticed when it boots fine it starts with:

setting preliminary key map
starting early crypto disks
etc
all good

when things freeze after the fsck then it goes straight to:
starting init crypto disks without the keymap stuff or the early crypto stuff

sometimes the grub boot menu doesn't show either... sometimes it does...

very erratic

Revision history for this message
Aymeric Mansoux (aymeric) wrote :

I experienced the same now in the following situation:

 * virtualbox: installation of Puredyne on HD via ubiquity, reboot and update to latest Puredyne kernel (2.6.31-6-pure) then reboot leads to (supposedly) random hangs after "starting init crypto disks [OK]"

 * Lenovo x61: karmic install from scratch with Puredyne kernel (2.6.31-6-pure) leads to (supposedly) random hangs after "starting init crypto disks [OK]"

Revision history for this message
Aymeric Mansoux (aymeric) wrote :

@rob: I did not see any similar behaviour when the kernel is used from liveUSB, so I am not sure this bug is valid against "Puredyne Live"

Changed in puredyne-live:
assignee: nobody → krgn (karsten-goto10)
assignee: krgn (karsten-goto10) → nobody
Changed in puredyne-kernel:
assignee: nobody → krgn (karsten-goto10)
Revision history for this message
Rob Canning (rob-goto10) wrote :

i am having this problem with this kernel 2.6.31-4-pure
am going to try the non rt kernel now and see if problem persists

Revision history for this message
danstowell (danstowell) wrote :

I'm also seeing this (eee 701, kernel 2.6.31-5-pure). It seems like I can boot after first install but then on future boots it gets stuck at this point - I think that's the pattern although I could be deluding myself that it's this regular. Also seeing some error messages just before that (render error, page table error). Happens whether or not I choose recovery mode.

Revision history for this message
spidernetuk (chris-spidernet) wrote :

I also see this after a fresh install using kernel 2.6.31-14-generic, 1st boot after install is fine. Second boot system hangs after "starting init crypto disk ok"

Changed in puredyne-live:
assignee: nobody → krgn (karsten-goto10)
m4r (marloes)
Changed in puredyne-live:
status: Incomplete → Confirmed
Revision history for this message
Aymeric Mansoux (aymeric) wrote :

I did not see the issue with the latest -dev ISO installed via ubiquity in Virtualbox.

Revision history for this message
danstowell (danstowell) wrote :

I did still see the issue with the latest -dev ISO installed via ubiquity on an eee 701, I'm afraid.

Revision history for this message
krgn (karsten-goto10) wrote :

I will hopefully be able to address this at some point today by making a new completely new kernel based on the ubuntu stock linux-rt in multiverse (or is it universe?) adding aufs to the source tree. that will hopefully fix this issue as after testing that kernel it seems to have gone away. I know, the proper way to deal with this problem would be to find the bug and a corresponding patch, but my time is really limited atm and googling around hasn't found much else about this problem.

Revision history for this message
Claude Heiland-Allen (claudiusmaximus) wrote :

current status: ubuntu stock linux-rt has aufs, but it doesn't seem to fix the problem entirely (it still occurs but less frequently)

Revision history for this message
F7205 2610539 54B8BD49D49D (krugerk) wrote :

while attempting to boot kubuntu 9.10 (live) from a usb stick, it worked to disable UDMA in BIOS on a Dell Dimension 4800

http://ubuntuforums.org/showthread.php?p=8713439

Revision history for this message
aleij (alejoduque) wrote :

was bitten by this bug while running on a fresh puredyne c+C install. the hardware: AMD/athlon 1.6ghz.

as stated by others before, the bug appears every now and then, i got 4 failed boots, then it worked.

will try to disable UDMA in BIOS as suggested and report back.

Revision history for this message
Aymeric Mansoux (aymeric) wrote :

This bug seems completely random. I recently installed a bunch of Puredyne machines for a workshop, all same models, some had it some not. The only thing that helped was to turn on EPT support on in the BIOS. On another machine, disabling USB legacy was the only thing that helped ....

so ... ahem...

Changed in puredyne-live:
milestone: none → 10.04
Changed in puredyne-kernel:
milestone: none → 10.04
Revision history for this message
iletys (iletys) wrote :

Hi,
I have Acer 1810TZ and Kubuntu 9.10 with latest software updates. The problem occurs always in shutdown process if lid have been closed and opened before shutdown.

I'am using default power safe settings.

Startup -> run -> shutdown: no problems
Startup -> run -> lid down -> lid up -> run -> shutdown: "Starting init crypto disk" always appears in shutdown process and system hangs.

When system hangs to "Starting init crypto disks... [OK]" so following text appears
nmdb is running
     * nmdb is running
and after while appears
[ 360.760173 ] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 360.760483 ] INFO: task Xorg:1199 blocked for more than 120 seconds.

Revision history for this message
yaxu (alex-slab) wrote :

Ok after many tries I got this new puredyne install to boot. Here's what eventually worked:

1/ Boot in recovery mode
2/ Wait for root prompt
3/ type: grub-mkconfig
4/ reboot

Maybe something is stopping the installation from completing fully? Like this:
  https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/30759

Though in this case I'd left it for hours and returned to find it complete, so I don't think this is a problem... But something could be terminating early in the upgrade process. Doesn't really make sense as aymeric and others have fixed theirs by fiddling with the bios...

alex

Revision history for this message
babagau (spiral-babagau) wrote :

I had this system hang happening really rarely and now that I added new repositories, I upgraded with error:

Errors were encountered while processing:
 /var/cache/apt/archives/linux-firmware_1.38_all.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

then restarted and now I have

"starting init crypto disks [OK]" and then
eth0: link up, 100Mbps, full duplex ... or so, I don' t remember exactly.
Won' t boot up even in recovery mode. I will investigate more and see...

Revision history for this message
babagau (spiral-babagau) wrote :

if I disable LAN from bios, system hangs at "starting init ctypto disks". Disabling UDMA and usb legacy support does nothing in my case.

Revision history for this message
babagau (spiral-babagau) wrote :

when I accidentally had an empty cd in the tray, last message was

cdrom: this disc doesn't have any tracks I recognize!

I hope all these can help

Revision history for this message
babagau (spiral-babagau) wrote :

It must be due to a module that is loaded.

Revision history for this message
Aymeric Mansoux (aymeric) wrote :

Thanks everyone for the feedback, I am marking this bug as won't fix as it is not something we can fix and this kernel is not updated anymore.

Hopefully this bug will not be there in the new Puredyne kernel...

Changed in puredyne-live:
status: Confirmed → Won't Fix
Changed in puredyne-kernel:
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.