The Linux Questions Thread: a bunch of pitfalls, but technically it's possible

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Linux Questions Thread: a bunch of pitfalls, but technically it's possible

«‹›1040 »

theperminator: Sep 16, 2009; by Smythe; Fun Shoe

RFC2324 posted:

Not ten years, but same. I assumed everyone would see it as a joke.

Ahh right sorry, I've had to deal with people that literally suggested cPanel for people who just wanted one mailbox.

# ? Jul 27, 2015 14:46

Adbot: ADBOT LOVES YOU

# ? Jun 7, 2024 09:21

Hollow Talk: Feb 2, 2014

theperminator posted:

I had to work with cPanel for 10 years as a sysadmin for a hosting company. gently caress ever touching that poo poo again.

I had this issue, I fixed it by wiping my bayes database, and then adding a cron to learn anything i put into my Junk folder as spam.
Make sure you've got a cron created for sa-update too.

Another option with something like dovecot is to use a small script that automatically calls sa with --spam or --ham on new messages instead of having to rely on a cron job like so: http://wiki2.dovecot.org/Plugins/Antispam

# ? Jul 27, 2015 14:48

ToxicFrog: Apr 26, 2008

theperminator posted:

I had this issue, I fixed it by wiping my bayes database, and then adding a cron to learn anything i put into my Junk folder as spam.
Make sure you've got a cron created for sa-update too.

I have both such crons, and the Bayes databases were wiped during the server rebuild. :shrug:

Maybe I'm not feeding it enough ham to counterbalance the spam?

# ? Jul 27, 2015 14:56

VAGENDA OF MANOCIDE: Aug 1, 2004; whoa, what just happened here?; College Slice

Truga posted:

Spamassassin works passably for me at work, but the thing that really cut the vast majority of spam we got was postgrey.

Just remember to set the retry time to something short so you don't have to wait 5 minutes to reset a password or something.

The sendmail equivalent (milter-greylist) cut my incoming spam by like 90%, and that's compared to the previous situation which is AFTER the spamassassin pass.

# ? Jul 27, 2015 15:36

dpkg chopra: Jun 9, 2007; Fast Food Fight; Grimey Drawer

Can anyone think of a reason why Ubuntu's repositories are super loving slow for me? I'm talking bytes/s on a 10Mb connection.

I've tried switching mirrors to the ones closest to me but it's all the same, and in any case I wouldn't expect literally bytes/s even if I was connecting to Russia.

Googling basically suggests "switch mirrors".

# ? Jul 27, 2015 22:08

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

Ur Getting Fatter posted:

Can anyone think of a reason why Ubuntu's repositories are super loving slow for me? I'm talking bytes/s on a 10Mb connection.

I've tried switching mirrors to the ones closest to me but it's all the same, and in any case I wouldn't expect literally bytes/s even if I was connecting to Russia.

Googling basically suggests "switch mirrors".

Are you running inside VirtualBox 4, by any chance? If so, upgrade.

# ? Jul 27, 2015 22:52

Qtotonibudinibudet: Nov 7, 2011; Omich poluyobok, skazhi ty narkoman? ya prosto tozhe gde to tam zhivu, mogli by vmeste uyobyvat' narkotiki

ruby idiot railed posted:

The sendmail equivalent (milter-greylist) cut my incoming spam by like 90%, and that's compared to the previous situation which is AFTER the spamassassin pass.

On the other hand, sendmail.

# ? Jul 27, 2015 22:58

VAGENDA OF MANOCIDE: Aug 1, 2004; whoa, what just happened here?; College Slice

annapacketstormaya posted:

On the other hand, sendmail.

It "works" WONTFIX.

I just finished building a new server with postfix though.

# ? Jul 27, 2015 23:59

RFC2324: Jun 7, 2012; http 418

