Re: [gentoo-user] Fresh install and problem with net.* init.d script
Am 22.07.2013 23:35, schrieb FredL: >> >> Do you perhaps have NetworkManager or wicd installed? >> >> >> no, none of them, it is a very basic install, with only the minimum >> packages installed . I have checked at the init script and find a line >> in the depend section saying : >> >> after lo lo0 dbus >> >> but dbus is not yet installed, can this be the cause of my problem? > > so I have just installed dbus and add it to default runlevel and my > net.* script are loaded correctly setting my static config, so every > thing is fine now. > > But why do we need dbus in a very minimalistic system? I was thinking > that it would be helpful in a full desktop environnement for > automagically mounting device and things like that... > > Saying that I've just remenbered that I have selected the desktop > profile instead of the default one, can this be why my init script need > dbus for starting net iface? > As Bruce did show: You don't need to have dbus installed for net.* to work. Also it did work, when you started net.* it manually, without having dbus installed, right? I don't know, what did start dhcp on your interfaces, you should check that. AFAIK your kernel does a automatic dhcp-configuration of your interfaces when you have set CONFIG_IP_PNP_DHCP. You could try to disable dbus and check, if your interfaces get up with dhcp again and then disable CONFIG_IP_PNP or all CONFIG_IP_PNP_*-options and check again. (If they where activated of course ;) ) For your net.* initscripts not starting automatically I don't have an idea other than maybe you forgot to add them to the runlevels right now, but that would not explain, why they do start after adding dbus... It would be interesting, to know, what did really happen, so please let us know, what you find out ;) Regards, Markus signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] more on SSD: swap
Am 21.07.2013 16:42, schrieb Peter Wilmott: > On 21/07/13 15:31, luis jure wrote: >> OK, now i have my system successfully installed and running on my new >> SSD. >> now i have to decide what to do with the rest of the disk (it's a 256MB >> samsung). >> >> the first big question is: what about swap? i found some web pages >> (perhaps old) stating that it's not wise to put swap on the SSD >> because of >> all the read/writes. but apparently from what i read on the recent >> thread on this list, that shouldn't be much of a concern now. >> >> i also read somewhere that if you have swap on the SSD and want to avoid >> unnecessary read/writes, you can reduce swappiness. i have 12GB RAM and i >> think normally i don't really need swap space on disk, so i thought that >> could be a good idea. >> >> so what i'm planning to do now is: >> >> - put swap on the SSD >> - reduce swappiness >> - put /var/tmp/portage on tmpfs >> >> so, do you guys think that's a good setup? >> > TBH, unless you are really stressing your RAM usage (Lots of VMs or Java > applications, stuff like that) I'd go without swap. I've been running > swapless on 8GB of RAM for a number of years now with no issues. > > As for /var/tmp/portage on tmpfs, this is fine 95% of the time, however > even with ~2GB I allocate some packages (Chromium, LibreOffice, ect) > will fail to compile due to lack of space. In these cases I just > un-mount /var/tmp/portage, do the compile on the disk, and then re-mount > it. > Portage can do that for you for packages you know to need that much space: markus@Nanga-Parbat ~ $ cat /etc/portage/env/notmpfs PORTAGE_TMPDIR="/var/tmp_notmpfs" [Fr 26.07.13 22:06 CEST][pts/2][x86_64/linux-gnu/3.10.1-gentoo][5.0.2] markus@Nanga-Parbat ~ $ cat /etc/portage/package.env www-client/firefox notmpfs [Fr 26.07.13 22:06 CEST][pts/2][x86_64/linux-gnu/3.10.1-gentoo][5.0.2] markus@Nanga-Parbat ~ $ mount | grep /var/tmp /dev/mapper/Nanga--Parbat--SSD-system--var--tmp_notmpfs on /var/tmp_notmpfs type btrfs (rw,noatime,ssd,autodefrag,compress=lzo) none on /var/tmp type tmpfs (rw,size=6350m) (Firefox is still in there from my pgo-builds, I should remove that now :D) Also: markus@Nanga-Parbat ~ $ free -h total used free sharedbuffers cached Mem: 15G12G 3,6G 0B 336M 6,0G -/+ buffers/cache: 5,7G 9,9G Swap: 0B 0B 0B never had any problems without swap, since i got more than 4GB of RAM ;) Regards, Markus signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Update BIOS with 4MB .exe
Hi, did you try, if your DELL is supported by libsmbios? http://www.gentoo-wiki.info/Dell_BIOS_Upgrade Worked for me on 3 DELL-Computers (1 Desktop and 2 Laptops). Markus Grant schrieb: > I'm amazed this is so difficult but I've just spent 3 hours trying to > update the BIOS on my Dell XPS 13 and hit nothing but dead ends. The > root of the problem seems to be that the 4MB BIOS update file is too > large for the available 1.44MB DOS boot disks. Apparently FreeDOS had > a LiveCD available at some point but it has reportedly been > unavailable for quite some time. > > The following method looks promising but it also doesn't work. DOS > can't seem to execute the .exe file which sits outside of the boot > image: > > http://en.gentoo-wiki.com/wiki/FreeDOS_Flash_Drive > > Does anyone know how to do this? > > - Grant > signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Re: Full system encryption on Gentoo
Am Donnerstag, 31. Dezember 2015, 00:15:33 schrieb Jeremi Piotrowski: > This will lead to you having to enter the password > twice - once when grub starts and once when the initramfs is setting up /. If, and ONLY if, your /boot is inside your LUKS-encrypted volume, you can also add a keyfile for your LUKS-volume (I used another keyslot for that, but you can also use the password, you use for manual unlocking..) to your crypttab and your dracut-initrd: % cat /etc/crypttab mySSD.cryptUUID=2850e418-f325-47b6-b42b-82a60055a0c6 /root/mySSD.lukskey discard,luks crypttab-format: (Name Path/Spec /path/to/keyoptions) (see man 5 crypttab) % cat /etc/dracut.conf.d/luks.conf install_items+="/etc/crypttab /root/mySSD.lukskey" check if the permissions for your initrd are save, aka only readable for root, dracut automatically sets them to 600 and root:root here, but better save than sorry.. with that setup you do not need to enter the password twice, because your initrd is able to open the luks-device with the keyfile.