Dual Booting Trisquel Complications
- Login o registrati per inviare commenti
I decided to dual boot Trisquel on my windows 10 desktop but it proved quite the dramatic adventure
So I freed some space from windows, and rebooted into a Trisquel live USB.
When I started the installer from the live environment,it did not recognise Windows 10 at all,and made no offer to install next to it. (Usually the first offer)
So I stopped the installer,went back into windows and made a Fedora live USB instead,to reproduce the issue.
Fedora detected the free space and installed without issue next to Windows. It made a Windows recovery option in grub,which booted windows when selected.
This was the first fail on Trisquel's part.
I rebooted again into the Trisquel live USB and started the installer again. This time,it did recognise Fedora 23 (TwentyThree) and made the usual offers (Next to,Wipe).I wiped Fedora and Installed Trisquel. Everything went smoothly. I restarted the PC. To my surprise Windows was not listed at all in Grub. I was shocked, since I was pretty sure I only wiped Fedora.
This was the second fail by Trisquel
I booted into Trisquel (the only option) and it booted fine. Inside Trisquel, I could see my Windows partitions in the File Manager but they weren't mounted. So it hadn't wiped windows after all. I went into terminal and ran the commands
sudo os-prober
sudo update-grub2
Which detected windows and added the option to Grub. All is well I thought. So I rebooted into grub and selected Windows recovery. Lo and behold Grub asked for a username.I key in my username and password.Nothing happens,and it goes back to the OS list on grub. I recall how it asked nothing of the sort on Fedora,and boot back into Trisquel again.
This is the third fail by Trisquel.
After some strong searching on the internets I come across someone with a similar issue,from this forum,and his solution. It seems Trisquel sets a password on anything that isn't Trisquel (He had Debian and Windows) and the username and password aren't the login ones (why? I do not know). The fix is commenting out the username and password in
/etc/grub.d/01_PASSWORD (needs root,don't forget to also update-grub2)
So one last time I reboot and select windows recovery in Grub.FINALLY, a working dual boot!
I feel this was unnecessarily hard and complex just to achieve a simple dual boot.
1.Trisquel 7 doesn't detect windows 10 at all
2.Trisquel doesn't list Windows in grub even if you do get them next to each other
3.Trisquel puts a username and password (that aren't readily apparent to the installer) on the Windows option if you do get grub to list it.
If someone wants to dual boot just let them. For a distro that is supposed to be giving users freedom this whole debacle feels highly restrictive.Similar functionality to Fedora would be ideal here (detect free space,add windows to grub,no passwords) in Trisquel 8.
Trisquel should not be password-protecting GRUB by default. It's a mostly useless security feature and causes confusion.
Everything else you experienced was probably inherited from upstream (Ubuntu). Fedora uses a different installer (Anaconda as opposed to Ubiquity), so that would be why Fedora detected Windows at the time of installation but Trisquel did not.
I do kind of agree that Anaconda is better than Ubiquity these days. But Canonical would be unlikely to switch to it, and it would be more effort than it's worth for Trisquel to do so when it's so much easier to just use what Ubuntu uses.
About two years ago i installed Xubuntu next to an old Windows system. No problem at all. Windows was detected and the few times i really wanted to get into it i wasn't asked a password. Doesn't that contradict the assumption it's a Ubuntu problem?
What i don't like in this matter is that since then i can't just simply replace the Xubuntu installation with another one. When i tried to install Trisquel i was only asked whether to wipe the disk or create a new partition.
The ubuntu release Trisquel 7 is based on is almost 5 years old, so no.
edit: got that wrong sorry
When you say "old Windows system", I assume you mean an older version of Windows than Windows 10, no? Ubuntu 14.04 was released in 2014. Windows 10 was released in 2015. It isn't surprising to me at all if the version of Ubiquity in Ubuntu 14.04, and thus Trisquel 7, is unable to detect Windows 10 properly. Allenitomwesh said specifically that it was Windows 10 that he had difficulty setting up dual-booting with.
So it is a default setting? That is absolutely unnecessary.
I agree. Even GRUB developers agree: https://www.gnu.org/software/grub/manual/grub.html#Security
By default, the boot loader interface is accessible to anyone with physical access to the console: anyone can select and edit any menu entry, and anyone can get direct access to a GRUB shell prompt. For most systems, this is reasonable since anyone with direct physical access has a variety of other ways to gain full access, and requiring authentication at the boot loader level would only serve to make it difficult to recover broken systems. However, in some environments, such as kiosks, it may be appropriate to lock down the boot loader to require authentication before performing certain operations.
Unfortunately, Trisquel has had a GRUB password by default since Trisquel 4.5 Slaine. Here is an old argument I had with Rúben (Trisquel's leader) back in 2011: https://trisquel.info/forum/how-come-trisquel-dont-have-recovery-mode
Since then, dozen of users on the forum (probably far more overall) have had to fight against this password: https://trisquel.info/search/node/01_password
I am a member!
I read the whole thread of your debate. Congratulations for hanging in there for what is right.
What I don't get is why a GRUB password can't be off by default? How does that lead to a user being able to log in straight as root without a password??? I don't know about you, but I do not have a GRUB password, but I do have a user password. If someone other than me boots my system, they don't have to put in a GRUB password, they are taken directly to the lightdm display manager to log in with a user password.
I'm sure I'm missing something, please explain.
What I don't get is why a GRUB password can't be off by default?
It can. I do not know if there even exists another distribution that sets a GRUB password by default.
How does that lead to a user being able to log in straight as root without a password??? (...) I do have a user password
Within GRUB, you can edit the options passed to the kernel. By adding "single", the kernel directly gives a root terminal. No password asked. That sometimes is useful. Consider, e.g., a system with one single user who forgot her password. She can redefine it with 'passwd' in the root terminal. Simple. In fact many distributions have "recovery mode menu entries" by default.
By default, Trisquel's GRUB asks for a password to do anything but boot one of the system with the default options. That make it difficult for beginners to solve problems such as the password issue mentioned above. And that is only an example. Another one is the use of memtest86+ to test the RAM. One cannot run it without the GRUB password or without disabling it. https://trisquel.info/search/node/01_password lists many other real examples.
That can look scary that anybody facing the GRUB menu can easily get a root terminal. But facing the GRUB menu means facing the physical computer. One cannot remotely interact with GRUB. And facing the physical computer usually means being able to boot a live system and read the GRUB password or simply 'chroot' into the installed system (i.e., get a root terminal in the installed system).
I wrote "usually" because encrypting the whole disk prevents that. And, in this case, the passphrase to read the disk is always asked, GRUB password or not. Encryption provides a real additional security... but a user who forgets the related passphrase is a user who has lost all her data forever!
Back to the absence of additional security with a GRUB password: quidam pointed out that the BIOS/EFI can be configured to not let the attacker boot a Live system (any recovery operation becomes even harder!). But, again: she is facing the computer. She can open the computer and take the disk home. Or the whole computer (especially if it is laptop).
Remain the cases where the computer by itself is not physically accessible. Only the screen, the keyboard and the mouse. Kiosks basically. Or the cases where the attacker is under enough "surveillance" to prevent her from opening/stealing the computer. Internet Cafés for example. In those cases, preventing the users from getting a GRUB Shell prompt makes sense. I do not think Trisquel mainly targets those rare contexts though. And, in those contexts, who installs the system should be skilled enough to know how to setup a GRUB password.
I am a member!
Thank you Magic, that was very clear.
I'm in complete agreement with you. Give me a petition and tell me where to sign! The illogic of it all is so strong I simply cannot understand why Trisquel's leader won't make the change and said the decision is "final". That is why I suggested the checkbox in the installer idea. Not because I think that is the best idea, or even a good idea, but because it is better than the current situation! I would much prefer the GRUB password being eliminated altogether.
Funny if, other than freedom respecting, the only other obvious difference between Trisquel and other distros is that Trisquel uses this GRUB password which has so far only inconvenienced a lot of new users.
Your comments also reminded me of something I read in a book on system administration, but applies in many areas of life. There is an inverse relationship between freedom and security. It pointed out that there are levels of computer security (the physical level is often the most neglected) and with each you need to decide if the trade-off with freedom is worth it. You could use all sorts of security on your home, put a moat around the house, land mines in the yard, an eyeball scanner, etc...:p but the one who will be most inconvenienced is the owner! Maybe it is called for if you are guarding the president in your home. Although even there, history has shown that even presidents aren't 100% safe, despite all of the security measures.
You take measures that are reasonable and appropriate to the situation; In our case a GRUB password is neither.
There is an inverse relationship between freedom and security.
What you call "freedom" actually is "convenience", in my opinion.
I am a member!
EDIT: I'll correct myself. I don't know if I should erase what is underneath, so I'll just include this edit.
You are right, the freedom in security/freedom is really convenience. I've made this point so many times to others, I don't know how I forgot it. According to rms, freedom is having control over one's own life. So if someone says, 'how free am I if I give up using my cell phone?' The best answer would explain the benefits of such a decision. From a linguistic point-of-view, however, there is no conflict. If you use your freedom of choice to not use a cell phone, you chose that freely so it isn't reducing your 'freedom', you are. If you don't want to do that, don't. In all these cases, freedom is convenience.
My analogy below with freedom of speech is faulty since that is something people have sacrificed their lives for--hardly a relevant place to talk about convenience.
That is the best I can do for now, but I welcome your critique either here or elsewhere. Regarding the issue of a GRUB password, I am repeatedly on the record saying I, like you, want it gone.
--------------------end of edit-------------------------
Give me an example of freedom that is not convenience. Take free speech. I think that is an example of freedom. One can argue it is an issue of convenience. It can be inconvenient to not be able to say what you want. It can be convenient to be able to say what you want.
But in any case, I was agreeing with you magic!
Freedom is being in control, not being restrained. For instance, free speech is about being able to express whatever you want. No restriction. In your house example, as long as its inhabitant *chooses* all the security measures, she is free. Those measures make her life less convenient but more secure.
In the case of GRUB, a password does not make the system more secure in most cases (but in the rare contexts I was discussing above). Only more inconvenient. But the user is free anyway. She is in control of her GRUB. She can disable the GRUB password. No restriction.
I am a member!
Also, why can't a GRUB password be an option given during installation. Check a box if you want it and vice-versa if you don't. My advice is make the default off. Explanation and/or advice can be offered, or given if a link is clicked. Even if the default is that it is on, at least the user has been warned of, or alerted to, this feature.
To not do at least this is hostile to most Trisquel users and contrary to Trisquel's mission.
An additional box in the installer is an additional complexity. Like I wrote above: in the rare contexts where a GRUB password makes sense, who installs the system should be skilled enough to know how to setup a GRUB password. She needs no check box.
To not do at least this is hostile to most Trisquel users and contrary to Trisquel's mission.
Well, "hostile" is a strong word. Let us say that, in this case, Trisquel makes it difficult to recover broken systems. For no good reason.
> If someone wants to dual boot just let them. For a distro that is supposed to be giving users freedom this whole debacle feels highly restrictive.
That is no policy decision but a simple bug.
That's been around since Trisquel 4? Feels ddeliberate to me.
I'm not talking about the password but the windoze 10 detection.
I think both should be attended to immediately for Trisquel 8. There's no reason it should frustrate users. I genuinely thought Trisquel wrongly wiped Windows and was cursing it.
I am a member!
I shared your frustration at least twice. It is so stupid I forgot the solution and went through it all a second time!
I also agree that we should fix this.
However, one observation I'll make is that you were able to see Windows from Trisquel, but not the other way around. Why is that? It is because MS goes out of its way to make your dual boot difficult. GNU/Linux is flexible, it can coexist with Windows. Either MS is too inept to do the same, or they deliberately try to sabotage efforts to put other OSes next to Windows. In the past, the dual boot was no problem, but Windows still didn't recognize the GNU/Linux partition. The standard line was "Windows doesn't play well with others". You could access all files in GNU/Linux but only Windows files in Windows. Windows didn't even recognize the GNU/Linux partition. It ignores its existence!
Windows typically acts like ext4 isn't a partition. A flash drive in ext4 won't be detected by windows. Ext4 isn't an option when formatting drives using the built in windows tool. They play dirty, but its Microsoft, they've always been shady. Windows media player doesn't support FLAC or ogg. These are open formats so supporting them is trivial. But it's competing with WMA,so nope.
Again, please remember that Windows 10 came out much later than Ubuntu 14.04, the version of Ubuntu that Trisquel 7 is based on. So it's almost certainly an upstream shortcoming which is completely understandable; after all, it must be harder to tell that an OS is already installed when you aren't even aware of the existence of the OS. I say this not knowing how Ubiquity detects other systems, of course. But I see no reason to expect this same shortcoming to exist in the version of Ubiquity included in Ubuntu 16.04.
Ubuntu 14.04.4 doesn't have this issue. Of course, the Trisquel 7 ISO is horribly outdated and that's why some of us have asked for a refresh of the ISO (Trisquel 7.1). Nothing happened.
- Login o registrati per inviare commenti