Re: [gentoo-user] Re: kernel choices for booting gentoo as guest in vbox vm
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
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
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
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
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
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.