Re: [gentoo-user] Re: kernel choices for booting gentoo as guest in vbox vm

[Alexander Kapshuk]

On Fri, Feb 2, 2018 at 6:32 AM, Harry Putnam  wrote:
> Alexander Kapshuk  writes:
>
> [...]
>
>>> Can anyone tell me what they used to allow gentoo in vbox to boot?
>>>
>>>
>>>
>> Did you enable the recommended kernel config options as suggested here [1]?
>> [1] https://wiki.gentoo.org/wiki/VirtualBox
>
> I did go thru that page and `think' I checked them off but I came to
> that URL kind of late in the game... It would have no doubt went
> better if I'd caught that earlier on.
>
> It does appear to share some confusion with a couple of other pages.
> I don't have them to hand but one said flatly not to use `any' of the
> first bunch of framebuffer settings (1st and 2nd is based on how they
> are arranged in `menuconfig') and to only use the second set (a few
> lines below).
>
> They were saying that the kernel frame buffering will absolutely
> not work if one employs any of the settings from the first bunch.
>
>

The Kernel modesetting section of the xorg guide,
https://wiki.gentoo.org/wiki/Xorg/Guide, recommends disabling most of
the drivers listed in the 'Support for frame buffer devices' section
of .config.
I could be wrong, but I believe that applies to installing the kernel
on real hardware specifically.

For emulated environments, such as virtualbox, the instructions given
in the wiki article for virtualbox take precedence.
Virtualbox uses GPU frame buffers and has routines that convert GPU
memory layouts to kernel ones and back, as far as I can tell.

Re: [gentoo-user] Re: kernel choices for booting gentoo as guest in vbox vm

[J García]

2018-02-01 7:57 GMT-06:00 Harry Putnam :


> I did get a screenshot but it is very limited showing only a couple
> dozen lines of the boot messages. (attached at the end.)
>
The kernel is not able to mount root.
What filesystem did you use? If you used something that is not
included by default like ext4, you may be missing the drivers, or you
may have them as loadable modules, when you need them to boot.
Try to set a label for the root partition if you haven't, reboot,
change grub to edit the boot commands, change the root argument for
the linux command line to root=LABEL=yourlabel and continue.

[gentoo-user] Re: kernel choices for booting gentoo as guest in vbox vm

[Harry Putnam]

Alexander Kapshuk  writes:

[...]

>> Can anyone tell me what they used to allow gentoo in vbox to boot?
>>
>>
>>
> Did you enable the recommended kernel config options as suggested here [1]?
> [1] https://wiki.gentoo.org/wiki/VirtualBox

I did go thru that page and `think' I checked them off but I came to
that URL kind of late in the game... It would have no doubt went
better if I'd caught that earlier on.

It does appear to share some confusion with a couple of other pages.
I don't have them to hand but one said flatly not to use `any' of the
first bunch of framebuffer settings (1st and 2nd is based on how they
are arranged in `menuconfig') and to only use the second set (a few
lines below).

They were saying that the kernel frame buffering will absolutely
not work if one employs any of the settings from the first bunch.

[gentoo-user] Re: kernel choices for booting gentoo as guest in vbox vm

[Harry Putnam]

David Haller  writes:

[...]

>>I've never used genkernel, but from what I understand it builds
>>everything + the kitchen sink.. so should get the right drivers
>>hopefully. 
>
> Actually no, you can quite easily configure it to just the tedious
> work.

First, thanks for the cogent and helpful post.

Now about the statements above.

Its hard to tell what you mean there. I said I figured since genkernel
builds so much stuff, its a good chance I will have the stuff I need
to get booted.

You start by saying `Actually no,' so do you mean there is a pretty good
chance I will NOT get the drivers I need? If so, then I may be wasting
my time with genkernel.

Or were you just saying that if you configure genkernel correctly you
can keep it from creating so much unneded junk?


> Currently I use this:
>
> 1. install new kernel sources (in my case vanilla-sources)
> 2. copy over old config from last source tree, /boot/, /proc/config.gz
>whatever
> 3. run 'make oldconfig'
> 4. optionally note down some new options and then checkup on them using
>'make menuconfig' and searching for the noted options
>it's this step I want to be able to do why I configured genkernel as
>I did (see below)
> 5. run 'genkernel --kerneldir=. all', but note config below!
> 6. check /boot/ and /boot/grub*/ if all went right
> 7. recompile neccessary out-of-tree drivers like e.g.
>x11-drivers/nvidia
> 8. done
>
> If I just reconfigure, I start at step 4, change the localversion too
> in menuconfig. If something breaks, I run 'make clean', save config
> and run 'make mrproper' restore config, etc.

That is a nice walk thru... I can't say I understand all of it, and
currently I have a genkernel compile running... (It seems to take a
really long time to complete) So probably it'll be tomorrow.

Nice to see.  Lots of it is default.

I think I would like to have a look at /usr/src/linux/.confg if that
is not getting too snoopy.  I realize it will not be the same as mine
but what is 

>  delcomments /etc/genkernel.conf [1]
> OLDCONFIG="no"
> MENUCONFIG="no"

[...]

> Of course you must adapt the options for your needs, esp. those for
> the initrd if you boot from e.g. a md-device and some such.
>
> I don't actually use the generated initrd, but having them in /boot
> with less that 3MB in my case is ok and might come in handy when
> something fails.

I have'nt used an initrd for at least 15 yrs.  So all pretty much like
new stuff.

> For me, this has worked nicely the last years. Esp. generating the
> grub1 entries and handling the symlinks to the current and last
> kernel, initrd and System.map works flawlessly[2].

OK, that sounds comforting, and promising

[...]


> [2] ok, if you manually prune versions from the middle, you'll need to
> set the .old symlinks back to an older version (or the current?),
> haven't checked that yet, but setting it to the previous remaining
> version works nicely.
>
> I still haven't checked too, if you could have this setup:

No, not like that... In this case there has been no OS before.  This a
fresh install after a hiatus from gentoo of about a year.  I did run
gentoo for 4-5 yrs awhile back..

I've been running primarily openindiana (x86 solaris-11* ish, powered
by illumos) I like that zfs file system.  But also have kept my home
mail setup on Debian.  I've tinkered fairly extensively with `lubuntu'
(Notice the `el'(l) in front... supposed to indicate a lightish version of
ububtu) It defaults to the lxde desktop which I like a lot too.

>
> title=Gentoo current kernel
>   root (hd0,1)
>   kernel /boot/kernel OPTIONS...
>   [initrd /boot/initramfs]


I also see you are using legacy grub. I moved to grub2 some 5-6 mnths
ago. But not on Openindiana


> and that new versioned entries would be put at the "HERE" or at the top.
>
> I marked the 'initrd' stuff as optional with the [], as I don't use
> an initrd.

I'm not really sure how blend your approach into grub2 but I could
drop back to legacy grub 

> And maybe some other boot options (e.g. for another distro or Winders)
> sprinkled in at some location.
>
> Anyway, generally genkernel is a great help and occasionally
> pruning/reordering entries in the grub1 /boot/grub/menu.lst is easy,
> just delete/move stuff around with $EDITOR :)
>
> I never understood why grub2 chucked out the major advantage grub1 had
> over lilo: not needing to re-install the boot-sector / stage1 of the
> bootloader after every change to the config... Beats me still today.
> Which is why I continue to use grub1, which can do all I need (and
> more) just nicely. Thank you very much.

Some of the debian based OSs' out there do not make that too
easy... (staying with grub1) But it seems easily done in gentoo.

Thanks again for the helpful post.

Re: [gentoo-user] Re: kernel choices for booting gentoo as guest in vbox vm

[David Haller]

Hello,

On Thu, 01 Feb 2018, Harry Putnam wrote:
>I did get a screenshot but it is very limited showing only a couple
>dozen lines of the boot messages. (attached at the end.)

Still helps: device 8,65 is /dev/sde1. Check on that ;) E.g. in the
fstab inside the initrd ... And keeping the initrd up-to-date is one
thing genkernel makes easy BTW ;)

Check your bootloader config! Check your initrd. Check your fstab (and
regenerate your initrd if changes concern the root- or resume-device).

>I've never used genkernel, but from what I understand it builds
>everything + the kitchen sink.. so should get the right drivers
>hopefully. 

Actually no, you can quite easily configure it to just the tedious
work.

Currently I use this:

1. install new kernel sources (in my case vanilla-sources)
2. copy over old config from last source tree, /boot/, /proc/config.gz
   whatever
3. run 'make oldconfig'
4. optionally note down some new options and then checkup on them using
   'make menuconfig' and searching for the noted options
   it's this step I want to be able to do why I configured genkernel as
   I did (see below)
5. run 'genkernel --kerneldir=. all', but note config below!
6. check /boot/ and /boot/grub*/ if all went right
7. recompile neccessary out-of-tree drivers like e.g.
   x11-drivers/nvidia
8. done

If I just reconfigure, I start at step 4, change the localversion too
in menuconfig. If something breaks, I run 'make clean', save config
and run 'make mrproper' restore config, etc.

 delcomments /etc/genkernel.conf [1]
OLDCONFIG="no"
MENUCONFIG="no"
CLEAN="no"
MRPROPER="no"
MOUNTBOOT="yes"
SYMLINK="yes"
SAVE_CONFIG="yes"
USECOLOR="yes"
LVM="no"
LUKS="no"
GPG="no"
DMRAID="no"
BUSYBOX="yes"
MDADM="no"
MULTIPATH="no"
ISCSI="no"
E2FSPROGS="yes"
ZFS="no"
BTRFS="no"
FIRMWARE="no"
FIRMWARE_DIR="/lib/firmware"
FIRMWARE_FILES=""
DISKLABEL="yes"
BOOTLOADER="grub"
SPLASH="no"
DOKEYMAPAUTO="no"
KEYMAP="0"
GK_SHARE="${GK_SHARE:-/usr/share/genkernel}"
CACHE_DIR="/var/cache/genkernel"
DISTDIR="${GK_SHARE}/distfiles"
LOGFILE="/var/log/genkernel.log"
LOGLEVEL=5
DEFAULT_KERNEL_SOURCE="/usr/src/linux"
BUSYBOX_APPLETS="[ ash sh mount uname echo cut cat mdev switch_root findfs 
umount unxz xz cpio fsck fdisk halt insmod less lzop makedevs modinfo modprobe 
reboot"
RAMDISKMODULES="0"
COMPRESS_INITRD="yes"
COMPRESS_INITRD_TYPE="gzip"
WRAP_INITRD=no


Of course you must adapt the options for your needs, esp. those for
the initrd if you boot from e.g. a md-device and some such.

I don't actually use the generated initrd, but having them in /boot
with less that 3MB in my case is ok and might come in handy when
something fails.

For me, this has worked nicely the last years. Esp. generating the
grub1 entries and handling the symlinks to the current and last
kernel, initrd and System.map works flawlessly[2].

HTH,
-dnh

[1] delcomments does just that, omit shell-style comments and empty
lines

#!/bin/sed -f
/^[[:space:]]*#/d
/^[[:space:]]*$/d


[2] ok, if you manually prune versions from the middle, you'll need to
set the .old symlinks back to an older version (or the current?),
haven't checked that yet, but setting it to the previous remaining
version works nicely.

I still haven't checked too, if you could have this setup:


[options omitted]

title=Gentoo current kernel
  root (hd0,1)
  kernel /boot/kernel OPTIONS...
  [initrd /boot/initramfs]

title=Gentoo old kernel
  root (hd0,1)
  kernel /boot/kernel.old OPTIONS...
  [initrd /boot/initramfs.old]

### <<=== HERE

title=Gentoo Linux (4.15.0-dnh1)
  root (hd0,1)
  kernel /boot/kernel-genkernel-x86_64-4.15.0-dnh1 OPTIONS...
  [initrd /boot/initramfs-genkernel-x86_64-4.15.0-dnh1]

title=Gentoo Linux (4.14.15-dnh1)
  root (hd0,1)
  kernel /boot/kernel-genkernel-x86_64-4.14.15-dnh1 OPTIONS...
  [initrd /boot/initramfs-genkernel-x86_64-4.14.15-dnh1]
...


and that new versioned entries would be put at the "HERE" or at the top.

I marked the 'initrd' stuff as optional with the [], as I don't use
an initrd.

And maybe some other boot options (e.g. for another distro or Winders)
sprinkled in at some location.

Anyway, generally genkernel is a great help and occasionally
pruning/reordering entries in the grub1 /boot/grub/menu.lst is easy,
just delete/move stuff around with $EDITOR :)

I never understood why grub2 chucked out the major advantage grub1 had
over lilo: not needing to re-install the boot-sector / stage1 of the
bootloader after every change to the config... Beats me still today.
Which is why I continue to use grub1, which can do all I need (and
more) just nicely. Thank you very much.

-- 
Too bloated to crash, it can only bounce gently into the limits set by
the laws of physics and stop, wobbling slightly.-- unknown

[gentoo-user] Re: kernel choices for booting gentoo as guest in vbox vm

[Harry Putnam]

80x24  writes:

> On Wed, Jan 31, 2018 at 8:44 PM, Harry Putnam  wrote:
>> Installing gentoo as guest into vbox vm on solaris-11 (openindiana)
>> HOST
>> gentoo-17
>> VBox 5.2.6
>> Kernel 4.15.0
>>
>> My first boot resulted in resulted in a kernel panic... not able to
>> mount root.
>>
>
> Maybe taking a video record or screenshot and providing a extact log
> message would help.
>
>> In a chroot now I can see lspci -k shows ata_piix in use .. but that
>> would probably be because in vbox I have the gentoo install media on
>> IDE secondary master.  But also shows sata controller ahci
>
> In case device driver is fine, you would want to check the filesystem
> type. I've done something like using btrfs as rootfs but didn't mark
> btrfs as builtin module.
>
> Similar kernel panic.

OK, tried the video capture but the video file never shows up.
That is, I used settings on vbox manager panel to enable video
capture. Start the bootup and I can see the video camera icon in
bottom right of vm window spinning as it should.

But, when the `panic' shows up I click the camera Icon as the
directions say to do to end capture and retrieve the vid file.

At the point of `panic'.. clicking the camera has no effect and it
continues to spin.

Trying to guess when the panic is about to happen and clicking just
ahead of the event does not produce a video file, nor does it stop the
camera spinning.

I did get a screenshot but it is very limited showing only a couple
dozen lines of the boot messages. (attached at the end.)

The log produced by Vbox is useless and I could see nothing useful in
it.  It is some kind of codified account of the VBox actions and has
nothing to say about the OS in the vm.  I'm pretty sure the `panic'
has nothing to do with the VBox controller.

I'm at the point now, after at least 5 reconfigurings and rebuilds
of the kernel, to no avail, that I'm going to try the genkernel
approach.

I've never used genkernel, but from what I understand it builds
everything + the kitchen sink.. so should get the right drivers
hopefully.