Ok, want to see if something will work before I try it. In my server I have 4 136G SAS drives in a hardware JBOD array, with an LVM volume on top of them(just the default that CentOS 6.5 set up on install). I just pulled an old 500G drive out of a laptop I figure on adding to the LVM group, but first I want to break apart the JBOD array and have LVM sitting on top of multiple disks for ease of moving them around in an emergency.

So, my questions are thus:

Is it feasible to extend the LVM volume to include the 500G drive, then pull the JBOD array out of it, so all the data migrates to the other drive?

What happens if I change parameters in lvm.conf, such as configuring it for striping instead of a linear config, will I have to rebuild the volume and lose the data?(I am still crawling through this file trying to determine how it defaulted)

Am I insane for trying this, and should just clone the operating partition over to the physical drive, break apart the JBOD, then build a new LVM and clone the data back to it before I extend the one the 500G drive?

TIA

# ? Jul 28, 2015 00:11

theperminator: Sep 16, 2009; by Smythe; Fun Shoe

That should be easily doable if everything will fit on the 500GB laptop drive
The below steps asume an EXT3/4 FS, if you're using XFS or some other Filesystem that can't be shrunk you're boned unless it's still small enough to fit on the 500GB drive alone.

Steps:
1. Add the drive to your Volume group
2. Shrink the LV so that it will fit on the 500GB drive alone.
df -h to see how much is used then make the LV and Filesystem just slightly larger than the used space with
# lvreduce -r -L200GB /dev/myvolgroup/mylogicalvolume
4. Move your extents from your JBOD PV device to your 500GB pv i.e
# pvmove /dev/md0 /dev/sdb1
5. remove the JBOD device from the VolGroup
# vgreduce myvolgroup /dev/md0
6. Remove the PV metadata
# pvremove /dev/md0

7. Now your VG & LV will exist only on the 500GB drive, but won't use the whole device. you will need to lastly expand it to fill your 500GB device
# lvextend -l+100%FREE /dev/myvolgroup/mylogicalvolume

:edit: it should be possible to move the LV over to a striped set of pvs too, I'm thinking move to the 500gb as above, create a new, striped volume group with your other disks, merge your volgroups, move the LV to other pv(s) then do a vgsplit and remove the 500Gb

:edit 2: Apparently not, the striping is at a logical volume level rather than the volgroup level, just move your data to the 500GB drive, create a new Volgroup & Striped Logical volume on your other disks and rsync from the 500GB to your new striped LV

theperminator fucked around with this message at 11:50 on Jul 28, 2015

# ? Jul 28, 2015 04:28

RFC2324: Jun 7, 2012; http 418

Sweet, other than the striping part it looks like it will work almost exactly as expected.

Thanks!

# ? Jul 28, 2015 15:15

dpkg chopra: Jun 9, 2007; Fast Food Fight; Grimey Drawer

Vulture Culture posted:

Are you running inside VirtualBox 4, by any chance? If so, upgrade.

Nope, physical PC connected via switch to a router. At this point I've tried a shitload of mirrors and it's all the same.

# ? Jul 28, 2015 17:18

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

Ur Getting Fatter posted:

Nope, physical PC connected via switch to a router. At this point I've tried a shitload of mirrors and it's all the same.

Your MTU matches your network, right?

Any change if you disable all TCP offloading (checksum, segment, etc.) on your network interface?

# ? Jul 28, 2015 17:39

dpkg chopra: Jun 9, 2007; Fast Food Fight; Grimey Drawer

Vulture Culture posted:

Your MTU matches your network, right?

Any change if you disable all TCP offloading (checksum, segment, etc.) on your network interface?

Nope.

Edit: turned out to be a faulty ethernet cable :doh:

dpkg chopra fucked around with this message at 19:34 on Jul 28, 2015

# ? Jul 28, 2015 18:07

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

Ur Getting Fatter posted:

Nope.

Edit: turned out to be a faulty ethernet cable

Boom. At least we were on the right track.

# ? Jul 28, 2015 20:10

Captain Foo: May 11, 2004; we vibin'
we slidin'
we breathin'
we dyin'

