[gentoo-user] Re: martian source with unknown IP and MAC
Grant gmail.com> writes: > I received a suspicious prompt while browsing a financial account of mine on my laptop so I restarted my modem but did not DHCP to it. I immediately received a series of type 08 00 martian sources logged to dmesg on my laptop from a 10.x.x.x source while my local network runs on 192.168.x.x only, and the logged MAC address does not match that of any systems on my LAN including the modem and I don't run wifi. Is that martian source suspicious? Always. But it could be a benign or mangled packet. Hard to tell without deeper analysis This might help [1]. As well as RFC 1812 [2] Post back if needed. [3] hth, James [1] http://www.cyberciti.biz/faq/linux-log-suspicious-martian-packets-un-routable-source-addresses/ [2] https://www.novell.com/support/kb/doc.php?id=3923798 [3] https://6session.wordpress.com/2009/04/08/ipv6-martian-and-bogon-filters/
[gentoo-user] Re: Install PreQualifying Matrix
Jeremi Piotrowski gmail.com> writes: > Planning questions are an OK-ish idea, but I surely wouldn't link to > derivative distributions to answer them. We have appropriate wiki pages > for all options, those that are insufficient should be improved. These > could be linked to so that people know what to expect. I'm not suggesting that the handbook not be referenced or recommended. I'm suggesting that we point to some sites for quick installs, including gentoo livedvd. Others might be after a failed handbook install. It's an idea, certainly not a mutiny But I do see that the handbook being the face of the gentoo install experience is sub optimal. ymmv. I think it should be an reference option for those ready for a deeper learning (pedantic) experience. I do think there is room for a quickie install semantic, if not many other install semantics other than the handbook. Hence the idea of the Planning Matrix Questions before a particular installation semantic is chosen by the new user. > > What I really would appreciate is some feedback on the Planning > > Questions listed below, as to help folks organized their thoughts and > > hardware details BEFORE actually performing an install or test-drive. > It's always good to plan before doing something so *this* part of your > proposal I support. Yes the idea works with just keeping the status quo for installs (pain and torture via the handbook) too. That's a minimal scope of what I have in mind so hence I'm first shopping the idea here to give gentoo the first shot. If not, I might just put up a neutral site and point to all the gentoo derivative distros; and let folks choose as they like. I've been on this list over 10 years now. I'm pretty convicted about this need to offer up a softer face to gentoo installs, one way or another. Sites like distrowatch do Gentoo a great dis-service. > > A recent discussion of the dev list showed > > encouragement for pointing gentoo-noobs to some of the gentoo derivative > > distros for a quick install experience. > Perhaps it would be enough to extend this page > https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/About That seems like a page to read just before attempting a Handbook install. However, you can take what ideas you like and make those mods as you like. What I'm talking about is a set of questions that help a user prepare the info and make critical decisions, like systemd vs openrc. > and under `Troubles` mention derivative distributions (by name) with a > _hint_ that their installers quickly lead to a working base system. That sounds like a good idea; do you have rights to the wiki page? Gonna post a bgo doc bug? > The decisions to be made during the installation are mostly orthogonal, so > I wouldn't try to break the current installation procedure which is for > the most part linear. Many think the current install (via the handbook) is like kissing a sour lemon on the first date. ymmv. > A matrix implies some form of interaction between the options, which I > don't quite see. The proposal is for planning before the install occurs. It does suggest that the handbook be only one of the possible pathways to a successful installation of gentoo (or a limited number of gentoo derivatives). It can be a (3) column table with links to appropriate install semantics. It's a thought looking for comments; not a hard pitch at all. I think I have identified some excellent questions to pose to potential gentoo install noobs, so they at least prepare for whatever installation semantic they choose to follow. If folks do not like the idea of pointing to other distros with installer programs. OK. That can be something informally suggested. I thought the link to calculate where its is clearly explained how to covert a calculate linux install to a gentoo install, is a valid idea and it first appeared in gentoo-dev. Many of the devs are aware of the drudgery of installing gentoo via the handbook. Sure many folks think that pain is necessary, but I do disagree, strongly. I never taught like that in any of my labs or folks I have mentored over the decades. But the 'hard ass' approach is a popular, legacy mentality and many youthful as well as older folks with experience just do not respond well to that sort of speech, imho. That's what the combination of the handbook and many responses in gentoo-user project, imho. Calcuate linux keeping a page around where folks and easily see how to convert a calculate linux install to a gentoo install is very classy on their part as they are interested in what is best for the user. > > straightforward for folks to discern the best route to their desired > > final result. When new installation semantics [1] mature, the > > installation matrix can be modified to include those options as links. > > Install PreQualifying Matrx::QUESTIONS > > Live Testdrive options before installation(usb/cd/dvd):: > Pretty much already covered by > https://wiki.gentoo
[gentoo-user] Re: [~amd64] Keyboard stops working several times/day
On Mon, 17 Aug 2015 18:51:34 +0200 Heiko Baums wrote: > Am 16.08.2015 um 18:45 schrieb walt: > > I've been seeing this keyboard problem for the past few weeks: > > after running some command from a bash prompt (haven't tried zsh > > yet) the keyboard stops working. Almost like somebody unplugged > > the keyboard from its usb port (except that the LED on the keyboard > > stays lit so I know the power is still on). > > I don't have this issue, but I guess you're using a terminal emulator > in a desktop environment. > > Which terminal emulator and which desktop environment are you using? > Maybe the problem is just that the terminal emulator takes the control > over the keyboard or the desktop environment gives the keyboard > controls to the terminal emulator. I see the keyboard problem in mate and xfce4 (the only ones I use now). I've wondered about the same things but I don't know how to debug those possible scenarios. At the moment I'm waiting for my new keyboard to arrive from amazon, hoping to pin the blame on flakey hardware instead of flakey software.
[gentoo-user] Re: [~amd64] Keyboard stops working several times/day
On Mon, 17 Aug 2015 23:21:54 +0200 Marc Joliet wrote: > I don't think you mention precisely which (type of) keyboard you use > within this thread (please forgive me if I overlooked it). Does it > happen to be a Logitech "Unifying Receiver" model? No I didn't mention which keyboard. I tend to forget about wireless devices because I don't have any. This keyboard has a cable that plugs directly into a usb port. You're probably too young to remember cables :)
[gentoo-user] Re: [WAS: keyboard stops working] Recent kernels block the loading of non-GPL kernel modules
On Mon, 17 Aug 2015 00:53:37 -0500 Dale wrote: > >> walt wrote: > >>> Linus and friends have been marking lots of existing > >>> kernel symbols with the SYMBOL_EXPORT_GPL macro, which was > >>> designed to block the loading of any kernel module not explicitly > >>> licensed as GPL software. > The only module I have > is Nvidia but that is one thing that doesn't work at times. > Sometimes, it doesn't want to boot all the way. It doesn't even get > through the kernel loading everything up at times. The Nvidia module is causing your problem then, because Nvidia supplies their binary blob under their own proprietary license. I'm using an elderly version of x11-drivers/nvidia-drivers on an elderly machine, but when I run 'modinfo -l nvidia' I see 'NVIDIA' as the response. If the response isn't 'GPL' then the affected kernels will refuse to load the module at boot time. The kernel devs have provided a workaround for the problem, however: You (or a gentoo dev) need to edit the source code for the problem kernel by changing the SYMBOL_EXPORT_GPL to SYMBOL_EXPORT. That macro appears maybe hundreds of places in the kernel sources, and has been there for years now, but only one or two of those source files needs to be patched, depending on which of those exported symbols is needed by your particular binary driver (e.g. nvidia-drivers or ati-drivers). This whole GPL/module thing is far from new. What's new is that the kernel devs are slowly adding more kernel symbols to their black list. I think the idea is to turn up the pressure very slowly on companies like Nividia and ATI to discourage them from providing proprietary drivers while not driving them out of the linux market completely. Every year linux is getting stronger and the devs can afford to be pushier with wealthy corporations who need more linux customers.
Re: [gentoo-user] Re: [~amd64] Keyboard stops working several times/day
Le 2015-08-17 03:17, netfab a écrit : Le 16/08/15 à 19:27, Michel Catudal a tapoté : the latest kernel from sunxi that supports the mali GPU (3.4.103) for my old Mele A2000G [offtopic] Latest up to date (3.4.108) can be found here [1]. It also embeds patchs and fixs from armbian [2]. ¹. https://github.com/dan-and/linux-sunxi ². http://forum.armbian.com/ [/offtopic] michel linux-sunxi # make CHK include/linux/version.h CHK include/generated/utsrelease.h make[1]: « include/generated/mach-types.h » est à jour. CALLscripts/checksyscalls.sh CHK include/generated/compile.h CHK kernel/config_data.h CC drivers/char/sunxi_mem/sunxi_physmem.o drivers/char/sunxi_mem/sunxi_physmem.c:22:27: erreur fatale: mach/includes.h : Aucun fichier ou dossier de ce type #include ^ compilation terminée. scripts/Makefile.build:307 : la recette pour la cible « drivers/char/sunxi_mem/sunxi_physmem.o » a échouée make[3]: *** [drivers/char/sunxi_mem/sunxi_physmem.o] Erreur 1 scripts/Makefile.build:443 : la recette pour la cible « drivers/char/sunxi_mem » a échouée make[2]: *** [drivers/char/sunxi_mem] Erreur 2 scripts/Makefile.build:443 : la recette pour la cible « drivers/char » a échouée make[1]: *** [drivers/char] Erreur 2 Makefile:947 : la recette pour la cible « drivers » a échouée make: *** [drivers] Erreur 2 -- For Linux Software visit http://home.comcast.net/~mcatudal http://sourceforge.net/projects/suzielinux/
Re: [gentoo-user] Install PreQualifying Matrix
On Mon, Aug 17, 2015 at 4:14 PM, Jeremi Piotrowski wrote: > If anything I would actually go for a simplification of the install > procedure, to something extremely low maintenence (for the handbook > authors ofc). An ext4 single disk install with grub2 (meh) that every one > can handle. > > Sure gentoo gives you choices but you have to be ready to handle them, so > perhaps the first install is not the right one for experimenting? I'm not convinced this is the right approach. The whole point of Gentoo is that if offers users a LOT of choice. We should of course present reasonable defaults, but we shouldn't send them hunting for alternative guides and trying to figure out what steps to substitute where anytime they change things. If they just want a default configuration they might as well just use something like Sabayon or Debian. Besides, once you start demoting all the options you invite the inevitable war over what the defaults should be. -- Rich
Re: [gentoo-user] Re: installation failure
Le 2015-08-17 14:58, »Q« a écrit : On Mon, 17 Aug 2015 20:46:44 +0200 Alan McKinnon wrote: Er, no. You don't. You really, really REALLY don't want to go Stage 1 :-) My second install was a stage 1, way back in the day when the stage 3s weren't fully usable out of the box yet. My first was a stage 2 (fully documented back then) and for the second one I decided to be brave. I did learn something, but it really wasn't worth the effort. For my second or third install I also used a stage 2, and I completely agree with you. It is always interesting to experiment with challenging stuff. I still remember the days when it was exciting just to be able to boot a Linux even though you couldn't do much with it. Michel -- For Linux Software visit http://home.comcast.net/~mcatudal http://sourceforge.net/projects/suzielinux/
Re: [gentoo-user] [~amd64] Keyboard stops working several times/day
Am Sun, 16 Aug 2015 09:45:52 -0700 schrieb walt : > I've been seeing this keyboard problem for the past few weeks: after > running some command from a bash prompt (haven't tried zsh yet) the > keyboard stops working. Almost like somebody unplugged the keyboard > from its usb port (except that the LED on the keyboard stays lit so I > know the power is still on). > > There are no error messages in journalctl or in /var/log/Xorg.0.log > > I don't know how to change to a console without using a ctrl-alt-Fn > keystroke from the keyboard (anyone know if it's possible?). > > When I unplug the keyboard from the usb port I can see the kernel > recognize the unplug event, which makes me think that it's not a > kernel/usb bug or a broken wire in the keyboard cable. > > When I re-plug the keyboard into a usb port the keyboard immediately > starts working normally again until the next time I happen to trigger > the problem by running some black-magical command from a command > prompt. There is no particular command that causes it--it can be any > arbitrary command AFAICT. > > Just one weird example: I can be typing a URL in a web browser window > when a bash command finishes running in a terminal window and the > keyboard stops working in the middle of my typing :( > > Any debugging suggestions would be most welcome. I don't think you mention precisely which (type of) keyboard you use within this thread (please forgive me if I overlooked it). Does it happen to be a Logitech "Unifying Receiver" model? My experience with the one I have is that the relative position and orientation of the keyboard to the receiver can strongly affect its reliability. Specifically, when the orientation is "bad", the keyboard will stop working intermittently (workarounds included moving the keyboard, but that never helped permanently). Moving the receiver to a USB slot in the side of the desktop case (as opposed to one in the back), thus changing its orientation by 90°, made the keyboard perform reliably again. (My suspicion is that the directionality of the receiver and/or keyboard is not uniform, though I can also imagine that the problem is (also?) caused by interference with WLAN or something like that.) HTH -- Marc Joliet -- "People who think they know everything really annoy those of us who know we don't" - Bjarne Stroustrup pgppWyKsFU4TP.pgp Description: Digitale Signatur von OpenPGP
Re: [gentoo-user] Install PreQualifying Matrix
On Mon, 17 Aug 2015, James wrote: > So another day, another borked set of installs. You are aware that for every failed install that comes to this mailing lists there are countless that go just fine, right? Planning questions are an OK-ish idea, but I surely wouldn't link to derivative distributions to answer them. We have appropriate wiki pages for all options, those that are insufficient should be improved. These could be linked to so that people know what to expect. > What I really would appreciate is some feedback on the Planning > Questions listed below, as to help folks organized their thoughts and > hardware details BEFORE actually performing an install or test-drive. It's always good to plan before doing something so *this* part of your proposal I support. > A recent discussion of the dev list showed > encouragement for pointing gentoo-noobs to some of the gentoo derivative > distros for a quick install experience. Perhaps it would be enough to extend this page https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/About and under `Troubles` mention derivative distributions (by name) with a _hint_ that their installers quickly lead to a working base system. The decisions to be made during the installation are mostly orthogonal, so I wouldn't try to break the current installation procedure which is for the most part linear. A matrix implies some form of interaction between the options, which I don't quite see. > straightforward for folks to discern the best route to their desired final > result. When new installation semantics [1] mature, the installation matrix > can be modified to include those options as links. > > Install PreQualifying Matrx::QUESTIONS > > > > Live Testdrive options before installation(usb/cd/dvd):: Pretty much already covered by https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Media and should really be a pre-install thing which it currently already is. > Intended Usage (workstation/server/device/) > Hardware or Vitual installation:: > PC mobo or tablet/embedded/device:: > Processor/Ram characteristics:: How are any of these relevant to the installation? For virtual installations I would only add mention of the `make kvmconfig` option that quickly pulls in qemu drivers. But the other things you mentioned don't have corresponding choices that need to be made (during the install and especially by newcomers). I'd remove them. > MBR vs (u)EFI (type of mobo):: > Single or Multi or RAID disk configuration:: > File System type(s):: > Grub1 vs Grub2 or other boot-semantics:: To me these are the only real things that need to be thought about during the install. MBR vs UEFI is well explained if you ask me. Single/RAID and filesystems are strongly connected but can be chosen freely independent of the other two. Grub2 can boot pretty much anything and if you use the EFI stub kernel on the ESP with initrd then that too can handle anything. So no dependencies here. So I would ask these questions in this order, and this is actually the order in which they show up in the handbook... which makes me wonder whether there is really a need for this. > OpenRC or Systemd:: More of a post install thing if you ask me but the handbook currently links to the systemd article at just the right time. If anything I would actually go for a simplification of the install procedure, to something extremely low maintenence (for the handbook authors ofc). An ext4 single disk install with grub2 (meh) that every one can handle. Sure gentoo gives you choices but you have to be ready to handle them, so perhaps the first install is not the right one for experimenting? > as well as valid install links > like sabayon for gentoo(ish) systemd > like calculate-linus for gentoo(ish)openrc > like pentoo for gentoo-penetration systems > like zentoo for gentoo CI systems > Like funtoo as an option install > like gentooliveUSB for a gentoo + persistence experience. The goal should be to get people to come to gentoo-gentoo, not to go elsewhere. > gentoo installs, so he is one of those guys that can single-handedly > solve this crisis: I actually don't feel that there is any crisis. The only time I've ever had problems with the install was when I decided to not follow the handbook. Most people should just stick to the handbook and learn. Experiment once they know what they're dealing with. I think an einstein quote is relevant here: Everything should be made as simple as possible, but not simpler. The current install procedure is pretty much as simple as can be, once you think about it.
[gentoo-user] Re: UEFI booting
On 17/08/2015 03:59 μμ, Rod wrote: Hi list, I'm trying to figure out how to make my boot partition to boot from UEFI, I have grub2 installed, but I keep getting a error when I ask it to install the boot information. mount /dev/sdc1 201633156 201478 1% /boot/efi I have the /boot/efi part mounted ok.. # efibootmgr efibootmgr: EFI variables are not supported on this system. Boot in UEFI mode first. You can't access those "variables" if you boot in BIOS mode. To do that, just boot from a SysRescueCD USB stick in UEFI mode and install the bootmanager from there.
[gentoo-user] Re: installation failure
On Mon, 17 Aug 2015 20:46:44 +0200 Alan McKinnon wrote: > Er, no. You don't. You really, really REALLY don't want to go Stage > 1 :-) > > My second install was a stage 1, way back in the day when the stage 3s > weren't fully usable out of the box yet. My first was a stage 2 (fully > documented back then) and for the second one I decided to be brave. > > I did learn something, but it really wasn't worth the effort. For my second or third install I also used a stage 2, and I completely agree with you.
Re: [gentoo-user] Re: installation failure
On 17/08/2015 20:54, Dale wrote: > Alan McKinnon wrote: >> On 17/08/2015 17:36, Dale wrote: >>> Heck, I wish a stage 1 install was supported. I think I'd give it a shot >>> if I could. >> >> Er, no. You don't. You really, really REALLY don't want to go Stage 1 :-) >> >> My second install was a stage 1, way back in the day when the stage 3s >> weren't fully usable out of the box yet. My first was a stage 2 (fully >> documented back then) and for the second one I decided to be brave. >> >> I did learn something, but it really wasn't worth the effort. In fact, >> LFS was less pain. Take a bootstrap setup and somehow get it to produce >> a working compiler, then use that to get a half-decent user-space and >> finally get a stage 3. Ugh :-) >> >> >> For a masochist like you, it might be fun :-) >> Stages are still on the download mirrors, and I'm sure we could find a >> copy of the handbook from back then for you. That thing was in CVS, >> wans't it? >> > > > Well, if I did it, it would be for giggles and because I was bored to > tears. Would I learn something, most likely. Question is, would what I > learn do me any good? Most likely not. You'd get street cred. There's only a very few people around brave (stupid?) enough to do a stage 1, just like there's only so many people that can really claim to have written main.cf from scratch by hand Dunno how much those bragging points are worth in this day and age though. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: installation failure
Alan McKinnon wrote: > On 17/08/2015 17:36, Dale wrote: >> Heck, I wish a stage 1 install was supported. I think I'd give it a shot if >> I could. > > Er, no. You don't. You really, really REALLY don't want to go Stage 1 :-) > > My second install was a stage 1, way back in the day when the stage 3s > weren't fully usable out of the box yet. My first was a stage 2 (fully > documented back then) and for the second one I decided to be brave. > > I did learn something, but it really wasn't worth the effort. In fact, > LFS was less pain. Take a bootstrap setup and somehow get it to produce > a working compiler, then use that to get a half-decent user-space and > finally get a stage 3. Ugh :-) > > > For a masochist like you, it might be fun :-) > Stages are still on the download mirrors, and I'm sure we could find a > copy of the handbook from back then for you. That thing was in CVS, > wans't it? > Well, if I did it, it would be for giggles and because I was bored to tears. Would I learn something, most likely. Question is, would what I learn do me any good? Most likely not. Dale :-) :-)
Re: [gentoo-user] Re: installation failure
On 17/08/2015 17:36, Dale wrote: > Alec Ten Harmsel wrote: >> On Mon, Aug 17, 2015 at 08:03:10PM +0700, jfmxl wrote: >>> It's pretty clear that you what you think I need to know about gentoo is >>> that its not for me because I don;t know what I'm doing and cannot think >>> logically ... Ill give it another shot, but I won't stick around on this >>> damn list any longer. >>> >>> Alan McKinnon wrote: All of which highlights something you need to know about Gentoo: arund here, we start by assuming you know what you are doing mostly and can think logically. >> Alan is *not* saying that Gentoo is not for you; he is merely saying >> that running Gentoo requires a decent amount of knowledge. For example, >> I ran Ubuntu for 2-3 years, then ArchLinux for 1-2 years, and now I run >> Gentoo. >> >> If you have never manually formatted a disk, installed a kernel, and >> installed grub, you can expect to fail the first time around. Like Alan >> also said, since you are doing this in Qemu, you should not be using an >> initrd and, in my opinion, you should just have a single MBR partition >> as it is very simple. >> >> Alec >> >> > > > I wouldn't recommend Gentoo to someone who has never even run Linux > before or been under the hood so to speak. That would be cruel. Like > you, I used Mandrake for a while before I tried Gentoo. It took me > several times to get my install done right. Heck, it took me 3 or 4 > times just to get a kernel that would boot. Then several more redos to > get everything to work right and that was before USB etc was what it is > now. The kernel was a lot simpler back then, I think. > > As was said in recent discussion about having a installer, the install > process teaches a lot. Gentoo is not a hand holding distro. Gentoo has > a learning curve and requires patience. If a person isn't able to > handle those two things, they won't like Gentoo. If a person wants > something that is easy and noob friendly, Gentoo isn't what they want. > Gentoo is what a person makes of it and Gentoo pretty much forces you to > make it what it is. It certainly isn't point and click distro which is > why I'm not real big on this installer thing. I can see some cases for > it when installing say to 50 identical servers or something but just not > for a single machine or even someone new to Gentoo. Heck, I wish a > stage 1 install was supported. I think I'd give it a shot if I could. Er, no. You don't. You really, really REALLY don't want to go Stage 1 :-) My second install was a stage 1, way back in the day when the stage 3s weren't fully usable out of the box yet. My first was a stage 2 (fully documented back then) and for the second one I decided to be brave. I did learn something, but it really wasn't worth the effort. In fact, LFS was less pain. Take a bootstrap setup and somehow get it to produce a working compiler, then use that to get a half-decent user-space and finally get a stage 3. Ugh :-) For a masochist like you, it might be fun :-) Stages are still on the download mirrors, and I'm sure we could find a copy of the handbook from back then for you. That thing was in CVS, wans't it? -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: [~amd64] Keyboard stops working several times/day
- Mail original - Le 16/08/15 à 19:27, Michel Catudal a tapoté : > the latest kernel from sunxi that supports the mali GPU (3.4.103) for > my old Mele A2000G [offtopic] Latest up to date (3.4.108) can be found here [1]. It also embeds patchs and fixs from armbian [2]. ¹. https://github.com/dan-and/linux-sunxi ². http://forum.armbian.com/ [/offtopic] resp: I don't think it would be off topic since the message is about keyboard that stops working, which happened with that kernel as well. [offtopic] How do you bottom post with comcast webmail? I only see the Microsoft exploder way which is only top post. [/offtopic]
[gentoo-user] martian source with unknown IP and MAC
I received a suspicious prompt while browsing a financial account of mine on my laptop so I restarted my modem but did not DHCP to it. I immediately received a series of type 08 00 martian sources logged to dmesg on my laptop from a 10.x.x.x source while my local network runs on 192.168.x.x only, and the logged MAC address does not match that of any systems on my LAN including the modem and I don't run wifi. Is that martian source suspicious? - Grant
Re: [gentoo-user] [~amd64] Keyboard stops working several times/day
Am 16.08.2015 um 18:45 schrieb walt: > I've been seeing this keyboard problem for the past few weeks: after > running some command from a bash prompt (haven't tried zsh yet) the > keyboard stops working. Almost like somebody unplugged the keyboard > from its usb port (except that the LED on the keyboard stays lit so I > know the power is still on). I don't have this issue, but I guess you're using a terminal emulator in a desktop environment. Which terminal emulator and which desktop environment are you using? Maybe the problem is just that the terminal emulator takes the control over the keyboard or the desktop environment gives the keyboard controls to the terminal emulator. > There are no error messages in journalctl That doesn't mean much. > When I unplug the keyboard from the usb port I can see the kernel > recognize the unplug event, which makes me think that it's not a > kernel/usb bug or a broken wire in the keyboard cable. > > When I re-plug the keyboard into a usb port the keyboard immediately > starts working normally again until the next time I happen to trigger > the problem by running some black-magical command from a command > prompt. There is no particular command that causes it--it can be any > arbitrary command AFAICT. Could theoretically also be a bug in systemd and/or udev? That wouldn't surprise me. And it wouldn't surprise me if Poettering and Sievers would blame the kernel developers for it again if it is a systemd and/or udev bug.
[gentoo-user] Re: Install PreQualifying Matrix
Dale gmail.com> writes: > James wrote: > > What I really would appreciate is some feedback on the Planning > > Questions listed below, as to help folks organized their thoughts and > > hardware details BEFORE actually performing an install or test-drive. > > Many/most of these options exist > > Install PreQualifying Matrx::QUESTIONS > > Live Testdrive options before installation(usb/cd/dvd):: > > Intended Usage (workstation/server/device/) > > Hardware or Vitual installation:: > > PC mobo or tablet/embedded/device:: > > Processor/Ram characteristics:: > > MBR vs (u)EFI (type of mobo):: > > Single or Multi or RAID disk configuration:: > > OpenRC or Systemd:: > > Grub1 vs Grub2 or other boot-semantics:: > > File System type(s):: > Hope other will also share and help give you ideas. > Dale Hello Dale, Acutally answering the question, with comments is a good idea. But what I had in mind, that is much more pressing is a list of additional questions, or re-ordering the questions or re-stating the quesions or matrix logic on the causal relationships between these quesions and other questions as to conclusion of valid install options is more of what I had in mind. Once that is reasoably vetted then I would look for some statisical inferences on the actual answers to these quetions as well as valid install links like sabayon for gentoo(ish) systemd like calculate-linus for gentoo(ish)openrc like pentoo for gentoo-penetration systems like zentoo for gentoo CI systems Like funtoo as an option install like gentooliveUSB for a gentoo + persistence experience. I think this sort of approach will take some stress off of the gentoo-user list and handbook whilst Blueness brings maturity to his efforts; he alreayd has lilblue, tinhat and tor-ramdisk gentoo installs, so he is one of those guys that can single-handedly solve this crisis: should he put his fingers to the task. MaffBlaster has been very quite of late. Blueness is a wonderful and collegial type of dev and is currently seeking input on his 'alpha' ideas:: https://wiki.gentoo.org/wiki/Project:RelEng_GRS THANKS! James
Re: [gentoo-user] Install PreQualifying Matrix
James wrote: > Hello, > > So another day, another borked set of installs. This really got me thinking > as I have been munging around a multitude of gentoo(ish) installation > options. What I really would appreciate is some feedback on the Planning > Questions listed below, as to help folks organized their thoughts and > hardware details BEFORE actually performing an install or test-drive. > > > It has dawned on me that an expansive set of Planning Questions that should > be answered prior to installation might be one posible way for those new > to gentoo to decide critial issues before choosing from the possible install > semantics for their given set of choices (constraints). As the matrix of > installation choices grows, so to can options for installation. If a given > set of choices does not have a viable installation pathway, of is just not > recommended, then that should be clearly explained. > > > Later on, a web interface and (a similarly in functional) GUI that is > extensible for installation media also) can be developed to enhance the > presentation of the decision processes. A graphical decision matrix > (row-column table initially). The handbook seems to be sort of moving > this direction anyway. A recent discussion of the dev list showed > encouragement for pointing gentoo-noobs to some of the gentoo derivative > distros for a quick install experience. > > > Many/most of these options exist, some atrophying currently, it's just not > straightforward for folks to discern the best route to their desired final > result. When new installation semantics [1] mature, the installation matrix > can be modified to include those options as links. > > > > Install PreQualifying Matrx::QUESTIONS > > > > Live Testdrive options before installation(usb/cd/dvd):: > > Intended Usage (workstation/server/device/) > > Hardware or Vitual installation:: > > PC mobo or tablet/embedded/device:: > > Processor/Ram characteristics:: > > MBR vs (u)EFI (type of mobo):: > > Single or Multi or RAID disk configuration:: > > OpenRC or Systemd:: > > Grub1 vs Grub2 or other boot-semantics:: > > File System type(s):: > > > James > > [1] https://wiki.gentoo.org/wiki/Project:RelEng_GRS > > > > I can't help much but will give my 2 cents worth. Grub, I switched to grub2 and it works. If you decide on grub1, keep in mind, I don't think it is maintained anymore. Some "new" stuff may not ever work with it and you may end up switching whether you want to or not. I think it is Neil that uses some other boot loader that he is happy with. Maybe he will chime in on it's name. I think it is a lot like Grub1 but currently maintained. I used resiserfs for ages. It sort of died a while back and at this point, I'm not sure if anyone is maintaining it at all. When I switched from reiserfs, I went to ext4. So far, I've had a drive to outright start failing hardware wise with only a loss of the data that was on that bad spot. The rest was fine. I have a UPS here so I can't really say much about how it handles a power fail or being rudely removed. All I can say is this, I'm happy with it so far. Others here like the shiney new BTRFS. I don't use it but maybe others can share their experience. I also use LVM and it just works, so far. I'm not sure what you want regarding Processor and Ram. I have a AMD Phenom II X4 955. That's 4 cores running at 3.2GHz. Libreoffice usually takes around 2 hours to compile. Firefox takes around 45 minutes. I have 16Gbs and have portage's work directory on tmpfs. I hope to upgrade both CPU and ram at some point. Hope to go to 8 cores at 4GHz and to 32GBs of ram. Hope. Ka ching. $$ I use openrc. Not going to start a flame war so leaving it at that. ;-) Hope other will also share and help give you ideas. Dale :-) :-)
Re: [gentoo-user] Re: installation failure
Alec Ten Harmsel wrote: > On Mon, Aug 17, 2015 at 08:03:10PM +0700, jfmxl wrote: >> It's pretty clear that you what you think I need to know about gentoo is >> that its not for me because I don;t know what I'm doing and cannot think >> logically ... Ill give it another shot, but I won't stick around on this >> damn list any longer. >> >> Alan McKinnon wrote: >>> All of which highlights something you need to know about Gentoo: arund >>> here, we start by assuming you know what you are doing mostly and can >>> think logically. > Alan is *not* saying that Gentoo is not for you; he is merely saying > that running Gentoo requires a decent amount of knowledge. For example, > I ran Ubuntu for 2-3 years, then ArchLinux for 1-2 years, and now I run > Gentoo. > > If you have never manually formatted a disk, installed a kernel, and > installed grub, you can expect to fail the first time around. Like Alan > also said, since you are doing this in Qemu, you should not be using an > initrd and, in my opinion, you should just have a single MBR partition > as it is very simple. > > Alec > > I wouldn't recommend Gentoo to someone who has never even run Linux before or been under the hood so to speak. That would be cruel. Like you, I used Mandrake for a while before I tried Gentoo. It took me several times to get my install done right. Heck, it took me 3 or 4 times just to get a kernel that would boot. Then several more redos to get everything to work right and that was before USB etc was what it is now. The kernel was a lot simpler back then, I think. As was said in recent discussion about having a installer, the install process teaches a lot. Gentoo is not a hand holding distro. Gentoo has a learning curve and requires patience. If a person isn't able to handle those two things, they won't like Gentoo. If a person wants something that is easy and noob friendly, Gentoo isn't what they want. Gentoo is what a person makes of it and Gentoo pretty much forces you to make it what it is. It certainly isn't point and click distro which is why I'm not real big on this installer thing. I can see some cases for it when installing say to 50 identical servers or something but just not for a single machine or even someone new to Gentoo. Heck, I wish a stage 1 install was supported. I think I'd give it a shot if I could. Dale :-) :-)
[gentoo-user] Install PreQualifying Matrix
Hello, So another day, another borked set of installs. This really got me thinking as I have been munging around a multitude of gentoo(ish) installation options. What I really would appreciate is some feedback on the Planning Questions listed below, as to help folks organized their thoughts and hardware details BEFORE actually performing an install or test-drive. It has dawned on me that an expansive set of Planning Questions that should be answered prior to installation might be one posible way for those new to gentoo to decide critial issues before choosing from the possible install semantics for their given set of choices (constraints). As the matrix of installation choices grows, so to can options for installation. If a given set of choices does not have a viable installation pathway, of is just not recommended, then that should be clearly explained. Later on, a web interface and (a similarly in functional) GUI that is extensible for installation media also) can be developed to enhance the presentation of the decision processes. A graphical decision matrix (row-column table initially). The handbook seems to be sort of moving this direction anyway. A recent discussion of the dev list showed encouragement for pointing gentoo-noobs to some of the gentoo derivative distros for a quick install experience. Many/most of these options exist, some atrophying currently, it's just not straightforward for folks to discern the best route to their desired final result. When new installation semantics [1] mature, the installation matrix can be modified to include those options as links. Install PreQualifying Matrx::QUESTIONS Live Testdrive options before installation(usb/cd/dvd):: Intended Usage (workstation/server/device/) Hardware or Vitual installation:: PC mobo or tablet/embedded/device:: Processor/Ram characteristics:: MBR vs (u)EFI (type of mobo):: Single or Multi or RAID disk configuration:: OpenRC or Systemd:: Grub1 vs Grub2 or other boot-semantics:: File System type(s):: James [1] https://wiki.gentoo.org/wiki/Project:RelEng_GRS
Re: [gentoo-user] installation failure
On Mon, 17 Aug 2015, jfmxl wrote: > but no joy. When I rebooted the machine I saw the grub and a bunch of > initializations whizzed by ... but the kernel failed to mount root. Sounds pretty much like grub is passing the wrong root parameter. > I opened a shell and looked at /etc/fstab, but found a /dev/ram0 and a > /proc and nothing like what I'd entered ... I'd followed the program in > the handbook. Would that be the rescue shell within the initramfs? In that case that's fine, I see the same thing in a genkernel initramfs. > When I tried to unmount the /mnt/gentoo (formerly) chroot partition at > the end the complaint was that something using it ... I couldn't > discover what that was, If you did mount --rbind on sys and dev and then tried to umount than I can tell you I always fail to unmount these properly. Rebooting (software reboot) is fine. > after waiting an retrying several times, I just > shut the vm down and restarted ... with the result above. Is there any > hope of rescuing this? Should be entirely salvageable. > Since I installed the whole system to a qemu 'partition' inside a binary file > I have no access to what I've done or failed to do. So I guess I'm just out of > luck? You can simply reboot the livecd within the VM and just go to the 'chroot` step. You could also mount the binary disk image on the host; depending on what type of image you're using the instructions are both here https://en.wikibooks.org/wiki/QEMU/Images#Mounting_an_image_on_the_host The only thing you're missing is the proper bootloader/initramfs configuration, so go back to this part. >To install an initramfs, install sys-kernel/genkernel first, then have it > generate an initramfs: >root #emerge genkernel >root #genkernel --install initramfs > > So yes, that's what I did, apparently. Without knowing the specifics of your setup, here's the steps I would take to fix it: 1. regenerate genkernel initramfs; you can try to specify a default real_root by executing genkernel --real-root, or in /etc/genkernel.conf. But it seems to me that if the correct root parameter from grub is passed then things should work. 2. grub2-mkconfig again; check the created grub.cfg to see that sane flags are being passed to the kernel. 3. try booting 4. if you don't have a freaky partition setup and the filesystem/block device controller modules are built-into the kernel, you can try to launch the kernel directly from grub-cmdline. Something like set root='hd0,2' linux /boot/vmlinuz-whatever root=/dev/sda4 boot should work (plug in the right partition numbers). This is actually what I would do, initramfs only as a last resort. if these don't work then you still have step 5: 5. generate a dracut initramfs and redo steps 2 and 3. Dracut can generate and save a kernel cmdline within itself which should fix any problems. > ... Ill give it another shot, but I won't stick around on this damn list any > longer. Seems pretty rash to run away after one email, don't you think?
Re: [gentoo-user] UEFI booting
On Mon, 17 Aug 2015, Rod wrote: > Hi list, Hi > I'm trying to figure out how to make my boot partition to boot from UEFI, > I have grub2 installed, but I keep getting a error when I ask it to install > the boot information. First things first, are you installing gentoo from an UEFI booted installation media? From what I know the gentoo minimal install cd does not allow for this, and I will assume you are using that. If you're using some other installation method, check whether the directory /sys/firmware/efi/efivars has any content, try to mount efivarfs following the instructions in this link: https://wiki.gentoo.org/wiki/Efibootmgr#Configuration and then check again. > # efibootmgr > efibootmgr: EFI variables are not supported on this system. > > > # grub2-install --target=x86_64-efi /dev/sdc > Installing for x86_64-efi platform. > efibootmgr: EFI variables are not supported on this system. > efibootmgr: EFI variables are not supported on this system. > Installation finished. No error reported. In your case it seems that the system is not in an UEFI-booted state. But we can work around this by using a nice part of the UEFI specification, details below. > mount > /dev/sdc1 201633156 201478 1% /boot/efi > > I have the /boot/efi part mounted ok.. Before we go further make sure that the partition is a valid EFI boot partition: code EF00 (gdisk), partition flags boot/esp (for parted). > How can I get this UEFI be become bootable without media to make it boot > in to that mode to begin with ? It's actually much easier than it may seem, and it's outlined here: https://wiki.gentoo.org/wiki/GRUB2#Alternative:_using_the_default_UEFI_firmware_location Basically, for all sorts of removable media there must be a way to tell UEFI what to boot without having to hardcode the entries into NVRAM (like efibootmgr does). Therefore UEFI firmware is supposed to check for the first ESP partition on a drive and boot \EFI\boot\bootx64.efi from it. This also works for harddrives, and since you can access a FAT partition even when booted in bios mode you just put grub there. Now this works perfectly well for a linux kernel with efi stub and cmdline built-in, but grub may have trouble finding it's configuration files, I do not know. So I suggest you try it. Find grubx64.efi in /boot/efi and copy it to /boot/efi/EFI/BOOT/BOOTX64.EFI. Voila, should boot just fine. On my first UEFI install I did not know about this, efibootmgr did not work, but the handbook says to place the kernel at /EFI/boot/bootx64.efi and it just magically worked. Generally you will find that provided the UEFI implementation of your vendor is not complete shit (lots of them exist) UEFI makes it generally easier to handle booting. One partition and the EFI variables and you can boot anything, no more hidden sectors.
Re: [gentoo-user] Re: installation failure
On 17/08/2015 15:03, jfmxl wrote: > It's pretty clear that you what you think I need to know about gentoo is > that its not for me because I don;t know what I'm doing and cannot think > logically ... Ill give it another shot, but I won't stick around on this > damn list any longer. No, that's not it. Almost the exact opposite actually. You do appear to know what you are doing. Someone who didn't would have worded the first mail very differently. I wrote what I wrote so you would have a clearer picture of how to read the docs - they will not hold your hand, instead they will tell you what you need to know so you can figure out your next step. Perhaps you got frustrated with the install and are now just a tad touchy? > >> All of which highlights something you need to know about Gentoo: arund >> here, we start by assuming you know what you are doing mostly and can >> think logically. > -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] UEFI booting
On Mon, Aug 17, 2015 at 10:59:30PM +1000, Rod wrote: > Hi list, > > # efibootmgr > efibootmgr: EFI variables are not supported on this system. > > > # grub2-install --target=x86_64-efi /dev/sdc > Installing for x86_64-efi platform. > efibootmgr: EFI variables are not supported on this system. > efibootmgr: EFI variables are not supported on this system. > Installation finished. No error reported. > I haven't done a UEFI install in a while, but the first thing that comes to mind is that you haven't booted your install medium in UEFI mode. What install media are you using and how did you boot it? Alec
Re: [gentoo-user] Re: installation failure
On Mon, Aug 17, 2015 at 08:03:10PM +0700, jfmxl wrote: > It's pretty clear that you what you think I need to know about gentoo is > that its not for me because I don;t know what I'm doing and cannot think > logically ... Ill give it another shot, but I won't stick around on this > damn list any longer. > > Alan McKinnon wrote: > > All of which highlights something you need to know about Gentoo: arund > > here, we start by assuming you know what you are doing mostly and can > > think logically. > Alan is *not* saying that Gentoo is not for you; he is merely saying that running Gentoo requires a decent amount of knowledge. For example, I ran Ubuntu for 2-3 years, then ArchLinux for 1-2 years, and now I run Gentoo. If you have never manually formatted a disk, installed a kernel, and installed grub, you can expect to fail the first time around. Like Alan also said, since you are doing this in Qemu, you should not be using an initrd and, in my opinion, you should just have a single MBR partition as it is very simple. Alec
[gentoo-user] Re: installation failure
jfmxl SDF.ORG> writes: > Since I installed the whole system to a qemu 'partition' inside a binary > file I have no access to what I've done or failed to do. So I guess I'm > just out of luck? I guess I will make a real DVD from the .iso and go > through the whole drill again on real hardware when I get it set up > tomorrow. It is a very long process only to come to ought, though. One > more chance is probably my last. Hello jfmxl, Gentoo is rewarding and awesome, no doubts on that; but the requisite 'pain' first endured during the installation is a subject of much heated debate recently, and this is not the first time. So, from me, *OUR* deepest apologies. We are working on the organization and initial appeal of gentoo, as well as some more streamlined installation options for those new to gentoo. Perhaps you should first embark on a traditional HD type of install and avoid the 'vm' for now; that is if you have such resources to work with. It does make following the handbook install more straightforward, imho. Then the file system you are to use for a simple /boot, /, and swap configuration, which is the default in the handbook. Plan your FS layout as well as grub1 vs grub2 and the (u)efi vs mbr status of your mobo. Perhaps others will ask you a few complementary questions so we can nail down all of the key decisions before you begin an installation? There are 'live' version of gentoo about that can allow you to test drive gentoo before installation. Perhaps one of those, with persistence (the ability to add codes) might better suit you initially? You also might want to try the 'calculate linux' [1,2,3] install medium and just change the profile and a few other tricks to end up with a native gentoo install on an actual HD? hth, James [1] http://www.calculate-linux.org/boards/15/topics/25561 [2] http://www.calculate-linux.org/main/en/cls [3] http://www.calculate-linux.org/main/en/cld
Re: [gentoo-user] Re: installation failure
It's pretty clear that you what you think I need to know about gentoo is that its not for me because I don;t know what I'm doing and cannot think logically ... Ill give it another shot, but I won't stick around on this damn list any longer. All of which highlights something you need to know about Gentoo: arund here, we start by assuming you know what you are doing mostly and can think logically.
[gentoo-user] UEFI booting
Hi list, I'm trying to figure out how to make my boot partition to boot from UEFI, I have grub2 installed, but I keep getting a error when I ask it to install the boot information. mount /dev/sdc1 201633156 201478 1% /boot/efi I have the /boot/efi part mounted ok.. # efibootmgr efibootmgr: EFI variables are not supported on this system. # grub2-install --target=x86_64-efi /dev/sdc Installing for x86_64-efi platform. efibootmgr: EFI variables are not supported on this system. efibootmgr: EFI variables are not supported on this system. Installation finished. No error reported. I have this disk as my 1st boot drive in BIOS, the 2nd is the normal drive. Boot order is EFI then Legacy (EFI only tells me "Insert boot disk and hit Enter) I'm assuming the "variables not supported" is blocking the install. BIOS reports the 1st disk to boot is EFI: ST2000DM001-1ER1 Mobo is a Gigabyte Z68X-UD3H-B3 (with the latest UEFI firmware) How can I get this UEFI be become bootable without media to make it boot in to that mode to begin with ? -- --- Regards, Rod Smart 0417 513 286
Re: [gentoo-user] Re: installation failure
On 17/08/2015 14:07, jfmxl wrote: > On 2015-08-17 17:20, Martin Vaeth wrote: >> jfmxl wrote: >>> I wrote a coupla days ago, using the guest interface at the website ... >> >> I do not know what you mean by "guest interface". >> One right place for your support question would be the >> gentoo forum "Installing Gentoo": >> https://forums.gentoo.org/viewforum-f-14.html >> > > Thanks for the speedy reply. I got to the 'wrong' place by clicking the > link to under 'Where to go from here' > at https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Finalizing > after the machine failed to boot. That led me to > https://www.gentoo.org/get-involved/mailing-lists/, where the big, > purple, and welcome 'Post to Gentoo User' > button caught my eye. It looked inviting, and so I used it. > >>> but the kernel failed to mount root. >> >> This can have many reasons. More informations are needed. >> According to this: >> >>> looked at /etc/fstab, but found a /dev/ram0 and a >>> /proc and nothing like what I'd entered ... >> >> you are probably using an initrd which you must have built and entered >> into grub (or grub2?) somewhere. Are you perhaps using genkernel to build >> such an initrd? > > > https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Kernel#Optional:_Building_an_initramfs > > >To install an initramfs, install sys-kernel/genkernel first, then > have it generate an initramfs: >root #emerge genkernel >root #genkernel --install initramfs > > So yes, that's what I did, apparently. I was working from one enormously > long Handbook, and the one I find now is broken into sections, but it > looks generally the same. I remembered Both versions are the same. You can read the handbook as one long page, or as separate chapters. Same thing either way. I'm not sure why you are bothering with an initrd to be honest. You are installing to a qemu guest so the odds are excellent it has one partition in that file-based disk. You are building Gentoo which is always done from scratch and has no need of one-size-must-fit-all which are required for binary distro installers. And you don't seem to be using exotic boot scenarios either (like LVM on RAID, or booting off btrfs in a raid configuration. So hence the question: You have none of the valid reasons why initrds were introduced, so why are you using one? Just dispense with the entire thing and take the much simpler route: hard-code into your install everything it needs to boot. Remember, Gentoo is built from scratch each time, it has no need to be generic and find out what it's running on each time it boots, you can simply tell it. Compile into your kernel (not as modules) each driver you need to boot: - your hardware chipset - all the FS types you think you'll use for / Then: - keep /usr on the same partition as / (you likely will do this anyway) - configure your boot loader with a "root=" parameter specifying where your / is located (do this inside the chroot) And follow the handbook for everything else. If you are not already 100% familiar with what kernel module does what, and what needs to be compiled in, you may end up repeating the booting off the install CD, mounting the disks, chroot into / process more than once. Don't lose heart! The learning experience is well worth the effort, and besides almost every Gentooer goes through this anyway. I myself have used Gentoo for 10+ years and my most recent manual install required chrooting FOUR times before I got it right, I was trying to be clever and short-cut the install process. That never works :-) genkernel is know to be problematic. List user are in recent times reporting issues with it that ought not to happen. Other users who use dracut instead are reporting a much happier experience than with genkernel. I suppose the handbook needs updating. > Well, I pushed the big friendly purple button and sent off my plea for > help, and waited and waited, and still have not seen my original post > appear on this list. You should remove that button if no one bothers to > moderate the posts it generates. The people who push it get their first > impression of the 'community' when they are in trouble and are ignored. > You know what they say about first impressions. Get rid of that button! > Or read and moderate the posts it generates. Your original post will not appear, you were not subscribed when you clicked the button. You need to subscribe first, otherwise the list rejects the post. All the button does is launch a mailto: link; in a perfect world the web page would grey out the purple button if you are not subscribed, but in the real world that page likely has no way to know if you are or not. Perhaps the page too could be made more obvious what the requirements are. All of which highlights something you need to know about Gentoo: arund here, we start by assuming you know what you are doing mostly and can think logically. So very little effort is put into detailing every detail of
Re: [gentoo-user] Re: installation failure
On 2015-08-17 17:20, Martin Vaeth wrote: jfmxl wrote: I wrote a coupla days ago, using the guest interface at the website ... I do not know what you mean by "guest interface". One right place for your support question would be the gentoo forum "Installing Gentoo": https://forums.gentoo.org/viewforum-f-14.html Thanks for the speedy reply. I got to the 'wrong' place by clicking the link to under 'Where to go from here' at https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Finalizing after the machine failed to boot. That led me to https://www.gentoo.org/get-involved/mailing-lists/, where the big, purple, and welcome 'Post to Gentoo User' button caught my eye. It looked inviting, and so I used it. but the kernel failed to mount root. This can have many reasons. More informations are needed. According to this: looked at /etc/fstab, but found a /dev/ram0 and a /proc and nothing like what I'd entered ... you are probably using an initrd which you must have built and entered into grub (or grub2?) somewhere. Are you perhaps using genkernel to build such an initrd? https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Kernel#Optional:_Building_an_initramfs To install an initramfs, install sys-kernel/genkernel first, then have it generate an initramfs: root #emerge genkernel root #genkernel --install initramfs So yes, that's what I did, apparently. I was working from one enormously long Handbook, and the one I find now is broken into sections, but it looks generally the same. I remembered I had used genkernel only once many years ago, and remember that you have to specify your root filesystem with the kernel parameter real_root=... If you do not use genkernel, you should pass the correct root partition with the kernel parameter root=... In the latter case, be sure that you have the filesystem support as well as the disk processor code compiled into the kernel (i.e. not as a module). Since I installed the whole system to a qemu 'partition' inside a binary file I have no access to what I've done or failed to do. So I guess I'm just out of luck? I guess I will make a real DVD from the .iso and go through the whole drill again on real hardware when I get it set up tomorrow. It is a very long process only to come to ought, though. One more chance is probably my last. that is if I'm not already blackballed for somehow not holding my mouth right. Why do you think that it should be problem to ask a support question, especially in a friendly way? There is no reason to stay anonymous. Well, I pushed the big friendly purple button and sent off my plea for help, and waited and waited, and still have not seen my original post appear on this list. You should remove that button if no one bothers to moderate the posts it generates. The people who push it get their first impression of the 'community' when they are in trouble and are ignored. You know what they say about first impressions. Get rid of that button! Or read and moderate the posts it generates.
[gentoo-user] Re: installation failure
jfmxl wrote: > I wrote a coupla days ago, using the guest interface at the website ... I do not know what you mean by "guest interface". One right place for your support question would be the gentoo forum "Installing Gentoo": https://forums.gentoo.org/viewforum-f-14.html > but the kernel failed to mount root. This can have many reasons. More informations are needed. According to this: > looked at /etc/fstab, but found a /dev/ram0 and a > /proc and nothing like what I'd entered ... you are probably using an initrd which you must have built and entered into grub (or grub2?) somewhere. Are you perhaps using genkernel to build such an initrd? I had used genkernel only once many years ago, and remember that you have to specify your root filesystem with the kernel parameter real_root=... If you do not use genkernel, you should pass the correct root partition with the kernel parameter root=... In the latter case, be sure that you have the filesystem support as well as the disk processor code compiled into the kernel (i.e. not as a module). > that is if I'm not already blackballed > for somehow not holding my mouth right. Why do you think that it should be problem to ask a support question, especially in a friendly way? There is no reason to stay anonymous.
[gentoo-user] installation failure
Hi, I wrote a coupla days ago, using the guest interface at the website ... but I guess no one bothers with that , or they just threw away my mail. I'm looking for an alternative to debian/systemd and gentoo seems a good possibility. I downloaded the minimal amd64 install and went through the drill making a qemu/kvm vm. I was careful and my efforts would pay off, but no joy. When I rebooted the machine I saw the grub and a bunch of initializations whizzed by ... but the kernel failed to mount root. I opened a shell and looked at /etc/fstab, but found a /dev/ram0 and a /proc and nothing like what I'd entered ... I'd followed the program in the handbook. When I tried to unmount the /mnt/gentoo (formerly) chroot partition at the end the complaint was that something using it ... I couldn't discover what that was, after waiting an retrying several times, I just shut the vm down and restarted ... with the result above. Is there any hope of rescuing this? I have a new machine and I'd like to make gentoo the primary os on it, but I'm once bitten ... and it took me several hours effort to fall on my face the first time around. Any suggestions appreciated ... that is if I'm not already blackballed for somehow not holding my mouth right. (I just sent foolishly this message from an unenrolled email address as well, so I am resending it now from my enrolled address)
Re: [gentoo-user] Re: [~amd64] Keyboard stops working several times/day
Le 16/08/15 à 19:27, Michel Catudal a tapoté : > the latest kernel from sunxi that supports the mali GPU (3.4.103) for > my old Mele A2000G [offtopic] Latest up to date (3.4.108) can be found here [1]. It also embeds patchs and fixs from armbian [2]. ¹. https://github.com/dan-and/linux-sunxi ². http://forum.armbian.com/ [/offtopic]
