What is something *new* you have learned about Linux within the past 7 days?
Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I learned that systemd has replaced init, since I last used Linux around 19 years ago.
I also learned that this was apparently very controversial and there is even a Debian fork because 'systemd' is bad.
As I user I just noticed that my mount points, USB, etc all gets reconnected automatically when I restart my laptop. It seems to work. I don't recall it being this easy 20 years ago!
Not with an EFI setup, it is BIOS only bootloader. And there is something new I learn for this week, elilo and using a stub in your EFI to just boot a kernel without any grub they say.
I really like elilo. It has been deliberately designed to have the same configuration interface as lilo although it is quite different inside. It isn't being maintained any more, but it's so simple that it really doesn't need any maintenance.
Using efistubs sounds like an ideal method for a single boot. jsbjsb001 put a bit about it into his kernel wiki article, based on what Emerson told him. But for multiboot it's not so good because you have to go into the UEFI to get your menu and that means pressing a magic key at exactly the right moment.
By "i386 only" do you mean it only works on IBM PC type computers? Because it definitely works on Archlinux, which is a 64 bit distro.
I suspect the Debian wiki is outdated, rather than the bootloader(s). Or you just misunderstood.
I was just going by the wording of it, they state i386 & amd64 at the top for those listed underneath, then when they get to it just the i386, the table at the very top does say both with EFI for it. Now I re-read to make certain of where I got that impression.
I really like elilo. It has been deliberately designed to have the same configuration interface as lilo although it is quite different inside. It isn't being maintained any more, but it's so simple that it really doesn't need any maintenance.
Using efistubs sounds like an ideal method for a single boot. jsbjsb001 put a bit about it into his kernel wiki article, based on what Emerson told him. But for multiboot it's not so good because you have to go into the UEFI to get your menu and that means pressing a magic key at exactly the right moment.
No key press is need, first drive in system, first fat partition on that drive containing a valid EFI boot loader will load by default. If Grub then you get your menu if it is enabled, if windows well it just loads, they do not care about other OSs. At least that is how my firmware works with the drives in the machine, if I want to boot anything different then I need to hit the F12 key to get the boot picker where I see my first drive listed at the top of the list as the default..
Edit: The first fat partition marked as type "EFI System Partition" will load a boot loader contained in its EFI directory, either in /boot or /distribution_name directory name, without that nothing. I learned way more than I ever wanted trying to get that GRUB to install to my /dev/sda and not clobber my /dev/nvme drive despite being told in the installer the /dev/sda was the place. The nvme is seen as first drive in the system, repaired its boot loader couple of times before I clued in and removed it to allow GRUB to do the job it should have been doing. It is so wonderful when Linux becomes the Microsoft of the computer world...
No key press is need, first drive in system, first fat partition on that drive containing a valid EFI boot loader will load by default. If Grub then you get your menu if it is enabled, if windows well it just loads, they do not care about other OSs. At least that is how my firmware works with the drives in the machine, if I want to boot anything different then I need to hit the F12 key to get the boot picker where I see my first drive listed at the top of the list as the default..
My situation is that I have three different Linux systems on one hard drive (no Windows, thank God!). So I need a boot menu to pick a system from. That's elilo in my case, but it could equally be GRUB or rEFInd or syslinux. In fact I did use rEFInd for a while. Or I could use the magic key to get the UEFI's built-in menu. But I can't just use efistubs because all that does is to make an individual kernel efi-bootable; it doesn't tell the hardware which kernel to boot.
My situation is that I have three different Linux systems on one hard drive (no Windows, thank God!). So I need a boot menu to pick a system from. That's elilo in my case, but it could equally be GRUB or rEFInd or syslinux. In fact I did use rEFInd for a while. Or I could use the magic key to get the UEFI's built-in menu. But I can't just use efistubs because all that does is to make an individual kernel efi-bootable; it doesn't tell the hardware which kernel to boot.
Definitely limitations to it for a boot method like all of them. They each have their quirks. It would be nice for GRUB not to fail when drive that is not part of the selected option to boot is not present. That one drives me completely batty and is good part of reason I dislike it so much. Its inflexible nature everything needs to be in place in the unused parts for it to boot too. Makes no sense whatsoever if the drive is not used for the booting why the failure. The editing of the files to do a no other drive scan or disconnecting the drive so it does not find it is windows behaviour, the I will clobber your boot partition if I damn well want to attitude...
Distribution: Currently: OpenMandriva. Previously: openSUSE, PCLinuxOS, CentOS, among others over the years.
Posts: 3,881
Rep:
Quote:
Originally Posted by hazel
...Using efistubs sounds like an ideal method for a single boot.
Like Emerson said in the building the kernel wiki article working thread in the kernel forum; if you roll your own kernel, using a bootloader loses it's advantage.
Quote:
jsbjsb001 put a bit about it into his kernel wiki article, based on what Emerson told him.
...
It wasn't just what Emerson said, yes they did indeed suggest putting it in the article, and their posts were very helpful; but it was from a number of posts (including one or two of yours) in the same thread mentioned above, as well as both the Arch Linux wiki and Gentoo wiki that helped me figure it out (and learnt a few things about UEFI in general that I didn't really know before) - particularly the bit about using efibootmgr to add entries to the UEFI boot menu.
Although, if Jeremy had named the title of this thread better by not including a 7 day time limit; I could say that's something else I learnt about Linux, in that you can boot the kernel directly from UEFI without needing a bootloader, but anyway...
@HappyTux
the [ ] are wildcards for filename generation in the shell, just like * and ?
If not escaped, and if there is a file named top in the current directory, the shell will substitute [t]op with the matching top, and again the grep can be found.
Correct are
I noticed that traffic shaping with GNU/Linux is done by a combination of nft (or iptables) plus tc, and that the latter is very, very complex especially compared to PF.
I discovered something slightly weird (entirely by accident). If you remove a partition using something like cfdisk and then create a new partition in the same space, it isn't empty. The filesystem that was on the old partition is still there on the new one. The only way to get rid of that old data is to reformat the partition with a suitable version of mkfs.
I assume from this that partition editors only edit the partition table and don't do anything to the disk surface.
I discovered something slightly weird (entirely by accident). If you remove a partition using something like cfdisk and then create a new partition in the same space, it isn't empty. The filesystem that was on the old partition is still there on the new one. The only way to get rid of that old data is to reformat the partition with a suitable version of mkfs.
I assume from this that partition editors only edit the partition table and don't do anything to the disk surface.
That is correct. A partition is just a container for a filesystem that basically define its location and size. You can resize a filesystem as well as the partition independently of each other which if not careful can lead to data loss.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.