You are not logged in.
Pages: 1
deleted
Last edited by Misbah (2012-02-14 05:09:06)
Offline
The part that I don't understand is the "Regenerating predefined images / using presets" in the wiki. What exactly does that do? Create some kind of default image I think using /etc/mkinitcpio.d/kernel26.preset, but I looked in that .preset file and I don't understand what's in it. It's not like the other .conf files. I presume it replaces the same /boot/kernel26.img. Could someone clarify this section for me? What exactly it does and why it's needed/useful? Just tryin to learn, thanks guys.
Presets are a kind of config files used by mkinitcpio. You can think of them as a sort of "profiles". Basically they're used to specify a set of modules, hooks, files etc. that need to be included in initial ramdisk created according to these presets. For example: you may want to have a preset for generating minimal sufficient init-ramdisk and one that generates full blown one with most of modules included along with some basic apps. A nice thing is that if you want to create one or the other, the only thing you must do is to specify preset using "-p" option—appropriate settings will be applied. The gain is that you don't have to change whole configuration file just to create desired init-ramdisk and then change it back to one that you consider default.
Don't take it as a rtfm but you could also take a look at manpage of mkinitcpio and look at already defined presets.
Hope this'll help!
Last edited by TheBodziO (2008-04-23 20:36:16)
It's not the best thing when they call you a "member" you know…
Offline
In a terminal, you can type
dmesg
Log files are in /var/log.
Offline
deleted
Last edited by Misbah (2012-02-14 05:08:48)
Offline
I think you need udev to create the nodes in /dev (e.g. /dev/sda2, which you need since the root filesystem is on there). Loading the module (say for sata disk) is not enough. If you don't want to use udev, you need to create the nodes manually - that would mean decompress initcpio, create the nodes and compress it back. You'd need to do this procedure whenever the new initcpio is generated.
If you read the wiki, the autodetect module is there to strip down all the modules from a subsequent hook (like sata) in order not to include *all* sata modules, just the ones that are needed for your system. If you include them manually in MODULES field, you can remove both sata and autodetect. Autodetect hook does not include any modules by itself.
I think the best you can do without the hassle of fixing the nodes every time is to see which sata modules you need (just boot and see which modules are loaded), and add them to the MODULES. For "safety" I'd recommend also adding some modules like usbinput (if you have usb keyboard), so that if something gets screwed and you'd be dropped into the emergency shell in initcpio, you can actually type something in
Offline
deleted
Last edited by Misbah (2012-02-14 05:08:35)
Offline
Leave the fallback image alone, unless you really know what you're doing. It's there to enable your system to boot if your default image stops working.
Offline
udev and mkinitcpio have nothing to do with each other. mkinitcpio is used ONLY by the boot loader to find, detect, and load the modules needed for your root filesystem. Once that is done, mkinitcpio is abandoned and deleted from memory. So, for me, it loads my disk module, ext3, and then dies.
Udev at boot time has nothing to do with this. The boot-time udev loads *every other module* your system needs. Not just the ones for your root fs.
Offline
Udev at boot time has nothing to do with this. The boot-time udev loads *every other module* your system needs. Not just the ones for your root fs.
So how are the /dev/ nodes created in initramfs? (I don't mean /dev/{null,zero,console,mem}).
Offline
the init script in the initrd
if [ ! -b "${root}" ]; then
# This duplicates code from the filesystem hook
# without this, mkinitcpio would fail for users who use
# neither the udev hook, nor the filesystem hook
msg "\nRoot device '${root}' doesn't exist, attempting to create it"
eval $(/bin/parseblock "${root}")
if [ "${BLOCKNAME}" = "unknown" ]; then
echo "ERROR: Failed to parse block device name for '${root}'"
elif [ -z "${BLOCKDEVICE}" ]; then
echo "ERROR: Failed to parse block device ids for '${root}'"
else
export root="${BLOCKNAME}"
echo "/bin/mknod \"${BLOCKNAME}\" b ${BLOCKDEVICE}"
/bin/mknod "${BLOCKNAME}" b ${BLOCKDEVICE} >/dev/null
fi
if [ ! -b "${root}" ]; then
err "Unable to create/detect root device '${root}'"
echo "Dropping to a recovery shell... type 'exit' to reboot"
echo "NOTE: klibc contains no 'ls' binary, use 'echo *' instead"
echo ""
echo "If the device '${root}' gets created while you are here,"
echo "try adding 'rootdelay=8' or higher to the kernel command-line"
PS1="ramfs$ " /bin/sh -i
msg "Rebooting..."
/bin/reboot
fi
fi
lol, I believe this is a feature especially added for phrakature...
Maybe someone knows best.
Last edited by carlocci (2008-04-24 17:58:45)
Offline
phrakture wrote:Udev at boot time has nothing to do with this. The boot-time udev loads *every other module* your system needs. Not just the ones for your root fs.
So how are the /dev/ nodes created in initramfs? (I don't mean /dev/{null,zero,console,mem}).
They are created with udev, sure, but there's only a small amount of modules in the initramfs image - that is, instead of loading 400 modules for every usb device, video card, and all that crap, it JUST loads enough to get at your root fs.
These /dev/ nodes are *not* copied to the live system either. Boot-time udev does everything *again*, it just doesn't need to reload any modules.
lol, I believe this is a feature especially added for phrakature...
Maybe someone knows best.
I'm not sure what you mean - can you clarify?
Offline
deleted
Last edited by Misbah (2012-02-14 05:08:02)
Offline
There's no one universally good answer what to do in such cases. First of all you have to know what you want from your system and what are the consequences of changing this or that in your config. If you're convinced that changes provided by "pacnew" or settings left in "pacsave" suits you then you should merge them into one, current configuration file. If no then you should discard one or another change. Either way you should know what you're doing.
It appears that adding BusLogic module is useful only for booting arch in vmware (as long as you don't have such controller phisically) so I'll discard this change. If you'll decide to do it too it has to be your own decision.
About the second part. If you have some time maybe you could update apropriate wiki section? It would be a nice contribution!
It's not the best thing when they call you a "member" you know…
Offline
carlocci wrote:lol, I believe this is a feature especially added for phrakature...
Maybe someone knows best.I'm not sure what you mean - can you clarify?
I believe so.
I mean it feels strange to have this duplicate code in the script and in the hooks, especially when there is the filesystems hook which does the same. This could be a pain to debug.
I think it would be better creating another minimal hook, rather than adding those lines to the script.
But I don't understand much of scripting itself, so I was waiting for someone more expert to give an explanation.
As for the lol, I imagined you dressed in a military suit shouting orders in german: "Ich ton't vant hooks"
Offline
I mean it feels strange to have this duplicate code in the script and in the hooks, especially when there is the filesystems hook which does the same. This could be a pain to debug.
Yeah, it's duplicate, but not that big of a deal. All it really does is let us figure out what our root device is. It's completely logical at this point, but a bit messy. Sometimes code just _is_ that way: messy.
Offline
Pages: 1