| View previous topic :: View next topic |
| Author |
Message |
leyvi
Apprentice
Joined: 08 Sep 2023
Posts: 289
|
 Posted: Thu Mar 27, 2025 11:39 pm Post subject: dm-crypt woes |
 |
|
Good grief, where do I start on this one 
I tried to make a "Swiss-army-knife" Gentoo install on a high-speed USB stick (USB-C 3.2). The idea was that I'd make it super secure, so that I could even run it on untrusted hardware, on untrusted networks, etc. As such, I did the following:- Made an ESP, FAT32, with shimx64.efi, mmx64.efi, and grubx64.efi, as well as a grub.cfg, all in the directory \EFI\gentoo
- A boot partition, encrypted with cryptsetup/device-mapper (password protected), formatted with ext4, containing vmlinuz and initramfs-6.14.0-gentoo.efi
- A root filesystem, also encrypted using cryptsetup/device-mapper, using a keyfile stored in the initramfs, and also on this same root filesystem, for future kernel versions
I built all the drivers necessary for booting directly into the kernel, and compiled everything else as a signed, compressed module. Initramfs was made with dracut, and contained kernel arguments telling it how to decrypt my root filesystem, and where to find the keyfile:
| Output of `bat /mnt/gentoo/etc/dracut.conf.d/*`: | compress="lz4"
do_strip="no"
drivers_dir="/lib/modules/6.14.0-gentoov1/"
install_items+=" /root/rootfs_keyfile "
kernel_cmdline="root=/dev/mapper/usb_rootfs cryptdevice=PARTUUID=3afd50e4-bca2-4c7f-90e1-0f5825dcd2ba:usb_rootfs:rw cryptkey=rootfs:rootfs_keyfile crypto=sha256:aes-xts-plain64:0:0 " |
Now what's the problem with all this, you might ask?- EFI firmware doesn't find shim, I'm using a VM to test it (with USB passthrough), so it drops me into an EFI shell.
- If I manually locate and execute the shim from the EFI shell, it loads GRUB. But GRUB does not show the kernel I configured, so I have to drop into a GRUB shell for the next part.
- If, in the GRUB shell, I manually locate the boot partition, GRUB will fail to decrypt it, since the secureboot signed GRUB image doesn't come with the necessary modules.
- If I instead use a different, non-secure GRUB install, with the appropriate modules loaded, it successfully decrypts the boot partition (with the correct password of course), and I can use the `linux` and `initrd` commands to set the kernel file and initramfs files, and use `boot` to boot with it. Except it doesn't; GRUB hangs there, and doesn't give any useful output.
I am lost; help me! |
|
| Back to top |
|
 |
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3583
|
| Posted: Fri Mar 28, 2025 1:29 am Post subject: |
|
|
| Quote: |
install on a high-speed USB stick (...) I'd make it super secure, so that I could even run it on untrusted hardware
(...)
EFI firmware doesn't find shim, |
Shim is the thing used for secure boot, right? So... You want to use secure boot on an untrusted hardware? How is it supposed to work?
Secure boot prevents your laptop from running modified code. It doesn't prevent the modified code on your stick from being run.
I think this whole idea falls apart right at the word "USB".
_________________
Make Computing Fun Again |
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5537
Location: Bavaria
|
| Posted: Fri Mar 28, 2025 1:31 am Post subject: Re: dm-crypt woes |
|
|
| leyvi wrote: | | [...] I am lost; help me! |
I am paranoid about IT security ... so maybe I can help you. First I have a question because I am not sure if I have understood it correctly -> Do you want:
1) A bootable USB stick ON which the root filesystem is also on (on a second partition), OR
2) A bootable USB stick that THEN boots to the root filesystem of the hard disk ?
If it is number 1, a second question: Why do you want to encrypt this root filesystem (on the USB stick) ? What is the point? You should know that AFTER the boot process the complete root filesystem is readable - and writeable - for your kernel (it has to be, otherwise you couldn't start it) ... and so everything can access it. Additional question: Should this stick be able to boot different PCs (AMD, Intel, ...) or only one specific one?
If it's number 2, I'll give you a link later ... but first my advice on how you should proceed:
Think about what dangers your system is exposed to (that's the threat analysis). Then think (maybe together with us here) about what you could do about it. Unfortunately, many users have a wrong understanding of IT security and especially about encryption. Encryption sounds cool, but is actually “only” there to protect data from prying eyes. It does not make a system more secure against hacking. For that, you need completely different things, such as a hardened kernel, a system that offers MAC (SELinux or AppArmor), integrity management, a firewall or even several firewalls (network-based and application-based firewalls), proxy servers ... and even then there is no 100% security, because you have no access to the microcode of your CPU, no access to the software in your ethernet card ... and even a hardened kernel can still contain a zero-day vulnerability.
So what do I recommend: First of all, you should be interested in a hardened kernel. You can always boot a Linux kernel directly from a USB stick (without grub) if you ...
| leyvi wrote: | | EFI firmware doesn't find shim, [...] |
This is because UEFI - for devices that are not permanently connected (=USB stick) - only searches for a single file: bootx64.efi (and not shimx64.efi). If you want to boot from a USB stick, you don't need all that crap (shim, grub). All you need is a kernel that has everything it needs and a root filesystem with the init system of your choice (OpenRC or systemd) and all the applications you want.
... rename this kernel to bootx64.efi
If you boot from a stick, the root filesystem does not need to be encrypted ... because that would not help you at all. You also don't need signed modules IF you just build everything into your kernel statically (I also have such a monolithic kernel). You don't even need an initramfs IF you want to boot the kernel from a usb stick AND access an encrypted root filesystem ... the kernel can do that without ... here is the promised link: https://forums.gentoo.org/viewtopic-t-1110764-highlight-.html
BUT... before you tackle this, talk to us about your threat scenario... and first learn how to configure a kernel yourself (without all that automagic crap). The advantage if you do something manually is that you understand what happens ... and then you can still use automatisms.
To say it clear: I dont think you will need this description ... I only want to show what is possible.
In this (german) post I described how to boot (only) a kernel (if you have already one) from an USB-stick:
https://forums.gentoo.org/viewtopic-t-1122548.html
->
| Code: | - connect your USB stick
# lsblk
! check if /dev/sdb is really your stick; (probably it is /dev/sdc or /sdd if you have more than one hd or ssd; then use this instead of sdb1 in the next command)
# parted -a optimal /dev/sdb
> mklabel gpt
> unit mib
> mkpart primary 1 128
! setting "boot on" is important to get the ESP flag for this partition, so UEFI can find the kernel in it
> set 1 boot on
> q
# mkfs.fat -F 32 /dev/sdb1
# mkdir -p /mnt/stick
! again: check if sdb1 is correct for you
# mount -t vfat /dev/sdb1 /mnt/stick
# mkdir -p /mnt/stick/EFI/BOOT
# cd /usr/src/linux
! If you have done B.3 SecureBoot use this to copy your kernel
# sbsign --key /mnt/tmp/efikeys/DB.key --cert /mnt/tmp/efikeys/DB.crt --output /mnt/stick/EFI/BOOT/bootx64.efi arch/x86/boot/bzImage
(! OR - without SecureBoot - use this to copy)
(# cp arch/x86/boot/bzImage /mnt/stick/EFI/BOOT/bootx64.efi)
# umount /mnt/stick |
_________________
https://wiki.gentoo.org/wiki/User:Pietinger |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 55102
Location: 56N 3W
|
| Posted: Fri Mar 28, 2025 10:41 am Post subject: |
|
|
leyvi,
Encryption protects data at rest.
At rest the USB stick will be in your pocket, so what is the purpose of the encryption?
At most, you only need protect /home but its a toolkit, not a working system, so why?
If you can boot your USB stick on a system with secure boot enabled, the system admin should be fired.
That's exactly what secure boot is supposed to prevent.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
leyvi
Apprentice
Joined: 08 Sep 2023
Posts: 289
|
| Posted: Fri Mar 28, 2025 11:49 am Post subject: |
|
|
I forgot to clarify a few things:
| NeddySeagoon wrote: | | At rest the USB stick will be in your pocket, so what is the purpose of the encryption? |
It's not just a toolkit; it's also a thin-client for my main machine at home. It has (or will have) and SSH key that I can use to securely remote in. It will also have waypipe, so that I can access it graphically as well.
| NeddySeagoon wrote: | If you can boot your USB stick on a system with secure boot enabled, the system admin should be fired.
That's exactly what secure boot is supposed to prevent. |
Maybe I misunderstood what secure boot was for, then 
I thought it also prevented tampering with the bootloader; not sure why I thought that. Maybe there's a way to do that? I don't want someone modifying the bootloader when I'm not looking, installing a keylogger, and finding my boot partition's password.
In any case, shim is signed by Microsoft, so it should boot with secure boot enabled on any Windows PC, from my understanding. Then it loads GRUB (which it did, albeit on a VM with no secure boot). |
|
| Back to top |
|
|
leyvi
Apprentice
Joined: 08 Sep 2023
Posts: 289
|
| Posted: Fri Mar 28, 2025 11:52 am Post subject: |
|
|
| szatox wrote: | | I think this whole idea falls apart right at the word "USB". |
Possibly. I wanted to try anyway. |
|
| Back to top |
|
|
leyvi
Apprentice
Joined: 08 Sep 2023
Posts: 289
|
| Posted: Fri Mar 28, 2025 12:20 pm Post subject: |
|
|
| pietinger wrote: | I am paranoid about IT security ... so maybe I can help you. First I have a question because I am not sure if I have understood it correctly -> Do you want:
1) A bootable USB stick ON which the root filesystem is also on (on a second partition), OR
2) A bootable USB stick that THEN boots to the root filesystem of the hard disk ? |
Everything is on the USB stick. The ESP, the boot partition, and the root filesystem.
| pietinger wrote: | | If it is number 1, a second question: Why do you want to encrypt this root filesystem (on the USB stick) ? What is the point? You should know that AFTER the boot process the complete root filesystem is readable - and writeable - for your kernel (it has to be, otherwise you couldn't start it) ... and so everything can access it. Additional question: Should this stick be able to boot different PCs (AMD, Intel, ...) or only one specific one? |
The point of encrypting is simple:- I have SSH keys on there that need to be kept secure.
- I don't do anything illegal (except media piracy, which is a legal grey area where I live), but I still don't feel comfortable being spied on.
- Using Gentoo has already put me on a government list (the government told me so), so they might actually take interest in me at some point.
Also: I selected as many kernel hardening options as I could find, except struct layout randomization, which I thought would make my system unbearably slow. SELinux and AppArmor modules are both built-in, and Netfilter/IPTables are signed modules. I want this to run everywhere (AMD64/x86-64), so I built the kernel for generic x86-64, and @world with all the relevant flags set to something like this: `-march=x86-64 -mtune=generic -O3 -pipe`. When I get the chance, I will configure firewalld and SELinux as soon as I can, though I need a portable network stack first. All my networking drivers are modules (at least the ones with that option). I have built modules for almost every networking device under the sun, and the same goes for audio, graphics, etc all modules.
| pietinger wrote: | | ... rename this kernel to bootx64.efi |
Could I just make a hard link?
| pietinger wrote: | | You also don't need signed modules IF you just build everything into your kernel statically (I also have such a monolithic kernel). |
So do I, but I have 64GiB of RAM, and a high-speed NVMe storage device. My USB, as fast as it might be, is comparatively slow, and I'd like this to boot as fast as possible, and also the systems I boot on (mostly school computers) only have 4GiB-16GiB of RAM. And I still need to run almost everywhere, so I need lots of modules. If I don't want the kernel to hog all the RAM, I need lots of modules.
| pietinger wrote: | | BUT... before you tackle this, talk to us about your threat scenario... and first learn how to configure a kernel yourself (without all that automagic crap). The advantage if you do something manually is that you understand what happens ... and then you can still use automatisms. |
I actually configured this kernel (and all kernels I have ever used) with `make menuconfig`. |
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5537
Location: Bavaria
|
| Posted: Fri Mar 28, 2025 1:44 pm Post subject: |
|
|
| leyvi wrote: | | pietinger wrote: | | ... rename this kernel to bootx64.efi |
Could I just make a hard link? |
No. The ESP is formatted with a FAT variant (FAT does not support hardlinks).
| leyvi wrote: | | The point of encrypting is simple: [...] I have SSH keys on there that need to be kept secure. |
Does this mean that you want to hand the usb stick over to others?
| leyvi wrote: | | SELinux and AppArmor modules are both built-in [...] |
That is pointless ... because ... You can only use one of them - they are mutually exclusive.
| leyvi wrote: | | [...] I will configure firewalld [...] |
Configure the FW yourself with iptables or nftables and do not rely on any generators. Also learn what a FW can and especially what it CANNOT do - sometimes a FW can only warn you but not prevent something; therefore the most important thing with a FW is logging.
_________________
https://wiki.gentoo.org/wiki/User:Pietinger |
|
| Back to top |
|
|
leyvi
Apprentice
Joined: 08 Sep 2023
Posts: 289
|
| Posted: Fri Mar 28, 2025 1:54 pm Post subject: |
|
|
| pietinger wrote: | | No. The ESP is formatted with a FAT variant (FAT does not support hardlinks). |
Got it.
| pietinger wrote: | | Does this mean that you want to hand the usb stick over to others? |
Not at all. I want to use it as a thin-client to remote into my main desktop at home.
| pietinger wrote: | | That is pointless ... because ... You can only use one of them - they are mutually exclusive. |
Right. I don't have a lot of experience with those things, so I guess I'll go with SELinux (it seems to be more popular) but I'll need to look into it.
| pietinger wrote: | | Configure the FW yourself with iptables or nftables and do not rely on any generators. Also learn what a FW can and especially what it CANNOT do - sometimes a FW can only warn you but not prevent something; therefore the most important thing with a FW is logging. |
I use firewalld on my home machine with the nftables backend. It has served me well. Why wouldn't I use it here? From my understanding, firewalld is good enough for web servers... |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 23280
|
| Posted: Fri Mar 28, 2025 2:20 pm Post subject: |
|
|
Secure Boot is intended to prevent the system from booting media that has an unexpected/unauthorized bootloader on it. If an attacker mangles your boot loader, your Secure Boot enabled system will deliberately fail to boot from the modified bootloader, rather than letting you use it and think everything is fine. It does nothing to prevent the modification to the bootloader. For that, you want hardware-enforced read-only mode, so that the system cannot write to the USB device, at all. That solves one problem. Another problem is whether you trust the hardware not to copy your data to its internal storage for someone to retrieve later. In the general case, that's not very likely, but it's not impossible. Guarding against that is fairly easy: you want a hardware-enforced no-access mode, which can be conveniently implemented by not connecting your USB stick to untrusted hardware.  An air gap works wonders for keeping the adversary from interacting with your USB stick. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 55102
Location: 56N 3W
|
| Posted: Fri Mar 28, 2025 3:32 pm Post subject: |
|
|
leyvi,
Once upon a time :) the ::gentoo repo had a ssh password program with the interesting property that each password could be used at most one time.
That may be more suited to your problem than carrying encrypted ssh keys.
Or maybe consider a hardware token, like Nitrokey.
You will decrypt the system and leave it unattended. Oops.
Then there is the attack of reboot and dump RAM for later analysis.
Most of RAM will survive a reboot like that.
When you say school, if you mean high school, thats the worst set of hackers you can expose your system to.
They know no fear and will try anything. If you mean Uni, the students will have grown up a bit by then.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
leyvi
Apprentice
Joined: 08 Sep 2023
Posts: 289
|
| Posted: Sat Mar 29, 2025 5:23 pm Post subject: |
|
|
| Hu wrote: | | Secure Boot is intended to prevent the system from booting media that has an unexpected/unauthorized bootloader on it. If an attacker mangles your boot loader, your Secure Boot enabled system will deliberately fail to boot from the modified bootloader, rather than letting you use it and think everything is fine. It does nothing to prevent the modification to the bootloader. For that, you want hardware-enforced read-only mode, so that the system cannot write to the USB device, at all. That solves one problem. Another problem is whether you trust the hardware not to copy your data to its internal storage for someone to retrieve later. In the general case, that's not very likely, but it's not impossible. Guarding against that is fairly easy: you want a hardware-enforced no-access mode, which can be conveniently implemented by not connecting your USB stick to untrusted hardware. An air gap works wonders for keeping the adversary from interacting with your USB stick. |
Ah, I think I understand now, thanks. What is hardware-enforced read-only mode? I'm not so concerned with encrypted partitions being copied, for obvious reasons. RAM is a much bigger concern...
Also, about the threat model:
I'm in 12th grade. Last year's 12th graders had a bit of a "cybersecurity incident" where one of them used all of the school computers to DDoS the ministry of education's website, internal network, etc. Why? It is not clear to me, nor is it clear what they did with him. But I do know that afterwards, the ministry of education contracted an IT firm to rework the school's networking infrastructure: new switches, firewalls, routers, etc. I imagine that they also installed a considerable amount of network monitoring tools, given how easy that is. It is unclear to me if they modified the school computers themselves, though considering the amount of work that would take (my school has hundreds of Lenovo all-in-ones, very hard to modify), I highly doubt they did. |
|
| Back to top |
|
|
leyvi
Apprentice
Joined: 08 Sep 2023
Posts: 289
|
| Posted: Sat Mar 29, 2025 5:33 pm Post subject: |
|
|
| NeddySeagoon wrote: | Once upon a time the ::gentoo repo had a ssh password program with the interesting property that each password could be used at most one time.
That may be more suited to your problem than carrying encrypted ssh keys. |
OK, that's interesting. Where might I find this legendary piece of software?
| NeddySeagoon wrote: | Then there is the attack of reboot and dump RAM for later analysis.
Most of RAM will survive a reboot like that. |
Yeah, in theory this would be one of my biggest concerns. However, I think it's unlikely. Even so: would encrypted RAM solve this issue? I know AMD has something like that, and I imagine that Intel does as well. I just don't know if it's available on consumer hardware...
| NeddySeagoon wrote: | When you say school, if you mean high school, thats the worst set of hackers you can expose your system to.
They know no fear and will try anything. |
Yes, indeed. They're usually to broke for any fancy hardware, like DMA cards, etc. But using software tools? They are terrifying (I should know, I'm one of them ). See my earlier post about last year's rouge 12th grade hacker. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 55102
Location: 56N 3W
|
| Posted: Sat Mar 29, 2025 5:54 pm Post subject: |
|
|
leyvi,
I couldn't remember the name so I had to ransack the internet.
| Code: |
* sys-auth/skey
Available versions: 1.1.5-r14 {split-usr static-libs}
Homepage: https://web.archive.org/web/20160710152027/http://www.openbsd.org:80/faq/faq8.html#SKey
Description: Linux Port of OpenBSD Single-key Password System |
You really don't want your decrypted keys exposed to untrusted hardware.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
leyvi
Apprentice
Joined: 08 Sep 2023
Posts: 289
|
| Posted: Sat Mar 29, 2025 6:09 pm Post subject: |
|
|
| NeddySeagoon wrote: | | You really don't want your decrypted keys exposed to untrusted hardware. |
Indeed. |
|
| Back to top |
|
|
leyvi
Apprentice
Joined: 08 Sep 2023
Posts: 289
|
| Posted: Sat Mar 29, 2025 6:11 pm Post subject: |
|
|
| NeddySeagoon wrote: | | I couldn't remember the name so I had to ransack the internet. |
Sorry, I just didn't know what I was looking for. |
|
| Back to top |
|
|
leyvi
Apprentice
Joined: 08 Sep 2023
Posts: 289
|
| Posted: Sat Mar 29, 2025 6:14 pm Post subject: |
|
|
To clarify:
A regular Gentoo install on a USB stick will do. No secure-boot, no encrypted partitions; just a different SSH authentication mechanism, along with some hardening options like SELinux, a firewall, etc? |
|
| Back to top |
|
|
pingtoo
Veteran
Joined: 10 Sep 2021
Posts: 1584
Location: Richmond Hill, Canada
|
| Posted: Sat Mar 29, 2025 7:00 pm Post subject: |
|
|
May be you can consider tiny core linux(note it is unsecured http connection). Try it out and get familiar with it. And later once you are comfortable with Linux with general concept of booting, network security and system administration then you could consider how to build a tiny core alike system using Gentoo.
It is one that match your desire to use USB pen device for remote access. |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3583
|
| Posted: Sat Mar 29, 2025 7:14 pm Post subject: |
|
|
So that's why the government told you you're on the list 
About the network: school is not very likely to hack into your own device/system. If you expose any services and someone connects to them, that's entirely on you.
However, even encrypted connections have endpoints, which reveals what you connect to. On top of that, some firewalls can do Deep Packet Inspection, which is capable of identifying different types of traffic, even if it's encrypted. Finally, there is stuff like mitmproxy, which attempts to bump encrypted connections.
Now, if you run your own OS instead of school-provided one, it _should_ not accept the certificate provided by the attacker, but since you're dealing with a government entity which already had a reason to get a closer look at the place you're in, it might be possible that they somehow got their hands on a valid intermediate CA cert. That's where HPKP comes in handy. Except that basically nobody deploys is, so you need to check server certificates yourself if you want to be sure nobody listens in on you... Or tunnel the traffic outside first. SSH can act as a SOCKS proxy, so you can e.g route your traffic through your home or a VPS.
BTW, encrypted stick is not a bad idea. It will keep your files save in case you lose it. But "secure boot" is for protecting the computer from you, not the other way around.
_________________
Make Computing Fun Again |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 55102
Location: 56N 3W
|
| Posted: Sat Mar 29, 2025 7:20 pm Post subject: |
|
|
szatox,
A government would deploy the $5 wrench attack.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3583
|
| Posted: Sat Mar 29, 2025 8:28 pm Post subject: |
|
|
Sure, if they target you specifically, yes, absolutely. If they fish for anything that's in the air, not necessarily. Planting a MITM and DPI firewall in a network you control is easy enough, attracts far less unwanted attention, and is way easier to excuse.
Because OBVIOUSLY we have to protect those dumb kids from their own stupidity, right? Right?
_________________
Make Computing Fun Again |
|
| Back to top |
|
|
leyvi
Apprentice
Joined: 08 Sep 2023
Posts: 289
|
| Posted: Sat Mar 29, 2025 8:48 pm Post subject: |
|
|
| NeddySeagoon wrote: | szatox,
A government would deploy the $5 wrench attack. |
My government? In the case of terrorism or organized crime, absolutely. No question. Not a moment of hesitation. Against high-school students? Highly unlikely, especially in my case. What I'm doing is highly sketchy, but totally legal. |
|
| Back to top |
|
|
leyvi
Apprentice
Joined: 08 Sep 2023
Posts: 289
|
| Posted: Sat Mar 29, 2025 9:52 pm Post subject: |
|
|
| szatox wrote: | | So that's why the government told you you're on the list |
Yes and no. I've been told my name is on multiple watch-lists, for things involving computers. But I've never committed any crimes (except small-scale personal media piracy, and this one time I took down someone's web server, but it was by mistake and they let me off the hook [I know them personally]. They were giving out a password to the system, had a telnet server there, and had sudo installed. You can see how that might cause problems, especially since I was 15-16 years old [and quite stupid, I should add] and had never seen Debian before). In any case, the government is definitely aware I exist, and knows that I could do some pretty destructive stuff if I really wanted to, and my government is the type to spy on people speculatively. Thus, I am quite paranoid. |
|
| Back to top |
|
|
leyvi
Apprentice
Joined: 08 Sep 2023
Posts: 289
|
| Posted: Sun Mar 30, 2025 9:32 am Post subject: |
|
|
In any case:
I am curious to know why my system isn't booting (after the GRUB step). Why does it hang? I'm guessing there's an issue with my `dracut` configuration; you can see it in my first post on this thread. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 55102
Location: 56N 3W
|
| Posted: Sun Mar 30, 2025 12:45 pm Post subject: |
|
|
leyvi,
Root on USB can be a problem. The kernel normally mounts root before it starts USB, thus root on USB usually fails.
You need rootdelay or rootwait on the kernel command line to avoid the panic. In fact, that won't fix it for you as you have an initrd and the delay will be applied to that, which is not what you want.
Your initrd needs to ensure that USB is started and the root device is visible in /dev before it does anything with it.
You should see the panic but you don't report that. Just nothing after grub.
What console driver are you trying to use?
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Kernel & Hardware