Ur Getting Fatter posted:

Nope.

Edit: turned out to be a faulty ethernet cable

Always check layer 1

# ? Jul 28, 2015 21:10

Storgar: Oct 31, 2011

I'm trying to install Korora (fedora offshoot) on my desktop that already has 500 GB of Windows 7 on a 1 TB harddrive. I just want to give it a trial run and see if I can use it full time for a few weeks, but I'm having trouble getting it to install to one partition.

By default, x86_64 systems have UEFI enabled but I don't have that on my current harddrive. Wiping Windows 7 is also not really an option, since I still want it and the data on it... I've been reading about ways to do some sort of "bios boot" thing, but I can't connect the dots. Apparently I'm supposed to make a 2 MB unformatted partition in the front with the boot flag set. But when I launch anaconda and do a manual config of my partition, there's no option for it to recognize the partition as part of the GPT. It won't let me advance the installer because "no valid target bootloader device".

Does anyone have any experience with this?

# ? Jul 29, 2015 06:04

evol262: Nov 30, 2010; #!/usr/bin/perl

Storgar posted:

By default, x86_64 systems have UEFI enabled but I don't have that on my current harddrive.

No, they don't. If you have a motherboard with UEFI and you've booted in EFI mode (not legacy), then it's enabled, that's not "your current hard drive". Windows may have been installed in legacy mode, or your system may not be EFI at all. I don't know which.

dmesg | grep -i efi

Storgar posted:

Wiping Windows 7 is also not really an option, since I still want it and the data on it... I've been reading about ways to do some sort of "bios boot" thing, but I can't connect the dots. Apparently I'm supposed to make a 2 MB unformatted partition in the front with the boot flag set.

EFI system partitions are larger than 2MB, if you're EFI. This sounds like a bios/legacy boot on a GPT disk (MBR/msdos disks don't need a bios boot partition).

Storgar posted:

But when I launch anaconda and do a manual config of my partition, there's no option for it to recognize the partition as part of the GPT. It won't let me advance the installer because "no valid target bootloader device".

Does anyone have any experience with this?

Why do you assume you need all this?

dmesg | grep -i efi

Will show you whether you're in EFI mode. If you are, you need an EFI system partition. If windows is already installed an you don't have one, windows was installed in legacy mode. It's more likely that you just don't have EFI.

Is your partition table actually GPT? "parted /dev/sda print". Again, if it were, windows would need to have a bios boot partition. I'm guessing windows installed on msdos/MBR. Or you already have a bios boot partition that you missed.

Please check this stuff and post the output. Most of your assumptions may be wrong.

# ? Jul 29, 2015 06:34

Storgar: Oct 31, 2011

evol262 posted:

No, they don't. If you have a motherboard with UEFI and you've booted in EFI mode (not legacy), then it's enabled, that's not "your current hard drive". Windows may have been installed in legacy mode, or your system may not be EFI at all. I don't know which.

dmesg | grep -i efi

EFI system partitions are larger than 2MB, if you're EFI. This sounds like a bios/legacy boot on a GPT disk (MBR/msdos disks don't need a bios boot partition).

Why do you assume you need all this?

dmesg | grep -i efi

Will show you whether you're in EFI mode. If you are, you need an EFI system partition. If windows is already installed an you don't have one, windows was installed in legacy mode. It's more likely that you just don't have EFI.

Is your partition table actually GPT? "parted /dev/sda print". Again, if it were, windows would need to have a bios boot partition. I'm guessing windows installed on msdos/MBR. Or you already have a bios boot partition that you missed.

Please check this stuff and post the output. Most of your assumptions may be wrong.

Ok sorry, I was speaking imprecisely. I meant that when you download a fedora/korora iso built for 64 bit systems, they try and set everything up to use UEFI. I did not mean to make any statements concerning my hardware or bios setup.

I already know that my windows installation is using "legacy mode" and that I don't have an EFI or boot bios partition. I have grub installed to my MBR. I'm trying to get Fedora to install itself without using UEFI. ("Install Fedora using legacy mode"?)

