• Please review our updated Terms and Rules here

Didn't you love those classic '90s "Linux installation reports"?

I never did get it installed, I got sick of hitting "Ignore" to all the incompatible architecture messages. I'll play around with trying it on the 486 later. It was released in 1997 I believe, which means it's old enough it *should* install in a 486, but new enough to install on an i686 compatible system.
 
Hmm...got it running an install on Bochs. Seems to be working, installer is fast as always, can't wait to see how fast the real OS is (as entire system emulation is ALWAYS slow).
 
All depends what system you're running the emulation software on. OS/2 v4 on MS VPC2004 on a 2.4gig p4 running XP is definately faster than a P133 running the same OS.
 
Bochs appears to work, quite fast considering how slow Bochs is. The only problem I found is that when I set the video adapter to the Cirrus Logic GD543x and set the display to 800x600 it went to 640x480 and now I don't have enough screen space to change it to something different because the screen is too small, lets manually edit the config tomorrow.
 
Pepinno said:
Here is a nice Linux installation report, dated 1996 (so just before the 2.0 kernel was born and with it the mainstream support for loadable modules), for the laptop Texas Instruments TravelMate 4000, using Linux kernel version 1.2.8 and the Slackware distribution:

http://www.kenharker.com/linux-tm4000m/toc.html

Pretty nifty, if you ask me.
Click to expand...
Indeed. That's the style. Those were very useful back in the day, and still is.. I used to check out a page called 'linuxlaptops.org' or something - I'm not sure of the exact name because there was also a spam site out there of nearly the same name which differed by only a single letter.

Edit: This may be the successor of that laptop site.. it looks like just the thing. I'll bookmark it for later for sure: http://tuxmobil.org/mylaptops.html

-Tor
 
The momentum for those "Linux installation reports" of yore is back in vogue!

Now with the death of BIOS and the new born EFI boot system, plus the Secure Boot attempt at tivo-izating the PC mass market, installing Linux on some computers is back to being just as painful as it was in 1995.

Behold this post, by user Val (vk1266) on the Ubuntu bug tracker:

I am delighted to report that Ubuntu 12.10 64-bit is now running on my Samsung NP700Z5C, dual booting in UEFI mode from Grub2 to either Ubuntu or pre-installed Windows 8.

My installation process is described below. However, the nature of this bug is such that you should consider very carefully if you still want to attempt installation of 64-bit Ubuntu on your Samsung laptop. If something does not work for you the way it should, your motherboard may be permanently damaged and your laptop may get bricked. For this reason, this bug should have been flagged "nuclear" rather than "critical".

The process below is long and much more arduous than it should be. It applies only to the installation of 12.10 64-bit. To install 12.04, get one of the latest daily builds from http://cdimage.ubuntu.com/precise/daily-live/current/ (dated January 18th, 2013 or later) and install from it in a usual way. To the best of my knowledge, daily builds for 12.10 Live CD are not available. I hope Steve or someone else could clarify this.

My system is: Samsung Chronos NP700Z5C, BIOS version P04ABJ, MICOM version P04ABJ, Windows 8 pre-installed on a GPT-partitioned disk. There is also a 16 Gb ExpressCache disk but I have not touched it yet.

1. While in Windows 8, make space for Ubuntu by shrinking Windows partition. It's probably a good idea at this point to leave all other partitions intact. You must not delete the EFI partition - the one flagged 'boot' - this thing alone may be enough to brick your laptop!

2. Make sure that:
- Fast BIOS Mode is disabled
- AHCI Mode is enabled
- "Secure Boot" is disabled
- VERY IMPORTANT: "OS Mode Selection" is set to "CSM OS"; any other setting will likely brick your laptop
- Save your BIOS settings

