Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Creating an Initramfs
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Installing Gentoo
View previous topic :: View next topic  
Author Message
Orionos
n00b
n00b


Joined: 27 Apr 2014
Posts: 10

PostPosted: Sun Apr 27, 2014 2:41 am    Post subject: Creating an Initramfs Reply with quote

I'm given myself the challenge of installing Gentoo on my ReadyNAS. So far, I have completed an install using the handbook and one of Pappy's kernel-seeds (while mourning the site now being gone). So I have successfully built a kernel that will recognize all the hardware.

I now want to take it up a notch and boot from a root based on lvm, based on a LUKS-volume, based on a RAID-device. That means I need an initramfs. That's where the problems begin.

I've been at this for days, but everything I try, from a simple to a complex init-file (even a file that does nothing more than drop me in a busybox-shell) causes my test-system to get all the way to the framebuffer (that's the screen with the penguin-per-cpu, right?) and the message it's setting the system-clock.
Then the systems halts and my CAPS and SCROLL start blinking.

This is what I've tried so far to figure out where I went wrong:
- created an initramfs with genkernel (BOOT)
- unpacked said genkernel initramfs, and repacked it using the same command I used to create my own (BOOT)
- placed my own init in the file structure created by genkernel's initramfs (FAIL)
- and, of course, checked if all the necessary executables were statically linked and my init is executable.

So I conclude that it must somehow be my init-file. But even an echo or msg on the first line does nothing. You'd expect it to at least print something to the screen. Perhaps the init doesn't load at all?

Now I know I could create an initram using genkernel or dracut etc. But I really want to learn how to do this on my own first.

To reduce the work and complexity, I'm currently testing this on a VMware workstation without the RAID, using an MBR and GRUB Legacy (GRUB2 mkconfig got very annoying after about the 7th attempt)

So, I'm hoping someone here can help me troubleshoot this, 'cause I'm at the point where even Google doesn't inspire me anymore. What do you need from me?

PS On a sidenote, someone should update the Quick Install guide with GPT and GRUB2, and the handbook with the (new) predictable NIC names.
Back to top
View user's profile Send private message
kwesadilo
n00b
n00b


Joined: 12 Jul 2010
Posts: 66
Location: United States

PostPosted: Sun Apr 27, 2014 4:35 am    Post subject: Reply with quote

Does your kernel panic when you're using the genkernel initramfs or just when you're using your custom initramfs?

I'm trying to do basically the same thing as you except without RAID, but I'm not even making it far enough for my keyboard lights to blink. What bootloader are you using?

For my current install, I'm just trying to use a pre-built initramfs (either genkernel's or better-initramfs, whichever one I get to work first).

For my previous install, I made my own. I copied the device nodes for my hard disk partitions and had busybox, lvm, and cryptsetup statically linked. I think my /init looked something like
Code:
#!/bin/bash
cryptsetup luksOpen /dev/sda4 crypt
vgchange -ay
mount /dev/mapper/vg-usr /usr # Make usr available to udev because systemd is taking over everything :(
# ... Whatever chroot stuff is supposed to take place; I can't remember
I didn't have a LUKS/LVM root for that machine, so it wasn't that complicated. Also I realized at some point that my root filesystem was never getting fscked. But I was able to boot with that. I can probably pull up my actual /init if you want it.

When I unpacked my genkernel initramfs and dug through it, I noticed that all of the symlinks for the LVM subcommands were broken. I didn't worry about it that much, because I had bigger fish to fry. Is that the case for your initramfs?

Lastly, this advice didn't do anything for me, but I'll parrot it anyway: Try passing the "debug" and "initcall_debug" parameters to the kernel when you boot. That might give you some more console output so you can figure out why you're panicking.
Back to top
View user's profile Send private message
redcap
n00b
n00b


Joined: 10 Jul 2010
Posts: 24

PostPosted: Sun Apr 27, 2014 11:04 am    Post subject: Reply with quote

Hi,

I found cach0rr0's howto to be incredibile useful:

https://www.whitehathouston.com/documentation/gentoo/initramfs_howto.htm


Can you post your init-script?
Back to top
View user's profile Send private message
szatox
Apprentice
Apprentice


Joined: 27 Aug 2013
Posts: 298

PostPosted: Sun Apr 27, 2014 1:00 pm    Post subject: Reply with quote