I read from random website using google that you can get Fedora to do something called "bios boot" but apparently according to the tutorials you need to make a bios boot partition. I can do that using gparted just fine, but when I get to the part where I am using anaconda to allocate disk space, I don't understand what to do next. I don't really care what boot bios is and I've never heard of it before and I'm not sure if it's the same as just installing to the MBR/legacy mode. I just want to install the dang OS to one partition on my drive without touching anything else.

Thanks.

# ? Jul 29, 2015 07:02

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

The bootloader basically sits at the front of the disk in a special BIOS boot partition, also known as the MBR. There can only be one bootloader. Windows has one, and Linux has one, called GRUB. The Windows bootloader doesn't support loading Linux, but GRUB supports both.

UEFI redesigned this so that it can support multiple bootloaders from the beginning. You unfortunately do not have UEFI, so you unfortunately cannot install Linux without touching the boot partition.

You need to make sure that GRUB is installed as the bootloader, and that it loads Windows. Recent versions of Fedora can be configured to do this for you. Anaconda has a lovely partition UI, we're all aware. When I was at Red Hat I tried super hard to get the Anaconda team to design and implement better UIs, but it just never happened.

# ? Jul 29, 2015 07:24

Storgar: Oct 31, 2011

Ok, yes. I am okay with completely messing with the MBR. My goal is to somehow get Fedora to not do UEFI.

Suspicious Dish posted:

You need to make sure that GRUB is installed as the bootloader, and that it loads Windows. Recent versions of Fedora can be configured to do this for you.

Yes, this is exactly what I want to do. I have tried unchecking the "install bootloader to this disk" option in anaconda and then just installing the base system to a partition. Afterward, I did a manual grub2 install to the MBR after chrooting into the new partition before I restart my live usb. I get grub but when I try and boot the partition, it tells me that it cannot find some linuxefi and initrdefi modules or something. Clearly I'm missing a few steps and configuration settings.

I can't seem to find any documentation on what to configure or how to do this. (I'm sure it's not because there isn't any documentation, but just because I am not familiar with Fedora). Could you guys point me in the right direction?

I was trying to make a bios boot partition because I was lead to believe that it is an alternative way to install Fedora to the system other than UEFI.

E. Oh yeah, and in an effort on my part to save some time, I have read the fedora installation guide. They have a multiboot section, specifically a subsection that deals with multiboot BIOS systems, here. Yes, it is a blank page. :negative:

Storgar fucked around with this message at 07:55 on Jul 29, 2015

# ? Jul 29, 2015 07:39

evol262: Nov 30, 2010; #!/usr/bin/perl

Storgar posted:

Ok, yes. I am okay with completely messing with the MBR. My goal is to somehow get Fedora to not do UEFI.

Fedora is behaving mostly correctly here, and does not do UEFI by default.

Storgar posted:

Yes, this is exactly what I want to do. I have tried unchecking the "install bootloader to this disk" option in anaconda and then just installing the base system to a partition. Afterward, I did a manual grub2 install to the MBR after chrooting into the new partition before I restart my live usb. I get grub but when I try and boot the partition, it tells me that it cannot find some linuxefi and initrdefi modules or something. Clearly I'm missing a few steps and configuration settings.

The problem is that your grub config says "linuxefi ...." and "initrdefi ..." instead of "linux" and "initrd"

The question is why that's happening. I have Fedora installed on a number of systems, some of which are EFI, and some of which are not (mostly virtual), and I've never seen this happen.

I went through the Anaconda source this morning (pyanaconda/bootloader.py has the grub bits), and it makes no assumptions whatsoever. It's actually quite modular, with support for a number of possible bootloader targets, only one of which is UEFI. grub-legacy is still there.

The grub config file is generated from grub2-mkconfig. The platform is detected with:

code:

from blivet import platform
print platform.platform

If it comes up as blivet.platform.X86 (as it should), it won't try to write to the EFi system partition. If it doesn't, the Korora people modified anaconda.

If it comes up as blivet.platform.X86, try "grub2-mkconfig -o /tmp/grub.cfg" and looking at that. If it comes up with "linuxefi" in there, the korora people modified grub2 and broke it.

Storgar posted:

I can't seem to find any documentation on what to configure or how to do this. (I'm sure it's not because there isn't any documentation, but just because I am not familiar with Fedora). Could you guys point me in the right direction?

You don't need to do anything, since it should just work. Please try the pieces above to see what's not working.

Storgar posted:

I was trying to make a bios boot partition because I was lead to believe that it is an alternative way to install Fedora to the system other than UEFI.

No, it isn't. And again, Fedora does not default to UEFI. Even the CDROM images have legacy and UEFI loaders coexisting. dumpet -i fedora.iso -d

UEFI requires a GPT partition table. UEFI requires an fat partition with a type of EFI system partition
BIOS/legacy with a GPT partition table requires a BIOS boot partition. This is because it keeps the GPT partition table goes in previously unused space that bootloaders had been using (because nothing had technically claimed it), and they needed somewhere else to go
BIOS/legacy with an msdos/mbr partition table requires nothing. It requires a boot-flagged partition where grub lives (usually /boot), and that's it. This appears to be your situation

The fact that GRUB is actually loading and reading the config file tells you two things:

grub is installed correctly
grub has correctly mapped grub's root()

You just need to fix the grub config file. Unfortunately, since you installed grub by hand, I don't know whether or not anaconda installed grub correctly or whether your chrooted install did it, but it doesn't matter at this point.

You should also find out why grub2-mkconfig is generating grub config files with "linuxefi", and go look at the changelogs and info for grub2-tools. I took a small look at their version of Anaconda, and I don't see any changes to the uncompiled bits other than a search and replace of Fedora with Korora, but I didn't download the srpm, and they could have changed something in the compiled parts for all I know.

Check what "grub2-mkconfig -o /tmp/grub.cfg" spits out.

Storgar posted:

E. Oh yeah, and in an effort on my part to save some time, I have read the fedora installation guide. They have a multiboot section, specifically a subsection that deals with multiboot BIOS systems, here. Yes, it is a blank page.

Multibooting on BIOS systems is just adding entries for the Windows partitions and chainloading them. "grub chainload windows" will get you millions of links with everything you need.

evol262 fucked around with this message at 16:56 on Jul 29, 2015

# ? Jul 29, 2015 16:52

spankmeister: Jun 15, 2008

Suspicious Dish posted:

The bootloader basically sits at the front of the disk in a special BIOS boot partition, also known as the MBR. There can only be one bootloader. Windows has one, and Linux has one, called GRUB. The Windows bootloader doesn't support loading Linux, but GRUB supports both.

UEFI redesigned this so that it can support multiple bootloaders from the beginning. You unfortunately do not have UEFI, so you unfortunately cannot install Linux without touching the boot partition.

You need to make sure that GRUB is installed as the bootloader, and that it loads Windows. Recent versions of Fedora can be configured to do this for you. Anaconda has a lovely partition UI, we're all aware. When I was at Red Hat I tried super hard to get the Anaconda team to design and implement better UIs, but it just never happened.

After years of using anaconda for installing various versions of red hat flavors and derivatives, the partitioning still trips me up sometimes.

# ? Jul 29, 2015 17:05

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

There's a script called grub2-mkconfig that determines whether you should use the EFI modules or not. The way it determines it is that it sees if /sys/firmware/efi exists on your system or not. Does that exist?

# ? Jul 29, 2015 17:17

Storgar: Oct 31, 2011

Ah I see. Good stuff. I'll try it out when I get home tonight.

quote:

BIOS/legacy with an msdos/mbr partition table requires nothing. It requires a boot-flagged partition where grub lives (usually /boot), and that's it.

Hmm, is it also fine to have one partition containing everything with mount point / and mark that as bootable?

# ? Jul 29, 2015 18:02

evol262: Nov 30, 2010; #!/usr/bin/perl

Storgar posted:

Ah I see. Good stuff. I'll try it out when I get home tonight.

Hmm, is it also fine to have one partition containing everything with mount point / and mark that as bootable?

Is long as that partition isn't on LVM or mdraid, yes. grub2 can technically boot off these, but sometimes it has issues wedging LVM modules into mbr/msdos disks, so it's better to not do it there.

# ? Jul 29, 2015 18:13

Varkk: Apr 17, 2004

Are you sure this is a Fedora issue and not due to the customisations made by the Korora project?

# ? Jul 30, 2015 00:25

Storgar: Oct 31, 2011

Varkk posted:

Are you sure this is a Fedora issue and not due to the customisations made by the Korora project?

No I'm not. I thought it might have been because I thought Fedora automatically tries to set up the partition space using UEFI,but it might be because I am installing grub incorrectly.

Edit:

evol262 posted:

The grub config file is generated from grub2-mkconfig. The platform is detected with:
code:
from blivet import platform
print platform.platform
If it comes up as blivet.platform.X86 (as it should), it won't try to write to the EFi system partition. If it doesn't, the Korora people modified anaconda.

If it comes up as blivet.platform.X86, try "grub2-mkconfig -o /tmp/grub.cfg" and looking at that. If it comes up with "linuxefi" in there, the korora people modified grub2 and broke it.

This returns me a blivet.platform.EFI object. I am chrooted into the installation system, but the live USB also gives me an EFI object. I am wondering if this has to do with the way I placed the ISO on to the USB device? I remember reading an article saying to be careful about which program to use to make a live USB and that you need to provide some flags to the program to allow for native BIOS mode. I used Fedora's live usb utility for windows but I could not find an analogous command line flag to copy what I read on the internet...

Edit Edit:

Golly gee, I think the answer's somewhere on this page: https://fedoraproject.org/wiki/How_to_create_and_use_Live_USB I have to jet, but I'll read it and try remaking my live USB again in a few hours...

Storgar fucked around with this message at 03:23 on Jul 30, 2015

# ? Jul 30, 2015 03:06

theperminator: Sep 16, 2009; by Smythe; Fun Shoe

Creating a USB stick with UNetBootin will give you an installer that boots in BIOS mode only, if I remember correctly this should also cause it to install your bootloader in a BIOS compatible manner rather than UEFI.

# ? Jul 30, 2015 04:11

evol262: Nov 30, 2010; #!/usr/bin/perl

Storgar posted:

No I'm not. I thought it might have been because I thought Fedora automatically tries to set up the partition space using UEFI,but it might be because I am installing grub incorrectly.

UEFI is not a partitioning scheme. UEFI requires GPT. Fedora uses GPT by default on new disks (and it's not synonymous with EFI), but yours is already MBR/msdos, and it won't change that.

Storgar posted:

This returns me a blivet.platform.EFI object. I am chrooted into the installation system, but the live USB also gives me an EFI object. I am wondering if this has to do with the way I placed the ISO on to the USB device?

It has nothing to do with it. BIOS systems cannot boot in EFI mode. Have you checked dmesg? Are you actually in EFI mode? blivet.platform.platform is set by blivet.platform.getPlatform(), which calls a number of "if blivet.arch.isx86(): #some stuff; elif blivet.arch.isefi()..."

E: gently caress android's copy from github. Go read isEfi from here

/sys/firmware/efi is created by the kernel if you're booted in EFI mode. grub2-mkconfig also checks this. At this point, I really think your system is EFI, but you've installed Windows in legacy mode without GPT, so the bootloader install won't happen automatically (because there's no EFI system partition), and you've wedged grub into the mbr.

But grub2 is smarter than grub-legacy, and it probes the system to see what you need, plus you probably don't have grub2-efi installed, so there's no module.

lsmod | grep efivars

Storgar posted:

reading an article saying to be careful about which program to use to make a live USB and that you need to provide some flags to the program to allow for native BIOS mode. I used Fedora's live usb utility for windows but I could not find an analogous command line flag to copy what I read on the internet...

You can do this, but it's easier just to go into your EFI boot menus, enable legacy boot, and put it earlier in the boot order.

Storgar posted:

Golly gee, I think the answer's somewhere on this page: https://fedoraproject.org/wiki/How_to_create_and_use_Live_USB I have to jet, but I'll read it and try remaking my live USB again in a few hours...

Making a liveusb will create a dual personality boot sector just like the dumpet command earlier would have shown you.

So, lsmod | grep efivars
ls /sys/firmware/efi

See whether the syslinux boot menu is bigger than 640x480 or something.

Break out of syslinux and edit the entries to see whether they say linuxefi

Any of these will show you if you're actually booting in EFI mode and just don't know it.

At this point I'm gonna ask for your motherboard info (you can get this from dmidecode if you don't remember it), because I suspect your system is EFI, booted in EFI mode, trying to install on an MBR disk, which would explain all of this

evol262 fucked around with this message at 05:58 on Jul 30, 2015

# ? Jul 30, 2015 05:54

Storgar: Oct 31, 2011

evol262 posted:

At this point I'm gonna ask for your motherboard info (you can get this from dmidecode if you don't remember it), because I suspect your system is EFI, booted in EFI mode, trying to install on an MBR disk, which would explain all of this

Yeah, I think this is the case. Am I stuck?

Let's see:

lsmod | grep efivars returns blank; It is printing a list of modules, but the text "efi" is not present...

/sys/firmware/efi does exist and contains stuff

dmesg ->

code:

efi: EFI v2.00 by American Megatrends
efi: SMBIOS=0xf0480 ACPI=0xdf4b7000 ACPI 2.0=0xdf4b7000 MPS=0xfcb60

followed by a bunch of lines like:
efi: memxx: [boot code or something | | | |... etc

Motherboard info: http://pastebin.com/R2bbBHgG (yeah, UEFI supported?)

evol262 posted:

/sys/firmware/efi is created by the kernel if you're booted in EFI mode. grub2-mkconfig also checks this. At this point, I really think your system is EFI, but you've installed Windows in legacy mode without GPT, so the bootloader install won't happen automatically (because there's no EFI system partition), and you've wedged grub into the mbr.

Hmmm, ok, I see. This is what happened; I initially had two partitions, one for Windows 7 and then another that had Gentoo, then Arch, then Linux Mint on it all of them installing grub to the MBR.

Oh yeah, I forgot to mention that my computer is X86_64. Were you assuming this already?

# ? Jul 30, 2015 07:37

evol262: Nov 30, 2010; #!/usr/bin/perl

Storgar posted:

Yeah, I think this is the case. Am I stuck?

Let's see:

lsmod | grep efivars returns blank; It is printing a list of modules, but the text "efi" is not present...

/sys/firmware/efi does exist and contains stuff

dmesg ->
code:
efi: EFI v2.00 by American Megatrends
efi: SMBIOS=0xf0480 ACPI=0xdf4b7000 ACPI 2.0=0xdf4b7000 MPS=0xfcb60