3. Boot Ubuntu 12.10 64-bit Live CD and select "Try Ubuntu without installing". You may be able to install from a USB drive. I have not tried that route. Create swap and root partitions for Ubuntu. Take note of the number of your Ubuntu partition, you will need it at the final stage of installation. In my case, it was partition 8 (gpt8). Create a 10 Mb BIOS Boot Partition: in GParted, create an unformatted partition and set bios_grub flag on it. If you want to preserve your original MBR, create a backup copy of it at some non-volatile location:
dd if=/dev/sda of=/mnt/mbr_original bs=440 count=1
Replace sda and location of mbr_original as necessary.

4. Install Ubuntu. Once you get to "Installation type", do not install Ubuntu alongside Windows; choose the "Something else" option instead. Use the Ubuntu root partition you created as the root mount point. If the installer offers you to resize a Windows partition, decline. You don't want to mess around with Windows partitions at this point; you can always do it later. The bootloader must be installed in /dev/sda (or whichever is the boot disk in your case), NOT in /dev/sda1 or other partition.

5. Reboot. Do NOT change any BIOS settings yet! Once you have Ubuntu booted from your hard disk, take note of the kernel version: "uname -a". Download and install Colin King's patches: http://kernel.ubuntu.com/~cking/samsung-1040557. Reboot and take note of the kernel version. It must match Colin King's version (as of time of this writing, it's 3.5.0-21.32).

6. Obtain UUID of your EFI partition. Assuming it's /dev/sda2, execute:
sudo blkid /dev/sda2
You should get something like this:
/dev/sda2: LABEL="SYSTEM" UUID="7816-793A" TYPE="vfat"

7. Create mount point for the EFI partition:
sudo mkdir /boot/efi
Add the following two lines to your /etc/fstab, using the UUID you obtained earlier:
# EFI boot partition
UUID=7816-793A /boot/efi vfat defaults 0 0

8. Reboot. Make sure that you see "Boot" and "Microsoft" directories in /boot/efi/EFI. If you do, continue to the next step. If you don't, stop and find out what's wrong. Once you have proceeded past the installation of grub-efi, you will not be able to boot in the CSM mode and you would likely need to start from the beginning if something is wrong with your Ubuntu installation.

9. In the CSM mode you can only install grub-efi but you cannot generate Grub menu because you need to be booted in the UEFI mode in order to read EFI variables that are necessary to generate Grub menu. Therefore, you need a UEFI bootloader that would allow you to boot Ubuntu in the UEFI mode for the first time. Windows UEFI bootloader will not help you; it will boot Windows, period. At this point, I recommend you obtain a rEFInd CD image and make a bootable CD with rEFInd. The advantage of rEFInd CD is that it will boot you in the UEFI mode and you won't have to mess around installing more files to your EFI partition and taking risks with efibootmgr. Obtain a rEFInd CD image from here: http://www.rodsbooks.com/refind/getting.html and burn the image to a CD.

10. Now, install grub-efi:
sudo apt-get install grub-efi-amd64
Note that this removes grub-pc and grub-gfxpayload-lists. That's fine. Install the EFI bootloader:
sudo grub-install --efi-directory=/boot/efi --target=x86_64-efi --bootloader-id=Ubuntu-12.10_64
Now you should see "Ubuntu-12.10_64" directory in /boot/efi/EFI.

11. Reboot and make one change to your BIOS settings:
- change "OS Mode Selection" from "CSM OS" to "UEFI OS"
Save settings. Insert your rEFInd CD and reboot.

12. Now comes the hardest part. From the rEFInd main menu, select "Ubuntu-12.10_64". You will now be placed in the Grub shell, and you will be manually typing Grub commands:
insmod efi_gop
insmod efi_uga
insmod ext2
insmod gzio
If you accidentally make a mistake in these commands or in the commands below, restart with Ctrl-Alt-Del and repeat your commands. This is generally safer than taking changes with your first boot.
Determine UUID of your EFI partition:
ls
You will get a list of partitions; assuming that your boot disk is 0 and your Ubuntu partition is gpt8 (use your number that you noted in Step 3), type:
ls '(hd0,gpt8)'
Take note of the UUID of your Ubuntu partition. It is a long identifier in the form of 641fdda9-3f4d-41c4-9d32-bfbf56e6d80d. Use your Ubuntu partition UUID to issue the following commands:
set root='(hd0,gpt8)'
search --no-floppy --fs-uuid --set=root 641fdda9-3f4d-41c4-9d32-bfbf56e6d80d
In the following two commands, use Tab key to auto-complete filenames for vmlinuz and initrd, such as: having typed /boot/vm, hit Tab and have Grub shell autocomplete the filename for you. This will ensure that you don't have a typo in the file name.
linux /boot/vmlinuz-3.5.0-21-generic root=UUID=641fdda9-3f4d-41c4-9d32-bfbf56e6d80d
initrd /boot/initrd.img-3.5.0-21-generic
boot
and with luck, now you are in Ubuntu for the first time in UEFI mode!

13. Create Grub menu:
sudo update-grub

That's it!

If you created a backup of your original MBR, now is the time to restore it, replacing mbr_original and sda as necessary. Double-check everything before executing this command, one mistake and your MBR may be filled with garbage:
dd if=/mnt/mbr_original of=/dev/sda bs=440 count=1
Also, it is safe to delete the BIOS Boot Partition at this point.

14. However, booting Windows from Grub menu will likely not work for you as it did not for me. It's a known bug:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1024383
I fixed the problem by following post #18 in the above page. However, I instantly hit another problem: Grub menu disappeared and Ubuntu was booting without any menu options. It turned out that it is caused by incorrect timeout setting in /etc/grub.d/30_os-prober. To fix it, comment out the line with "adjust_timeout" in this block of code in 30_os-prober (I am going to file a bug report on this):
if [ "x${GRUB_DISABLE_OS_PROBER}" = "xtrue" ]; then
adjust_timeout
exit 0
fi

15. Most likely you will see that "kworker" process consumes 80-100% of one CPU core on your Samsung laptop. It is a known bug:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/887793
Follow post #116 to fix it.
Click to expand...

One thing has not changed: hard core Linux users are hard core.
 
I recently installed Debian on the latest&greatest NEC laptop (which is sometimes called Lenovo now, although I think that particular super-lightweight one is mostly NEC). I didn't bother with dual-booting Windows though, I simply exchanged the 128GB M.2 SSD it came with for a 256GB M.2 of the same type, went into the BIOS and turned off secure boot, and installed. It went without hickup, the only sidetrack was that I had to download the Intel firmware for the network/BT chipset. I used a USB-Ethernet dongle (the Apple one works fine, and an Asus one with the same AXIS chipset) for the initial install, because this thing doesn't have Ethernet, only wireless, and as I mentioned I had to download the firmware. So a bit of bootstrap there. But everything worked flawlessly and there was no pain involved at all. It's all Intel inside (network, video, sound etc), and that's a guarantee for success in my experience (no R*tek cor B*com junk). The half-4K screen also worked fine. All in all easier than nearly any previous laptop installation because after the install was finished and the firmware loaded everything was done. Nothing extra to fiddle with to set up video or get video acceleration or sound or wifi or Bluetooth mouse to work. All was fine out of the box.

Dual-boot would probably create more trouble. Maybe. I don't know. Too small SSD anyway. I have an older Samsung notebook where I left Windows in place (notebook given to me from work), I don't use the Windows partition for anything but I can't get it to boot Windows if I install Grub the normal way. I don't think there's any UEFI there. In any case, I have Grub installed on a tiny (as in small capacity) SD card and have that SD card in the SD slot. It loads Grub from there, which then boots Linux from the right partition.

Anyway, with just forgetting about Windows that NEC installation was a breeze.

My only worry now is that I want another of the same NEC laptop, and they sell the same one with different version numbers (or letters really) for those that come with Windows 10 (and they're more expensive, even though the ones with Win 8.1 can be upgraded to 10 w/o cost). Specs are otherwise exactly the same. But I've heard rumors about MS demanding that Secure boot cannot be disabled in Windows 10 laptops.. and my worry is that those models with that other letter, which is what I can mostly find in shops now, have that mis-feature. Is this really true? Windows 10 OEM laptops cannot disable secure boot? (And no, I'm not going to ask in the shop, they won't know, and besides my Japanese is severely lacking for that level of questioning).
 
Tor said:
But I've heard rumors about MS demanding that Secure boot cannot be disabled in Windows 10 laptops.. and my worry is that those models with that other letter, which is what I can mostly find in shops now, have that mis-feature. Is this really true? Windows 10 OEM laptops cannot disable secure boot?
Click to expand...

AFAIK, to qualify for the "Windows 8 logo" OEMs had to ship their wares with SecureBoot either disabled by default or with the option to have it disabled in UEFI settings by the user; however, now Microsoft has dropped that requirement for OEMs to qualify for the "Windows 10 logo". So theoretically you could get a PC/laptop with SecureBoot on by default and without an option to disable it in UEFI settings.

In that case just return the bought PC/laptop and let the retailer feed-back to the manufacturer.
 
Pepinno said:
In that case just return the bought PC/laptop and let the retailer feed-back to the manufacturer.
Click to expand...

Why? There are boot-shims available for linux, signed with a Microsoft certificate, eg: https://wiki.ubuntu.com/SecurityTeam/SecureBoot
These will work fine on a system with secure boot enabled.

I do find it funny though, that the linux community, once boasting about their 'security', now actively opposes an industry-standard which makes installing a rootkit considerably more difficult.
The proper answer is that UEFI SecureBoot should never be disabled, but instead all OSes should support it (note that the Ubuntu-example above doesn't actually improve security past GRUB itself. Fedora does implement SecureBoot by also having signed kernel and modules, and actively enforcing signed-only code).
 
Last edited:
SecureBoot and signed code in general is just an extortion scheme on the part of certificate authorities and their cronies. There, I said it.
 
commodorejohn said:
SecureBoot and signed code in general is just an extortion scheme on the part of certificate authorities and their cronies. There, I said it.
Click to expand...

Well, Microsoft sabotaged that by offering a service for signing third-party software using their certificate :)
This problem was solved years ago.
 
Secure boot is about locking your machine to Microsoft, and nothing else. The only security issue it can do anything about is when somebody has physical access to your machine. The 'evil maid' scheme. And what's needed to prevent that is authenticating the *user* to the machine, not the *software*. The latter only prevents *me*, the owner, for doing what *I* want with the machine.

In any case, there is an unfortunate chance that a new laptop is prevented from installing Linux. It's not that easy for me to return a laptop to a shop, in the country I'm in. So MS succeeds.

I'm looking at that Ubuntu Secureboot link Scali provided. Looks complicated, but I'll study it. Page after page of stuff.. and only talking about installing signed kernels. Well, I don't have signed kernels, either I use a Debian-built kernel or I build the kernel myself. But I'll study the link.
 
Tor said:
I'm looking at that Ubuntu Secureboot link Scali provided. Looks complicated, but I'll study it. Page after page of stuff.. and only talking about installing signed kernels. Well, I don't have signed kernels, either I use a Debian-built kernel or I build the kernel myself. But I'll study the link.
Click to expand...

You don't need signed kernels, just a signed GRUB, which is already provided. As I said, the problem was solved years ago already. By none other than Microsoft. Which nullifies the rest of your post. You're just spreading FUD.
 
And now we enter that stage of the argument where any view anybody disagrees with is labelled "FUD."

In any case, any person or program that tries to tell me what I can and can't do with my own computer can piss right off, and that's all there is to it.
 
commodorejohn said:
And now we enter that stage of the argument where any view anybody disagrees with is labelled "FUD."
Click to expand...

This is not a 'view' that someone 'disagrees' with.

This is me pointing out an article on the Ubuntu-site which describes how Ubuntu uses a Microsoft-signed bootloader to boot on SecureBoot systems (which afaik has been fully integrated into their live DVDs for a while now, at least, the 64-bit versions, so installing on a SecureBoot system is as simple as popping in the DVD and installing). These are facts, not a 'view'. Note that the only 'secure' part is the signed shim and GRUB-combination. GRUB itself does not enforce any signing, so you can boot any supported unsigned OS once you have this version of GRUB installed on your system. It doesn't have to be Ubuntu, doesn't even have to be linux.

Which is responded to with remarks such as "Secure boot is about locking your machine to Microsoft, and nothing else." and "In any case, there is an unfortunate chance that a new laptop is prevented from installing Linux".
Clearly both statements are patently false given the provided link, and given their "Microsoft is scary and evil!"-message, can clearly be classified as FUD (it is not disagreeing, it is downright denying the facts presented to you).

And then I didn't even get into the other misinformation such as: "The only security issue it can do anything about is when somebody has physical access to your machine."
Erm no, SecureBoot is for preventing malware from modifying your bootloader and/or kernel without you ever knowing about it. The so-called 'rootkit', which is nearly impossible to detect by conventional antivirus software, since the rootkit can control the kernel, and therefore make itself invisible to other software.
These rootkits can easily be installed via exploiting vulnerabilities in the OS/applications, so it can easily be installed in a number of ways without physical access to the machine. Such as via an exploit in one of your services (eg httpd, ftpd, sshd and such), via software you download and run from the internet, or even via 'drive by' webpage exploits.
All these are well-documented and well-understood in the world of security.
 
Last edited:
Scali said:
I do find it funny though, that the linux community, once boasting about their 'security', now actively opposes an industry-standard which makes installing a rootkit considerably more difficult.
Click to expand...

An industry standard where a select few companies hold all of the keys to a market with millions/billions of players is a terrible industry standard.

Also, your point about UEFI being more difficult to root is invalid. Several UEFI exploits have existed for a few years already that allow rootkits to succeed on several different vendors. Many of these exploits have not been patched for the same reason there are millions of hackable routers on the internet, vendor negligence. I'd argue that UEFI is far less secure than a traditional BIOS since it's far more complex and relies on per-vendor implementation, which we've seen time and again is a disaster for security.

I'll take a traditional BIOS over an UEFI with its tentacles in everything every day of the week.
 
GiGaBiTe said:
An industry standard where a select few companies hold all of the keys to a market with millions/billions of players is a terrible industry standard.
Click to expand...

That is a symptom of certificate signing in general, not of SecureBoot in particular. The system is simply based on the idea that only a select few organizations are designated as authorities to give out software (and let's be clear on this, Microsoft is not one of them).
For some reason I never heard these complaints related to HTTPS, SSL, Java code signing etc.

GiGaBiTe said:
Also, your point about UEFI being more difficult to root is invalid.
Click to expand...

No, it is not.
The fact that it has been rooted does not imply that it is not more difficult to root (in fact, you yourself point that there are per-vendor implementations, so exploits need to be targeted per-vendor as well. So you have already implicitly stated that it is more difficult to root than an unprotected boot, where one size fits all).
Your claim is equivalent to claiming that there's no point in running antivirus software, because some viruses may go undetected.

*sigh*


GiGaBiTe said:
I'll take a traditional BIOS over an UEFI with its tentacles in everything every day of the week.
Click to expand...

Pick whatever you want. Just don't spread misinformation about it. People should be properly educated on the technology so they can make their own well-informed decisions.
I mean, telling someone to send back a new computer, when they could just download an Ubuntu live-DVD (or others, Fedora is another option that supports SecureBoot out-of-the-box, there may be more), isn't exactly sound advice in my opinion.
 
Last edited:
You must log in or register to reply here.
Back
Top