What is the error message? Can your kernel decompress your modified initramfs? Initramfs build by genkernel seems to be compressed with XZ, but when i compressed my own initramfs with XZ it didn't work, gzip and bz2 were fine though
Back to top
View user's profile Send private message
Orionos
n00b
n00b


Joined: 27 Apr 2014
Posts: 10

PostPosted: Sun Apr 27, 2014 2:17 pm    Post subject: Reply with quote

Let's see if I can answer all in one post.

The genkernel initramfs works, it boots successfully. The LVM symlinks are indeed broken, it places relative symlinks in /sbin and the lvm executable in /bin. Probably an oversight on the part of the developers (lvm should be in /sbin). Doesn't break functionality as long as you prefix all commands with 'lvm'. For example: 'lvm vgchange -ay'.
I unpacked the XZ genkernel-initramfs and repacked it with GZIP and it still boots, so the compression method is not the issue.

@kwesadilo
I emerged my genkernel with USE="crypt cryptsetup" and created the initramfs with "genkernel --install --luks --lvm initramfs" For RAID, you'd presumably have to add '--mdadm'' to it as well, but I'm currently not (yet) using RAID either. I'm not sure if the USE-flags are still necessary, haven't tested yet.
I then got it to work by adding
"kernel /boot/kernel-3.12.13-gentoo crypt_root=UUID=1bdec473-d712-etc dolvm real_root=UUID=12d9c845-93e0-etc"
to my GRUB Legacy config. I don't know how to add such options in GRUB2, so I can't help you there. As you can see, I'm using UUID's, my eventual goal is to use a USB or (since it's a SAN) switch drives without breaking functionality. It works just as well with
"crypt_root=/dev/sda2 real_root=/dev/system/root"
If you get either one wrong, it'll drop you into a shell where you can experiment.
I think fschecks on crypt volumes don't happen, you'll have to make that part of your maintenance scripts.
The 'debug' and 'initcall debug' spam my screen ending with
'initcall 23_async_port_probe+0x0/0x70 returned 0 after 359775 usecs'

EDIT:
I read through your issue a bit, seems interesting. Don't have EFI though. My attempts with GRUB2 ended the same way, blinking lights. Probably because I simply don't know how to configure GRUB2. Shouldn't GRUB2 have crypt and lvm support built-in, allowing for booting without the need for an initramfs?
EDIT2:
The genkernel initramfs contains 'echo 1 > /proc/sys/kernel/printk' to avoid kernel message spamming. Maybe that's why you don't get output with 'debug' and 'initcall debug'?
EDIT3:
By the way, I don't know if this is of any help to you at all, but the switches for better-initramfs that work for me are "luks enc_root=/dev/sda2 lvm root=/dev/system/root" or the UUID equivalents.

@recap
Thanks, I'll start reading through that document. The issue with most documents I find is that they're all so old. It's hard to find anything past 2009, yet so much has changed since then. And almost all modern articles use genkernel & dracut.

The most basic yet functional init I use is:
Code:
# Mount PROC and SYS
echo -ne "Starting"
mount -t proc none /proc
mount -t sysfs none /sys
# echo 0 > /proc/sys/kernel/printk

# Decrypt and enable ROOT
/sbin/cryptsetup luksOpen /dev/sda2
/sbin/lvm vgscan --mknodes
/sbin/lvm lvchange -aly system/swap
/sbin/lvm lvchange -aly system/root

# Mount
mount /dev/mapper/system-root /mnt/root

# Finish
umount /proc
umount /sys

# Switch to ROOT and boot
exec switch_root /mnt/root /sbin/init

I put the echo in there just to see if it would show anything.

And finally, there's no error, just the holiday-lights on my keyboard. It appears it doesn't even complete the pre-initramfs (with genkernel it goes on a bit longer before initramfs gets executed). I never thought I'd say this, but I kinda miss the old-day kernel panic. Less flashy, more usefulness.

EDIT3:
I honestly don't know what makes my initramfs so different. Speaking in Windows terms, perhaps it's saved in a wrong format, like UTF8 instead of plain text?
EDIT4:
I just keep the edits coming. After considering the above, i did a 'file' on both inits:
Code:
# file /initramfs/init
/initramfs/init: ASCII text
# file /test/init
/test/init: POSIX shell script, ASCII text executable

It is set as executable though:
Code:
# ls -l /initramfs/ | grep init
-rwxr-xr-x 1 root root  437 Apr 27 17:48 init
# ls -l /test/ | grep init
-rwxr-xr-x 1 root root 21203 Apr 27 04:24 init

Could that be the issue? If so, how to fix my file?
(For clarification, the /test is the genkernel init, the /initramfs is mine)
EDIT5:
Never mind EDIT4, I added #!/bin/sh to the init and it was detected as a script. Still doesn't boot though.
Back to top
View user's profile Send private message
kwesadilo
n00b
n00b


Joined: 12 Jul 2010
Posts: 66
Location: United States

PostPosted: Sun Apr 27, 2014 6:10 pm    Post subject: Reply with quote

Orionos wrote:

@kwesadilo
I emerged my genkernel with USE="crypt cryptsetup" and created the initramfs with "genkernel --install --luks --lvm initramfs" For RAID, you'd presumably have to add '--mdadm'' to it as well, but I'm currently not (yet) using RAID either. I'm not sure if the USE-flags are still necessary, haven't tested yet.
I then got it to work by adding
"kernel /boot/kernel-3.12.13-gentoo crypt_root=UUID=1bdec473-d712-etc dolvm real_root=UUID=12d9c845-93e0-etc"
to my GRUB Legacy config. I don't know how to add such options in GRUB2, so I can't help you there. As you can see, I'm using UUID's, my eventual goal is to use a USB or (since it's a SAN) switch drives without breaking functionality. It works just as well with
"crypt_root=/dev/sda2 real_root=/dev/system/root"
If you get either one wrong, it'll drop you into a shell where you can experiment.
I think fschecks on crypt volumes don't happen, you'll have to make that part of your maintenance scripts.
The 'debug' and 'initcall debug' spam my screen ending with
'initcall 23_async_port_probe+0x0/0x70 returned 0 after 359775 usecs'

Looks like you're getting well past your bootloader anyway, so I doubt that's your problem. I think I'm dying either at the very end of my bootloader or the very beginning of my kernel.

Orionos wrote:

EDIT:
I read through your issue a bit, seems interesting. Don't have EFI though. My attempts with GRUB2 ended the same way, blinking lights. Probably because I simply don't know how to configure GRUB2. Shouldn't GRUB2 have crypt and lvm support built-in, allowing for booting without the need for an initramfs?

That's what I thought too, but it turns out that GRUB2's LVM/LUKS support only allows it to read the kernel and initramfs off of the encrypted volume. So my root is /dev/mapper/vgssd-root, but that doesn't exist when my kernel starts. So I need an initramfs to start my cryptodisk and logical volume.

Orionos wrote:

EDIT2:
The genkernel initramfs contains 'echo 1 > /proc/sys/kernel/printk' to avoid kernel message spamming. Maybe that's why you don't get output with 'debug' and 'initcall debug'?

Oh, I didn't know that. I'll have to check whether better-initramfs does that too. It would be really annoying if it were hiding all of my debug output.

Orionos wrote:

EDIT3:
By the way, I don't know if this is of any help to you at all, but the switches for better-initramfs that work for me are "luks enc_root=/dev/sda2 lvm root=/dev/system/root" or the UUID equivalents.

I have similar. It's good to know they're sort of working for somebody else.
Back to top
View user's profile Send private message
XavierMiller
Moderator
Moderator


Joined: 23 Jul 2004
Posts: 5442
Location: ~Brussels - Belgique

PostPosted: Sun Apr 27, 2014 6:13 pm    Post subject: Reply with quote

Hello,

Do you have /dev/console and /dev/null in your initramfs ?

I had problems until I create those 2 nodes. At leas /dev/console is mandatory, until devfs is created by the kernel.
http://wiki.gentoo.org/wiki/Custom_Initramfs

Mine looks like this:
Code:
#!/bin/busybox sh

rescue_shell() {
    echo "Something went wrong. Dropping you to a shell."
    exec /bin/sh
}

mount -t devtmpfs none /dev

# Mount the /proc and /sys filesystems.
mount -v -t proc none /proc
mount -v -t sysfs none /sys

busybox --install -s

loadkeys be-latin1

# Do your stuff here.
cryptsetup -d - luksOpen /dev/sda vg0
vgscan && vgchange -ay vg0

# Mount the root filesystem.
mount -v -o ro /dev/mapper/vg0-gentoo /mnt/root || rescue_shell

# Clean up.
umount /proc
umount /sys
umount /dev

# Boot the real thing.
exec switch_root /mnt/root /sbin/init ${CMDLINE}

_________________
Xavier Miller
(FR) Merci de respecter les règles du forum.
http://www.xaviermiller.be
Back to top
View user's profile Send private message
XavierMiller
Moderator
Moderator


Joined: 23 Jul 2004
Posts: 5442
Location: ~Brussels - Belgique

PostPosted: Sun Apr 27, 2014 6:26 pm    Post subject: Reply with quote

I'll add that your LVM2 binaries cannot be built with UDEV support, it doesn't work, since udev is not yet started.
_________________
Xavier Miller
(FR) Merci de respecter les règles du forum.
http://www.xaviermiller.be
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 31713
Location: 56N 3W

PostPosted: Sun Apr 27, 2014 6:39 pm    Post subject: Reply with quote

Orionos
Code:
# Mount PROC and SYS


You are missing
Code:
#!/bin/busybox sh
as the first line is your init script.
The #! is a single symbol called a shebang its not a comment.
It tells what program should be used to execute the following commands in the file.

Heres how I used to do it.
However, there is no crypto there and I use a static /dev in the initrd. With DEVTMPFS, thats no longer needed.

If you do have some dynamically linked proyrams to install in the initrd, you need to use lddtree to make sure you get all the bits.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Orionos
n00b
n00b


Joined: 27 Apr 2014
Posts: 10

PostPosted: Sun Apr 27, 2014 9:50 pm    Post subject: Reply with quote

Wow, that's a lot of replies all at once.

@kwesadilo
So, GRUB2 can read from an encrypted /boot, but still needs an initram to run cryptsetup to decrypt the root? What if /boot is in the same partition as / ? Technically, / would be readable. Then again, as soon as GRUB ends, so does the decryption key and with it the filesystem. These paradoxes (paradoxi?) make my head spin.
I checked better-initramfs for you. Sorry:
Code:
# Disable kernel messages from popping onto the screen
echo 0 > /proc/sys/kernel/printk

I don't know if that blocks the debug messages, but it would be logical. On the plus side, that would mean you made it to the initramfs.

Sidenote: what's the difference between 'echo 0' (better-initramfs) and 'echo 1' (genkernel)?

@Neddy
I actually had #!/bin/sh in there. But I suppose it doesn't work without the symlink for 'sh' to busybox.
Thanks for the link, I'll take any opportunity to learn. Using hardened is one challenge I gave up on for now. When I tried, I got no DHCP (only static IP), and no SSH (until I created the tty devices), not to mention a load of gcc errors. And that was just to start out with. I just don't know enough.

Anyway, with the '#!/bin/busybox sh' it actually started working. Working, as in revealing how fundamentally broken my init was. No name-mapping for cryptsetup, lvm nodes weren't created and mount failed. I then proceeded to destroy my initramfs file structure by accidentally unpacking the better-initramfs cpio into it (for kwesadilo above). 8O

But at least it gets run. Thank you for embarrassing me by stating the obvious.

@Xavier
As stated, the shebang was what I needed. I'll be putting that rescue shell in my next init though, thanks!
As for UDEV, that's one more thing that makes my head spin. Hey, what do you expect, I'm a Microsoft administrator. I do powershell-scripting, not shell-scripting.

I'll go and rebuild my initramfs and try again. Let's see if I can manage now.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 31713
Location: 56N 3W

PostPosted: Sun Apr 27, 2014 10:19 pm    Post subject: Reply with quote

Orionos,

Hardened is just a distraction in my link.
The initrd is the same regardless.

Ignore udev. Its not needed in the initrd.

DEVTMPFS and MOUNTDEVTMPFS in the kernel will populate /dev in the initrd.
As the init script in the initrd runs as root, you don't care about correct owners and permissions on the /dev entries. At least, not in the initrd.
The initrd is not an attack vector unless you put networking in there, so its the same risk as any other physical access attack.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
kwesadilo
n00b
n00b


Joined: 12 Jul 2010
Posts: 66
Location: United States

PostPosted: Sun Apr 27, 2014 10:43 pm    Post subject: Reply with quote

I'm not super clear on how the handoff between GRUB and the kernel works, but here's what I think is going on. GRUB just needs to be able to read the kernel off of whatever disk it's on so that it can load it into memory. Then GRUB passes control to the kernel and is no longer active and probably not even in memory anymore. The kernel doesn't initially know where any of the devices are, but it can probe for them. When it's found all of the block devices, it uses the kernel boot parameters (passed to it by GRUB, presumably on the kernel's stack in memory) to figure out where to find the root filesystem, and then it runs /sbin/init on that filesystem. In this scenario, you wouldn't need an initramfs.

When the root filesystem is on a virtual device, the kernel won't find it by probing, because it needs to be set up first. This presents a chicken-and-egg problem, because /sbin/init contains the commands necessary to set up the virtual device, and the virtual device needs to be available to read /sbin/init. This is where the initramfs comes in. <speculation>The kernel doesn't need to load the initramfs from an inaccessible filesystem, because GRUB already loaded it into memory where the kernel can access it (or it was compiled into the kernel and is now in the kernel's memory already).</speculation> The kernel can load /init from the initramfs, run the commands that it needs to, and then jump into the real root once the virtual device for the root filesystem (in my case /dev/mapper/vgssd-root) has been created.

The above could be wrong. I'm unfamiliar with the Linux boot protocol. But that at least seems like it could work. As to why the kernel can't just probe for device mapper block devices itself, I assume that they wanted to keep the kernel early boot routines relatively simple. After all, there are like an infinite number of weird ways that you could boot, and making the kernel check for all of them would be pretty complex and almost always unnecessary. I think using an initramfs to do just the setup necessary for your system conforms more closely to the Unix philosophy.

That's disappointing about better-initramfs, but I suppose it's easily remedied. The deal with the numbers is that there are different levels of log importance within the kernel. I can't remember the name of each number, but you can look it up. Lower numbers correspond to more important things and higher numbers to less important things. I think 0 would be no logs at all, and 1 would be only critical errors. I think the debug parameter sets it to the highest level (9?), which corresponds to debugging messages. The lower the number, the less output you get. You can check what the actual numbers are if you want to play around with it.

I'll give it a shot with the logging turned on an see what happens. However, given that I don't see blinking lights when I crash, I suspect I'm crashing before /init starts rather than crashing after it starts and just not seeing my logs.
Back to top
View user's profile Send private message
Orionos
n00b
n00b


Joined: 27 Apr 2014
Posts: 10

PostPosted: Sun Apr 27, 2014 11:59 pm    Post subject: Reply with quote

Okay, so it works!

I used recap's link for some easy copy & paste instructions, and ended up with this (minus the commented sections):
Code:

#!/bin/busybox sh

rescue_shell() {
        echo "Something went wrong. Dropping you to a shell."
                busybox --install -s
        exec /bin/sh
        }

mount -t proc none /proc
mount -t sysfs none /sys
mount -t devtmpfs none /dev

cryptsetup -T 5 luksOpen /dev/sda2 system

lvm vgchange -ay
lvm vgscan --mknodes

mount -o ro -t ext4 /dev/system/root /mnt/root || rescue_shell

umount /proc
umount /sys
umount /dev

exec switch_root /mnt/root /sbin/init

That shell helped a great deal in troubleshooting why my lvm wasn't working. Turns out I needed vgchange -ay first to activate the now decrypted and thus visible volumes, only then would vgscan --mknodes create the references in /dev
If I ran vgscan first, it would see the volumes but do nothing.

I also added the fstype to the mount command, since it tried mounting as ext2 & 3 first, I've had quite enough error messages, thank you.

A few questions:
So if I have DEVTMPFS and DEVTMPFS_MOUNT active in my kernel, I only need to create a /dev in my initramfs? Because I only have the first active right now, and my /dev was quite populated. Or is that because I did mount -t devtmpfs none /dev in my initramfs? So if I enable the mount in my kernel, I don't need it in my initramfs?

Why do all those initramfs instructions end with the umounts? Isn't that automatically done when the initramfs unloads from memory?

Anyway, next up is to use UUID's instead of absolute paths. Then I'll do the whole thing in GPT/GRUB2 (expect questions about G2). Next add the RAID. That will be during the next two days.

Do I still need to do mdadm if I have CONFIG_MD_AUTODETECT in my kernel?

Finally, for the icing on the cake, I want to see if I can add SSH in there (the NAS will be headless after all) and use a USB stick with the decryption key. When I finally figure out how to do more than post Hello, world! to my LCD (echo E "Hello, world!" > /dev/ttyS1), I might even try implementing that (asking for my USB key for example). Hope you'll check back every now and then, I'm sure I could use the help.

@kwesadilo
To make it easy:
Code:

cd /tmp/
wget https://bitbucket.org/piotrkarbowski/better-initramfs/downloads/release-x86_64-v0.8.0.1.tar.bz2
tar xvf release-x86_64-v0.8.0.1.tar.bz2
cd release-x86_64-v0.8.0.1_NAIo0/
mkdir /usr/src/betterinit
cd /usr/src/betterinit
cpio -vid < ../tmp/release-x86_64-v0.8.0.1_NAIo0/initramfs.cpio
nano -w init
find . -print0 | cpio --null -ov --format=newc | gzip -9 > /boot/initramfs-3.12.13-better

Obviously, you may need to change your initram-name, and the text editor if you're a vi/vim addict.

I may try to do your install as well to see if I can help. VMware Workstation doesn't appear to have EFI, but there are advantages to working as a VMware admin. Like having lots of vSphere at my disposal at work. ESXi does have EFI.

PS I finally figured out why your nickname sounded so familiar. Been nagging me all day. Quesadillo. Love the UrbanDictionary explanation. :D
Back to top
View user's profile Send private message
redcap
n00b
n00b


Joined: 10 Jul 2010
Posts: 24

PostPosted: Mon Apr 28, 2014 4:29 pm    Post subject: Reply with quote

Starting a ssh-server from the initramfs works perfectly fine. The instructions here are based on a Debian system but I think they will get you started:

http://blog.neutrino.es/2011/unlocking-a-luks-encrypted-root-partition-remotely-via-ssh/
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 31713
Location: 56N 3W

PostPosted: Mon Apr 28, 2014 9:56 pm    Post subject: Reply with quote

Orionos,

CONFIG_MD_AUTODETECT only works with raid metadata version 0.90 raid sets.
Its not needed with mdadm in the initrd and quite useless with raid metadata version >= 1

mdadm --create defaults to metadata 1.2, which is what you will have if you didin't know the above.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Orionos
n00b
n00b


Joined: 27 Apr 2014
Posts: 10

PostPosted: Mon Apr 28, 2014 10:17 pm    Post subject: Reply with quote

@redcap
Thanks, I'll add it to my list of locally saved webpages.

@Neddy
I remember reading somewhere that metadata 0.90 was no longer necessary with GRUB2 (or modern kernels, I forgot which). It's still in most instructions floating around though.



As it turns out, performing a luksOpen by UUID fails because the /dev/disk/by-uuid is apparently populated by UDEV. So, I changed my cryptsetup command into
Code:
cryptsetup luksOpen $(findfs UUID=1bdec473-d712-48d8-bff5-d5943eaa2619) system

It's a bit unsophisticated, but it does the job.

I'm beginning to feel that when I'm done, my init will have an eerie resemblance to better-initramfs. At least I'll know exactly how it works then.

Tomorrow I'll do a clean install using GPT and GRUB2, combined with the kernel/initramfs that I now know works. Do I need to pass any extra options to the GRUB config file, or will it detect the right options automatically? Also, do I need to run grub2-mkconfig every time I make a change to the initramfs, or can I just replace the current initramfs with an identically named new one (like I do with GRUB1)?

Completely off-topic: I seem to have pressed a key in vim while on the word mount, and now every time I open vim it highlights every instance of that word, even across reboots. Any idea what I did?
Back to top
View user's profile Send private message
khayyam
Advocate
Advocate


Joined: 07 Jun 2012
Posts: 2184

PostPosted: Tue Apr 29, 2014 2:08 am    Post subject: Reply with quote

Orionos wrote:
Completely off-topic: I seem to have pressed a key in vim while on the word mount, and now every time I open vim it highlights every instance of that word, even across reboots. Any idea what I did?

Orionos ... it sounds like 'hlsearch', you should be able to clear it with :nohlsearch (which will only disable the current search highlight, the next search should reset it). If I'm correct, then hlsearch must be enabled in your .vimrc as the default is nohlsearch.

If it persists then I'm not sure exactly what it might be, you could look in .viminfo which is where such persistant data is stored (and of course removing that file will reset all searches, command history, etc).

HTH & best ... khay
Back to top
View user's profile Send private message
Orionos
n00b
n00b


Joined: 27 Apr 2014
Posts: 10

PostPosted: Wed May 07, 2014 12:35 am    Post subject: Reply with quote

Took me a bit longer, had to install a new front door and pass a VMware exam which proved more annoying than I thought.

I did a new install, CRYPT -> LVM -> EXT4 on GRUB2. With the initram I'd created/fixed thanks to you, the system now boots on GRUB2. Unfortunately, it took a bit of checking to figure out what grub2-mkconfig expected the filename of the init to be.

Next up will be to add the MDADM layer, first on a single drive (creating a broken RAID1 set). Then maybe I'll see about encrypting that /boot with GRUB2, should prove a challenge. Next, USB decryption keys. Finally, SSH decryption. Apart from LCD control, that should meet every demand I could want.

Almost done with the core system.

EDIT:

I now have MDADM operational. GRUB2 threw out some errors though:
Code:

# grub2-install /dev/sda
/usr/sbin/grub2-probe: warning: Couldn't find physical volume `(null)'. Some modules may be missing from core image..
/usr/sbin/grub2-probe: warning: Couldn't find physical volume `(null)'. Some modules may be missing from core image..
Installation finished. No error reported.

# grub2-mkconfig -o /boot/grub/grub.cfg
Generating grub.cfg ...
Found linux image: /boot/kernel-3.12.13-gentoo
Found initrd image: /boot/initrd-3.12.13-gentoo
/usr/sbin/grub2-probe: warning: Couldn't find physical volume `(null)'. Some modules may be missing from core image..
/usr/sbin/grub2-probe: warning: Couldn't find physical volume `(null)'. Some modules may be missing from core image..
/usr/sbin/grub2-probe: warning: Couldn't find physical volume `(null)'. Some modules may be missing from core image..
done


Any reason?

System still booted though.

The second thing that happened was when trying to mount the RAID arrays during the init:
Code:

# mdadm --assemble --scan
mdadm main: failed to get exclusive lock on mapfile


No arrays were detected, even though I had defined them in mdadm.conf
I did not define the DEVICE option in mdadm.conf, only the ARRAYs because I need to figure out how to do that with UUIDs.

As it turns out, when I initially created the arrays using the System Rescue CD using
Code:

# mdadm --create --name=boot --verbose /dev/md1 --level=1 --raid-devices=2 /dev/sda2 missing
mdadm: size set to 130944K
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.


it named itself sysresccd:boot, apparently an array belonging to the sysresccd system.
As a result, the default mdadm --assemble --scan didn't mount them.

Once I renamed them using
Code:
mdadm --assemble /dev/md1 --name=GenTST:boot --update=name /dev/sda2

it started mounting them. I still get failed to get exclusive lock on mapfile though.

Question: Assuming this is standard behavior, how would the initram-environment know whether it's running on sysresccd or GenTST? The hostname hasn't been defined yet.

Next will be USB decryption keys and SSH. The encrypted /boot requires a re-install, I've already done 3 today.

@khayyam
vim did indeed have a default search history. A colleague and vim-fanboy pointed it out. Very annoying. Thanks!
Back to top
View user's profile Send private message
Orionos
n00b
n00b


Joined: 27 Apr 2014
Posts: 10

PostPosted: Fri May 23, 2014 2:30 pm    Post subject: Reply with quote

The encrypted boot failed, even with the extra option passed to GRUB2 (GRUB_CRYPTODISK_ENABLE=y), it still fails, stating it can't boot from the device, and therefore doesn't want to install. Maybe that only works with EFI, where the loader can be placed in the BIOS?

Also, does anyone have any instructions for SSH access to the initramfs? Everything I find has instructions for initramfs-tools and genkernel, I haven't found a single thing on how to do it manually.
I figure I should first get the environment to get on the network, in the case of a static IP that should be little more than 'ifconfig' in the initramfs. Then dropbear, then figure out how to work with a key etc.

Anyone?
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Installing Gentoo All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum