Failure to complete boot following initial install of Suse 10.1
Looking for help on this issue. Downloaded and installed 10.1 from the CDs, then rebooted, only to get the message (early in the boot process): /bin/run-init: /sbin/init:Permission denied. Kernel panic-not syncing:Attempted to kill init!!. Hmm, so thinking I had a bad disk, I did the install using the internet, only to run into the exact same problem when rebooting the first time. No logs to review since it never really gets past the initial problem. I've searched for resolution, but haven't found others with the same issue. On this same machine, I'm running 4 other Linux versions, including Suse 10, all without problems. Also tested memory, all is well and good there. The strange thing is that I've sucessfully installed and ran several beta versions of 10.1 and then removed same by reformatting the respective partitions. I watch during the boot process as the partition (formatted as reiserfs) is changed to read/write so I know it's not write protected. Suse 10 continues to run fine, as do other versions of Linux. Sure wish there were some log file to look at however it doesn't seem to get far enough along to generate same. /Var/log has nothing in the way of files referencing the issue Scratching my head for a resolution, any pointers as to where to go to find a resolve
On Monday 15 May 2006 15:36, Sac Geek wrote:
Scratching my head for a resolution, any pointers as to where to go to find a resolve
Hi Sac, First, this topic really belongs on suse-linux-e (SLE) as opposed to opensuse. Since I'm already responding, here's what I think is going on: I have a system with three hard drives containing many partitions and multiple installed OS's... including (now) SUSE 10.1, 10.0 and 9.3. During the installations of both 10.0 and 10.1, the installer proposed incorrect boot loader configurations. I had to manually edit each Grub menu entry after confirming and revising the proposed partitioning schemes, as well. This time around, while the 10.1 installer correctly labeled the 9.3 share it selected (and inserted) the incorrect root partition. I suspect what may be happening is you are accepting the proposed partitioning scheme and boot loader configuration without first taking the time to verify the settings. These tools are great when either no OS exists on the system or you're intending to dual boot a single installation of SUSE with Windows, but there is a limit to how accurately the scripts can 'deduce' your intentions as the complexity of the environment increases. regards, Carl
I have a system with three hard drives containing many partitions and multiple installed OS's... including (now) SUSE 10.1, 10.0 and 9.3.
Sounds almost identical to my own situation. Now that you mention it, Suse does prefer to call my primary boot drive, by another "name", i.e. hde, instead of hda. Suse 10 did the same thing, however it installed and ran properly. During the installations of both 10.0 and 10.1, the installer proposed
incorrect boot loader configurations. I had to manually edit each Grub menu entry after confirming and revising the proposed partitioning schemes, as well.
Yes, I've also done the same thing for my other Linux installations (had to change HDA to HDE in order for them to boot properly, this because Suse sees that drive differently and of course, it's Suse Grub that's doing the booting. Hmmm, that makes me wonder if I went to a different version of Grub, namely Ubuntu, and input the correct parameters for the 10.1 install, if things would go swimmingly. Yep, gonna try that, and, I'll post my results. Thanks for the comeback, and for sprinkling the right fertilizer on my brain. Ciao Jim
participants (2)
-
Carl Hartung -
Sac Geek