followed by a bunch of lines like:
efi: memxx: [boot code or something | | | |... etc
Motherboard info: http://pastebin.com/R2bbBHgG (yeah, UEFI supported?)

Hmmm, ok, I see. This is what happened; I initially had two partitions, one for Windows 7 and then another that had Gentoo, then Arch, then Linux Mint on it all of them installing grub to the MBR.

Oh yeah, I forgot to mention that my computer is X86_64. Were you assuming this already?

Go into your boot setup menus. There will be a list of boot setup options like "USB" and "Legacy: USB". Make sure legacy has higher priority. Then boot the installer and make sure /sys/firmware/efi doesn't exist, and you'll be good.

Or change the grub config file you have now to " linux" instead of "linuxefi", and you'll probably be able to boot.

# ? Jul 30, 2015 14:50

Storgar: Oct 31, 2011

evol262 posted:

Go into your boot setup menus. There will be a list of boot setup options like "USB" and "Legacy: USB". Make sure legacy has higher priority. Then boot the installer and make sure /sys/firmware/efi doesn't exist, and you'll be good.

I couldn't find anything. I do notice that when the USB is in, it gives me an entry that says "UEFI: USB etc...". There is nothing in the menus that seems like legacy usb. I have an entry called "Sumeru" which I vaguely feel relates to USB somehow, but it just fails silently.

evol262 posted:

Or change the grub config file you have now to " linux" instead of "linuxefi", and you'll probably be able to boot.

Yes, I should have done this to begin with. Success. I managed to install linux on my computer. We're in business now, boyz. :downs:

Thanks for all of your help, peeps.

# ? Jul 31, 2015 09:34

Cingulate: Oct 23, 2012; by Fluffdaddy

free shows me there is basically no memory left. There is still 30GB buffers, but something is eating up hundreds of GB. If I display programs by memory usage, I find a few idling things not owned by me that together amount to a few GB, but I cannot account for >70% of memory used by looking at the top 60 processes. Is there some other way to figure out what's eating the RAM?

I don't have root and our admin is ... unavailable.

# ? Aug 2, 2015 10:36

VictualSquid: Feb 29, 2012; Gently enveloping the target with indiscriminate love.

Cingulate posted:

free shows me there is basically no memory left. There is still 30GB buffers, but something is eating up hundreds of GB. If I display programs by memory usage, I find a few idling things not owned by me that together amount to a few GB, but I cannot account for >70% of memory used by looking at the top 60 processes. Is there some other way to figure out what's eating the RAM?

I don't have root and our admin is ... unavailable.

Do you count cache as free or used here?

# ? Aug 2, 2015 11:58

Cingulate: Oct 23, 2012; by Fluffdaddy

tonberrytoby posted:

Do you count cache as free or used here?

As buffers, actually. But it it's only a small fraction of the total.
And there's no reason for hundreds of GB of buffers all of a sudden either!

# ? Aug 2, 2015 12:25

VictualSquid: Feb 29, 2012; Gently enveloping the target with indiscriminate love.

Did you check if your top 60 programs includes all programs or if it excludes inactive processes? Many lists exclude them by default.

# ? Aug 2, 2015 13:20

Cingulate: Oct 23, 2012; by Fluffdaddy

tonberrytoby posted:

Did you check if your top 60 programs includes all programs or if it excludes inactive processes? Many lists exclude them by default.

I used this: ps -e axo pid,args,pmem,rss,vsz --sort -pmem,-rss,-vsz | head -n 30

# ? Aug 2, 2015 13:42

evol262: Nov 30, 2010; #!/usr/bin/perl

Cingulate posted:

free shows me there is basically no memory left. There is still 30GB buffers, but something is eating up hundreds of GB. If I display programs by memory usage, I find a few idling things not owned by me that together amount to a few GB, but I cannot account for >70% of memory used by looking at the top 60 processes. Is there some other way to figure out what's eating the RAM?

I don't have root and our admin is ... unavailable.

Please post /proc/meminfo and "free -m", to start.

# ? Aug 2, 2015 16:32

Adbot: ADBOT LOVES YOU

# ? Jun 7, 2024 09:21

Cingulate: Oct 23, 2012; by Fluffdaddy

evol262 posted:

Please post /proc/meminfo and "free -m", to start.

Hm .. I just tried it (free -gt), and the problem seems to have solved itself. Something just freed up hundreds of GB of RAM.
Processes look unchanged.

Cingulate fucked around with this message at 16:46 on Aug 2, 2015

# ? Aug 2, 2015 16:42

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Linux Questions Thread: a bunch of pitfalls, but technically it's possible

«‹›1040 »