can boot X86 livecds but not AMD64 livecd to repair my AMD64 Gentoo system
 

My Gentoo system was originally installed using livecd-amd64-installer-2008.0-beta2.iso.
During a editing session requiring many su switches I changed the root password to a shorter one to avoid repeatedly typing the long original password. Because of an interruption I did not save the shorter password at a convenient place and did not reset the original password before shutdown. I can no longer access the root partition. To rescue the situation I made a a livecd with the newer livecd-amd64-installer-2008.0.r1,iso version. I wanted to use this version for resetting the root password with the recommended chroot procedure. To my surprise my system could not load the livecd software although the boot sequence was set to start by reading the CDRom first. x86 livecds were correctly loaded, however, but could not be used for
chrooting because of incompatibility with the amd64 system. I discovered that during booting the BIOS-bug PCI-message "mcfg area e0000000 is not E820-reserved. not loading MMCONFIG" is displayed. I found no solution to booting the AMD64 livecd, neither the new one nor the beta version from which I originally installed my system. I also tried to change the entries in the boot menu to single user when it is displayed, but GRUB does not accept the changes and boots the runlevel 3 system where I can login, but without access to neede root files that require the root password. Does anybody have a suggestion? Should I flash the BIOS with the latest bios software? Has the BIOS anything to do with my problem?

Question and request.
 

Did you say that the original install cd did not work?

To help get the cd's booted might be helpful to post your system specifications.

ldemaey,

Boot normally but at the grub splash screen press the e key.
Find the kernel line you want to boot and add at the end.
Follow the on screen instructions to continue booting.

This leaves root mounted read only and just the kernel and bash running.
There are no daemons and nothing else. The boot time will be impressive.
Run the command root is now read/write
Run to reset roots password, followed by to reboot normally.

Thanks for suggestions
 

To: Hern 28:
System hardware configuration:
mainboard MSI K9AGM4-L (MS-7373) AM2 mATX from micro-star-international;
AMD Athlon(tm) 64 X2 Dual Core Processor 3600+;
AMD® 690V and SB600 Chipset;
2048MB memory;
BIOS MS7373 VER:1.1
SAMSUNG HD16HJ SATA hardddisk;
HL-DT-STDVD-RAM GS IDE dvd.
installed software: Gentoo Linux installed from livecd-amd64-installer-2008.0_beta2.iso
in april 2008.
boot sequence setting in BIOS:
1st Boot Device [1st FLOPPY DRIVE]
2nd Boot Device [CD/DVD:PM-HL-DT-ST]
3rd Boot Device [SATA:3M-SAMSUNG HD]
Boot From Other Device [Yes]

The livecd from which the system was installed does no longer load at boot. Livecds for x86 systems (e.g. knoppix, or for a x86 gentoo system on cdrom) do boot.

To: NeddySeagoon
As I said: editing the displayed grub boot menu screen (after pressing e-key) can apparently be done but after pressing the b-key the edit changes are not effective.

You could use the 32 bit cd and maually edit the passwd file (definately make a backup first).

ldemaey,

If the command sequence I posted fails, something is badly broken.
You can try init=/bin/bb in place of init=/bin/bash

Busybox (bb) provides a cut down set of commands

To: NeddySeagoon
Unfortunately this doesnt work either. After the boot menu-line is edited using the e-key and returning to the boot menu with "enter" the changed line is displayed, including the change, but boot-start with the b-key does not execute the change. It always goes to the normal boot where it executes init=/linuxrc and ends in runlevel 3.
There is a file grub.conf in directory /boot/grub with permissions 644 that contains:

default 0
timeout 30
splashimage=(hd0,0)/splash.xpm.gz
title Gentoo Linux
root (hd0,0)
kernel /kernel-genkernel-x86_64-gentoo-r5 root=/dev/ram/ init=/linux rc ramdik=8192
real_root=/dev/sda3 doscsi
initrd /initramfs-genkernel-x86_64-gentoo-r5

This is also what is displayed as boot-menu. There is also a file-link to this grub.conf
with the name menu.list with permissions 1777. Obviously the linked file grub.conf is not changed when menu.lst is edited, therefor the edit does not change the boot behavior.

The info displaying loaded modules during booting cd includes at the end the command
INIT= Entering runlevel 3.
It also tells me that something is wrong with my configuration file, but since i have no access I cannot consult the syslog-ng.conf file.
Exchanging the cd-drive did not change the behavior. Thanks for your efforts
ldemaey

ldemaey,

I failed to explain how what I suggested works. During the boot process, grub reads the grub.con file into memory and waits for When you press e, you are able to edit this in memory copy, so the changes apply for a single boot.
Grub cannot write the change file back to disk as the kernel is not yet loaded and it has no disk write code of its own.default 0
looks like a copy typed post as it contains several errors.

My method fails because you are using an initrd file as a "fake root filesystem" and the init is contained within that. It it run before your real_root is mounted.

The next thing to try is to press the letter "I" key to be able to choose which things are started at boot.
Provided your system gets that far, you will get further on screen instructions.

NeddySeagoon
Thanks for explaining the reason why my editing the boot menu did not give the desired result. I am learning more and more about booting. I found a way to reset the root's
password by a method similar to chrooting. It is explained in <http://linuxgazette.net/107/tomar.html>. Using the instructions given there with my Knoppix cdrom I can now access the root files. This has not yet solved my problem not to be able to load the AMD64 livecd. I assume that the BIOS of my system is playing a role in this. AMD states in <http://developer.amd.com/Assets/pci%20-%20pci%20express%20configuration%20space%20access.pdf>
that recent Linux kernels for ARCH=x86_64 make use of MMIO access, but fall back to IO access if this is not possible. I can now consult the kernel log files to learn more about this. Again, thanks for your continuing interest in this problem.
ldemaey