You are not logged in.
Pages: 1
I removed pata and scsi from my initcpio hooks because i thought my root was on sata (i still think it is). The initcpio got rebuilt with the upgrade to 3.0. Now it doesn't boot;
it gets to the encrypt hook, says 'waiting 10 seconds for /dev/sda2' (my root), fails at that, says 'waiting 10 seconds for /dev/mapper/root', fails, and drops me in recovery shell.
I booted an old (april) install/recovery media to rebuild the initcpio with scsi and pata. after mounting everything, I did 'mkinitcpio -c /media/root/etc/mkinitcpio.conf -k 3.0-ARCH -b /media/root', but it failed, complaining about not finding /lib/modules/3.0-ARCH. It should be looking at /media/root/lib/modules/3.0-ARCH for that stuff. I found in the mkinitcpio script where /lib/modules was hardcoded instead of $MODULEDIR and fixed it. I retried the build and got some more errors:
:: Begin dry run
...
:: Parsing hook [encrypt]
ERROR: module 'dm[-_]crypt' not found
...
:: Dry run complete ...
I also had errors relating to [autodetect] (hardcoded /lib/modules), [keymap], and any module I put in MODULES. I removed those unnecessary things tho, so we are left with the above problem.
I traced the source of the dm_crypt error to a find command in add_module() in initcpio/functions; it is looking for ${fil}.ko, but everything is .ko.gz, so it finds nothing. If I make it find the .ko.gz files, I get 'ERROR: modinfo: could not open /.../...ko.gz: Exec format error'. I can't figure out what this means (with google, duckduckgo, and man modinfo), so I don't know how to fix it.
I'm basically lost, if anyone could show me what I'm doing wrong or suggest a path around the modinfo thing, that would be great.
Last edited by apefish (2011-08-09 20:10:33)
Offline
Maybe you need to chroot into the existing install to be able to run mkinitcpio? Or run the latest testing iso which contains the 3.x kernel and associated tools.
Regarding the hooks, if your SATA controller is running in legacy mode that might be why it broke when you removed pata.
But whether the Constitution really be one thing, or another, this much is certain - that it has either authorized such a government as we have had, or has been powerless to prevent it. In either case, it is unfit to exist.
-Lysander Spooner
Offline
I removed pata and scsi from my initcpio hooks because i thought my root was on sata (i still think it is). The initcpio got rebuilt with the upgrade to 3.0. Now it doesn't boot;
it gets to the encrypt hook, says 'waiting 10 seconds for /dev/sda2' (my root), fails at that, says 'waiting 10 seconds for /dev/mapper/root', fails, and drops me in recovery shell.I booted an old (april) install/recovery media to rebuild the initcpio with scsi and pata. after mounting everything, I did 'mkinitcpio -c /media/root/etc/mkinitcpio.conf -k 3.0-ARCH -b /media/root', but it failed, complaining about not finding /lib/modules/3.0-ARCH. It should be looking at /media/root/lib/modules/3.0-ARCH for that stuff. I found in the mkinitcpio script where /lib/modules was hardcoded instead of $MODULEDIR and fixed it. I retried the build and got some more errors:
:: Begin dry run ... :: Parsing hook [encrypt] ERROR: module 'dm[-_]crypt' not found ... :: Dry run complete ...
I also had errors relating to [autodetect] (hardcoded /lib/modules), [keymap], and any module I put in MODULES. I removed those unnecessary things tho, so we are left with the above problem.
I traced the source of the dm_crypt error to a find command in add_module() in initcpio/functions; it is looking for ${fil}.ko, but everything is .ko.gz, so it finds nothing. If I make it find the .ko.gz files, I get 'ERROR: modinfo: could not open /.../...ko.gz: Exec format error'. I can't figure out what this means (with google, duckduckgo, and man modinfo), so I don't know how to fix it.
I'm basically lost, if anyone could show me what I'm doing wrong or suggest a path around the modinfo thing, that would be great.
You're using an old version of mkinitcpio, and the basedir support is more or less broken. Either upgrade mkinitcpio on the install media (which means installing a few extras along with it) or chroot into the install.
Offline
Maybe you need to chroot into the existing install to be able to run mkinitcpio? Or run the latest testing iso which contains the 3.x kernel and associated tools.
Regarding the hooks, if your SATA controller is running in legacy mode that might be why it broke when you removed pata.
I forgot to mention that i did try chroot. I forget what the problem was but that didn't work. Maybe I have learned some things since then, I'll try again.
The new install media is the next thing I'll try, but I was hoping there was some quick way to avoid that, as it will take a bit more time (only have access to shitty work computer with windows).
Should my sata not be running in legacy mode?
EDIT:
ok I just tried the chroot: it breaks because /dev in the chroot is not real (I also remember some trouble with /sys, but that may have been fixed with the -k parameter).
Here's the problem: '/dev/fd/62: no such file or directory'
Unless someone knows some tricks, I guess I have to wait until I can make a new install thing.
Is it possible to somehow mount a clone /dev?
mount --move /dev /media/root/dev didn't seem to do anything...
Last edited by apefish (2011-08-09 21:07:16)
Offline
Offline
You're free to bind mount things to wherever you like elsewhere on the filesystem...
for mount in dev proc sys; do mount --bind "/$mount" "/media/root/$mount" done
Thank you! That worked perfectly. Now to see if it boots.
EDIT: it worked!
Last edited by apefish (2011-08-09 21:39:51)
Offline
I have a similar problem and I'm trying to use this same fix. Where exactly are you performing the bind mount, in the chroot or before it?
EDIT: Never mind, I figured it out after re-reading the whole thread. You mount your filesystem, bind mount the necessary directories BEFORE chroot, then chroot and run mkinitcpio. I was getting confused because you were using his specific mount point in your code example, and I was mounting in a different place. A thousand thanks for the help!
Last edited by Deemoney14 (2011-08-09 21:47:04)
This isn't the signature you're looking for... Move along...
Offline
Should my sata not be running in legacy mode?
IMHO, not unless you need it to be. For example, if you're dual-booting with Windows, AHCI drivers may not be installed and Windows would BSOD.
But that may not even be the problem, so one thing at a time.
But whether the Constitution really be one thing, or another, this much is certain - that it has either authorized such a government as we have had, or has been powerless to prevent it. In either case, it is unfit to exist.
-Lysander Spooner
Offline
apefish wrote:Should my sata not be running in legacy mode?
IMHO, not unless you need it to be. For example, if you're dual-booting with Windows, AHCI drivers may not be installed and Windows would BSOD.
But that may not even be the problem, so one thing at a time.
Ok, now that my trouble is fixed, how do you make the thing run in non-legacy mode? Is that some bios option that I have to go digging for? Or is it a software thing?
Offline
It's in the BIOS, and the way to enable it can vary greatly.
For example, on an ASUS P5Q Pro, the method is to go to Main -> 'Storage Config' and set 'SATA Configuration' to 'Enhanced' and 'Configure SATA as' to 'AHCI'.
On a cheapo ECS board, the method is to go to 'Integrated Peripherials' and set 'SATA Mode Select' to 'AHCI Mode'.
Both of those have AMI BIOSes, but hopefully that will give you some idea of where to start looking.
And if you're wondering why you shold go to all the trouble, it's because legacy mode doesn't support fancy SATA features like NCQ and hot-swapping. See AHCI on wikipedia.
Last edited by alphaniner (2011-08-10 17:39:58)
But whether the Constitution really be one thing, or another, this much is certain - that it has either authorized such a government as we have had, or has been powerless to prevent it. In either case, it is unfit to exist.
-Lysander Spooner
Offline
Pages: 1