Guys, this is an OK version of Netrunner, don’t get me wrong, but both the server and torrent links for what you claim is Manjaro/Arch-based Netrunner Rolling 2017.07 is actually Debian-based Netrunner 17.06. Post-install I’ve confirmed it via:
$ cat /etc/issue.net
Debian GNU/Linux 9
Have you actually released a brand new version of Manjaro/Arch-based Netrunner Rolling? If so, could you please fix the download link?
Thanks in advance.
under Download the serverlink to Manjarobased ISO is this:
Is this the actual ISO you downloaded and it still installs as Debian?
Does it have octopi shipped or synaptic?
starbuck, yes, I hit that very link, and post-install I have apt-get & synaptic, NOT octopi.
I’m trying the download link now, and will load the ISO in VB as soon as it downloads.
If you don’t mind me asking, did you compare the sha256sum from the download page to the ISO?
How did test the ISO, (Virtual box, etc., or via burned media on bare metal)?
What kind of media did you use (DVD or USB stick)?
What application did you use to burn it?
If USB stick, did the stick previously contain the Debian variant?
Did you wipe the stick prior to burning to it?
I tried to perform an sha256sum check – but sha256sum reported the DVD didn’t have a checksum attached. Generally speaking I have high confidence & trust in the Netrunner devs – you haven’t steered me wrong yet, so the lack of a sha256 checksum wasn’t a deal-breaker for me. The downloaded file was named “netrunner-rolling-2017.07-64bit.iso”, so it looked to be the Right File.
I installed the media to bare metal, from a USB 3.0-compatible 64GB USB stick I’d setup for the purpose. I used netbootin for Mac. I forget what I had on that stick beforehand, but it was wiped.
And to be clear: the installed system was clearly dressed to the nines in Netrunner 17.06-branding.
Also: the system appears to be functional – maybe missing the menu launcher icon, but otherwise a perfectly fine Debian-based distro!
Thanks again for any insight you can offer.
There is part of the problem, this is a hybrid ISO which needs to be written to the USB in raw mode.
Unetbootin, or any similar utility that partitions, formats and copies the files to it and then creates it’s own grub menu, will not work properly with these ISO’s.
READ here for details on these ISO files and how to write them to a USB stick:
Note: That page is slightly out of date, the isousb application is now in the Manjaro repositories.
Since the Netrunner Rolling ISO is a hybrid (IE. contains two partition structures), it needs to be a bit for bit RAW copy of the ISO written to the stick.
Aha, thanks! I’ll digest this and proceed. Thanks again!
UPDATE: I’ve managed to boot from the USB stick correctly, and am able to run the installer from there. I’ve got a different problem now, because the installer didn’t setup GRUB correctly, and now I can’t boot into either my Windows or NRR installs.
When I’ve had similar problems in the past with Kubuntu I was able to restore both systems by booting into an Ubuntu recovery disk, fire up boot-repair and use it to either fix the MBR or reinstall GRUB. Are similar tools available within NRR Live?
Thanks in advance for any pointers, I’m looking forward to getting back to a fully operational system.
I’m assuming you have a uefi system and thus grub doesn’t go on a MBR.
Did you boot the Live media from the UEFI boot menu or from legacy mode?
Did you turn off secure boot before trying to install manjaro?
I booted from UEFI mode. My system’s BIOS doesn’t seem to have a secure boot to turn off.
That is strange, it’s usually under the security settings.
I would check again, may I ask what make and model system or mainboard (if custom built) you have?
You may have run into a calamares and/or uefi implementation bug, there was a user with a similar issue in the manjaro IRC yesterday,
It’s an ASUS Crosshair V Formula 990FX motherboard, running American Megatrends AMIBIOS Revision 1503. I can check for a BIOS update, there probably is one available. I’ve been all over the menus of this BIOS and there does not seem to be a “Secure Boot” option.
Re: the calamares and/or UEFI bug, was there a workaround for that?
No it turned out to be a UEFI bug. Just like how most UEFI systems only expose vesa information to the system if the UEFI menu is selected at boot. If the UEFI system boots straight into the default item in it’s list (Manjaro grub), then this info is not passed and grub as well as TTY is displayed in low resolution until the kernel module is loaded.
Thanks for this, but my BIOS doesn’t display exactly those options under my “Boot” settings – nowhere in that section is any mention of Secure Boot, or I would have already disabled it. The thing that puzzles me about this is that I had no problems installing NRR from a year ago. NRR hasn’t significantly changed its setup routines since the last major release, has it?
If so I can certainly try upgrading my BIOS, but I’d rather take a conservative approach to this if it’s not strictly necessary. Does the install process for NRR require a BIOS with Secure Boot available but disabled?
Thanks again for the guidance.
OK, if booted into UEFI mode calamares should reflect this in top corner of partitioning page.
What option did you use to install?
1: replace system - I know it was not this one.
2: install along side windows
3: replace existing partition
4: partition manually
Could you post a screen shot of your partitions from within KDE partition manager?
I chose option 4: manual partition.
See the attached PNGs, each labelled according to the drive in question.
sda1 - 100MB reserved NTFS for Windows 10
sda2 - ~236GB Windows 10
sda3 - < 500MB NTFS Windows 10 recovery partition
sdb1 - 1.82TB NTFS file store for Windows 10
sdc1 - 701GB EXT4 /home partition
sdc2 - 230GB EXT4 /var partition
sdd1 - 250MB FAT32 EFI partition (originally mounted under /efi)
sdd3 - 221GB EXT4 / partition
sdd4 - 2GB swap
There are two other disks, both external, both used for backup/storage.
Thanks again for any insight.
Well the efi partition needs to be mounted as /boot/efi for calamares to install properly, and for the system to boot.
Also ensure the drives are using gpt and not mbr if at all possible.
Crap, looks like my system’s partition tables for each of my disks is “msdos” (as reported by parted -l). That’s irritating, because I used to have my system setup fine on sdd. ISTR GPT was determined to be The Way to Go a few years ago & thought (incorrectly, apparently) that I setup my Linux system disk (sdd) with GPT.
Looks like I have a bit of work to do. How does this sound: using GParted I completely wipe sdd, creating a new partition table on it, with the following partitions:
/dev/sdd1. ~500MB FAT32 space for /boot/efi
/dev/sdd2. ~220GB EXT4 space for /
/dev/sdd3. ~2GB linuxswap
I can then then install NRR with that setup, and setup my /home and /var mounts from sdc. Ideally I’d have GRUB installed on sdd, probably sdd1, and would then setup my BIOS to boot from that disk to allow me access to GRUB on startup.
I’m wondering if I should reinstall Windows 10 first, since that seems to be truly borked?
Thanks again for your insight.
No grub does not install to a MBR in a uefi/gpt setup. Grub would be in an image on the ESP (efi system partition)
Just as windows would have it’s bootloader in that partition. Changing anything about the efi partition looses the bootloaders for all operating systems installed. This means if there is already a efi partition containing bootloaders, then do not move, remove, or format this partition. If you did any of these things, you will need to repair the windows bootloader first, before installing Linux…
I think you have a bit of reading to do before trying a manual install.
Aha, thanks for this. Evidently I’ve forgotten how I’d set this up before. I’ll read up and proceed. Thanks!